Life Cycle Models

Lead Authors: Kevin Forsberg, Rick Adcock, Contributing Author: Alan Faisandier

Model cyklu życia jest jedną z kluczowych koncepcji inżynierii systemów (SE). Cykl życia systemu składa się zazwyczaj z serii etapów regulowanych przez zestaw decyzji zarządczych, które potwierdzają, że system jest wystarczająco dojrzały, aby opuścić jeden etap i wejść w kolejny.

Tematy

Każda część SEBoK jest podzielona na obszary wiedzy (KA), które są grupami informacji z powiązanym tematem. KA z kolei podzielone są na tematy. Ten KA zawiera następujące tematy:

• System Life Cycle Process Drivers and Choices
• System Life Cycle Process Models: Vee
• Modele procesów cyklu życia systemu: Iterative
• Integracja modeli procesów i produktów
• Lean Engineering

Zobacz artykuł Matryca przykładów implementacji dla odwzorowania studiów przypadków i winiet zawartych w części 7 do tematów poruszanych w części 3.

Typ produktów/usług o wartości dodanej

Generyczny Model Cyklu Życia pokazuje tylko jednoetapowe podejście do przechodzenia przez etapy cyklu życia systemu. Dodawanie wartości (jako produktu, usługi lub obu), jest wspólnym celem wszystkich przedsiębiorstw, zarówno publicznych jak i prywatnych, nastawionych na zysk lub non-profit. Wartość jest wytwarzana poprzez dostarczanie i integrowanie elementów systemu w produkt lub usługę zgodnie z opisem systemu i przekształcanie go w produktywne zastosowanie. Te rozważania na temat wartości będą prowadzić do różnych form ogólnego podejścia do zarządzania cyklem życia przedstawionego na rysunku 1. Niektóre przykłady są następujące (Lawson 2010):

• Przedsiębiorstwo produkcyjne produkuje nakrętki, śruby i podkładki zabezpieczające, a następnie sprzedaje swoje produkty jako elementy wartości dodanej do wykorzystania przez inne przedsiębiorstwa; z kolei te przedsiębiorstwa integrują te produkty z bardziej kompleksowym systemem wartości dodanej, takim jak samolot lub samochód. Ich wymagania będą zazwyczaj wstępnie określone przez klienta lub przez standardy przemysłowe.

• Przedsiębiorstwo zajmujące się sprzedażą hurtową lub detaliczną oferuje produkty swoim klientom. Jego klienci (osoby fizyczne lub przedsiębiorstwa) nabywają te produkty i wykorzystują je jako elementy w swoich systemach. System wsparcia przedsiębiorstwa będzie prawdopodobnie ewoluował oportunistycznie, w miarę pojawiania się nowych możliwości infrastruktury lub wzorców popytu.

• Komercyjne przedsiębiorstwo usługowe, takie jak bank, sprzedaje swoim klientom różnorodne produkty jako usługi. Obejmuje to rachunki bieżące, rachunki oszczędnościowe, kredyty i zarządzanie inwestycjami. Usługi te stanowią wartość dodaną i są włączane do systemów klientów indywidualnych lub przedsiębiorstw. System wsparcia przedsiębiorstwa usługowego będzie również prawdopodobnie ewoluował w sposób oportunistyczny, w miarę pojawiania się nowych możliwości infrastruktury lub wzorców popytu.

• Rządowe przedsiębiorstwo usługowe świadczy obywatelom usługi, które są bardzo zróżnicowane, ale mogą obejmować takie usługi jak opieka zdrowotna, autostrady i drogi, emerytury, egzekwowanie prawa lub obrona. W stosownych przypadkach, usługi te stają się elementami infrastruktury wykorzystywanymi w większych systemach obejmujących osoby fizyczne i/lub przedsiębiorstwa. Główne inicjatywy, takie jak system kontroli ruchu lotniczego nowej generacji lub system zarządzania kryzysowego na obszarze metropolitalnym (huragan, tajfun, trzęsienie ziemi, tsunami, powódź, pożar), będą wystarczająco złożone, aby zastosować ewolucyjne podejście do rozwoju i wprowadzania na rynek. Na poziomie elementarnym będą prawdopodobnie istniały z góry określone, jednoprzebiegowe cykle życia.

