Modele procesów cyklu życia systemu: Vee

Lead Authors: Dick Fairley, Kevin Forsberg, Contributing Author: Ray Madachy

Istnieje duża liczba modeli procesów cyklu życia. Jak omówiono w artykule System Life Cycle Process Drivers and Choices, modele te dzielą się na trzy główne kategorie: (1) przede wszystkim procesy z góry określone i sekwencyjne; (2) przede wszystkim procesy ewolucyjne i współbieżne (np. racjonalny proces zunifikowany oraz różne formy modeli Vee i spiralnego); oraz (3) przede wszystkim procesy interpersonalne i nieograniczone (np. rozwój zwinny, Scrum, programowanie ekstremalne (XP), metoda dynamicznego rozwoju systemu oraz procesy oparte na innowacjach).

W niniejszym artykule skupiono się w szczególności na modelu Vee jako podstawowym przykładzie procesów z góry określonych i sekwencyjnych. W tej dyskusji ważne jest, aby zauważyć, że model Vee i jego odmiany dotyczą tego samego podstawowego zestawu działań inżynierii systemów (SE). Kluczową różnicą pomiędzy tymi modelami jest sposób, w jaki grupują i reprezentują wyżej wymienione działania SE.

Ogólne implikacje stosowania modelu Vee do projektowania i rozwoju systemu są omówione poniżej; aby uzyskać bardziej szczegółowe zrozumienie, w jaki sposób ten model cyklu życia wpływa na działania inżynierii systemów, należy zapoznać się z innymi obszarami wiedzy (KA) w części 3.

Pierwotnie wstępnie określony i sekwencyjny model procesu: The Vee Model

Sekwencyjna wersja Modelu Vee jest przedstawiona na Rysunku 1. Jego rdzeń obejmuje sekwencyjny postęp planów, specyfikacji i produktów, które są bazowane i poddawane zarządzaniu konfiguracją. Pionowa, dwugłowa strzałka umożliwia projektom wykonywanie równoległych analiz możliwości i ryzyka, jak również ciągłą walidację w trakcie procesu. Model Vee obejmuje trzy pierwsze etapy cyklu życia wymienione w tabeli „Generic Life Cycle Stages” podręcznika INCOSE Systems Engineering Handbook: badania eksploracyjne, koncepcja i rozwój (INCOSE 2012).

Rysunek 1. Lewa strona modelu sekwencyjnego Vee (Forsberg, Mooz, i Cotterman 2005). Przedrukowano za zgodą firmy John Wiley & Sons Inc. All other rights are reserved by the copyright owner.

Model Vee popiera definicję INCOSE Systems Engineering Handbook (INCOSE 2012) dotyczącą etapów cyklu życia i ich celów lub działań, jak pokazano na rysunku 2 poniżej.

Rysunek 2. Przykład etapów, ich celów i głównych bramek decyzyjnych. (SEBoK Original)

Podręcznik INCOSE Systems Engineering Handbook 3.2.2 zawiera bardziej szczegółową wersję diagramu Vee (2012, Rysunki 3-4, str. 27), która włącza działania cyklu życia do bardziej ogólnego modelu Vee. Podobny diagram, opracowany w amerykańskim Defense Acquisition University (DAU), można zobaczyć na rysunku 3 poniżej.

Rysunek 3. Diagram aktywności Vee (Prosnik 2010). Wydane przez Defense Acquisition University (DAU)/U.S. Department of Defense (DoD).

Zastosowanie modelu Vee

Lawson (Lawson 2010) omawia działania na każdym etapie cyklu życia i zauważa, że przydatne jest rozważenie struktury ogólnego modelu etapów cyklu życia dla dowolnego typu systemu interesów (SoI), jak przedstawiono na Rysunku 4. Ten model (T) wskazuje, że jeden lub więcej etapów definiowania poprzedza etap(y) produkcji, w którym(ch) implementacja (nabycie, dostarczenie lub rozwój) dwóch lub więcej elementów systemu została zakończona.

Rysunek 4. Ogólna (T) struktura etapowa modeli cyklu życia systemu (Lawson 2010). Przedrukowano za zgodą Harolda Lawsona. Wszelkie inne prawa są zastrzeżone przez właściciela praw autorskich.

Rysunek 5 przedstawia generyczne etapy cyklu życia dla różnych interesariuszy, od organizacji normalizacyjnej (ISO/IEC) do organizacji komercyjnych i rządowych. Chociaż etapy te różnią się w szczegółach, wszystkie mają podobny format sekwencyjny, który kładzie nacisk na podstawowe działania, jak zauważono na Rysunku 2 (definicja, produkcja i wykorzystanie/wycofanie).

