Weźmy pod uwagę cykl życia oprogramowania, tj. proces jego tworzenia i stosowania od początku do końca. Cykl życia rozpoczyna się w momencie rozpoznania pojawienia się tego oprogramowania, a kończy w momencie jego całkowitej dezaktualizacji. Proces ten składa się z kilku etapów: zdefiniowania wymagań i specyfikacji, projektowania, programowania i utrzymania.

Pierwszy etap, definiowanie wymagań i specyfikacji, można nazwać etapem analizy systemu. Ustala ogólne wymagania oprogramowania: niezawodność, produktywność, poprawność, wszechstronność, wydajność, spójność informacji itp.

Uzupełniane są wymaganiami klienta, obejmującymi ograniczenia czasoprzestrzenne, niezbędne funkcje i możliwości, tryby pracy, wymagania dotyczące dokładności i niezawodności itp., czyli opis systemu tworzony jest z punktu widzenia użytkownika.

Przy ustalaniu specyfikacje(zestaw wymagań i parametrów, jakie musi spełniać oprogramowanie) dokonano dokładnego opisu funkcji oprogramowania, opracowano i zatwierdzono języki wejściowe i pośrednie, formę informacji wyjściowej dla każdego z podsystemów, możliwą interakcję z innym oprogramowaniem opisano systemy, określono sposoby rozbudowy i modyfikacji oprogramowania, opracowano interfejsy serwisowe i główne podsystemy, rozwiązano problemy z bazami danych i zatwierdzono podstawowe algorytmy.

Efektem tego etapu są specyfikacje operacyjno-funkcjonalne zawierające szczegółowy opis oprogramowania. Opracowanie specyfikacji wymaga starannej pracy analityków systemowych będących w stałym kontakcie z klientami, którzy w większości przypadków nie są w stanie sformułować jasnych i realistycznych wymagań.

Specyfikacje operacyjne zawierają informacje o szybkości oprogramowania, zużyciu pamięci, wymaganym sprzęcie, niezawodności itp.

Specyfikacje funkcjonalne określają funkcje, jakie musi realizować oprogramowanie, tj. definiują, co system musi zrobić, a nie jak to zrobić.

Specyfikacje muszą być kompletne, dokładne i jasne. Kompletność eliminuje potrzebę pozyskiwania przez twórców oprogramowania w trakcie swojej pracy od klientów informacji innych niż zawarte w specyfikacjach. Precyzja nie pozwala na różne interpretacje. Jasność oznacza łatwość zrozumienia zarówno przez klienta, jak i dewelopera, jeśli jest interpretowana jednoznacznie.

Wartość specyfikacji:

1. Specyfikacje są zadaniem twórców oprogramowania, a ich realizacja stanowi prawo twórcy.

2. Specyfikacje służą sprawdzeniu gotowości oprogramowania.

3. Specyfikacje stanowią integralną część dokumentacji oprogramowania i ułatwiają konserwację oraz modyfikację oprogramowania,

Drugi etap to projektowanie oprogramowania. Na tym etapie:

1. Tworzona jest struktura oprogramowania i opracowywane są algorytmy określone w specyfikacjach.

2. Ustala się skład modułów, dzieląc je na hierarchiczne poziomy w oparciu o badanie diagramów algorytmów.

3. Wybrano strukturę tablic informacyjnych.

4. Interfejsy międzymodułowe są stałe.

Celem tego etapu jest hierarchiczny podział złożonych zadań tworzenia oprogramowania na podzadania o mniejszej złożoności. Efektem prac na tym etapie są specyfikacje poszczególnych modułów, których dalsza dekompozycja jest niepraktyczna.

Trzeci etap - programowanie. Na tym etapie moduły są programowane. Rozwiązania projektowe uzyskane na poprzednim etapie wdrażane są w formie programów. Tworzone są osobne bloki, które łączą się z tworzonym systemem. Jednym z zadań jest świadomy wybór języków programowania. Na tym samym etapie rozwiązywane są wszystkie problemy związane z funkcjami typu komputera.

Czwarty etap - debugowanie oprogramowania polega na sprawdzeniu wszystkich wymagań, wszystkich elementów konstrukcyjnych systemu na tak wielu różnych kombinacjach danych, na ile pozwala zdrowy rozsądek i budżet. Ten etap polega na identyfikacji błędów w programach, sprawdzeniu funkcjonalności oprogramowania i zgodności ze specyfikacjami.

Piąty etap - akompaniament, te. proces poprawiania błędów, koordynacja wszystkich elementów systemu zgodnie z wymaganiami użytkownika, wprowadzanie wszelkich niezbędnych poprawek i zmian.

Przed rozpoczęciem tworzenia oprogramowania należy przeprowadzić działania marketingowe.

Marketing przeznaczony do badania wymagań dla tworzonego oprogramowania (technicznego, oprogramowania, użytkownika). Badane są również istniejące analogi i produkty konkurencyjne. Oceniane są zasoby materialne, robocze i finansowe potrzebne do rozwoju oraz ustalane są przybliżone ramy czasowe rozwoju. Etapy tworzenia oprogramowania opisuje GOST 19.102-77. Zgodnie z nią podajemy nazwy i krótki opis każdego etapu (patrz tabela 1). Norma ta określa etapy opracowywania programów i dokumentacji programów dla komputerów, kompleksów i systemów, niezależnie od ich przeznaczenia i zakresu zastosowania.