• W przypadku systemów lotniczych i samochodowych, prawdopodobnie istniałby z góry określony, wieloprzebiegowy cykl życia, pozwalający na wykorzystanie wczesnych zdolności w pierwszym przejściu, ale zaprojektowany tak, aby dodać dalsze zdolności zwiększające wartość w późniejszych przejściach.

• Zróżnicowane przedsiębiorstwo zajmujące się tworzeniem oprogramowania dostarcza produkty programowe, które spełniają wymagania (potrzeby) zainteresowanych stron, zapewniając w ten sposób usługi użytkownikom produktów. Będzie musiało być rozwinięte, aby posiadać możliwości, które mogą być dostosowane do wykorzystania w różnych podejściach klientów do cyklu życia, a także możliwości linii produktów, które mogą być szybko i łatwo zastosowane do podobnych projektów systemów klienta. Jego model biznesowy może również obejmować zapewnienie klientowi wsparcia w cyklu życia systemu i możliwości ewolucji.

W ramach tych przykładów istnieją systemy, które pozostają stabilne w rozsądnie długich okresach czasu i te, które zmieniają się szybko. Różnorodność reprezentowana przez te przykłady i ich procesy ilustruje, dlaczego nie istnieje jeden uniwersalny proces, który może być użyty do zdefiniowania określonego cyklu życia systemu. Podejścia do zarządzania i przywództwa muszą uwzględniać rodzaj systemów, ich trwałość oraz potrzebę szybkiej adaptacji do nieprzewidzianych zmian, czy to w konkurencji, technologii, przywództwie, czy priorytetach misji. Z kolei podejście do zarządzania i przywództwa wpływa na rodzaj i liczbę modeli cyklu życia, które są wdrażane, jak również na procesy, które będą stosowane w ramach każdego konkretnego cyklu życia.

Istnieje kilka przyrostowych i ewolucyjnych podejść do sekwencjonowania etapów cyklu życia, aby poradzić sobie z niektórymi z kwestii poruszonych powyżej. W obszarze wiedzy Modele cyklu życia podsumowano szereg przyrostowych i ewolucyjnych modeli cyklu życia, w tym ich główne mocne i słabe strony, a także omówiono kryteria wyboru najlepiej dopasowanego podejścia.

Kategorie modelu cyklu życia

Generyczny model cyklu życia systemu na rysunku 1 nie pasuje jednoznacznie do wszystkich sytuacji. Prosty, precedensowy, kontynuacyjny system może potrzebować tylko jednej fazy na etapie definiowania, podczas gdy złożony system może potrzebować więcej niż dwóch. W przypadku systemów typu build-upon (vs. throwaway) prototypyprototypy, znaczna część rozwoju może mieć miejsce podczas etapu definiowania. Integracja systemu, weryfikacja, walidacja i zatwierdzenie mogą nastąpić po wdrożeniu lub nabyciu elementów systemu. W przypadku oprogramowania, szczególnie testowego i budowanego codziennie, integracja, weryfikacja i walidacja są przeplatane z implementacją elementów. Dodatkowo, z nadchodzącą Trzecią Rewolucją Przemysłową druku trójwymiarowego i produkcji cyfrowej (Whadcock 2012), nie tylko wstępny rozwój, ale również wstępna produkcja może być wykonana na etapie koncepcji.

Oprogramowanie jest elastycznym i plastycznym medium, które ułatwia iteracyjną analizę, projektowanie, konstruowanie, weryfikację i walidację w większym stopniu niż jest to zazwyczaj możliwe w przypadku czysto fizycznych komponentów systemu. Każde powtórzenie iteracyjnego modelu rozwoju dodaje materiał (kod) do rosnącej bazy oprogramowania, w którym rozszerzona baza kodu jest testowana, przerabiana w razie potrzeby i demonstrowana w celu spełnienia wymagań dla linii podstawowej.

