Beskrivelse
Før definere Reference Architecture, det er bedre å ha noen idé om programvare arkitektur. Programvarearkitektur har ulike definisjoner som er utledet fra ulike kilder. Det spenner fra å designe, skape og vedlikeholde all koden av store datasystemer for å innlemme alle funksjon av de fysiske og logiske komponenter i bedriftens systemer så vel. Det er en kombinasjon og interaksjon av alle komponentene (programvare og maskinvare) å lage et komplett system som er spesifikk for ulike behov.
The Reference Architecture og Fit / Gap analyse er et kort dokument som angir Reference Architecture som skal brukes som grunnlag for det aktuelle prosjektet arkitektur og med begrunnelsen for denne avgjørelsen. Det er også en analyseprosess for å forstå referanse arkitektur og gjennomføringen.
En Reference Architecture er en forhåndsdefinert arkitektonisk mønster som er laget for bruk i bestemt virksomhet og tekniske sammenhenger.
Kilde til referansearkitekturer i en organisasjon kan være noen påvist rammeverk og kapitalforvaltning brukt i tidligere prosjekter. Arbeidet produktet er generisk og gjelder både valg av referansearkitekturer fra andre kilder.
Den viktigste delen av en Reference Architecture er å forstå fitness og hull funnet under analyse.
En Reference Architecture Fit / Gap Analysis tabulates viktige faktorer involvert i å velge en Reference Architecture:
- Forretningsscenarier
- Virksomheten drivere
- Arkitektur egenskaper
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
Nå la oss sjekke formål Fit / Gap analyse i Reference Architecture modell. The Reference Architecture Fit / Gap Analysis brukes for følgende
- Å bistå i å bestemme omfanget av et forslag til løsning utviklingsprosjekt
- As an input to other architecture work products. Depending on the size of the gaps, valgt Reference Architecture og tilhørende passform / gap-analyse kan danne grunnlag 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 hjelper også å velge referanse arkitektur for det foreslåtte prosjektet.
Virkningen av å ikke ha Reference Architecture
Velge en Reference Architecture reduserer risikoen ved å gjenbruke bevist, best-practice solutions. Not applying a standard Reference Architecture increases project effort and cost, og øker risikoen for prosjektet mislykkes.
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.
Grunner for ikke å bruke Reference Architecture
På aktiva-baserte prosjekter, dette produktet skal alltid bli produsert.
Hvis det er hensiktsmessig referansearkitekturer er ikke tilgjengelig for et prosjekt eller et prosjekt bestemmer seg for ikke å bruke en Reference Architecture, deretter på de fleste Kortfattet sammendrag, inkludert grunner til at en Reference Architecture ikke ble valgt, should be completed. Often even this is unnecessary. A note can be added to the documentation of the choice of work products.
Hvordan Fit / Gap Analysen er dokumentert
En Reference Architecture Fit / Gap Analysis er i utgangspunktet tekstlig dokument, med tabeller som vurderer kravene karakteristiske profil og fagområde dekning. Den tabellform beskriver alle de nødvendige poeng for å få et klart bilde av den referert arkitektur og sin egnethet i det foreslåtte prosjektet.
Kortfattet sammendrag: Kort redegjørelse for utvalgte Reference Architecture og noen store problemer / risiko.
Innledning: Innledende kommentarer om referanse arkitektur.
Viktige drivere: En kort redegjørelse for de forretningsmessige mål eller begrensninger.
Arkitektur Krav Sjekkliste: Dokumentet består av et standard sett av spørsmål og mulige svar angående 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 dokumentert i en tabell, som nedenfor. Dette er et eksempel bord, og det kan være av et annet format i henhold til standarden for organisasjonen.
| Krav | Reference Architecture Karakteristisk | Nødvendig Verdi for Project | Risiko / problemer / kommentarer poeng å undersøke |
| Kravet navn | Relevant mengde verdier for denne arkitekturen | Rekkevidde gjelder for kundens | Noen hull, risikoer, sannsynlige fremtidige utgaver, emner for påfølgende analyse |
Subject Area Checklist:Hver Reference Architecture omfatter flere fagområder (noen ganger referert til som "domener"). Subject areas are specific areas of concern, Eksempelvis, web-basert levering kanal er et fagområde som består av nettlesere, domenenavnet servere, osv.. 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 tabell for å fange detaljene.
Fagområde |
Tilstede i Arkitektur? | Kreves av kunden? | Problemer / Risiko / Noter |
| Navnet 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 veiledning gis på hvert nivå på egenskapene støttes. For hvert område der Reference Architecture ikke oppfyller kravene, beskriv kort:
- Det udekkede kravet. Dette er svært viktig for valg av referanse arkitektur.
- Typen og graden av delta som ville være nødvendig for referansekurven Arkitektur for å møte kravet. Også nevne hvis det må utvides, modifisert, eller motta et nytt fagområde?
- Et estimat for kostnader og risiko av deltaet
Development Approach
Følgende tiltak bør tas i å generere dette arbeidet produktet:
- Identify the most likely Reference Architecture candidate. As there are a small number of Reference Architectures, hver med en veldefinert fokus, det skal være enkelt å identifisere en eller to som er relevant for kundens prosjektmål og fremtidige forretningsmodell.
- Leser beskrivelsen av eiendelen sammenheng, som er gitt i både tekstlig og illustrasjon skjema, with the customer to assess fit. The illustrations, særlig, are a powerful way of checking customer understanding of the proposed approach. During this process, kunden kan beslutte å endre sine tidligere uttalt krav, Eksempelvis, gjennom erkjennelsen av at den arkitektoniske mønsteret levert av Reference Architecture er overordnet den han hadde tidligere planlagt.
- Bruk Forretningsreisende Drivers, IT grunnlag og krav lister å karakterisere kundekrav Sjekk med kunden på om det er noen andre viktige krav som ikke er omfattet av de vanlige kjennetegn.
- Undersøke tilpasning av kravene med egenskapene levert av Reference Architecture på ulike nivåer av abstraksjon.
- Fra eiendelen basen, 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:
- Utvide arkitektur (e.g., koble til en ekstra fagområde)
- Endre Reference Architecture (dvs., endre sin interne struktur eller oppførsel)
- Dokumentere begrunnelsen for hver av disse beslutningene i form av forutsetninger, forretningsmessig begrunnelse, risikoer, osv..
- Foreta en samlet vurdering av levedyktighet og risiko basert på tilgjengelig informasjon på dette punktet.
Validering og verifisering
Utføre følgende kontroller:
- Kontroller at kunden har godkjent kriteriene som brukes for å sammenligne og velge referansearkitekturer.
- Kontroller at alle større krav områder av kunden har vært ansett.
- Kontroller at kritiske avhengigheter av arkitekturen i målet miljøet kan oppfylles.
- Validere eventuelle avveininger blir gjort med kunden og Asset Providers med følgende kriterier.
- Kontroller at arkitekturen er motstandsdyktige mot forventede endringer.