Tabela 1

Etapy rozwoju, etapy i treść pracy nad stworzeniem oprogramowania

Cykl życia oprogramowania

Jednym z podstawowych pojęć metodologii projektowania oprogramowania jest koncepcja cyklu życia oprogramowania (SO). Cykl życia oprogramowania to proces ciągły, który rozpoczyna się od momentu podjęcia decyzji o potrzebie jego stworzenia, a kończy w momencie jego całkowitego wycofania z eksploatacji.

Głównym dokumentem regulacyjnym regulującym cykl życia oprogramowania jest międzynarodowa norma ISO/IEC 12207 (ISO – Międzynarodowa Organizacja Normalizacyjna, IEC – Międzynarodowa Komisja Elektrotechniczna). Definiuje strukturę cyklu życia zawierającą procesy, działania i zadania, które należy wykonać podczas tworzenia oprogramowania. W tym standardzie Oprogramowanie (oprogramowanie) definiuje się jako zbiór programów komputerowych, procedur i ewentualnie powiązanej dokumentacji i danych. Proces definiuje się jako zbiór powiązanych ze sobą działań, które przekształcają niektóre dane wejściowe w dane wyjściowe. Każdy proces charakteryzuje się określonymi zadaniami i sposobami ich rozwiązania, danymi wejściowymi uzyskanymi z innych procesów oraz wynikami.

Struktura cyklu życia oprogramowania zgodnie z normą ISO/IEC 12207 opiera się na trzech grupach procesów:

· główne procesy cyklu życia oprogramowania (zakup, dostawa, rozwój, eksploatacja, wsparcie);

· procesy pomocnicze zapewniające realizację procesów głównych (dokumentacja, zarządzanie konfiguracją, zapewnienie jakości, weryfikacja, certyfikacja, ocena, audyt, rozwiązywanie problemów);

· procesy organizacyjne (zarządzanie projektami, tworzenie infrastruktury projektowej, definiowanie, ocena i doskonalenie samego cyklu życia, szkolenia).

Modele cyklu życia oprogramowania

Model cyklu życia- struktura określająca kolejność wykonania oraz powiązanie etapów i etapów realizowanych w całym cyklu życia. Model cyklu życia zależy od specyfiki oprogramowania oraz konkretnych warunków, w jakich jest ono tworzone i funkcjonuje. Główne modele cyklu życia są następujące.

1. Model kaskadowy(do lat 70. XX w.) wyznacza sekwencyjne przejście do kolejnego etapu po zakończeniu poprzedniego.

Model ten charakteryzuje się automatyzacją poszczególnych, niepowiązanych ze sobą zadań, która nie wymaga integracji informacji i kompatybilności, oprogramowania, interfejsu technicznego i organizacyjnego.

Godność: dobre wskaźniki pod względem czasu rozwoju i niezawodności przy rozwiązywaniu poszczególnych problemów.

Wada: Nie ma zastosowania do dużych i złożonych projektów ze względu na zmienność wymagań systemowych w długim okresie projektowania.

2. Model iteracyjny(lata 80. XX w.) odpowiada technologii projektowania „oddolnego”. Umożliwia iteracyjny powrót do poprzednich etapów po ukończeniu kolejnego etapu;

Model przewiduje uogólnienie uzyskanych rozwiązań projektowych dla poszczególnych problemów na rozwiązania ogólnosystemowe. W takim przypadku istnieje potrzeba zweryfikowania wcześniej sformułowanych wymagań.

Godność: możliwość szybkiego wprowadzenia poprawek do projektu.

Wada: przy dużej liczbie iteracji wydłuża się czas projektowania, pojawiają się rozbieżności w rozwiązaniach projektowych i dokumentacji, a architektura funkcjonalna i systemowa tworzonego oprogramowania ulega pomieszaniu. Konieczność przeprojektowania starego systemu lub stworzenia nowego może pojawić się bezpośrednio po etapie wdrożenia lub eksploatacji.

3. Model spiralny(lata 90. XX w.) odpowiada technologii projektowania „od góry do dołu”. Polega na wykorzystaniu prototypu oprogramowania, który umożliwia rozbudowę oprogramowania. Projekt systemu cyklicznie powtarza ścieżkę od uszczegółowienia wymagań do uszczegółowienia kodu programu.

Projektując architekturę systemu, w pierwszej kolejności określa się skład podsystemów funkcjonalnych i rozwiązuje problemy ogólnosystemowe (organizacja zintegrowanej bazy danych, technologia gromadzenia, przesyłania i przechowywania informacji). Następnie formułowane są indywidualne problemy i opracowywana jest technologia ich rozwiązania.