Oprogramowanie może być elektronicznie kupowane, sprzedawane, dostarczane i aktualizowane w dowolnym miejscu na świecie w zasięgu komunikacji cyfrowej, co czyni jego logistykę znacznie inną i bardziej opłacalną niż sprzęt. Nie zużywa się, a jego poprawki zmieniają jego zawartość i zachowanie, co sprawia, że testowanie regresyjne jest bardziej złożone niż w przypadku poprawek sprzętu. Jego dyskretna natura dyktuje, że jego testowanie nie może liczyć na ciągłość analityczną jak w przypadku sprzętu. Dodanie 1 do 32767 w 15-bitowym rejestrze nie daje 32768, ale 0 zamiast, jak doświadczono w poważnych sytuacjach, takich jak użycie pocisku Patriot.

Istnieje duża liczba potencjalnych modeli procesów cyklu życia. Należą one do trzech głównych kategorii:

1. głównie procesy predefiniowane i sekwencyjne (np. jednoetapowy model wodospadowy)
2. głównie procesy ewolucyjne i współbieżne (np. lean development, racjonalny zunifikowany proces oraz różne formy modelu żyłkowego i spiralnego)
3. głównie procesy interpersonalne i emergentne (np. zwinny rozwój, scrum, programowanie ekstremalne (XP), metoda dynamicznego rozwoju systemu oraz procesy oparte na innowacjach)

Wyłonienie się zintegrowanych, interaktywnych systemów sprzętowo-programowych sprawiło, że wstępnie określone procesy stały się potencjalnie szkodliwe, ponieważ najbardziej efektywne interfejsy człowiek-system miały tendencję do wyłaniania się wraz z jego użyciem, prowadząc do dalszych odmian procesów, takich jak miękki SE (Warfield 1976, Checkland 1981) oraz procesy integracji człowiek-system (Booher 2003, Pew i Mavor 2007). Do niedawna standardy procesów i modele dojrzałości próbowały objąć każdą ewentualność. Obejmowały one rozbudowane procesy zarządzania zakupami, wyboru źródeł, przeglądów i audytów, zapewnienia jakości, zarządzania konfiguracją i zarządzania dokumentacją, które w wielu przypadkach stawały się nadmiernie zbiurokratyzowane i nieefektywne. Doprowadziło to do wprowadzenia bardziej szczupłych (Ohno 1988; Womack et al. 1990; Oppenheim 2011) i zwinnych (Beck 1999; Anderson 2010) podejść do współbieżnych podejść sprzętowo-programowo-ludzkich, takich jak współbieżne modele vee (Forsberg 1991; Forsberg 2005) i Incremental Commitment Spiral Model (Pew i Mavor 2007; Boehm i Lane 2007).

W następnym artykule dotyczącym System Life Cycle Process Drivers and Choices, te wariacje na temat modeli cyklu życia zostaną zidentyfikowane i przedstawione.

Odpowiedzialność inżynierii systemów

Niezależnie od zastosowanych modeli cyklu życia, rola inżyniera systemów obejmuje cały cykl życia interesującego nas systemu. Inżynierowie systemów zarządzają rozwojem i ewolucją rozwiązania, od zdefiniowania wymagań poprzez eksploatację, aż do wycofania systemu z użycia. Zapewniają, że eksperci z danej dziedziny są odpowiednio zaangażowani, wszystkie korzystne możliwości są wykorzystywane, a wszystkie znaczące ryzyka są identyfikowane i, jeśli to możliwe, ograniczane. Inżynier systemów ściśle współpracuje z kierownikiem projektu w dostosowaniu ogólnego cyklu życia, w tym kluczowych bramek decyzyjnych, do potrzeb ich konkretnego projektu.

Zadania inżynierii systemów są zwykle skoncentrowane na początku cyklu życia; jednak zarówno organizacje komercyjne, jak i rządowe uznają potrzebę SE w całym cyklu życia systemu. Często ten ciągły wysiłek ma na celu modyfikację lub zmianę systemu, produktu lub usługi po jego wejściu do produkcji lub uruchomieniu. W związku z tym, SE jest ważną częścią wszystkich etapów cyklu życia. Podczas etapów produkcji, wsparcia i użytkowania (PSU), na przykład, SE wykonuje analizę wydajności, monitorowanie interfejsu, analizę awarii, analizę logistyczną, śledzenie i analizę proponowanych zmian. Wszystkie te działania są niezbędne do ciągłego wsparcia systemu.