Rysunek 5. Porównanie modeli cyklu życia (Forsberg, Mooz, and Cotterman 2005). Przedrukowano za zgodą John Wiley & Sons. All other rights are reserved by the copyright owner.

Należy zauważyć, że wiele działań w całym cyklu życia jest iterowanych. Jest to przykład rekurencji (glosariusz)rekurencji (glosariusz) omówionej w części 3 Wprowadzenie.

Fundamenty etapów cyklu życia i fazy zarządzania programem

Dla tej dyskusji ważne jest, aby zauważyć, że:

• Termin etap odnosi się do różnych stanów systemu podczas jego cyklu życia; niektóre etapy mogą nakładać się na siebie w czasie, takie jak etap wykorzystania i etap wsparcia. Termin „etap” jest używany w ISO/IEC/IEEE 15288.

• Termin „faza” odnosi się do różnych etapów programu, które wspierają i zarządzają życiem systemu; fazy zazwyczaj nie nakładają się na siebie. Termin „faza” jest używany w wielu dobrze ugruntowanych modelach jako odpowiednik terminu „etap.”

Zarządzanie programemZarządzanie programem wykorzystuje fazy, kamienie milowe i bramki decyzyjne, które są używane do oceny ewolucji systemu poprzez jego różne etapy. Etapy zawierają czynności wykonywane w celu osiągnięcia celów i służą do kontroli i zarządzania sekwencją etapów oraz przejściami pomiędzy poszczególnymi etapami. Dla każdego projektu istotne jest zdefiniowanie i opublikowanie terminów i związanych z nimi definicji używanych w poszczególnych projektach, aby zminimalizować nieporozumienia.

Typowy program składa się z następujących faz:

• Faza badań wstępnych, w której identyfikuje się potencjalne możliwości zaspokojenia potrzeb użytkowników za pomocą nowych rozwiązań, które mają sens biznesowy.
• Faza wykonalności polega na badaniu wykonalności alternatywnych koncepcji w celu osiągnięcia drugiej bramki decyzyjnej przed rozpoczęciem etapu realizacji. Podczas fazy wykonalności, wymagania interesariuszy i wymagania systemowe są identyfikowane, wykonalne rozwiązania są identyfikowane i badane, a wirtualne prototypy (glosariusz) prototypów (glosariusz) mogą być wdrożone. W tej fazie decyzja o podjęciu dalszych działań opiera się na:
  • czy koncepcja jest wykonalna i uważa się, że jest w stanie przeciwdziałać zidentyfikowanemu zagrożeniu lub wykorzystać nadarzającą się okazję;
  • czy koncepcja jest wystarczająco dojrzała, aby uzasadnić dalszy rozwój nowego produktu lub linii produktów; oraz
  • czy zatwierdzić propozycję wygenerowaną w odpowiedzi na zapytanie ofertowe.
• Faza wykonawcza obejmuje działania związane z czterema etapami cyklu życia systemu: rozwojem, produkcją, wykorzystaniem i wsparciem. Zazwyczaj z czynnościami wykonawczymi związane są dwie bramki decyzyjne i dwa kamienie milowe. Pierwszy kamień milowy daje kierownictwu możliwość przejrzenia planów wykonania przed wydaniem zgody. Drugi kamień milowy daje możliwość przeglądu postępów przed podjęciem decyzji o rozpoczęciu produkcji. Bramki decyzyjne podczas realizacji mogą być wykorzystane do określenia, czy produkować opracowany SoI i czy go ulepszyć lub wycofać.

Te poglądy na zarządzanie programem mają zastosowanie nie tylko do SoI, ale także do jego elementów i struktury.

Etapy cyklu życia

Odmiany modelu Vee dotyczą tych samych ogólnych etapów cyklu życia:

• Nowe projekty zazwyczaj rozpoczynają się od fazy badań rozpoznawczych, która na ogół obejmuje działania związane z definiowaniem koncepcji, a w szczególności tematy analizy biznesowej lub analizy misji oraz zrozumienie potrzeb i wymagań interesariuszy. Dojrzewają one w miarę przechodzenia projektu z fazy eksploracji do fazy koncepcji do fazy rozwoju.
• Faza produkcji obejmuje działania związane z definicją systemu i realizacją systemu, a także opracowanie wymagań systemowych (glosariusz)wymagań (glosariusz) i architektury (glosariusz)architektury (glosariusz) poprzez weryfikację i walidację.
• Faza wykorzystania obejmuje działania związane z wdrożeniem systemu i jego eksploatacją.
• Faza wsparcia obejmuje działania związane z utrzymaniem systemu, logistyką oraz zarządzaniem życiem produktu i usług, które mogą obejmować działania takie jak przedłużenie życia systemu lub aktualizacje zdolności, uaktualnienia i modernizacje.
• Faza wycofania obejmuje działania związane z usuwaniem i wycofywaniem, chociaż w niektórych modelach działania takie jak przedłużenie okresu eksploatacji lub aktualizacje zdolności, uaktualnienia i modernizacje są zgrupowane w fazie „wycofania”.