Podczas programowania najpierw opracowywane są główne moduły oprogramowania, a następnie moduły realizujące poszczególne funkcje. W pierwszej kolejności zapewniona jest interakcja modułów ze sobą oraz z bazą danych, a następnie implementacja algorytmów.

Zalety:

1. zmniejszenie liczby iteracji, a co za tym idzie liczby błędów i niespójności wymagających korekty;

2. skrócenie czasu projektowania;

3. uproszczenie tworzenia dokumentacji projektowej.

Wada: wysokie wymagania co do jakości ogólnosystemowego repozytorium (wspólna baza danych projektowych).

Podstawą jest model spiralny technologie szybkiego tworzenia aplikacji czy technologię RAD (szybkie tworzenie aplikacji), która polega na aktywnym udziale użytkowników końcowych przyszłego systemu w procesie jego tworzenia. Główne etapy inżynierii informacji są następujące:

· Analiza i planowanie strategii informacyjnej. Użytkownicy wraz ze specjalistycznymi programistami biorą udział w identyfikacji obszaru problemowego.

· Projekt. Użytkownicy pod okiem programistów biorą udział w projektowaniu technicznym.

· Budowa. Programiści projektują działającą wersję oprogramowania przy użyciu języków czwartej generacji;

· Realizacja. Programiści szkolą użytkowników do pracy w nowym środowisku oprogramowania.

Standardy cyklu życia oprogramowania

• GOST 34.601-90
• ISO/IEC 12207:1995 (odpowiednik rosyjski - GOST R ISO/IEC 12207-99)

Standardowy GOST 34 .601-90

Model iteracyjny

Alternatywą dla modelu sekwencyjnego jest tzw. iteracyjny i przyrostowy model rozwoju. rozwój iteracyjny i przyrostowy, IID ), który także otrzymał od T. Gilba w latach 70-tych. Nazwa model ewolucyjny. Ten model jest również nazywany model iteracyjny I model przyrostowy .

Model IID polega na rozbiciu cyklu życia projektu na sekwencję iteracji, z których każda przypomina „miniprojekt”, obejmujący wszystkie procesy rozwojowe zastosowane do stworzenia mniejszych fragmentów funkcjonalności w porównaniu z projektem jako całością. Celem każdego iteracje- uzyskanie działającej wersji systemu oprogramowania, zawierającej funkcjonalność określoną przez zintegrowaną treść wszystkich poprzednich i bieżących iteracji. Wynik końcowej iteracji zawiera całą wymaganą funkcjonalność produktu. Zatem po zakończeniu każdej iteracji produkt otrzymuje przyrost - przyrost- do swoich możliwości, które konsekwentnie rozwijają ewolucyjnie. Iteracyjność, inkrementalność i ewolucja w tym przypadku są wyrazem tego samego znaczenia różnymi słowami z nieco innych punktów widzenia.

Jak to ujął T. Gilb, „ewolucja jest techniką zaprojektowaną w celu stworzenia pozorów stabilności. Szanse na pomyślne stworzenie złożonego systemu będą największe, jeśli zostanie on wdrożony w serii małych kroków i jeśli każdy krok będzie zawierał jasno określony sukces, a także możliwość „cofnięcia się” do poprzedniego udanego etapu w przypadku niepowodzenia . Deweloper przed uruchomieniem wszystkich zasobów przeznaczonych do stworzenia systemu ma możliwość otrzymania sygnałów zwrotnych ze świata rzeczywistego i skorygowania ewentualnych błędów w projekcie.”

Podejście IID ma też swoje negatywne strony, które w istocie są odwrotną stroną zalet. Po pierwsze, od bardzo dawna brakowało całościowego zrozumienia możliwości i ograniczeń projektu. Po drugie, podczas iteracji musisz odrzucić część pracy wykonanej wcześniej. Po trzecie, sumienność specjalistów w wykonywaniu pracy wciąż maleje, co można wytłumaczyć psychologicznie, gdyż stale dominuje u nich poczucie, że „wszystko i tak można później przerobić i ulepszyć”.

W większości nowoczesnych metodologii programowania (RUP, MSF) wdrażane są różne warianty podejścia iteracyjnego.

Model spiralny

Każda iteracja polega na utworzeniu fragmentu lub wersji oprogramowania, podczas której doprecyzowuje się cele i charakterystykę projektu, ocenia jakość uzyskanych wyników i planuje prace nad kolejną iteracją.

W każdej iteracji oceniane są:

• ryzyko przekroczenia terminów i kosztów projektu;
• konieczność wykonania kolejnej iteracji;
• stopień kompletności i dokładności zrozumienia wymagań systemowych;
• możliwość zakończenia projektu.

Ważne jest, aby zrozumieć, że model spiralny nie jest alternatywą dla modelu ewolucyjnego (model IID), ale specjalnie opracowaną wersją. Niestety, model spiralny jest często albo błędnie używany jako synonim modelu ewolucyjnego w ogóle, albo (nie mniej błędnie) określany jako model całkowicie niezależny wraz z IID.

Charakterystyczną cechą modelu spiralnego jest zwrócenie szczególnej uwagi na ryzyka wpływające na organizację cyklu życia i punkty kontrolne. Boehm formułuje 10 najczęstszych (według priorytetu) zagrożeń:

