Ledande författare: Vee: Dick Fairley, Kevin Forsberg, Medverkande författare: Dick Fairley, Kevin Forsberg: Ray Madachy
Det finns ett stort antal modeller för livscykelprocesser. Som diskuterades i artikeln System Life Cycle Process Drivers and Choices faller dessa modeller in i tre huvudkategorier: (1) främst förspecificerade och sekventiella processer, (2) främst evolutionära och samtidiga processer (t.ex. den rationella enhetliga processen och olika former av Vee- och spiralmodellerna) och (3) främst mellanmänskliga och obegränsade processer (t.ex. agil utveckling, Scrum, Extreme Programming (XP), den dynamiska systemutvecklingsmetoden och innovationsbaserade processer).
Denna artikel fokuserar särskilt på Vee-modellen som det primära exemplet på förspecificerade och sekventiella processer. I denna diskussion är det viktigt att notera att Vee-modellen, och variationer av Vee-modellen, alla behandlar samma grundläggande uppsättning systemtekniska aktiviteter (SE). Den viktigaste skillnaden mellan dessa modeller är det sätt på vilket de grupperar och representerar de ovannämnda SE-verksamheterna.
Allmänna konsekvenser av att använda Vee-modellen för systemdesign och systemutveckling diskuteras nedan; för en mer specifik förståelse av hur denna livscykelmodell påverkar systemtekniska aktiviteter, se de andra kunskapsområdena (KA) i del 3.
- En primärt förspecificerad och sekventiell processmodell: Vee-modellen
- Applicering av Vee-modellen
- Fundamentals of Life Cycle Stages and Program Management Phase
- Livscykelstadier
- Förberedande forskningsstadium
- Konceptfasen
- Utvecklingsstadiet
- Produktionsstadiet
- Användningsskede
- Support Stage
- Retableringsfasen
- Life Cycle Reviews
- Works Cited
- Primära referenser
- Andra referenser
- Relevanta videor=
En primärt förspecificerad och sekventiell processmodell: Vee-modellen
Den sekventiella versionen av Vee-modellen visas i figur 1. Dess kärna omfattar en sekventiell utveckling av planer, specifikationer och produkter som är baserade och läggs under konfigurationshantering. Den vertikala, tvåhövdade pilen gör det möjligt för projekten att utföra samtidiga möjlighets- och riskanalyser samt kontinuerlig validering under processen. Vee-modellen omfattar de tre första livscykelstadierna i tabellen ”Generic Life Cycle Stages” i INCOSE Systems Engineering Handbook: utforskande forskning, koncept och utveckling (INCOSE 2012).
Veee-modellen stöder INCOSE Systems Engineering Handbook (INCOSE 2012) definition av livscykelstadier och deras syften eller aktiviteter, som visas i figur 2 nedan.
I INCOSE Systems Engineering Handbook 3.2.2 finns en mer detaljerad version av Vee-diagrammet (2012, Figures 3-4, s. 27) som införlivar livscykelaktiviteter i den mer generiska Vee-modellen. Ett liknande diagram, utvecklat vid USA:s Defense Acquisition University (DAU), kan ses i figur 3 nedan.
Applicering av Vee-modellen
Lawson (Lawson 2010) utvecklar aktiviteterna i varje livscykelstadium och konstaterar att det är användbart att betrakta strukturen för en generisk livscykelstadiemodell för alla typer av system-of-interest (SoI), vilket avbildas i figur 4. Denna (T)-modell anger att ett eller flera definitionsstadier föregår ett eller flera produktionsstadier där genomförandet (förvärv, tillhandahållande eller utveckling) av två eller flera systemelement har genomförts.
Figur 5 visar de generiska livscykelstegen för en mängd olika intressenter, från en standardiseringsorganisation (ISO/IEC) till kommersiella och statliga organisationer. Även om dessa stadier skiljer sig åt i detalj har de alla ett liknande sekventiellt format som betonar de kärnverksamheter som anges i figur 2 (definition, produktion och användning/avveckling).
Det är viktigt att notera att många av aktiviteterna under hela livscykeln är itererade. Detta är ett exempel på rekursion (ordlista)rekursion (ordlista) som diskuteras i del 3 Introduktion.
Fundamentals of Life Cycle Stages and Program Management Phase
För den här diskussionen är det viktigt att notera att:
- Tecknet stegstadium hänvisar till de olika tillstånden för ett system under dess livscykel; vissa stadier kan överlappa varandra tidsmässigt, som till exempel utnyttjandestadiet och stödstadiet. Termen ”stage” används i ISO/IEC/IEEE 15288.
- Termen fas hänvisar till de olika stegen i programmet som stöder och hanterar systemets livslängd; faserna överlappar vanligtvis inte varandra. Termen ”fas” används i många väletablerade modeller som en motsvarighet till termen ”steg”.
ProgramhanteringProgramhantering använder sig av faser, milstolparmilstolpar och beslutsgrindarbeslutsgrindar som används för att bedöma utvecklingen av ett system genom dess olika stadier. Etapperna innehåller de aktiviteter som utförs för att uppnå målen och tjänar till att kontrollera och hantera sekvensen av etapper och övergångarna mellan varje etapp. För varje projekt är det viktigt att definiera och publicera de termer och relaterade definitioner som används i respektive projekt för att minimera förvirring.
Ett typiskt programprogramprogram består av följande faser:
- Fasen med förstudier, som identifierar potentiella möjligheter att tillgodose användarnas behov med nya lösningar som är affärsmässigt vettiga.
- Fasen med genomförbarhetsstudier består av att studera genomförbarheten av alternativa koncept för att nå en andra beslutsgrind innan man inleder genomförandeskedet. Under genomförbarhetsfasen identifieras intressenternas krav och systemkraven, genomförbara lösningar identifieras och studeras, och virtuella prototyper (ordlista)prototyper (ordlista) kan genomföras. Under denna fas baseras beslutet att gå vidare på:
- om ett koncept är genomförbart och anses kunna motverka ett identifierat hot eller utnyttja en möjlighet;
- om ett koncept är tillräckligt moget för att motivera fortsatt utveckling av en ny produkt eller produktserie; och
- om ett förslag som genererats som svar på en anbudsförfrågan ska godkännas.
- Exekveringsfasen omfattar aktiviteter relaterade till fyra stadier av systemets livscykel: utveckling, produktion, användning och stöd. Vanligtvis finns det två beslutsgrindar och två milstolpar som är förknippade med genomförandeaktiviteter. Den första milstolpen ger ledningen möjlighet att granska planerna för utförandet innan den ger klartecken. Den andra milstolpen ger möjlighet att granska framstegen innan beslut fattas om att inleda produktion. Beslutsgrindarna under genomförandet kan användas för att avgöra om den utvecklade SoI ska produceras och om den ska förbättras eller tas ur bruk.
Dessa programledningssynpunkter gäller inte bara SoI, utan även dess element och struktur.
Livscykelstadier
Variationer av Vee-modellen behandlar samma allmänna stadier i en livscykel:
- Nya projekt börjar vanligen med en utforskande forskningsfas som i allmänhet innefattar aktiviteterna för begreppsdefinition, särskilt ämnena affärs- eller uppdragsanalys och förståelsen av intressenternas behov och krav. Dessa mognar allteftersom projektet går från den utforskande fasen till konceptfasen och till utvecklingsfasen.
- Produktionsfasen omfattar aktiviteterna systemdefinition och systemrealisering, samt utvecklingen av systemkraven (ordlista)krav (ordlista)krav (ordlista) och arkitekturen (ordlista)arkitektur (ordlista)arkitektur (ordlista) genom verifiering och validering.
- Användningsfasen omfattar aktiviteterna systemutbyggnad och systemdrift.
- Supportfasen omfattar aktiviteterna systemunderhåll, logistik och hantering av produkt- och servicelivslängd, vilket kan omfatta aktiviteter som förlängning av servicelivslängden eller kapacitetsuppdateringar, uppgraderingar och modernisering.
- Den utgående fasen omfattar aktiviteterna bortskaffande och pensionering, även om i vissa modeller aktiviteter som förlängning av livslängden eller kapacitetsuppdateringar, uppgraderingar och modernisering grupperas i fasen ”pensionering”.
Den ytterligare informationen om var och en av dessa faser finns i avsnitten nedan (se länkarna till ytterligare artiklar i del 3 ovan för ytterligare detaljer). Det är viktigt att notera att dessa livscykelstadier, och aktiviteterna i varje stadium, stöds av en uppsättning systemtekniska förvaltningsprocesser.
Förberedande forskningsstadium
Analys och överenskommelse om användarnas krav är en del av det förberedande forskningsstadiet och är avgörande för utvecklingen av framgångsrika system. Utan en ordentlig förståelse av användarnas behov riskerar alla system att byggas för att lösa fel problem. Det första steget i den utforskande forskningsfasen är att definiera användarens (och intressenternas) krav och begränsningar. En viktig del av denna process är att fastställa om det är möjligt att uppfylla användarkraven, inklusive en bedömning av den tekniska beredskapen. Som med många SE-verksamheter sker detta ofta iterativt, och intressenternas behov och krav ses över när ny information blir tillgänglig.
En nyligen genomförd studie av National Research Council (National Research Council 2008) fokuserade på att minska utvecklingstiden för projekt inom US Air Force. I rapporten konstateras att ”enkelt uttryckt är systemteknik översättningen av en användares behov till en definition av ett system och dess arkitektur genom en iterativ process som resulterar i en effektiv systemdesign”. Det iterativa engagemanget med intressenterna är avgörande för projektets framgång.
Med undantag för den första och sista beslutsporten i ett projekt utförs portarna samtidigt. Se figur 6 nedan.
Konceptfasen
Under konceptfasen skapas alternativa koncept för att fastställa det bästa tillvägagångssättet för att uppfylla intressenternas behov. Genom att föreställa sig alternativ och skapa modeller, inklusive lämpliga prototyper, klargörs intressenternas behov och de drivande frågorna lyfts fram. Detta kan leda till ett inkrementellt eller evolutionärt tillvägagångssätt för systemutveckling. Flera olika koncept kan undersökas parallellt.
Utvecklingsstadiet
Det eller de utvalda koncept som identifierats i konceptstadiet utarbetas i detalj ner till den lägsta nivån för att ta fram den lösning som uppfyller intressenternas kravintressenternas kravintressenternas krav. Under hela detta skede är det viktigt att fortsätta med användarinvolvering genom validering inom processen (den uppåtriktade pilen på Vee-modellerna). På hårdvara sker detta med frekventa programgenomgångar och en eller flera representanter från kunden (om det är lämpligt). Vid agil utveckling är praxis att kundrepresentanten integreras i utvecklingsteamet.
Produktionsstadiet
Produktionsstadiet är det stadium där SoI byggs eller tillverkas. Produktändringar kan krävas för att lösa produktionsproblem, för att minska produktionskostnaderna eller för att förbättra produktens eller SoI:s kapacitet. Alla dessa ändringar kan påverka systemkraven och kan kräva omkvalificering av systemet omkvalificering, omverifiering omverifiering eller omvalidering omvalidering omvalidering. Alla sådana ändringar kräver SE-bedömning innan ändringarna godkänns.
Användningsskede
En viktig aspekt av produktlivscykelhanteringen är tillhandahållandet av stödsystem som är avgörande för att upprätthålla driften av produkten. Medan den levererade produkten eller tjänsten kan ses som det snäva system av intresse (NSOI) för en förvärvare-förvärvare, måste förvärvaren också införliva stödsystemen i ett bredare system av intresse (WSOI). Dessa stödsystem bör ses som systemtillgångar som vid behov aktiveras som svar på en situation som uppstått i samband med driften av NSOI. Samlingsnamnet för uppsättningen stödsystem är det integrerade logistikstödsystemet (ILS).
Det är viktigt att ha en helhetssyn när man definierar, producerar och driver systemprodukter och -tjänster. I figur 7 skildras förhållandet mellan systemets utformning och utveckling och ILS-kraven.
Kraven på tillförlitlighet, som resulterar i behovet av underhållbarhet och testbarhet, är drivande faktorer.
Support Stage
I supportstadiet tillhandahålls SoI tjänster som möjliggör fortsatt drift. Modifieringar kan föreslås för att lösa stödbarhetsproblem, för att minska driftskostnaderna eller för att förlänga systemets livslängd. Dessa ändringar kräver SE-bedömning för att undvika förlust av systemets kapacitet under drift. Motsvarande tekniska process är underhållsprocessen.
Retableringsfasen
I retableringsfasen tas SoI och dess tillhörande tjänster bort från drift. SE-verksamheten i detta skede är i första hand inriktad på att se till att kraven för bortskaffande uppfylls. I själva verket är planeringen av bortskaffandet en del av systemdefinitionen under konceptstadiet. Erfarenheterna från 1900-talet visade upprepade gånger på konsekvenserna av att systemets avveckling och bortskaffande inte beaktades från början. I början av 2000-talet har många länder ändrat sina lagar för att hålla skaparen av ett SoI ansvarig för korrekt bortskaffande av systemet i slutet av dess livscykel.
Life Cycle Reviews
För att kontrollera ett projekts framskridande planeras olika typer av granskningar. De vanligaste är följande, även om namnen inte är allmängiltiga:
- Systemkravsgranskningen (SRR) planeras för att verifiera och validera uppsättningen systemkrav innan den detaljerade konstruktionsverksamheten inleds.
- Den preliminära konstruktionsgranskningenPreliminär konstruktionsgranskning (PDR) planeras för att verifiera och validera systemkraven, konstruktionsartefakterna och rättfärdigande element i slutet av den första tekniska slingan (även känd som ”design-to”-grinden).
- Den kritiska konstruktionsgranskningenDen kritiska konstruktionsgranskningen (CDR) planeras för att verifiera och validera systemkraven, konstruktionsföremålen och rättfärdigande element i slutet av den sista tekniska slingan (konstruktionerna ”build-to” och ”code-to” släpps efter denna granskning).
- IntegreringIntegrering, verifieringVerifiering och valideringValideringsgranskningar planeras när komponenterna sätts samman till delsystem och element på högre nivå. En sekvens av granskningar hålls för att säkerställa att allt integreras korrekt och att det finns objektiva bevis för att alla krav har uppfyllts. Det bör också finnas en validering under processen som visar att systemet, så som det utvecklas, kommer att uppfylla intressenternas krav (se figur 7).
- Den slutliga valideringsgranskningen genomförs i slutet av integrationsfasen.
- Andra ledningsrelaterade granskningar kan planeras och genomföras för att kontrollera att arbetet fortskrider på ett korrekt sätt, baserat på typen av system och de risker som är förknippade med det.
Works Cited
Eichmueller, P. and B. Foreman. 2010. S3000LTM. Bryssel, Belgien: Aerospace and Defence Industries Association of Europe (ASD)/Aerospace Industries Association (AIA).
Faisandier, A. 2012. Systemarkitektur och design. Belberaud, Frankrike: Sinergy’Com.
Forsberg, K., H. Mooz och 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 resa genom systemlandskapet. London, UK: College Publications, Kings College, UK.
Primära referenser
Beedle, M., et al. 2009. ”The Agile Manifesto: Principles behind the Agile Manifesto”. i The Agile Manifesto . Tillgänglig den 04 december 2014 på www.agilemanifesto.org/principles.html
Boehm, B. och R. Turner. 2004. Balansering av smidighet och disciplin. New York, NY, USA: Addison-Wesley.
Fairley, R. 2009. Managing and Leading Software Projects. New York, NY, USA: J. Wiley & Sons.
Forsberg, K., H. Mooz och H. Cotterman. 2005. Visualisering av projektledning. 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 resa genom systemlandskapet. Kings College, UK: College Publications.
Pew, R. och A. Mavor (red.) 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.
Andra referenser
Anderson, D. 2010. Kanban. Sequim, WA, USA: Blue Hole Press.
Baldwin, C. och 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 . Tillgänglig 2010. Tillgänglig på: www.agilemanifesto.org/principles.html
Biffl, S., A. Aurum, B. Boehm, H. Erdogmus och P. Gruenbacher (red.). 2005. Värdebaserad programvaruteknik. New York, NY, USA: Springer.
Boehm, B. 1988. ”A Spiral Model of Software Development”. IEEE Computer 21(5): 61-72.
Boehm, B. 2006. ”Några framtida trender och konsekvenser för system- och programvaruteknikprocesser”. Systems Engineering. 9(1): 1-19.
Boehm, B., A. Egyed, J. Kwan, D. Port, A. Shah och R. Madachy. 1998. ”Användning av WinWin-spiralmodellen: A Case Study”. IEEE Computer. 31(7): 33-44.
Boehm, B., R. Turner, J. Lane, S. Koolmanojwong. 2014 (i tryck). Att omfamna spiralmodellen: Skapa framgångsrika system med spiralmodellen för inkrementellt engagemang. Boston, MA, USA: Addison Wesley.
Castellano, D.R. 2004. ”Top Five Quality Software Projects”. CrossTalk. 17(7) (juli 2004): 4-19. Tillgänglig på:
Checkland, P. 1981. Systems Thinking, Systems Practice. New York, NY, USA: Wiley.
Crosson, S. och B. Boehm. 2009. ”Adjusting Software Life cycle Anchorpoints”: 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 och N. Moe (red.). 2010. ”Agile Software Development: Current Research and Future Directions. Kapitel i B. Boehm, J. Lane, S. Koolmanjwong och R. Turner, Architected Agile Solutions for Software-Reliant Systems. New York, NY, USA: Springer.
Dorner, D. 1996. Logiken bakom ett misslyckande. 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. Louis, MO, USA.
Forsberg, K. 2010. ”Projekt börjar inte 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. Målet. 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. System- och programvaruteknik, del 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. System- och programvaruteknik — Systemlivscykelprocesser. 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. Tillgänglig på: http://www.crosstalkonline.org/storage/issue-archives/2003/200307/200307-0-Issue.pdf.
Kruchten, P. 1999. Rational Unified Process. New York, NY, USA: Addison Wesley.
Landis, T. R. 2010. Lockheed Blackbird-familjen (A-12, YF-12, D-21/M-21 & SR-71). North Branch, MN, USA: Specialty Press.
Madachy, R. 2008. Dynamik i programvaruprocesser. 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. Systemteknik före milstolpe A och i tidig fas. Washington, DC, USA: The National Academies Press.
Osterweil, L. 1987. ”Software Processes are Software Too”. Förhandlingar från SEFM 2011: 9th International Conference on Software Engineering. Monterey, CA, USA.
Poppendeick, M. och T. Poppendeick. 2003. Lean Software Development: an Agile Toolkit. New York, NY, USA: Addison Wesley.
Rechtin, E. 1991. Systemarkitektur: Creating and Building Complex Systems. Upper Saddle River, NY, USA: Prentice-Hall.
Rechtin, E. och M. Maier. 1997. The Art of System Architecting. Boca Raton, FL, USA: CRC Press.
Schwaber, K. och M. Beedle. 2002. Agil programvaruutveckling med Scrum. Upper Saddle River, NY, USA: Prentice Hall.
Spruill, N. 2002. ”Top Five Quality Software Projects”. CrossTalk. 15(1) (januari 2002): 4-19. Tillgänglig 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. Tillgänglig på: http://www.crosstalkonline.org/storage/issue-archives/2005/200509/200509-0-Issue.pdf.
Warfield, J. 1976. Samhällssystem: Planning, Policy, and Complexity. New York, NY, USA: Wiley.
Womack, J. och D. Jones. 1996. Lean Thinking. New York, NY, USA: Simon and Schuster.
Relevanta videor=
- Grundläggande introduktion till systemteknik (V-metoden)
- Grundläggande introduktion till systemteknik (V-metoden) Del 2 av 2