Dick Fairley, Kevin Forsberg, Medvirkende forfattere:: Dick Fairley, Kevin Forsberg, Medvirkende forfattere: Dick Fairley, Kevin Forsberg: Ray Madachy
Der findes et stort antal livscyklusprocesmodeller. Som diskuteret i artiklen System Life Cycle Process Drivers and Choices falder disse modeller i tre hovedkategorier: (1) primært forudspecificerede og sekventielle processer; (2) primært evolutionære og samtidige processer (f.eks. den rationelle ensartede proces og forskellige former for Vee- og spiralmodellerne); og (3) primært interpersonelle og ubegrænsede processer (f.eks. agil udvikling, Scrum, ekstrem programmering (XP), den dynamiske systemudviklingsmetode og innovationsbaserede processer).
Denne artikel fokuserer specifikt på Vee-modellen som det primære eksempel på forudspecificerede og sekventielle processer. I denne diskussion er det vigtigt at bemærke, at Vee-modellen og variationer af Vee-modellen alle omhandler det samme grundlæggende sæt af systemteknologiske (SE) aktiviteter. Den væsentligste forskel mellem disse modeller er den måde, hvorpå de grupperer og repræsenterer de førnævnte SE-aktiviteter.
Generelle implikationer af at bruge Vee-modellen til systemdesign og -udvikling diskuteres nedenfor; for en mere specifik forståelse af, hvordan denne livscyklusmodel påvirker systemtekniske aktiviteter, se venligst de andre vidensområder (KA’er) i del 3.
- En primært forudspecificeret og sekventiel procesmodel: Vee-modellen
- Anvendelse af Vee-modellen
- Fundamentals of Life Cycle Stages and Program Management Phase
- Livscyklusfaser
- Fasen for udforskende forskning
- Konceptfasen
- Udviklingsfasen
- Produktionsfasen
- Udnyttelsesfase
- Supportfasen
- Udfasningsfasen
- Life Cycle Reviews
- Citerede værker
- Primære referencer
- Supplerende referencer
- Relevante videoer=
En primært forudspecificeret og sekventiel procesmodel: Vee-modellen
Den sekventielle version af Vee-modellen er vist i figur 1. Dens kerne omfatter et sekventielt forløb af planer, specifikationer og produkter, der er baseret og lagt ind under konfigurationsstyring. Den lodrette pil med to spidser gør det muligt for projekterne at udføre samtidige muligheder og risikoanalyser samt løbende validering undervejs i processen. Vee-modellen omfatter de første tre livscyklusfaser, der er anført i tabellen “Generic Life Cycle Stages” i INCOSE Systems Engineering Handbook: udforskende forskning, koncept og udvikling (INCOSE 2012).
Veee-modellen tilslutter sig INCOSE Systems Engineering Handbook (INCOSE 2012) definition af livscyklusfaser og deres formål eller aktiviteter, som vist i figur 2 nedenfor.
IncOSE Systems Engineering Handbook 3.2.2 indeholder en mere detaljeret version af Vee-diagrammet (2012, figurer 3-4, s. 27), som inkorporerer livscyklusaktiviteter i den mere generiske Vee-model. Et lignende diagram, der er udviklet på det amerikanske Defense Acquisition University (DAU), kan ses i figur 3 nedenfor.
Anvendelse af Vee-modellen
Lawson (Lawson 2010) uddyber aktiviteterne i hvert livscyklusstadie og bemærker, at det er nyttigt at overveje strukturen af en generisk livscyklusstadiemodel for enhver type system-of-interest (SoI) som afbildet i figur 4. Denne (T)-model angiver, at en eller flere definitionsfaser går forud for en eller flere produktionsfase(r), hvor implementeringen (anskaffelse, tilvejebringelse eller udvikling) af to eller flere systemelementer er blevet gennemført.
Figur 5 viser de generiske livscyklusfaser for en række forskellige interessenter, fra en standardiseringsorganisation (ISO/IEC) til kommercielle og statslige organisationer. Selv om disse faser adskiller sig i detaljer, har de alle et lignende sekventielt format, der lægger vægt på de kerneaktiviteter som nævnt i figur 2 (definition, produktion og udnyttelse/nedlæggelse).
Det er vigtigt at bemærke, at mange af aktiviteterne i hele livscyklussen er iterative. Dette er et eksempel på rekursion (ordliste)rekursion (ordliste)rekursion (ordliste) som diskuteret i del 3 Introduktion.
Fundamentals of Life Cycle Stages and Program Management Phase
For denne diskussion er det vigtigt at bemærke, at:
- Tegnet stadiefasen refererer til de forskellige tilstande af et system i løbet af dets livscyklus; nogle faser kan overlappe hinanden i tid, såsom udnyttelsesfasen og supportfasen. Udtrykket “stage” anvendes i ISO/IEC/IEEE 15288.
- Udtrykket fase henviser til de forskellige trin i programmet, der understøtter og styrer systemets levetid; faserne overlapper normalt ikke hinanden. Udtrykket “fase” anvendes i mange veletablerede modeller som en ækvivalent til udtrykket “fase.”
ProgramstyringProgramstyring anvender faser, milepælemilestonesmilestones og decision gatesdecision gates, som anvendes til at vurdere udviklingen af et system gennem dets forskellige faser. Faser indeholder de aktiviteter, der udføres for at nå målene, og tjener til at kontrollere og styre sekvensen af faser og overgangene mellem de enkelte faser. For hvert projekt er det vigtigt at definere og offentliggøre de udtryk og relaterede definitioner, der anvendes på de respektive projekter, for at minimere forvirring.
Et typisk programprogramprogram består af følgende faser:
- Forundersøgelsesfasen, som identificerer potentielle muligheder for at imødekomme brugernes behov med nye løsninger, der giver forretningsmæssig mening.
- Fasen for gennemførlighed består i at undersøge gennemførligheden af alternative koncepter for at nå en anden beslutningsgate, før man påbegynder udførelsesfasen. I gennemførlighedsfasen identificeres interessenternes krav og systemkravene, levedygtige løsninger identificeres og undersøges, og virtuelle prototyper (ordliste)prototyper (ordliste) kan implementeres. I denne fase er beslutningen om at gå videre baseret på:
- om et koncept er gennemførligt og anses for at kunne imødegå en identificeret trussel eller udnytte en mulighed;
- om et koncept er tilstrækkeligt modent til at retfærdiggøre fortsat udvikling af et nyt produkt eller en produktserie; og
- om et forslag, der er udarbejdet som svar på en anmodning om tilbud, skal godkendes.
- Udførelsesfasen omfatter aktiviteter i forbindelse med fire faser af systemets livscyklus: udvikling, produktion, udnyttelse og støtte. Typisk er der to beslutningsporte og to milepæle forbundet med udførelsesaktiviteter. Den første milepæl giver ledelsen mulighed for at gennemgå planerne for udførelsen, før den giver grønt lys. Den anden milepæl giver mulighed for at gennemgå fremskridtene, før der træffes beslutning om at sætte produktionen i gang. Beslutningsportene under udførelsen kan bruges til at afgøre, om den udviklede SoI skal produceres, og om den skal forbedres eller tages ud af drift.
Disse programledelsessynspunkter gælder ikke kun for SoI’en, men også for dens elementer og struktur.
Livscyklusfaser
Variationer af Vee-modellen omhandler de samme generelle faser i en livscyklus:
- Nye projekter begynder typisk med en eksplorativ forskningsfase, som generelt omfatter aktiviteterne i forbindelse med konceptdefinition, specifikt emnerne forretnings- eller missionsanalyse og forståelsen af interessenternes behov og krav. Disse modnes i takt med, at projektet går fra den udforskende fase til konceptfasen og videre til udviklingsfasen.
- Produktionsfasen omfatter aktiviteterne systemdefinition og systemrealisering samt udvikling af systemkravene (ordliste)krav (ordliste)krav (ordliste)krav (ordliste)arkitektur (ordliste)arkitektur (ordliste)gennem verifikation og validering.
- Anvendelsesfasen omfatter aktiviteterne systemimplementering og systemdrift.
- Supportfasen omfatter aktiviteterne vedligeholdelse af systemet, logistik og forvaltning af produkt- og levetid, som kan omfatte aktiviteter som f.eks. forlængelse af levetiden eller kapacitetsopdateringer, opgraderinger og modernisering.
- Fasen for udfasning omfatter aktiviteterne bortskaffelse og udfasning, selv om aktiviteter som f.eks. levetidsforlængelse eller kapacitetsopdateringer, opgraderinger og modernisering i nogle modeller er grupperet i “udfasningsfasen”.
Der kan findes yderligere oplysninger om hver af disse faser i afsnittene nedenfor (se links til yderligere artikler i del 3 ovenfor for yderligere detaljer). Det er vigtigt at bemærke, at disse livscyklusfaser og aktiviteterne i hver fase understøttes af et sæt systemtekniske ledelsesprocesser.
Fasen for udforskende forskning
Analyse af brugerkrav og aftale herom er en del af den udforskende forskningsfase og er afgørende for udviklingen af vellykkede systemer. Uden en ordentlig forståelse af brugernes behov risikerer ethvert system at blive bygget for at løse de forkerte problemer. Det første skridt i den udforskende forskningsfase er at definere brugernes (og interessenternes) krav og begrænsninger. En vigtig del af denne proces er at fastslå, om det er muligt at opfylde brugerkravene, herunder at vurdere, om teknologien er klar til brug. Som med mange SE-aktiviteter foregår dette ofte iterativt, og interessenternes behov og krav tages op til fornyet overvejelse, efterhånden som nye oplysninger bliver tilgængelige.
En nylig undersøgelse foretaget af National Research Council (National Research Council 2008) fokuserede på at reducere udviklingstiden for projekter i det amerikanske luftvåben. Rapporten bemærker, at “simpelt sagt er systemteknik oversættelsen af en brugers behov til en definition af et system og dets arkitektur gennem en iterativ proces, der resulterer i et effektivt systemdesign”. Den iterative inddragelse af interessenterne er afgørende for projektets succes.
Med undtagelse af den første og sidste beslutningsport i et projekt udføres portene samtidig. Se figur 6 nedenfor.
Konceptfasen
I konceptfasen oprettes alternative koncepter for at bestemme den bedste tilgang til at opfylde interessenternes behov. Ved at forestille sig alternativer og skabe modeller, herunder passende prototyper, vil interessenternes behov blive afklaret, og de drivende spørgsmål vil blive fremhævet. Dette kan føre til en inkrementel eller evolutionær tilgang til systemudvikling. Flere forskellige koncepter kan undersøges parallelt.
Udviklingsfasen
Det eller de udvalgte koncepter, der er identificeret i konceptfasen, udarbejdes i detaljer ned til det laveste niveau for at frembringe den løsning, der opfylder interessenternes kravinteressenternes krav. I hele denne fase er det afgørende at fortsætte med brugerinddragelse gennem validering i processen (den opadgående pil på Vee-modellerne). På hardware sker dette med hyppige programgennemgange og en eller flere repræsentanter for kunden på stedet (hvis det er relevant). I agil udvikling er det praksis, at kunderepræsentanten integreres i udviklingsteamet.
Produktionsfasen
Produktionsfasen er den fase, hvor SoI’en bygges eller fremstilles. Der kan være behov for produktændringer for at løse produktionsproblemer, reducere produktionsomkostningerne eller forbedre produktets eller SoI’ens egenskaber. Enhver af disse ændringer kan påvirke systemkravene og kan kræve systemrekvalificeringkvalificeringkvalificering, reverificeringverificeringverificering eller revalideringvalideringvalidering. Alle sådanne ændringer kræver en SE-vurdering, før ændringerne godkendes.
Udnyttelsesfase
Et væsentligt aspekt af produktets livscyklusstyring er tilvejebringelsen af støttesystemer, som er afgørende for at opretholde produktets drift. Selv om det leverede produkt eller den leverede tjeneste kan betragtes som det snævre interessesystem (NSOI) for en erhverver/erhverver, skal erhververen også indarbejde støttesystemerne i et bredere interessesystem (WSOI). Disse støttesystemer bør ses som systemaktiver, der, når der er behov for det, aktiveres som reaktion på en situation, der er opstået i forbindelse med driften af NSOI’et. Den kollektive betegnelse for de forskellige støttesystemer er det integrerede logistikstøttesystem (ILS).
Det er afgørende at have et holistisk syn, når systemprodukter og -tjenester skal defineres, produceres og drives. I figur 7 er forholdet mellem systemdesign og -udvikling og ILS-kravene skildret.
Kravene til pålidelighed, der resulterer i behovet for vedligeholdbarhed og testbarhed, er drivende faktorer.
Supportfasen
I supportfasen får SoI’en leveret tjenester, der muliggør fortsat drift. Der kan foreslås ændringer for at løse problemer med understøttelighed, for at reducere driftsomkostningerne eller for at forlænge et systems levetid. Disse ændringer kræver en SE-vurdering for at undgå tab af systemets kapacitet, mens det er i drift. Den tilsvarende tekniske proces er vedligeholdelsesprocessen.
Udfasningsfasen
I udfasningsfasen tages SoI’et og dets relaterede tjenester ud af drift. SE-aktiviteterne i denne fase er primært fokuseret på at sikre, at bortskaffelseskravene er opfyldt. Faktisk er planlægning af bortskaffelse en del af systemdefinitionen i konceptfasen. Erfaringerne fra det 20. århundrede har gentagne gange vist konsekvenserne af, at der ikke fra starten blev taget hensyn til pensionering og bortskaffelse af systemer. I begyndelsen af det 21. århundrede har mange lande ændret deres lovgivning for at holde skaberen af et SoI ansvarlig for korrekt bortskaffelse af systemet ved slutningen af dets levetid.
Life Cycle Reviews
For at kontrollere et projekts fremskridt planlægges forskellige typer af reviews. De mest almindeligt anvendte er anført nedenfor, selv om navnene ikke er universelle:
- Systemkravsrevisionen (SRR) er planlagt til at verificere og validere sæt af systemkrav, før de detaljerede designaktiviteter påbegyndes.
- Den foreløbige design reviewpreliminary design review (PDR) er planlagt til at verificere og validere sæt af systemkrav, design artefakter og retfærdiggørelseselementer i slutningen af det første tekniske loop (også kendt som “design-to” gate).
- Den kritiske designgennemgangDen kritiske designgennemgang (CDR) er planlagt til at verificere og validere sæt af systemkrav, designartefakter og begrundelseselementer ved afslutningen af det sidste tekniske loop (“build-to”- og “code-to”-designs frigives efter denne gennemgang).
- Integrationintegration, verifikationverifikationverifikation og valideringvalideringgennemgange er planlagt, efterhånden som komponenterne samles til delsystemer og elementer på højere niveau. Der afholdes en række gennemgange for at sikre, at alting integreres korrekt, og at der er objektive beviser for, at alle krav er blevet opfyldt. Der bør også foretages en validering undervejs i processen af, at systemet, som det udvikler sig, vil opfylde interessenternes krav (se figur 7).
- Det endelige valideringsreview gennemføres ved afslutningen af integrationsfasen.
- Der kan planlægges og gennemføres andre ledelsesrelaterede reviews med henblik på at kontrollere, at arbejdet skrider korrekt frem, baseret på systemtypen og de dermed forbundne risici.
Citerede værker
Eichmueller, P. og B. Foreman. 2010. S3000LTM. Bruxelles, Belgien: Aerospace and Defence Industries Association of Europe (ASD)/Aerospace Industries Association (AIA).
Faisandier, A. 2012. Systemarkitektur og design. Belberaud, Frankrig: Sinergy’Com.
Forsberg, K., H. Mooz, og H. Cotterman. 2005. Visualizing Project Management, 3rd ed. New York, NY, USA: J. Wiley & Sons.
INCOSE. 2012. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.2.
Lawson, H. 2010. En rejse gennem systemlandskabet. London, UK: College Publications, Kings College, UK.
Primære referencer
Beedle, M., et al. 2009. “The Agile Manifesto”: Principles behind the Agile Manifesto”. i The Agile Manifesto . Besøgt den 04. december 2014 på www.agilemanifesto.org/principles.html
Boehm, B. og R. Turner. 2004. Balancering af agilitet og disciplin. New York, NY, USA: Addison-Wesley.
Fairley, R. 2009. Ledelse og ledelse af softwareprojekter. New York, NY, USA: J. Wiley & Sons.
Forsberg, K., H. Mooz, og H. Cotterman. 2005. Visualisering af projektledelse. 3rd ed. New York, NY, USA: J. Wiley & Sons.
INCOSE. 2012. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.2.
Lawson, H. 2010. En rejse gennem systemlandskabet. Kings College, UK: College Publications.
Pew, R., og A. Mavor (eds.) 2007. Human-System Integration in the System Development Process: A New Look. Washington, DC, USA: The National Academies Press.
Royce, W.E. 1998. Software Project Management: A Unified Framework. New York, NY, USA: Addison Wesley.
Supplerende referencer
Anderson, D. 2010. Kanban. Sequim, WA, USA: Blue Hole Press.
Baldwin, C. og K. Clark. 2000. Design Rules: The Power of Modularity. Cambridge, MA, USA: MIT Press.
Beck, K. 1999. Extreme Programming Explained. New York, NY, USA: Addison Wesley.
Beedle, M., et al. 2009. “The Agile Manifesto”: Principles behind the Agile Manifesto”. i The Agile Manifesto . Tilgået i 2010. Tilgængelig på: www.agilemanifesto.org/principles.html
Biffl, S., A. Aurum, B. Boehm, H. Erdogmus, og P. Gruenbacher (eds.). 2005. Værdibaseret softwareudvikling. New York, NY, USA: Springer.
Boehm, B. 1988. “En spiralmodel for softwareudvikling”. IEEE Computer 21(5): 61-72.
Boehm, B. 2006. “Nogle fremtidige tendenser og konsekvenser for system- og softwareteknikprocesser”. Systems Engineering. 9(1): 1-19.
Boehm, B., A. Egyed, J. Kwan, D. Port, A. Shah, og R. Madachy. 1998. “Brug af WinWin-spiralmodellen: A Case Study.” IEEE Computer. 31(7): 33-44.
Boehm, B., R. Turner, J. Lane, S. Koolmanojwong. 2014 (under tryk). Omfavnelse af spiralmodellen: Skabelse af succesfulde systemer med spiralmodellen Incremental Commitment Spiral Model. Boston, MA, USA: Addison Wesley.
Castellano, D.R. 2004. “Top Five Quality Software Projects”. CrossTalk. 17(7) (juli 2004): 4-19. Tilgængelig på:
Checkland, P. 1981. Systems Thinking, Systems Practice. New York, NY, USA: Wiley.
Crosson, S. og B. Boehm. 2009. “Justering af softwarelivscyklusens ankerpunkter: Lessons Learned in a System of Systems Context.” Proceedings of the Systems and Software Technology Conference, 20-23 April 2009, Salt Lake City, UT, USA.
Dingsoyr, T., T. Dyba. og N. Moe (eds.). 2010. “Agile Software Development: Current Research and Future Directions.” Kapitel i B. Boehm, J. Lane, S. Koolmanjwong og R. Turner, Architected Agile Solutions for Software-Reliant Systems. New York, NY, USA: Springer.
Dorner, D. 1996. The Logic of Failure. New York, NY, USA: Basic Books.
Forsberg, K. 1995. “‘If I Could Do That, Then I Could…’ System Engineering in a Research and Development Environment.” Proceedings of the Fifth Annual International Council on Systems Engineering (INCOSE) International Symposium. 22-26 juli 1995. St. Louis, MO, USA.
Forsberg, K. 2010. “Projekter begynder ikke med krav”. Proceedings of the IEEE Systems Conference, 5-8 april 2010, San Diego, CA, USA.
Gilb, T. 2005. Competitive Engineering. Maryland Heights, MO, USA: Elsevier Butterworth Heinemann.
Goldratt, E. 1984. The Goal. Great Barrington, MA, USA: North River Press.
Hitchins, D. 2007. Systems Engineering: A 21st Century Systems Methodology. New York, NY, USA: Wiley.
Holland, J. 1998. Emergence. New York, NY, USA: Perseus Books.
ISO/IEC. 2010. Systems and Software Engineering, Part 1: Guide for Life Cycle Management. Genève, Schweiz: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 24748-1:2010.
ISO/IEC/IEEE. 2015. Systems and Software Engineering — System Life Cycle Processes. Genève, Schweiz: International Organisation for Standardisation / International Electrotechnical Commissions / Institute of Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2015.
ISO/IEC. 2003. Systems Engineering – A Guide for The Application of ISO/IEC 15288 System Life Cycle Processes. Genève, Schweiz: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 19760:2003 (E).
Jarzombek, J. 2003. “Top Five Quality Software Projects.” CrossTalk. 16(7) (juli 2003): 4-19. Tilgængelig på: http://www.crosstalkonline.org/storage/issue-archives/2003/200307/200307-0-Issue.pdf.
Kruchten, P. 1999. The Rational Unified Process. New York, NY, USA: Addison Wesley.
Landis, T. R. 2010. Lockheed Blackbird-familien (A-12, YF-12, D-21/M-21 & SR-71). North Branch, MN, USA: Specialty Press.
Madachy, R. 2008. Software Process Dynamics. Hoboken, NJ, USA: Wiley.
Maranzano, J.F., S.A. Rozsypal, G.H. Zimmerman, G.W. Warnken, P.E. Wirth, D.W. Weiss. 2005. “Architecture Reviews: Practice and Experience.” IEEE Software. 22(2): 34-43.
National Research Council of the National Academies (USA). 2008. Pre-Milestone A og systemteknik i den tidlige fase. Washington, DC, USA: The National Academies Press.
Osterweil, L. 1987. “Softwareprocesser er også software”. Proceedings of the SEFM 2011: 9th International Conference on Software Engineering. Monterey, CA, USA.
Poppendeick, M. og T. Poppendeick. 2003. Lean Software Development: an Agile Toolkit (Lean softwareudvikling: en agil værktøjskasse). New York, NY, USA: Addison Wesley.
Rechtin, E. 1991. System Architecting: Creating and Building Complex Systems. Upper Saddle River, NY, USA: Prentice-Hall.
Rechtin, E., og M. Maier. 1997. The Art of System Architecting. Boca Raton, FL, USA: CRC Press.
Schwaber, K. og M. Beedle. 2002. Agil softwareudvikling med Scrum. Upper Saddle River, NY, USA: Prentice Hall.
Spruill, N. 2002. “Top Five Quality Software Projects.” CrossTalk. 15(1) (januar 2002): 4-19. Tilgængelig på: http://www.crosstalkonline.org/storage/issue-archives/2002/200201/200201-0-Issue.pdf.
Stauder, T. 2005. “Top Five Department of Defense Program Awards”. CrossTalk. 18(9) (september 2005): 4-13. Tilgængelig på: http://www.crosstalkonline.org/storage/issue-archives/2005/200509/200509-0-Issue.pdf.
Warfield, J. 1976. Societal Systems: Planning, Policy, and Complexity. New York, NY, USA: Wiley.
Womack, J. og D. Jones. 1996. Lean Thinking. New York, NY, USA: Simon and Schuster.
Relevante videoer=
- Grundlæggende introduktion til systemteknik (V-metode)
- Grundlæggende introduktion til systemteknik (V-metode) Del 2 af 2