1. Niedobór specjalistów.
2. Nierealne terminy i budżet.
3. Implementacja niewłaściwej funkcjonalności.
4. Zaprojektowanie niewłaściwego interfejsu użytkownika.
5. Perfekcjonizm, niepotrzebna optymalizacja i dopracowanie szczegółów.
6. Ciągły strumień zmian.
7. Brak informacji o komponentach zewnętrznych, które definiują środowisko systemu lub biorą udział w integracji.
8. Wady pracy wykonywanej przez zasoby zewnętrzne (w stosunku do projektu).
9. Niewystarczająca wydajność powstałego systemu.
10. Luka w kwalifikacjach specjalistów z różnych dziedzin.

Dzisiejszy model spiralny definiuje następujący ogólny zestaw punktów kontrolnych:

1. Concept of Operations (COO) - koncepcja (użytkowanie) systemu;
2. Cele cyklu życia (LCO) – cele i treść cyklu życia;
3. Architektura cyklu życia (LCA) - architektura cyklu życia; tutaj można mówić o gotowości architektury koncepcyjnej docelowego systemu oprogramowania;
4. Wstępna zdolność operacyjna (IOC) – pierwsza tworzona wersja produktu, nadająca się do próbnej pracy;
5. Final Operational Capability (FOC) to gotowy produkt, wdrożony (zainstalowany i skonfigurowany) do rzeczywistego działania.

Metodyki tworzenia oprogramowania

• Struktura rozwiązań firmy Microsoft (MSF). Obejmuje 4 fazy: analizę, projektowanie, rozwój, stabilizację, obejmuje zastosowanie modelowania obiektowego.
• Ekstremalne programowanie Programowanie ekstremalne, XP). Metodologia opiera się na pracy zespołowej i efektywnej komunikacji pomiędzy klientem a wykonawcą przez cały czas trwania projektu rozwoju własności intelektualnej. Rozwój odbywa się w oparciu o sukcesywnie udoskonalane prototypy.
• ESPD to zbiór standardów państwowych Federacji Rosyjskiej, które ustalają powiązane zasady opracowywania, realizacji i obiegu programów oraz dokumentacji programowej.

Literatura

• Bratishchenko V.V. Projektowanie systemów informatycznych. - Irkuck: Wydawnictwo BGUEP, 2004. - 84 s.
• Vendrov A.M. Projektowanie oprogramowania systemów informacji gospodarczej. - M.: Finanse i statystyka, 2000.
• Grekul V.I., Denishchenko G.N., Korovkina N.L. Projektowanie systemów informatycznych. - M .: Internetowy Uniwersytet Technologii Informacyjnych - INTUIT.ru, 2005.
• Mishenin A.I. Teoria systemów informacji gospodarczej. - M.: Finanse i statystyka, 2000. - 240 s.

Notatki

Fundacja Wikimedia. 2010.

Zobacz, co oznacza „Cykl życia oprogramowania” w innych słownikach:

Okres rozwoju i funkcjonowania oprogramowania, w którym zazwyczaj wyróżnia się następujące etapy: 1 pojawienie się i badanie pomysłu; 2 analiza i projektowanie wymagań; 3 programowanie; 4 testowanie i debugowanie; 5 wprowadzenia programu w życie; 6… … Słownik finansowy

cykl życia oprogramowania - … Przewodnik tłumacza technicznego

cykl życia oprogramowania- 3.7 cykl życia oprogramowania; cykl życia oprogramowania: Sekwencja kolejnych procesów tworzenia i użytkowania programowalnego oprogramowania związanych z bezpieczeństwem budynku lub... ...

cykl życia oprogramowania- Sekwencja następujących po sobie procesów tworzenia i użytkowania oprogramowania, zachodzących w okresie czasu rozpoczynającym się wraz z opracowaniem ogólnej koncepcji oprogramowania, a kończącym się, gdy... ... Kompleksowe zapewnienie bezpieczeństwa i ochrony antyterrorystycznej budynków i budowli

Cykl życia oprogramowania- Cykl życia oprogramowania: okres obejmujący etapy: opracowywanie wymagań oprogramowania, tworzenie oprogramowania, kodowanie, testowanie, integracja, instalacja i... ... Oficjalna terminologia

koło życia- 4.16 Cykl życia: Rozwój systemu, produktu, usługi, projektu lub innego obiektu stworzonego przez człowieka, od etapu koncepcji do zakończenia użytkowania. Źródło … Słownik-podręcznik terminów dokumentacji normatywnej i technicznej

Na tym polega proces jego budowy i rozwoju. Cykl życia systemu informacyjnego to okres, który rozpoczyna się od momentu podjęcia decyzji o konieczności stworzenia systemu informacyjnego, a kończy w momencie jego całkowitego wycofania z... ...Wikipedii