Dodatkowe informacje na temat każdego z tych etapów można znaleźć w poniższych sekcjach (patrz linki do dodatkowych artykułów Części 3 powyżej w celu uzyskania dalszych szczegółów). Należy zauważyć, że te etapy cyklu życia oraz działania w każdym z nich są wspierane przez zestaw procesów zarządzania inżynierią systemów.

Eksploracyjny etap badań

Analiza i uzgodnienie wymagań użytkownika jest częścią eksploracyjnego etapu badań i ma krytyczne znaczenie dla rozwoju udanych systemów. Bez właściwego zrozumienia potrzeb użytkownika, każdy system jest narażony na ryzyko zbudowania go w celu rozwiązania niewłaściwych problemów. Pierwszym krokiem w fazie badań rozpoznawczych jest zdefiniowanie wymagań i ograniczeń użytkownika (oraz interesariuszy). Kluczową częścią tego procesu jest ustalenie wykonalności spełnienia wymagań użytkownika, w tym ocena gotowości technologicznej. Podobnie jak w przypadku wielu działań SE, jest to często wykonywane iteracyjnie, a potrzeby i wymagania interesariuszy są ponownie analizowane w miarę pojawiania się nowych informacji.

Ostatnie badanie przeprowadzone przez National Research Council (National Research Council 2008) skupiło się na skróceniu czasu rozwoju projektów US Air Force. Raport stwierdza, że „po prostu inżynieria systemów jest tłumaczeniem potrzeb użytkownika na definicję systemu i jego architektury poprzez iteracyjny proces, którego wynikiem jest efektywny projekt systemu.” Iteracyjne zaangażowanie z interesariuszami jest krytyczne dla sukcesu projektu.

Z wyjątkiem pierwszej i ostatniej bramy decyzyjnej projektu, bramy są wykonywane jednocześnie. Patrz rysunek 6 poniżej.

Rysunek 6. Harmonogramowanie faz rozwoju. (SEBoK Original)

Faza koncepcyjna

Podczas fazy koncepcyjnej tworzone są alternatywne koncepcje w celu określenia najlepszego podejścia do zaspokojenia potrzeb interesariuszy. Poprzez przewidywanie alternatyw i tworzenie modeli, w tym odpowiednich prototypów, potrzeby interesariuszy zostaną wyjaśnione, a kwestie napędowe uwypuklone. Może to prowadzić do przyrostowego lub ewolucyjnego podejścia do rozwoju systemu. Kilka różnych koncepcji może być badanych równolegle.

Etap rozwoju

Wybrana(e) koncepcja(e) zidentyfikowana(e) w etapie koncepcji jest(są) szczegółowo opracowywana(e) aż do najniższego poziomu w celu wytworzenia rozwiązania, które spełnia wymagania interesariuszy. Na tym etapie istotne jest kontynuowanie zaangażowania użytkownika poprzez walidację wewnątrzprocesową (strzałka w górę na modelach Vee). W przypadku sprzętu odbywa się to za pomocą częstych przeglądów programu i przedstawiciela(-i) klienta (jeśli jest to właściwe). W przypadku rozwoju zwinnego praktyką jest włączenie przedstawiciela klienta do zespołu rozwojowego.

Etap produkcyjny

Etap produkcyjny to etap, w którym ISW jest konstruowany lub wytwarzany. Modyfikacje produktu mogą być wymagane w celu rozwiązania problemów produkcyjnych, zmniejszenia kosztów produkcji lub zwiększenia możliwości produktu lub SoI. Każda z tych modyfikacji może mieć wpływ na wymagania systemowe i może wymagać ponownej kwalifikacji systemu, ponownej weryfikacji lub ponownej walidacji. Wszystkie takie zmiany wymagają oceny SE przed zatwierdzeniem zmian.

Etap użytkowania

Ważnym aspektem zarządzania cyklem życia wyrobu jest zapewnienie systemów wspierających, które są istotne w podtrzymaniu działania wyrobu. Podczas gdy dostarczony produkt lub usługa mogą być postrzegane jako wąski system zainteresowania (NSOI) dla jednostki nabywającej, jednostka nabywająca musi również włączyć systemy wspierające do szerszego systemu zainteresowania (WSOI). Te systemy wspierające powinny być postrzegane jako aktywa systemowe, które w razie potrzeby są aktywowane w odpowiedzi na sytuację, która pojawiła się w odniesieniu do działania NSOI. Zbiorcza nazwa zestawu systemów wspierających to zintegrowany system wsparcia logistycznego (ILS).