Wszyscy kierownicy projektów muszą zapewnić, że aspekt biznesowy (koszt, harmonogram i wartość) oraz aspekt techniczny cyklu projektu pozostają zsynchronizowane. Często aspekt techniczny napędza projekt. Obowiązkiem inżynierów systemów jest zapewnienie, że rozważane rozwiązania techniczne są zgodne z celami dotyczącymi kosztów i harmonogramu. Może to wymagać współpracy z użytkownikami i klientami, aby zrewidować cele tak, aby mieściły się w granicach biznesowych. Kwestie te wpływają również na potrzebę odpowiedniego rozmieszczenia bramek decyzyjnych w całym cyklu projektu. Chociaż charakter tych bramek decyzyjnych będzie się różnił w zależności od powyższych głównych kategorii, każda z nich będzie obejmować walidację wewnątrzprocesową pomiędzy programistami a użytkownikami końcowymi. Walidacja wewnątrzprocesowa zadaje pytanie: „Czy to, co planujemy lub tworzymy, zaspokoi potrzeby interesariuszy?”. Walidacja wewnątrzprocesowa rozpoczyna się na etapie inicjalizacji projektu podczas odkrywania potrzeb użytkowników i trwa przez codzienne działania, formalne przeglądy bramek decyzyjnych, dostarczanie produktu końcowego lub rozwiązania, operacje, a ostatecznie do zamknięcia systemu i utylizacji.

Works Cited

Anderson, D. 2010. Kanban. Sequim, WA: Blue Hole Press.

Beck, K. 1999. Extreme Programming Explained. Boston, MA: Addison Wesley.

Boehm, B. and J. Lane. 2007. „Using the Incremental Commitment Model to Integrate System Acquisition, Systems Engineering, and Software Engineering”. CrossTalk. October 2007: 4-9.

Booher, H. (ed.) 2003. Podręcznik integracji systemów ludzkich. Hoboken, NJ, USA: Wiley.

Checkland, P. 1999. Systems Thinking, Systems Practice, 2nd ed. Hoboken, NJ, USA: Wiley.

Cusumano, M., and D. Yoffie. 1998. Competing on Internet Time, New York, NY, USA: The Free Press.

Forsberg, K. i H. Mooz. 1991. „The Relationship of System Engineering to the Project Cycle”, Proceedings of INCOSE, October 1991.

Forsberg, K., H. Mooz, and H. Cotterman. 2005. Visualizing Project Management, 3rd ed. Hoboken, NJ: J. Wiley & Sons.

ISO/IEC/IEEE. 2015.Systemy i inżynieria oprogramowania – procesy cyklu życia systemu.Genewa, Szwajcaria: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), Institute of Electrical and Electronics Engineers.ISO/IEC 15288:2015.

Lawson, H. 2010. A Journey Through the Systems Landscape (Podróż przez krajobraz systemów). London, UK: College Publications.

Ohno, T. 1988. Toyota Production System. New York, NY: Productivity Press.

Oppenheim, B. 2011. Lean dla inżynierii systemów. Hoboken, NJ: Wiley.

Pew, R. i A. Mavor (eds.). 2007. Human-System Integration in The System Development Process: A New Look. Washington, DC, USA: The National Academies Press.

Warfield, J. 1976. Inżynieria systemów. Washington, DC, USA: US Department of Commerce (DoC).

Whadcock, I. 2012. „A third industrial revolution.” The Economist. April 21, 2012.

Womack, J.P., D.T. Jones, and D. Roos 1990. The Machine That Changed the World: The Story of Lean Production. New York, NY, USA: Rawson Associates.

Primary References

Blanchard, B.S., and W.J. Fabrycky. 2011. Inżynieria i analiza systemów, 5th ed. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.

Forsberg, K., H. Mooz, H. Cotterman. 2005. Visualizing Project Management, 3rd Ed. Hoboken, NJ: J. Wiley & Sons.

INCOSE. 2012. Podręcznik inżynierii systemów, wersja 3.2.2. San Diego, CA, USA: Międzynarodowa Rada Inżynierii Systemów (INCOSE). INCOSE-TP-2003-002-03.2.2.