Cykl życia systemu informacyjnego to proces jego budowy i rozwoju. Cykl życia systemu informacyjnego to okres czasu rozpoczynający się od chwili podjęcia decyzji o konieczności stworzenia systemu informacyjnego i kończący się w... ... Wikipedia, O. V. Kazarin. Książka analizuje teoretyczne i stosowane aspekty problemu ochrony oprogramowania przed różnego rodzaju złośliwymi działaniami. Szczególną uwagę zwraca się na modele i metody tworzenia...

Cykl życia programu.

Cykl życia oprogramowania to okres czasu rozpoczynający się od momentu podjęcia decyzji o konieczności stworzenia produktu programowego i kończący się w momencie jego całkowitego wycofania z użytku. Cykl ten to proces tworzenia i rozwijania oprogramowania.

Etapy cyklu życia:

2. Projekt

3. Wdrożenie

4. Montaż, testowanie, testowanie

5. Wdrożenie (wydanie)

6. Eskorta

Istnieją 2 przypadki produkcji oprogramowania: 1) Oprogramowanie jest tworzone dla konkretnego klienta. W takim przypadku musisz zamienić zastosowane zadanie w zadanie programistyczne. Musisz zrozumieć, jak działa środowisko wymagające automatyzacji (analiza procesów biznesowych). W rezultacie pojawia się specyfikacja dokumentacyjna wymagania, która wskazuje, jakie konkretne zadania należy wykonać. rozwiązany i na jakich warunkach. Pracę tę wykonuje analityk systemowy (analityk procesów biznesowych).

2) Oprogramowanie jest opracowywane na potrzeby rynku. Trzeba przeprowadzić badania marketingowe i dowiedzieć się, jakiego produktu nie ma na rynku. Wiąże się to z dużym ryzykiem. Celem jest opracowanie specyfikacji wymagań.

Projekt

Celem jest określenie ogólnej struktury (architektury) oprogramowania. Wynikiem jest specyfikacja oprogramowania. Pracę tę wykonuje programista systemu.

Realizacja

Pisanie kodu programu. Wdrożenie obejmuje rozwój, testowanie i dokumentację.

Montaż, testowanie, testowanie

Kompilacja wszystkiego, co stworzyli różni programiści. Testowanie całego pakietu oprogramowania. Debugowanie – znajdowanie i eliminowanie przyczyn błędów. Testowanie – wyjaśnienie właściwości technicznych. W rezultacie program ma gwarancję działania.

Implementacja (wydanie)

Wdrożeniowe – gdy pracują dla jednego klienta. Obejmuje ustawienie programu u klienta, przeszkolenie klienta, konsultacje, eliminację błędów i oczywistych braków. Oprogramowanie musi być wyobcowane – użytkownik może pracować z oprogramowaniem bez udziału autora.

Wydanie – kiedy oprogramowanie jest opracowywane na rynek. Rozpoczyna się od etapu testów beta. Odp. wersja - wersja beta. Testowanie alfa to testowanie przez osoby z tej samej organizacji, które nie były zaangażowane w rozwój programów. Beta testy polegają na wyprodukowaniu kilku kopii oprogramowania i wysłaniu ich do potencjalnych klientów. Celem jest ponowne sprawdzenie rozwoju oprogramowania.

Jeśli na rynek zostanie wypuszczone zasadniczo nowe oprogramowanie, możliwych jest kilka testów beta. Po testach beta - wydanie wersji komercyjnej.

Eskorta

Eliminacja błędów zauważonych podczas pracy. Wprowadzanie nieistotnych ulepszeń. Nagromadzenie propozycji opracowania kolejnej wersji.

Modele cyklu życia

1. Wodospad („wodospad”, model kaskadowy)

2. Prototypowanie

Po pierwsze, nie powstaje samo oprogramowanie, ale jego prototyp, który zawiera rozwiązanie głównych problemów stojących przed programistami. Po pomyślnym zakończeniu prac nad prototypem, na tych samych zasadach tworzone jest prawdziwe oprogramowanie. Prototyp pozwala lepiej zrozumieć wymagania stawiane tworzonemu programowi. Korzystając z prototypu, Klient może także dokładniej sformułować swoje wymagania. Deweloper ma możliwość, korzystając z prototypu, zaprezentować klientowi wstępne efekty swojej pracy.

3. Model iteracyjny

Zadanie podzielone jest na podzadania i ustalana jest kolejność ich realizacji tak, aby każde kolejne podzadanie poszerzało możliwości oprogramowania. Sukces zależy w dużej mierze od tego, jak dobrze podzielone są zadania na podzadania i jaka jest ich kolejność. Zalety: 1) możliwość aktywnego udziału klienta w rozwoju, ma on możliwość wyjaśnienia swoich wymagań w trakcie rozwoju; 2) możliwość testowania nowo opracowanych części razem z wcześniej opracowanymi, obniży to koszty złożonego debugowania; 3) w trakcie programowania możesz rozpocząć wdrażanie w częściach.

Powinniśmy zacząć od zdefiniowaniaCykl życia oprogramowania(Model Cyklu Życia Oprogramowania) to okres czasu rozpoczynający się od momentu podjęcia decyzji o stworzeniu oprogramowania i kończący się w momencie jego całkowitego wycofania z użytku. Cykl ten to proces tworzenia i rozwijania oprogramowania.

