Beschrijving
Alvorens Referentie Architectuur, is het beter om een idee over software architectuur hebben. Software architectuur heeft verschillende definities die zijn afgeleid van verschillende bronnen. Het varieert van het ontwerpen, het creëren en onderhouden van de code van grote computersystemen waarin de werking van de fysieke en logische componenten van bedrijfssystemen en. Het is een combinatie en interactie van alle componenten (software en hardware) een compleet systeem specifiek voor de verschillende behoeften van het bedrijfsleven te maken.
De Referentie Architectuur en Fit / Gap-analyse is een kort document waarin de Referentie Architectuur moet worden gebruikt als basis voor de architectuur van het huidige project en inbegrip van de beweegredenen voor dit besluit. Het is ook een analyseproces van de referentie architectuur en de uitvoering begrijpen.
Een Referentie Architectuur is een vooraf gedefinieerde architectonische patroon ontworpen voor gebruik in het bijzonder bedrijfs-en technische contexten.
Bron van Reference Architectures binnen een organisatie kan iedere bewezen kader en actief wordt gebruikt in eerdere projecten zijn. Het werk product is generiek en geldt evenzeer voor selectie van Reference Architectures uit andere bronnen.
Het belangrijkste onderdeel van een Referentie Architectuur is om de fitness en hiaten gevonden tijdens de analyse begrijpen.
Een Referentie Architectuur Fit / Gap Analyse tabulates de belangrijkste factoren die betrokken zijn bij het selecteren van een Referentie Architectuur:
- Business scenario's
- Business drivers
- Architectuur kenmerken
Asset selection involves tradeoffs. Reference Architecture Fit/Gap Analysis documents the differences between the desired project architecture and the reference architecture in a statement-of-fit and identifies modifications required for the project.
Doel
Laten we nu de toepassing Fit / Gap analyse in Referentie Architectuur model controleren. De Referentie Architectuur Fit / Gap-analyse worden gebruikt voor de volgende
- Om te helpen bij het bepalen van de scope van een voorgestelde oplossing ontwikkelingsproject
- As an input to other architecture work products. Depending on the size of the gaps, de gekozen Referentie Architectuur en bijbehorende fit / gap analyse kan de basis vormen voor de gehele architectuur vormen.
- To highlight any gaps where the Reference Architecture does not fit project requirements. These indicate areas of risk or substantial architectural work required in the project. Het helpt ook om de referentie-architectuur voor het voorgestelde project te selecteren.
Gevolgen van het niet hebben Referentie Architectuur
Het selecteren van een Referentie Architectuur vermindert het risico door hergebruik van beproefde, best-practice solutions. Not applying a standard Reference Architecture increases project effort and cost, en verhoogt het risico van mislukking project.
The best way to use architectural assets is to start by selecting a Reference Architecture. This will form the context for a more detailed selection of assets and guidance.
Redenen voor het niet gebruiken Referentie Architectuur
Op activa gebaseerde projecten, Dit product moet altijd worden geproduceerd.
Indien nodig Reference Architectures zijn niet beschikbaar voor een project of een project besluit een Referentie Architectuur gebruiken, dan hooguit de samenvatting, inbegrip van de redenen waarom een Referentie Architectuur niet werd geselecteerd, should be completed. Often even this is unnecessary. A note can be added to the documentation of the choice of work products.
Hoe Fit / Gap analyse wordt gedocumenteerd
Een Referentie Architectuur Fit / Gap-analyse is in principe tekstuele document, met tafels de beoordeling van de eisen karakteristieke profiel en onder dekking. De tabelvorm beschrijft alle benodigde punten om een duidelijk beeld van de genoemde architectuur en haar conditie te krijgen in het voorgestelde project.
Samenvatting: Korte uiteenzetting van geselecteerde Referentie Architectuur en alle belangrijke vraagstukken / risico.
Introductie: Inleidende opmerkingen over de referentiearchitectuur.
Key Drivers: Een korte verklaring van de zakelijke doelstellingen of beperkingen.
Architecture Requirements Checklist: Het document bestaat uit een standaard set van vragen en mogelijke antwoorden met betrekking tot architectonische eisen, which allows a systematic collection of the architectural requirements for the project. This set is used as a checklist to prompt for customer architectural requirements and associated issues, die zijn gedocumenteerd in een tabel, zoals hieronder. Dit is een voorbeeld tafel en het kan zijn van een ander formaat volgens de standaard van de organisatie.
| Eis | Referentie Architectuur Kenmerk | Vereist Waar voor Project | Risico's / Problemen / Reacties Punten om te onderzoeken |
| Naam eis | Relevante bereik van waarden voor deze architectuur | Bereik voor de klant | Eventuele lacunes, risico's, waarschijnlijke toekomstige kwesties, onderwerpen voor verdere analyse |
Subject Area Checklist:Elke Referentie Architectuur omvat verschillende vakgebieden (soms aangeduid als "domeinen"). Subject areas are specific areas of concern, bij voorbeeld, de webgebaseerde levering kanaal is een gebied dat bestaat uit webbrowsers, domeinnaam servers, etc.. A simple and clear way of examining the “fit” of a Reference Architecture to customer requirements is to compare it to the subject area coverage. Hieronder is een tabel voor het vastleggen van de details.
Subject Area |
Aanwezig in Architectuur? | Vereist door de klant? | Kwesties / Risico / Notes |
| Naam van het gebied | Yes/No | Yes/No |
Statement of Fit:A summary of the extent of “fit” between the Reference Architecture and customer requirements. Each Reference Architecture is described at several levels of abstraction, en begeleiding wordt geleverd op elk niveau op de ondersteunde kenmerken. Voor ieder gebied waar de Referentie Architectuur niet voldoet aan eisen, Beschrijf in het kort:
- De onvervulde behoefte. Dit is zeer belangrijk voor het selecteren van de referentie architectuur.
- De aard en omvang van delta die vereiste zou zijn voor de Referentie Architectuur aan de eis te voldoen. Vermeld ook als het moet worden uitgebreid, gewijzigd, of krijgen een nieuw onderwerp?
- Een raming van de kosten en het risico van de delta
Development Approach
De volgende stappen moeten worden genomen bij het genereren van dit werk product:
- Identify the most likely Reference Architecture candidate. As there are a small number of Reference Architectures, elk met een goed gedefinieerde aandacht, Het moet eenvoudig zijn om een of twee als relevant te identificeren aan de klant projectdoelen en toekomstige business model.
- Beoordelen de beschrijving van de context actief, die is voorzien in zowel tekstuele en illustratie vorm, with the customer to assess fit. The illustrations, vooral, are a powerful way of checking customer understanding of the proposed approach. During this process, de klant kan beslissen om zijn eerder gestelde eisen te wijzigen, bij voorbeeld, door erkenning dat de architecturale patroon door de Referentie Architectuur superieur is aan degene die hij eerder had overwogen.
- Gebruik Business Drivers, IT Principes en Requirements lijsten te eisen van de klant karakteriseren Controleer met de klant over de vraag of er nog andere belangrijke eisen die niet zijn gedekt door de standaard kenmerken.
- Onderzoek de pasvorm van de eisen met de kenmerken die door de Referentie Architectuur op verschillende niveaus van abstractie.
- Uit de asset base, identify the subject areas covered by the Reference Architecture. Compare these with the subject areas required by the customer.
- Analyze the fit between the Reference Architecture and the customer requirements. Document all gaps, and make initial assessments with the customer on how these shortcomings will be resolved. This may involve:
- Uitbreiding van de architectuur (e.g., linken naar een extra gebied)
- Het wijzigen van de Referentie Architectuur (d.w.z., het veranderen van de interne structuur of gedrag)
- De motivering voor elk van deze beslissingen in termen van veronderstellingen, zakelijke rechtvaardiging, risico's, etc..
- Een algehele evaluatie maken van de levensvatbaarheid en de risico's op basis van de beschikbare informatie op dit punt.
Validatie en verificatie
Voer de volgende controles:
- Controleer of de klant de criteria die worden gebruikt om te vergelijken en kies de Reference Architectures heeft goedgekeurd.
- Controleer of alle belangrijke vereiste gebieden van de klant werden beschouwd.
- Controleer of de kritische afhankelijkheden van de architectuur in het doel milieu kan worden voldaan.
- Valideren elke afwegingen worden gemaakt met de klant en Asset Providers met de volgende criteria.
- Controleer of de architectuur is veerkrachtig te verwachte veranderingen.