Podczas definiowania, wytwarzania i eksploatacji produktów i usług systemowych istotne jest posiadanie holistycznego spojrzenia. Na rysunku 7 przedstawiono związek pomiędzy projektowaniem i rozwojem systemu a wymaganiami ILS.

Rysunek 7. Powiązanie ILS z cyklem życia systemu (Eichmueller i Foreman 2009). Przedrukowano za zgodą Komitetu Sterującego ASD/AIA S3000L. Wszelkie inne prawa są zastrzeżone przez właściciela praw autorskich.

Wymagania dotyczące niezawodności, skutkujące potrzebą utrzymania i testowalności, są czynnikami napędowymi.

Etap wsparcia

W etapie wsparcia SoI otrzymuje usługi, które umożliwiają kontynuację działania. Modyfikacje mogą być proponowane w celu rozwiązania problemów związanych z obsługą techniczną, zmniejszenia kosztów operacyjnych lub przedłużenia okresu eksploatacji systemu. Zmiany te wymagają oceny SE, aby uniknąć utraty możliwości systemu w trakcie eksploatacji. Odpowiednim procesem technicznym jest proces utrzymania.

Etap wycofania

Na etapie wycofania SoI i związane z nim usługi są wycofywane z eksploatacji. Działania SE na tym etapie koncentrują się przede wszystkim na zapewnieniu spełnienia wymagań dotyczących usuwania. W rzeczywistości planowanie utylizacji jest częścią definicji systemu na etapie koncepcji. Doświadczenia z XX wieku wielokrotnie pokazywały konsekwencje, gdy wycofanie systemu z eksploatacji i jego utylizacja nie były brane pod uwagę od samego początku. Na początku XXI wieku wiele krajów zmieniło swoje prawo, aby obarczyć twórcę SI odpowiedzialnością za właściwe pozbycie się systemu po zakończeniu jego eksploatacji.

Przeglądy cyklu życia

Aby kontrolować postępy projektu, planuje się różne rodzaje przeglądów. Najczęściej stosowane z nich wymieniono poniżej, choć nazwy nie są uniwersalne:

• Przegląd wymagań systemowych (SRR) jest planowany w celu weryfikacji i walidacji zbioru wymagań systemowych przed rozpoczęciem szczegółowych działań projektowych.
• Przegląd projektu wstępnegoPrzegląd projektu wstępnego (PDR) jest planowany w celu weryfikacji i walidacji zestawu wymagań systemowych, artefaktów projektowych oraz elementów uzasadnienia na końcu pierwszej pętli inżynierskiej (znanej również jako bramka „design-to”).
• Przegląd krytyczny projektuPrzegląd krytyczny projektu (CDR) jest planowany w celu weryfikacji i walidacji zestawu wymagań systemowych, artefaktów projektowych i elementów uzasadnienia na końcu ostatniej pętli inżynierskiej (projekty „build-to” i „code-to” są uwalniane po tym przeglądzie).
• Przeglądy integracji, weryfikacji i walidacjiPrzeglądy integracji, weryfikacji i walidacji są planowane w miarę jak komponenty są montowane w podsystemy i elementy wyższego poziomu. Sekwencja przeglądów jest przeprowadzana w celu zapewnienia, że wszystko jest prawidłowo zintegrowane i że istnieją obiektywne dowody, że wszystkie wymagania zostały spełnione. Należy również przeprowadzić walidację w procesie, że system, w miarę jego rozwoju, będzie spełniał wymagania interesariuszy (patrz rysunek 7).
• Końcowy przegląd walidacyjny jest przeprowadzany na koniec fazy integracji.
• Inne przeglądy związane z zarządzaniem mogą być planowane i przeprowadzane w celu kontroli prawidłowego postępu prac, w oparciu o typ systemu i związane z nim ryzyko.

Rysunek 8. Prawa strona modelu Vee (Forsberg, Mooz, and Cotterman 2005). Przedrukowano za zgodą firmy John Wiley & Sons Inc. All other rights are reserved by the copyright owner.

Works Cited

Eichmueller, P. and B. Foreman. 2010. S3000LTM. Bruksela, Belgia: Aerospace and Defence Industries Association of Europe (ASD)/Aerospace Industries Association (AIA).

Faisandier, A. 2012. Architektura i projektowanie systemów. Belberaud, Francja: Sinergy’Com.