Modele cyklu życia oprogramowania

Cykl życia można przedstawić w formie modeli. Obecnie najczęściej spotykane to:kaskada, przyrostowe (model krokowy ze sterowaniem pośrednim ) I spiralamodele cyklu życia.

Model kaskadowy

Model kaskadowy(Język angielski) model wodospadu) to model procesu wytwarzania oprogramowania, którego cykl życia wygląda jak przepływ, który kolejno przechodzi przez fazy analizy wymagań i projektowania. wdrożenie, testowanie, integracja i wsparcie.

Proces rozwoju realizowany jest poprzez uporządkowaną sekwencję niezależnych kroków. Model zakłada, że ​​każdy kolejny krok rozpoczyna się po całkowitym zakończeniu poprzedniego. Na wszystkich etapach modelu realizowane są procesy i prace pomocnicze i organizacyjne, obejmujące zarządzanie projektami, ocenę i zarządzanie jakością, weryfikację i certyfikację, zarządzanie konfiguracją oraz opracowywanie dokumentacji. W wyniku zakończenia etapów powstają produkty pośrednie, których nie można zmienić w kolejnych etapach.

Cykl życia jest tradycyjnie podzielony na następujące głównegradacja:

1. Analiza wymagań,
2. Projekt,
3. Kodowanie (programowanie),
4. Testowanie i debugowanie,
5. Obsługa i konserwacja.

Zalety modelu:

• stabilność wymagań w całym cyklu życia oprogramowania;
• na każdym etapie generowany jest komplet dokumentacji projektowej spełniający kryteria kompletności i spójności;
• pewność i przejrzystość etapów modelu oraz łatwość jego stosowania;
• etapy pracy wykonywane w logicznej kolejności pozwalają zaplanować termin zakończenia wszystkich prac i odpowiadające im zasoby (pieniężne, rzeczowe i ludzkie).

Wady modelu:

• trudność w jasnym formułowaniu wymagań i brak możliwości ich dynamicznej zmiany w całym cyklu życia;
• niska elastyczność w zarządzaniu projektami;
• spójność liniowej struktury procesu rozwojowego, w efekcie powrót do poprzednich kroków w celu rozwiązania pojawiających się problemów prowadzi do wzrostu kosztów i zakłócenia harmonogramu prac;
• nieprzydatność półproduktu do stosowania;
• niemożność elastycznego modelowania unikalnych systemów;
• Późne wykrywanie problemów montażowych dzięki jednoczesnej integracji wszystkich wyników na końcu rozwoju;
• niewystarczający udział użytkowników w tworzeniu systemu – na samym początku (podczas opracowywania wymagań) i na końcu (podczas testów akceptacyjnych);
• użytkownicy nie mogą być pewni jakości opracowywanego produktu, dopóki cały proces rozwoju nie zostanie zakończony. Nie mają możliwości oceny jakości, ponieważ nie można zobaczyć gotowego produktu rozwojowego;
• użytkownik nie ma możliwości stopniowego przyzwyczajania się do systemu. Proces uczenia się następuje na koniec cyklu życia, kiedy oprogramowanie zostało już uruchomione;
• każda faza jest warunkiem wstępnym kolejnych działań, co czyni tę metodę ryzykownym wyborem dla systemów, które nie mają analogii, ponieważ nie nadaje się do elastycznego modelowania.

Wdrożenie modelu cyklu życia Cascade jest trudne ze względu na złożoność tworzenia systemu oprogramowania bez powrotu do poprzednich kroków i zmiany ich wyników w celu wyeliminowania pojawiających się problemów.

Zakres zastosowania modelu kaskadowego

O ograniczeniu zakresu stosowania modelu kaskadowego decydują jego wady. Jego użycie jest najskuteczniejsze w następujących przypadkach:

1. przy opracowywaniu projektów z jasnymi, niezmiennymikoło życia wymagania, zrozumiałe wdrożenie i metody techniczne;
2. przy opracowywaniu projektu skupiającego się na zbudowaniu systemu lub produktu tego samego typu, który został już wcześniej opracowany przez programistów;
3. przy opracowywaniu projektu związanego ze stworzeniem i wydaniem nowej wersji istniejącego produktu lub systemu;
4. przy opracowywaniu projektu związanego z przeniesieniem istniejącego produktu lub systemu na nową platformę;
5. przy realizacji dużych projektów, w które zaangażowanych jest kilka dużych zespołów programistycznych.

Model przyrostowy

(model krok po kroku ze sterowaniem pośrednim)

Model przyrostowy(Język angielski) przyrost- wzrost, przyrost) oznacza rozwój oprogramowania z liniową sekwencją etapów, ale w kilku przyrostach (wersjach), tj. z planowanymi ulepszeniami produktów przez cały czas, aż do zakończenia Cyklu Życia Rozwoju Oprogramowania.

Tworzenie oprogramowania odbywa się w iteracjach, z pętlami sprzężenia zwrotnego pomiędzy etapami. Korekty międzyetapowe umożliwiają uwzględnienie rzeczywistego wzajemnego wpływu wyników rozwoju na różnych etapach. Czas trwania każdego etapu rozciąga się na cały okres rozwoju.