Lawson, H. 2010. A Journey Through the Systems Landscape. London, UK: College Publications.

Pew, R. and A. Mavor (Eds.). 2007. Human-System Integration in The System Development Process: A New Look. Washington, DC, USA: The National Academies Press.

Additional References

Chrissis, M., M. Konrad, and S. Shrum. 2003. CMMI: Wytyczne dla integracji procesów i doskonalenia produktów. New York, NY, USA: Addison Wesley.

Larman, C. i B. Vodde. 2009. Scaling Lean and Agile Development. New York, NY, USA: Addison Wesley.

Następujące trzy książki nie są przywoływane w tekście SEBoK, ani nie są „tekstami” inżynierii systemów; jednakże zawierają ważne lekcje inżynierii systemów, a czytelnicy niniejszego SEBOK są zachęcani do ich przeczytania.

Kinder, G. 1998. Statek ze złotem na głębokim błękitnym morzu. New York, NY, USA: Grove Press.

Jest to doskonała książka, która podąża za pomysłem od jego powstania do ostatecznie udanej realizacji. Chociaż inżynieria systemów nie jest omawiana, jest ona wyraźnie zilustrowana w całym procesie od wczesnej definicji projektu do alternatywnego rozwoju koncepcji do etapowych eksploracji i „eksperymentów myślowych” do podejmowania wyzwań po drodze. Pokazuje również problem nieprzewidywania krytycznych problemów wykraczających poza zwykły zakres projektu i inżynierii. Zlokalizowanie i wydobycie 24 ton sztabek złota i monet z zatopionego na głębokości 2500 metrów statku zajęło około pięciu lat, ale wygranie batalii prawnej z prawnikami reprezentującymi firmy ubezpieczeniowe, które rościły sobie prawo własności na podstawie 130-letnich polis wystawionych właścicielom złota w 1857 roku, zajęło dziesięć lat.

McCullough, D. 1977. The Path Between the Seas: The Creation of the Panama Canal (1870 – 1914). New York, NY, USA: Simon & Schuster.

Chociaż „inżynieria systemów” nie jest wymieniona, książka ta podkreśla wiele kwestii związanych z inżynierią systemów i ilustruje potrzebę SE jako dyscypliny. Książka ilustruje również niebezpieczeństwo zastosowania wcześniej udanej koncepcji (kanał na poziomie morza zastosowany w Suezie dekadę wcześniej) w podobnej, ale innej sytuacji. Ferdinand de Lesseps kierował zarówno projektem sueskim, jak i panamskim. Ilustruje to niebezpieczeństwo braku cyklu projektowego opartego na faktach i znaczących bramek decyzyjnych w całym cyklu projektowym. Podkreśla również niebezpieczeństwo związane z brakiem widoczności statusu projektu. Po pięciu latach od rozpoczęcia dziesięcioletniego projektu inwestorom powiedziano, że projekt jest ukończony w ponad 50%, podczas gdy w rzeczywistości wykonano jedynie 10% prac. Druga runda rozwoju pod kierownictwem Stevensa w 1904 roku skupiła się na „przesuwaniu ziemi”, a nie na kopaniu kanału, co stanowiło koncepcję inżynierii systemowej kluczową dla ukończenia kanału. The Path Between the Seas zdobył National Book Award dla historii (1978), the Francis Parkman Prize (1978), the Samuel Eliot Morison Award (1978), and the Cornelius Ryan Award (1977).

Shackleton, Sir E.H. 2008. (Pierwotnie opublikowana w przez William Heinemann, Londyn, 1919). South: The Last Antarctic Expedition of Shackleton and the Endurance. Guilford, CT, USA: Lyons Press.

Jest to niesamowita historia ostatniej antarktycznej wyprawy Shackletona i Endurance w latach 1914-1917. Lekcja inżynierii systemów polega na ciągłej, codziennej ocenie ryzyka przez kapitana, kierownika ekspedycji i załogę, którzy leżeli uwięzieni w arktycznym lodzie przez 18 miesięcy. Przeżyło wszystkich 28 członków załogi.

Relevant Videos

• NASA’s Approach to Systems Engineering- Space Systems Engineering 101 w/ NASA