Beskrivelse
Før definere Referencearkitektur, det er bedre at have en idé om software arkitektur. Softwarearkitektur har forskellige definitioner, som er afledt fra forskellige kilder. Det spænder fra design, skabe og vedligeholde al koden af store edb-systemer til at indarbejde alle de velfungerende fysisk og logisk komponenter af virksomhedens systemer samt. Det er en kombination, og interaktionen mellem alle de komponenter, (software og hardware) at lave et komplet system specifikke for de forskellige forretningsmæssige behov.
Referenceprogrammet Arkitektur og Fit / Gap analyse er et kort af dokument med Reference Architecture, der skal bruges som grundlag for det aktuelle projekt arkitektur og herunder begrundelsen for denne beslutning. Det er også en analyseproces at forstå reference arkitektur og dens gennemførelse.
En reference Arkitektur er en foruddefineret arkitektonisk mønster designet til anvendelse i særdeleshed forretningsmæssige og tekniske sammenhænge.
Referencekilde arkitekturer inden for en organisation kan være nogen dokumenteret rammer og aktiver, der bruges i tidligere projekter. Arbejdet Produktet er generisk og gælder ligeledes for udvælgelse af referencearkitekturer fra andre kilder.
Den vigtigste del af en reference Architecture er at forstå fitness og huller fundet under analysen.
En Referencearkitektur Fit / Gap Analysis tabulates de vigtigste faktorer involveret i at vælge en reference arkitektur:
- Erhverv scenarier
- Business drivers
- Arkitektur egenskaber
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.
Formål
Lad os tjekke formål Fit / Gap analyse Referencearkitektur model. Referencearkitekturen Fit / Gap Analysis anvendes til følgende
- For at hjælpe med at bestemme omfanget af et løsningsforslag udviklingsprojekt
- As an input to other architecture work products. Depending on the size of the gaps, det valgte referencestof Arkitektur og tilhørende fit / gap-analysen kan danne grundlag for hele arkitekturen.
- 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. Det hjælper også til at vælge reference arkitektur for det foreslåede projekt.
Virkningen af ikke at have Referencearkitektur
Valg af en reference arkitektur reducerer risikoen ved at genbruge gennemprøvede, best-practice solutions. Not applying a standard Reference Architecture increases project effort and cost, og øger risikoen for projektets fiasko.
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.
Grunde til ikke at bruge Referencearkitektur
På asset-baserede projekter, dette produkt bør altid fremstilles.
Hvis passende henvisning arkitekturer ikke er tilgængelige for et projekt eller et projekt beslutter ikke at bruge en reference arkitektur, så i de fleste Executive Summary, herunder grunde til at en reference arkitektur ikke blev valgt, should be completed. Often even this is unnecessary. A note can be added to the documentation of the choice of work products.
Hvor Fit / Gap analyse er dokumenteret
En Referencearkitektur Fit / Gap Analysis er dybest set tekstmæssige dokument, med borde der vurderer krav karakteristiske profil og fagområde dækningsområde. Den tabelform beskriver alle de krævede points for at få et klart billede af den nævnte arkitektur og dens egnethed i det foreslåede projekt.
Resumé: Kort redegørelse for udvalgte reference Arkitektur og alle større spørgsmål / risici.
Indledning: Indledende kommentarer om henvisningen arkitektur.
Vigtigste drivkræfter: En kort redegørelse for de forretningsmæssige mål eller begrænsninger.
Arkitektur Krav Tjekliste: Dokumentet består af et standard sæt af spørgsmål og mulige svar vedrørende arkitektoniske krav, 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, som er dokumenteret i en tabel, som nedenfor. Dette er et eksempel tabel, og det kan være af et andet format i henhold til standarden for organisationen.
| Krav | Henvisning Architecture Karakteristisk | Nødvendig Value for Project | Risici / spørgsmål / Comments Points til at undersøge |
| Krav navn | Relevant række værdier for denne arkitektur | Interval for kunden | Eventuelle huller, risici, sandsynlige fremtidige problemstillinger, emner for efterfølgende analyse |
Subject Area Checklist:Hver reference Architecture omfatter flere fagområder (undertiden benævnt "domæner"). Subject areas are specific areas of concern, for eksempel, den webbaserede levering kanal er et emne område bestående af webbrowsere, domænenavneservere, 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. Følgende er en tabel for at indfange detaljerne.
Emne Area |
Til stede i Architecture? | Kræves af Kunden? | Emner / Risici / Noter |
| Navn på fagområdet | 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, og vejledning på hvert niveau på de understøttede egenskaber. For hvert område, hvor Reference Architecture ikke opfylder kravene, Beskriv kort:
- Den udækkede krav. Dette er meget vigtigt for valg reference arkitektur.
- Typen og omfanget af delta, der ville være nødvendige for Reference Architecture at opfylde kravet. Også nævne, hvis det skal udvides, modificeret, eller modtage et nyt fagområde?
- Et skøn over omkostningerne og risikoen for, at delta
Development Approach
Følgende trin skal tages i at generere dette arbejde produkt:
- Identify the most likely Reference Architecture candidate. As there are a small number of Reference Architectures, hver med en veldefineret fokus, det skal være nemt at identificere en eller to som er relevante for kundens projektets mål og fremtidige forretningsmodel.
- Gennemgå beskrivelsen af aktivet kontekst, som er tilvejebragt i både tekst-og illustration formular, with the customer to assess fit. The illustrations, navnlig, are a powerful way of checking customer understanding of the proposed approach. During this process, kunden kan beslutte at ændre sine tidligere udmeldte krav, for eksempel, gennem anerkendelse af, at den arkitektoniske mønster fra Reference Arkitektur er overlegen i forhold til den, han tidligere havde planlagt.
- Bruge Business Drivers, IT principper og krav lister til at karakterisere kundernes krav Check med kunden om, hvorvidt der er andre vigtige krav, som ikke er omfattet af standarden karakteristika.
- Undersøg fit af de krav, med de egenskaber, som Reference Architecture på forskellige niveauer af abstraktion.
- Fra aktivbasen, 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:
- Forlængelse af arkitekturen (e.g., linker til en ekstra fagområde)
- Ændring Reference Architecture (dvs, ændre sin interne struktur eller adfærd)
- Dokumentere grundlaget for hver af disse beslutninger i form af antagelser, forretningsmæssig begrundelse, risici, etc..
- Foretage en samlet vurdering af virksomhedens rentabilitet og risiko på de foreliggende oplysninger på dette punkt.
Validering og Verifikation
Udfør følgende kontroller:
- Kontroller, at kunden har godkendt de kriterier, der anvendes til at sammenligne og vælge Reference-arkitekturer.
- Kontroller, at alle de store krav områder af kunden er blevet overvejet.
- Kontroller, at kritiske afhængigheder af arkitekturen i target miljø kan opfyldes.
- Godkend eventuelle kompromiser, der gøres med kunden og Asset Providers med følgende kriterier.
- Kontroller, at arkitekturen er modstandsdygtig over for forventede ændringer.