Na początku pracy nad projektem ustalane są wszystkie podstawowe wymagania stawiane systemowi i dzielone na mniej i bardziej istotne. System jest następnie rozwijany przyrostowo, aby programista mógł wykorzystać dane uzyskane podczas tworzenia oprogramowania. Każdy przyrost powinien dodawać pewną funkcjonalność do systemu. W tym przypadku wydanie rozpoczyna się od komponentów o najwyższym priorytecie. Po zidentyfikowaniu części systemu, weź pierwszą część i zacznij ją opisywać szczegółowo, stosując najbardziej odpowiedni do tego proces. Jednocześnie możliwe jest doprecyzowanie wymagań dla innych części, które zostały zamrożone w bieżącym zestawie wymagań dla tej pracy. W razie potrzeby możesz wrócić do tej części później. Jeśli część jest już gotowa, trafia do klienta, który może ją wykorzystać w swojej pracy. Umożliwi to klientowi wyjaśnienie wymagań dotyczących następujących komponentów. Następnie opracowują kolejną część systemu. Kluczowymi etapami tego procesu jest po prostu wdrożenie podzbioru wymagań oprogramowania i udoskonalenie modelu w serii kolejnych wydań, aż do pełnego wdrożenia oprogramowania.

Cykl życia tego modelu jest typowy przy tworzeniu złożonych i złożonych systemów, dla których istnieje jasna wizja (zarówno ze strony klienta, jak i dewelopera) tego, jaki powinien być efekt końcowy. Tworzenie wersji odbywa się z różnych powodów:

• brak możliwości sfinansowania przez klienta od razu całego, kosztownego projektu;
• deweloperowi brakuje niezbędnych zasobów do realizacji złożonego projektu w krótkim czasie;
• wymagania dotyczące etapowego wdrażania i przyjmowania produktu przez użytkowników końcowych. Wdrożenie całego systemu od razu może wywołać odrzucenie wśród jego użytkowników i jedynie „spowolnić” proces przejścia na nowe technologie. Mówiąc obrazowo, mogą po prostu „nie strawić dużego kawałka, więc należy go posiekać i podać w częściach”.

Zalety I wadyTen model (strategie) jest taki sam, jak model wodospadu (klasyczny model cyklu życia). Jednak w przeciwieństwie do klasycznej strategii, klient może zobaczyć rezultaty wcześniej. Na podstawie wyników opracowania i wdrożenia pierwszej wersji może nieznacznie zmienić wymagania dotyczące opracowania, z niego zrezygnować lub zaoferować opracowanie bardziej zaawansowanego produktu wraz z zawarciem nowej umowy.

Zalety:

• koszty ponoszone w związku ze zmieniającymi się wymaganiami użytkowników są zmniejszone, ponowne analizy i dokumentacja są znacznie zmniejszone w porównaniu do modelu kaskadowego;
• Łatwiej jest uzyskać od klienta informację zwrotną na temat wykonanej pracy – klient może wyrazić swoje uwagi na temat gotowych elementów i zobaczyć, co już zostało zrobione. Ponieważ Pierwsze części systemu stanowią prototyp systemu jako całości.
• klient ma możliwość szybkiego pozyskania i opanowania oprogramowania – klienci mogą osiągnąć realne korzyści z systemu szybciej, niż byłoby to możliwe w przypadku modelu kaskadowego.

Wady modelu:

• menedżerowie muszą stale mierzyć postęp procesów. w przypadku szybkiego rozwoju nie należy tworzyć dokumentów dla każdej minimalnej zmiany wersji;
• struktura systemu ma tendencję do pogarszania się w miarę dodawania nowych komponentów – ciągłe zmiany zakłócają strukturę systemu. Aby tego uniknąć, refaktoryzacja wymaga dodatkowego czasu i pieniędzy. Zły projekt sprawia, że ​​późniejsze zmiany oprogramowania są trudne i kosztowne. A przerwany cykl życia oprogramowania prowadzi do jeszcze większych strat.

Schemat nie pozwala na szybkie uwzględnienie pojawiających się zmian i doprecyzowań wymagań oprogramowania. Koordynacja wyników prac rozwojowych z użytkownikami odbywa się jedynie w punktach zaplanowanych po zakończeniu każdego etapu prac, a ogólne wymagania dotyczące oprogramowania zapisane są w formie specyfikacji technicznych przez cały czas jego tworzenia. Dlatego użytkownicy często otrzymują oprogramowanie, które nie odpowiada ich rzeczywistym potrzebom.

Model spiralny

Model spiralny:Cykl życia - na każdym zwoju spirali tworzona jest kolejna wersja produktu, wyjaśniane są wymagania projektu, określana jest jego jakość i planowana jest praca nad kolejnym zakrętem. Szczególną uwagę zwraca się na początkowe etapy rozwoju – analizę i projektowanie, gdzie poprzez stworzenie prototypów sprawdzana jest i uzasadniana wykonalność określonych rozwiązań technicznych.