Forsberg, K., H. Mooz, and 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, wersja 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.

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

Primary References

Beedle, M., et al. 2009. „The Agile Manifesto: Principles behind the Agile Manifesto”. in The Agile Manifesto . Accessed December 04 2014 at www.agilemanifesto.org/principles.html

Boehm, B. and R. Turner. 2004. Balancing Agility and Discipline. 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, and 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, wersja 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.

Lawson, H. 2010. A Journey Through the Systems Landscape. Kings College, 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.

Royce, W.E. 1998. Software Project Management: A Unified Framework. New York, NY, USA: Addison Wesley.

Additional References

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

Baldwin, C. i 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”. in The Agile Manifesto . Accessed 2010. Dostępne pod adresem: www.agilemanifesto.org/principles.html

Biffl, S., A. Aurum, B. Boehm, H. Erdogmus, and P. Gruenbacher (eds.). 2005. Value-Based Software Engineering. New York, NY, USA: Springer.

Boehm, B. 1988. „A Spiral Model of Software Development.” IEEE Computer 21(5): 61-72.

Boehm, B. 2006. „Some Future Trends and Implications for Systems and Software Engineering Processes.” Systems Engineering. 9(1): 1-19.

Boehm, B., A. Egyed, J. Kwan, D. Port, A. Shah, and R. Madachy. 1998. „Using the WinWin Spiral Model: A Case Study.” IEEE Computer. 31(7): 33-44.

Boehm, B., R. Turner, J. Lane, S. Koolmanojwong. 2014 (w druku). Embracing the Spiral Model: Creating Successful Systems with the Incremental Commitment Spiral Model. Boston, MA, USA: Addison Wesley.

Castellano, D.R. 2004. „Top Five Quality Software Projects”. CrossTalk. 17(7) (lipiec 2004): 4-19. Dostępne pod adresem: http://www.crosstalkonline.org/storage/issue-archives/2004/200407/200407-0-Issue.pdf

Checkland, P. 1981. Myślenie systemowe, praktyka systemowa. New York, NY, USA: Wiley.

Crosson, S. i 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. and N. Moe (eds.). 2010. „Agile Software Development: Current Research and Future Directions.” Rozdział w B. Boehm, J. Lane, S. Koolmanjwong, and 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 lipca 1995. St. Louis, MO, USA.

Forsberg, K. 2010. „Projects Don’t Begin With Requirements.” 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. Emergencja. New York, NY, USA: Perseus Books.

ISO/IEC. 2010. Inżynieria systemów i oprogramowania, Część 1: Guide for Life Cycle Management. Genewa, Szwajcaria: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 24748-1:2010.

ISO/IEC/IEEE. 2015. Inżynieria systemów i oprogramowania — Procesy cyklu życia systemu. Genewa, Szwajcaria: 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. Genewa, Szwajcaria: 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) (lipiec 2003): 4-19. Dostępne na: 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 Family (A-12, YF-12, D-21/M-21 & SR-71). North Branch, MN, USA: Specialty Press.

Madachy, R. 2008. Dynamika procesów oprogramowania. Hoboken, NJ, USA: Wiley.

Maranzano, J.F., S.A. Rozsypal, G.H. Zimmerman, G.W. Warnken, P.E. Wirth, D.W. Weiss. 2005. „Przeglądy architektoniczne: Practice and Experience.” IEEE Software. 22(2): 34-43.

National Research Council of the National Academies (USA). 2008. Pre-Milestone A and Early-Phase Systems Engineering. Washington, DC, USA: The National Academies Press.

Osterweil, L. 1987. „Software Processes are Software Too.” Proceedings of the SEFM 2011: 9th International Conference on Software Engineering. Monterey, CA, USA.

Poppendeick, M. and T. Poppendeick. 2003. Lean Software Development: an Agile Toolkit. 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., and M. Maier. 1997. The Art of System Architecting. Boca Raton, FL, USA: CRC Press.

Schwaber, K. i M. Beedle. 2002. Agile Software Development with Scrum. Upper Saddle River, NY, USA: Prentice Hall.

Spruill, N. 2002. „Top Five Quality Software Projects.” CrossTalk. 15(1) (styczeń 2002): 4-19. Dostępne pod adresem: 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) (wrzesień 2005): 4-13. Dostępne pod adresem 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. and D. Jones. 1996. Lean Thinking. New York, NY, USA: Simon and Schuster.

Relevant Videos=

• Podstawowe wprowadzenie do inżynierii systemów (V-metoda)
• Podstawowe wprowadzenie do inżynierii systemów (V-metoda) Część 2 z 2