Model ten to proces tworzenia oprogramowania, który łączy projektowanie i prototypowanie przyrostowe, aby połączyć zalety koncepcji oddolnych i odgórnych, kładąc nacisk na wczesne etapy cyklu życia: analizę i projektowanie.Osobliwość Model ten zwraca szczególną uwagę na ryzyka wpływające na organizację cyklu życia.

Na etapie analizy i projektowania weryfikowana jest wykonalność rozwiązań technicznych i stopień zaspokojenia potrzeb klienta poprzez tworzenie prototypów. Każdy obrót spirali odpowiada utworzeniu działającego fragmentu lub wersji systemu. Pozwala to wyjaśnić wymagania, cele i cechy projektu, określić jakość rozwoju i zaplanować pracę nad kolejnym zwojem spirali. W ten sposób pogłębiane i konsekwentnie doprecyzowywane są szczegóły projektu, w wyniku czego wybierany jest rozsądny wariant, spełniający rzeczywiste wymagania klienta i doprowadzany do realizacji.

Cykl życia na każdym zakręcie spirali – można zastosować różne modele procesu wytwarzania oprogramowania. Ostatecznie produktem końcowym jest gotowy produkt. Model łączy w sobie możliwości modelu prototypowego imodel wodospadu. Rozwój poprzez iteracje odzwierciedla obiektywnie istniejący spiralny cykl tworzenia systemu. Niepełne zakończenie prac na każdym etapie pozwala przejść do kolejnego etapu bez czekania na całkowite zakończenie prac na obecnym. Głównym zadaniem jest jak najszybsze pokazanie użytkownikom systemu działającego produktu, aktywując tym samym proces doprecyzowywania i uzupełniania wymagań.

Zalety modelu:

• pozwala szybko pokazać użytkownikom systemu działający produkt, aktywując w ten sposób proces doprecyzowywania i uzupełniania wymagań;
• pozwala na zmianę wymagań w trakcie tworzenia oprogramowania, co jest typowe dla większości rozwinięć, w tym standardowych;
• model pozwala na elastyczne projektowanie, ponieważ ucieleśnia zalety modelu kaskadowego, a jednocześnie umożliwia iteracje we wszystkich fazach tego samego modelu;
• pozwala uzyskać bardziej niezawodny i stabilny system. W miarę rozwoju oprogramowania błędy i słabości są wykrywane i korygowane w każdej iteracji;
• model ten pozwala użytkownikom aktywnie uczestniczyć w działaniach związanych z planowaniem, analizą ryzyka, projektowaniem i oceną;
• ryzyko klienta jest zmniejszone. Klient może ukończyć rozwój mało obiecującego projektu przy minimalnych stratach finansowych;
• Informacje zwrotne od użytkowników do programistów pojawiają się z dużą częstotliwością i na początku modelu, co zapewnia utworzenie pożądanego produktu o wysokiej jakości.

Wady modelu:

• jeśli projekt wiąże się z niskim ryzykiem lub jest niewielki, model może być kosztowny. Ocena ryzyka po każdej spirali wiąże się z wysokimi kosztami;
• Cykl życia modelu ma złożoną strukturę, więc jego wykorzystanie przez programistów, menedżerów i klientów może być trudne;
• spirala może ciągnąć się w nieskończoność, gdyż każda reakcja klienta na stworzoną wersję może wygenerować nowy cykl, co opóźnia zakończenie projektu;
• duża liczba cykli pośrednich może skutkować koniecznością przetworzenia dodatkowej dokumentacji;
• korzystanie z modelu może okazać się drogie, a nawet niedostępne, ponieważ czas. czas spędzony na planowaniu, redefiniowaniu celów, przeprowadzaniu analiz ryzyka i tworzeniu prototypów może być nadmierny;
• Zdefiniowanie celów i kamieni milowych wskazujących na gotowość do kontynuowania procesu rozwoju w kolejnym etapie może być trudne

Głównym problemem cyklu spiralnego jest określenie momentu przejścia do kolejnego etapu. Aby rozwiązać ten problem, dla każdego etapu wprowadzane są ograniczenia czasowe.koło życia a przejście przebiega zgodnie z planem, nawet jeśli nie wszystkie zaplanowane prace zostaną ukończone.Planowaniewyprodukowane na podstawie danych statystycznych uzyskanych w poprzednich projektach i osobistych doświadczeń deweloperów.

Zakres stosowania modelu spiralnego

Stosowanie modelu spiralnego jest wskazane w następujących przypadkach:

• przy opracowywaniu projektów z wykorzystaniem nowych technologii;
• przy opracowywaniu nowej serii produktów lub systemów;
• podczas opracowywania projektów, w których spodziewane są znaczące zmiany lub uzupełnienia wymagań;
• do realizacji projektów długoterminowych;
• przy opracowywaniu projektów wymagających zademonstrowania jakości i wersji systemu lub produktu w krótkim czasie;
• podczas opracowywania projektów. dla których konieczne jest obliczenie kosztów związanych z oceną i rozwiązaniem ryzyka.