Cykl życia i etapy tworzenia oprogramowania. Cykl życia oprogramowania: koncepcja, standardy, procesy Cykl życia oprogramowania
Figa. 5.2.
Te aspekty to:
- aspekt umowny, w którym klient i dostawca wchodzą w stosunek umowny i wdrażają procesy zaopatrzenia i dostawy;
- aspekt zarządzania, który obejmuje działania związane z zarządzaniem osobami uczestniczącymi w cyklu życia oprogramowania (dostawca, klient, programista, operator itp.);
- aspekt operacyjny, w tym działania operatora w celu świadczenia usług użytkownikom systemu;
- aspekt inżynieryjny, który obejmuje działania programisty lub usługi wsparcia w celu rozwiązania problemów technicznych związanych z opracowywaniem lub modyfikacją oprogramowania;
- aspekt wsparcia związany z realizacją procesów wsparcia, poprzez które służby wsparcia świadczą niezbędne usługi wszystkim pozostałym uczestnikom prac. W tym aspekcie można wyróżnić aspekt zarządzania jakością oprogramowania, w tym procesy zapewnienia jakości, weryfikację, certyfikację, ocenę wspólną i audyt.
Procesy organizacyjne realizowane są na poziomie korporacyjnym lub na poziomie całej organizacji jako całości, tworząc podstawę do wdrażania i ciągłego doskonalenia procesów cyklu życia oprogramowania.
5.6. Modele i etapy cyklu życia oprogramowania
Model cyklu życia rozumiany jest jako struktura, która określa kolejność wykonywania i wzajemne powiązania procesów, działań i zadań w trakcie cyklu życia oprogramowania. Model cyklu życia zależy od specyfiki, skali i złożoności projektu oraz specyfiki warunków, w których system jest tworzony i działa.
ISO / IEC 12207 nie oferuje określonego modelu cyklu życia i metod tworzenia oprogramowania. Jej postanowienia są wspólne dla wszystkich modeli cyklu życia, metod i technologii wytwarzania oprogramowania. Norma opisuje strukturę procesów cyklu życia oprogramowania, ale nie precyzuje, jak wdrożyć lub wykonać czynności i zadania zawarte w tych procesach.
Model cyklu życia dowolnego konkretnego oprogramowania determinuje charakter procesu jego tworzenia, czyli uporządkowany w czasie zbiór prac połączonych ze sobą i połączonych etapami (fazami), których wykonanie jest niezbędne i wystarczające do stworzenia oprogramowania spełniającego określone wymagania.
Etap (faza) wytwarzania oprogramowania rozumiany jest jako część procesu tworzenia oprogramowania, ograniczona przez pewien czas i kończąca się wydaniem określonego produktu (modele oprogramowania, komponenty oprogramowania, dokumentacja itp.), Zdeterminowanej wymaganiami określonymi dla tego etapu. Etapy wytwarzania oprogramowania wyróżniono ze względu na racjonalne planowanie i organizację pracy, kończące się określonymi rezultatami. Cykl życia oprogramowania obejmuje zazwyczaj następujące etapy:
- tworzenie wymagań oprogramowania;
- projektowanie (opracowanie projektu systemu);
- wdrożenie (można podzielić na etapy: szczegółowy projekt, kodowanie);
- testowanie (można je podzielić na samodzielne i złożone testowanie i integrację);
- uruchomienie (wdrożenie);
- obsługa i konserwacja;
- wycofanie z eksploatacji.
Niektórzy eksperci wprowadzają dodatkowy etap początkowy - studium wykonalności systemy. Dotyczy to oprogramowania i systemu sprzętu, dla którego oprogramowanie jest tworzone, kupowane lub modyfikowane.
Etap kształtowania wymagań programowych jest jednym z najważniejszych i decyduje w znaczącym (wręcz decydującym!) Stopniu o powodzeniu całego projektu. Początkiem tego etapu jest uzyskanie zatwierdzonej i walidowanej architektury systemu z uwzględnieniem podstawowych umów na dystrybucję funkcji pomiędzy sprzętem a oprogramowaniem. Dokument ten powinien również zawierać potwierdzenie ogólnej znajomości funkcjonowania oprogramowania, w tym podstawowych uzgodnień dotyczących podziału funkcji między osobą a systemem.
Etap tworzenia wymagań oprogramowania obejmuje następujące etapy.
- Planowanie pracy przed rozpoczęciem pracy nad projektem. Główne zadania etapu to określenie celów rozwojowych, wstępna ocena ekonomiczna projektu, budowa harmonogramu prac, utworzenie i przeszkolenie wspólnej grupy roboczej.
- Przeprowadzenie przeglądu działalności zautomatyzowanej organizacji (obiektu), w ramach którego dokonywana jest wstępna identyfikacja wymagań dla przyszłego systemu, ustalenie struktury organizacji, ustalenie listy docelowych funkcji organizacji, analiza podziału funkcji według działów i pracowników, identyfikacja interakcji funkcjonalnych pomiędzy pionami, przepływ informacji w ramach pionów i między nimi , zewnętrzne w odniesieniu do organizacji obiektów i zewnętrznych wpływów informacji, analiza istniejących narzędzi automatyzacji organizacji.
- model „AS-IS” („as is”), który odzwierciedla aktualny stan rzeczy w organizacji w czasie badania i pozwala zrozumieć, jak działa organizacja, a także zidentyfikować wąskie gardła i sformułować propozycje poprawy sytuacji;
- model „TO BYĆ” („jak powinno być”), odzwierciedlający ideę nowych technologii w organizacji.
Budowa modelu działalności (obiektu) organizacji, z uwzględnieniem przetwarzania materiałów sondażowych oraz budowy dwóch typów modeli:
Każdy z modeli powinien zawierać kompletny model funkcjonalno-informacyjny działań organizacji, a także (w razie potrzeby) model opisujący dynamikę zachowań organizacji. Należy zwrócić uwagę, że skonstruowane modele mają niezależne znaczenie praktyczne, niezależnie od tego, czy przedsiębiorstwo opracuje i wdroży system informacyjny, ponieważ mogą one służyć do szkolenia pracowników i doskonalenia procesów biznesowych przedsiębiorstwa.
Efektem zakończenia etapu formowania wymagań na oprogramowanie są specyfikacje oprogramowania, specyfikacje funkcjonalne, techniczne i interfejsowe, dla których potwierdzono ich kompletność, testowalność i wykonalność.
Etap projektowania obejmuje następujące etapy.
Opracowanie projektu systemu oprogramowania. Na tym etapie udzielana jest odpowiedź na pytanie „Co powinien zrobić przyszły system?”, A mianowicie: określa się architekturę systemu, jego funkcje, zewnętrzne warunki działania, interfejsy i podział funkcji pomiędzy użytkowników a system, wymagania dotyczące oprogramowania i komponentów informacyjnych, skład wykonawców i terminy. rozwój, plan debugowania oprogramowania i kontrola jakości.
Projekt systemu oparty jest na modelach projektowanego systemu, które są oparte na modelu „TO-BE”. Rezultatem opracowania projektu systemu powinna być zatwierdzona i potwierdzona specyfikacja wymagań programowych: funkcjonalna, techniczna i interfejsowa, dla której została potwierdzona ich kompletność, testowalność i wykonalność.
- Opracowanie szczegółowego projektu (technicznego). Na tym etapie wykonywany jest rzeczywisty projekt oprogramowania, w tym projekt architektury systemu oraz projekt wykonawczy. W ten sposób udziela się odpowiedzi na pytanie: „Jak zbudować system, aby spełniał wymagania?”
Efektem szczegółowego projektowania jest opracowanie zweryfikowanej specyfikacji oprogramowania, w tym:
- tworzenie hierarchii komponentów oprogramowania, intermodularnych interfejsów danych i sterowania;
- specyfikacja każdego komponentu oprogramowania, nazwa, cel, założenia, rozmiary, kolejność wywołań, dane wejściowe i wyjściowe, błędne wyjścia, algorytmy i układy logiczne;
- tworzenie fizycznych i logicznych struktur danych do poziomu poszczególnych pól;
- opracowanie planu dystrybucji zasobów obliczeniowych (czas procesora, pamięć itp.);
- weryfikacja kompletności, spójności, wykonalności i ważności wymagań;
- wstępny plan integracji i debugowania, podręcznik użytkownika i plan testów akceptacyjnych.
Zakończenie etapu szczegółowego projektu
Standardy cyklu życia oprogramowania
- GOST 34.601-90
- ISO / IEC 12207: 1995 (rosyjski analog - GOST R ISO / IEC 12207-99)
Standard GOST 34 .601-90
Model iteracyjny
Alternatywą dla modelu sekwencyjnego jest tzw. Iteracyjny i przyrostowy model rozwoju (ang. rozwój iteracyjny i przyrostowy, IID ), który również otrzymał od T. Gilba w latach 70. imię model ewolucyjny... Ten model jest również nazywany model iteracyjny i model przyrostowy .
Model IID polega na rozbiciu cyklu życia projektu na serię iteracji, z których każda przypomina „mini-projekt”, w tym wszystkie procesy rozwojowe stosowane do tworzenia mniejszych elementów funkcjonalności niż projekt jako całość. Celem każdego iteracje - uzyskanie działającej wersji systemu oprogramowania, obejmującej funkcjonalność zdefiniowaną przez zintegrowaną zawartość wszystkich poprzednich i aktualnych iteracji. Ostateczny wynik iteracji zawiera wszystkie wymagane funkcje produktu. Tak więc po zakończeniu każdej iteracji iloczyn jest zwiększany - przyrost - na jego możliwości, które w związku z tym się rozwijają ewolucyjnie... Iteratywność, inkrementalność i ewolucyjność w tym przypadku są wyrazem tego samego znaczenia w różnych słowach z nieco innych punktów widzenia.
Według T. Gilba „ewolucja jest techniką stworzoną w celu stworzenia pozoru stabilności. Szanse na pomyślne stworzenie złożonego systemu zostaną zmaksymalizowane, jeśli zostanie wdrożony w serii małych kroków i jeśli każdy krok będzie zawierał dobrze zdefiniowany sukces, a także możliwość „powrotu” do poprzedniego udanego etapu w przypadku niepowodzenia. Przed uruchomieniem wszystkich zasobów przeznaczonych do stworzenia systemu, deweloper ma możliwość uzyskania informacji zwrotnej z realnego świata i poprawienia ewentualnych błędów w projekcie. ”
Podejście IID ma również swoje negatywne strony, które w rzeczywistości 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, nadal obniża się sumienność specjalistów przy wykonywaniu pracy, co jest zrozumiałe psychologicznie, ponieważ nieustannie dominuje w nich poczucie, że „mimo wszystko wszystko można przerobić i poprawić później”.
Różne wersje podejścia iteracyjnego są zaimplementowane w większości nowoczesnych metodologii rozwoju (RUP, MSF,).
Model spiralny
Każda iteracja odpowiada utworzeniu fragmentu lub wersji oprogramowania, na nim określa się cele i cechy projektu, ocenia się jakość uzyskanych wyników, planowana jest praca kolejnej iteracji.
W każdej iteracji oceniane są następujące elementy:
- ryzyko przekroczenia terminów i kosztów projektu;
- potrzeba wykonania kolejnej iteracji;
- stopień kompletności i dokładności zrozumienia wymagań dla systemu;
- wykonalność 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 błędnie używany jako synonim modelu ewolucyjnego w ogóle lub (nie mniej błędnie) określany jako model całkowicie niezależny wraz z IID.
Charakterystyczną cechą modelu spiralnego jest skupienie się na ryzyku cyklu życia i kamieniach milowych. Boehm wymienia 10 najczęściej występujących (uszeregowanych pod względem ważności) zagrożeń:
- Niedobór specjalistów.
- Nierealistyczny harmonogram i budżet.
- Implementacja niewłaściwej funkcjonalności.
- Projektowanie niewłaściwego interfejsu użytkownika.
- Perfekcjonizm, niepotrzebna optymalizacja i szlifowanie szczegółów.
- Nieustanny strumień zmian.
- Brak informacji o komponentach zewnętrznych definiujących środowisko systemu lub zaangażowanych w integrację.
- Braki w pracy wykonanej przez zasoby zewnętrzne (w stosunku do projektu).
- Niewystarczająca wydajność powstałego systemu.
- Luka w kwalifikacjach specjalistów z różnych dziedzin.
Bieżący model spiralny definiuje następujący ogólny zestaw punktów kontrolnych:
- Concept of Operations (COO) - pojęcie (zastosowanie) systemu;
- Cele cyklu życia (LCO) - cele i treść cyklu życia;
- Life Cycle Architecture (LCA) - architektura cyklu życia; można tu mówić o gotowości architektury koncepcyjnej docelowego systemu oprogramowania;
- Initial Operational Capability (IOC) - pierwsza tworzona wersja produktu nadająca się do uruchomienia próbnego;
- Final Operational Capability (FOC) to gotowy produkt, wdrożony (zainstalowany i skonfigurowany) do rzeczywistego działania.
Metodologie tworzenia oprogramowania
- Microsoft Solutions Framework (MSF). Obejmuje 4 fazy: analiza, projektowanie, rozwój, stabilizacja, obejmuje zastosowanie modelowania obiektowego.
- Programowanie ekstremalne (eng. Programowanie ekstremalne, XP). Metodologia oparta jest na pracy zespołowej, efektywnej komunikacji pomiędzy klientem a wykonawcą podczas całego projektu rozwoju IS. Rozwój odbywa się przy użyciu konsekwentnie udoskonalanych prototypów.
- ESPD to zbiór standardów państwowych Federacji Rosyjskiej, które ustanawiają powiązane zasady opracowywania, projektowania i rozpowszechniania programów i dokumentacji programowej.
Literatura
- Bratishchenko V.V. Projektowanie systemów informacyjnych. - Irkuck: Wydawnictwo BSUEP, 2004. - 84 str.
- Vendrov A.M. Projektowanie oprogramowania dla systemów informacji gospodarczej. - M .: Finanse i statystyka, 2000.
- Grekul V.I., Denischenko G.N., Korovkina N.L. Projektowanie systemów informacyjnych. - M.: Internetowy Uniwersytet Technologii Informacyjnych - INTUIT.ru, 2005.
- Mishenin A.I. Teoria ekonomicznych systemów informacyjnych. - M .: Finanse i statystyki, 2000. - 240 str.
Uwagi
Fundacja Wikimedia. 2010.
Pojęcie „cyklu życia” oznacza coś, co rodzi się, rozwija i umiera. Podobnie jak żywy organizm, oprogramowanie jest tworzone, obsługiwane i rozwijane w czasie.
Koło życia oprogramowanie obejmuje wszystkie etapy jego rozwoju: od pojawienia się potrzeby do całkowitego zaprzestania jego użytkowania z powodu starzenia się lub utraty potrzeby rozwiązywania odpowiednich problemów.
Istnieje kilka faz istnienia oprogramowania w trakcie jego cyklu życia. Nadal nie ma ogólnie przyjętych nazw tych faz i ich liczby. Ale nie ma też szczególnych sporów w tej kwestii. Dlatego istnieje kilka opcji podziału cyklu życia oprogramowania na etapy. Pytanie, czy dana partycja jest lepsza od innych, nie jest główną. Najważniejsze jest, aby odpowiednio zorganizować tworzenie oprogramowania z uwzględnieniem ich.
Ze względu na czas trwania cyklu życia oprogramowanie można podzielić na dwie klasy: mały i długa żywotność. Te klasy programów odpowiadają elastycznemu (miękkiemu) podejściu do ich tworzenia i używania oraz sztywnemu przemysłowemu podejściu do regulowanego projektowania i działania oprogramowania. Na przykład w organizacjach naukowych i na uniwersytetach przeważa rozwój programów pierwszej klasy, aw organizacjach projektowych i przemysłowych - drugiej.
Oprogramowanie o krótkim okresie użytkowania są tworzone głównie do rozwiązywania problemów naukowych i inżynierskich, do uzyskiwania określonych wyników obliczeń. Takie programy są zwykle stosunkowo małe. Są opracowywane przez jednego specjalistę lub małą grupę. Główną ideę programu omawia jeden programista i użytkownik końcowy. Niektóre szczegóły są zapisywane na papierze, a projekt kończy się w ciągu kilku dni lub tygodni. Nie są przeznaczone do powielania i przenoszenia do późniejszego wykorzystania przez inne grupy. Jako takie, takie programy są częścią prac badawczo-rozwojowych i nie mogą być traktowane jako zbywalne produkty oprogramowania.
Na ich cykl życia składa się długi interwał analizy systemu i formalizacja problemu, znaczący etap projektowania programów oraz stosunkowo krótki czas działania i uzyskiwania wyników. Wymagania dotyczące cech funkcjonalnych i projektowych z reguły nie są sformalizowane, nie ma sformalizowanych testów programów. Ich wskaźniki jakości są kontrolowane tylko przez programistów zgodnie z ich nieformalnymi pomysłami.
Oprogramowanie o krótkim okresie użytkowania
Utrzymanie i modyfikacja takich programów nie jest konieczna, a ich cykl życia kończy się po otrzymaniu wyników obliczeń. Główne koszty w cyklu życia takich programów przypadają na etapy analizy i projektowania systemu, które trwają od miesiąca do 1 ... 2 lat, w efekcie
przy czym cykl życia oprogramowania rzadko przekracza 3 lata.
Oprogramowanie o długiej żywotności są tworzone w celu regularnego przetwarzania i zarządzania informacjami. Struktura takich programów jest złożona. Ich rozmiary mogą się zmieniać w szerokich granicach (1 ... 1000 tys. Komend), ale wszystkie mają właściwości poznawalności i możliwości modyfikacji w procesie wieloletniej obsługi i użytkowania przez różnych specjalistów. Oprogramowanie tej klasy może być replikowane, towarzyszy im dokumentacja jako produkty przemysłowe i reprezentuje oprogramowanie wyalienowane od programisty.
Oprogramowanie o długiej żywotności
W ich projektowanie i eksploatację zaangażowane są duże zespoły specjalistów, co wymaga sformalizowania systemu oprogramowania, a także sformalizowanych testów i określenia osiąganych wskaźników jakości produktu końcowego. Ich cykl życia wynosi 10 ... 20 lat. Aż 70 ... 90% tego czasu jest poświęcane na obsługę i konserwację. Ze względu na masową replikację i długoterminową konserwację, całkowite koszty eksploatacji i utrzymania takiego oprogramowania znacznie przewyższają koszty analizy i projektowania systemu.
Wszystkie kolejne prezentacje skupiają się na tworzeniu dużego (złożonego) oprogramowania do sterowania i przetwarzania informacji.
Model uogólniony koło życia oprogramowanie może wyglądać następująco:
JA. Analiza systemu:
badanie;
b) analiza wykonalności:
Operacyjny;
Gospodarczy;
Reklama w telewizji.
II. Projektowanie Oprogramowania:
projekt:
Funkcjonalna dekompozycja systemu, jego architektura;
Projektowanie oprogramowania zewnętrznego;
Projekt bazy danych;
Architektura oprogramowania;
b) programowanie:
Projektowanie oprogramowania wewnętrznego;
Projektowanie zewnętrzne modułów oprogramowania;
Wewnętrzny projekt modułów oprogramowania;
Kodowanie;
Programy do debugowania;
Programowanie;
c) debugowanie oprogramowania.
III. Ocena (testowanie) oprogramowania.
IV. Użytkowanie oprogramowania:
a) operacja;
b) akompaniament.
ja... Analiza systemu.Na początku tworzenia oprogramowania przeprowadzana jest analiza systemu (projekt wstępny), podczas której określa się jego potrzebę, cel i główne cechy funkcjonalne. Szacuje się koszty i możliwą wydajność przyszłego oprogramowania.
Na tym etapie sporządzana jest lista wymagań, czyli jasna definicja tego, czego użytkownik oczekuje od gotowego produktu. Tutaj wyznaczane są cele i zadania, dla których powstaje sam projekt. Fazę analizy systemów można podzielić na dwa kierunki: badania i studia wykonalności.
Rozpoczynają się badania od momentu, gdy kierownik ds. rozwoju zdaje sobie sprawę z potrzeby oprogramowania.
Zadanie polega na planowaniu i koordynowaniu czynności niezbędnych do przygotowania formalnej odręcznej listy wymagań dla opracowywanego oprogramowania.
Badania się kończą gdy wymagania są sformułowane w taki sposób, że stają się widoczne i, jeśli to konieczne, mogą być modyfikowane i zatwierdzane przez odpowiedzialnego kierownika.
Studium wykonalności jest część techniczna badań i zaczyna się, gdy intencja kierownictwa zostaje na tyle wzmocniona, że \u200b\u200bzostaje powołany kierownik projektu, który organizuje projektowanie i alokację zasobów (pracy).
Praca polega na zbadaniu proponowanego oprogramowania w celu uzyskania praktycznej oceny wykonalności projektu, w szczególności określa:
- wykonalność operacyjna , czy produkt będzie wystarczająco wygodny do praktycznego użytku?
- wykonalność ekonomiczna , czy koszt opracowywanego produktu jest akceptowalny? Jaki to koszt? Czy produkt będzie opłacalnym narzędziem w rękach użytkownika?
- wykonalność komercyjna, czy produkt będzie atrakcyjny, poszukiwany, łatwy w instalacji, przystosowany do obsługi, łatwy do nauczenia?
Te i inne kwestie należy rozwiązać głównie przy rozważaniu powyższych wymagań.
Studium wykonalności kończy się po zebraniu i zatwierdzeniu wszystkich wymagań.
Przed przystąpieniem do dalszych prac nad projektem należy upewnić się, że otrzymano wszystkie niezbędne informacje. Informacje te muszą być dokładne, zrozumiałe i wykonalne. Powinien przedstawiać kompletny zestaw wymagań spełniających wymagania użytkownika dla tworzonego oprogramowania, sporządzony w formie specyfikacji.
Niespełnienie tego wymogu może znacznie spowolnić realizację projektu w przyszłości ze względu na wielokrotne apele do użytkownika o wyjaśnienie błędnie zinterpretowanych szczegółów, nieokreślonych warunków, aw konsekwencji będzie wymagało przeróbki już opracowanych części.
Często w okresie analizy systemu zapada decyzja o zaprzestaniu dalszego rozwoju oprogramowania.
II... Projektowanie Oprogramowania. Projektowanie to główna i decydująca faza cyklu życia oprogramowania, podczas której powstaje oprogramowanie, a 90% nabiera ostatecznej formy.
Ten etap życia obejmuje różne działania projektu i można go podzielić na trzy główne fazy: projektowanie, programowanie i debugowanie oprogramowania.
Budowa oprogramowanie zwykle rozpoczyna się już na etapie studium wykonalności, kiedy pewne wstępne cele i wymagania zostaną zapisane na papierze.
Do czasu zatwierdzenia wymagań prace w fazie projektowej będą się toczyć pełną parą.
W tym segmencie życia oprogramowania wykonują:
Funkcjonalna dekompozycja rozwiązanego problemu, na podstawie której określana jest systemowa architektura tego problemu;
Projektowanie zewnętrzne oprogramowania, wyrażone w postaci zewnętrznej interakcji z użytkownikiem;
Projekt bazy danych, jeśli to konieczne;
Projektowanie architektury oprogramowania - definiowanie obiektów, modułów i ich interfejsu.
Rozpoczyna się programowanie już w fazie projektowania, gdy tylko podstawowe specyfikacje dla poszczególnych komponentów oprogramowania staną się dostępne, ale nie przed zatwierdzeniem porozumienia wymagań. Nakładanie się etapów programowania i projektowania prowadzi do oszczędności w ogólnym czasie projektowania, a także do zapewnienia walidacji decyzji projektowych, aw niektórych przypadkach wpływa na rozwiązanie kluczowych problemów.
Na tym etapie wykonywane są prace związane z montażem oprogramowania. Polega na szczegółowym projekcie wewnętrznym oprogramowania, opracowaniu wewnętrznej logiki każdego modułu systemu, która jest następnie wyrażana w tekście konkretnego programu.
Faza programowania kończy się, gdy programiści zakończą dokumentowanie, debugowanie i składanie poszczególnych elementów oprogramowania w jedną całość.
Oprogramowanie do debugowania jest przeprowadzana po tym, jak wszystkie jej składniki są debugowane osobno i montowane w jednym produkcie.
III... Ocena (testowanie) oprogramowania.Na tym etapie oprogramowanie jest poddawane rygorystycznym testom systemowym przez grupę osób niebędących programistami.
Ma to na celu zapewnienie, że gotowe oprogramowanie spełnia wszystkie wymagania i specyfikacje, może być używane w środowisku użytkownika, jest wolne od jakichkolwiek wad i zawiera niezbędną dokumentację, która dokładnie i kompletnie opisuje oprogramowanie.
Faza oceny rozpoczyna się, gdy wszystkie komponenty (moduły) zostaną zmontowane i przetestowane, tj. po pełnym debugowaniu gotowego oprogramowania. Kończy się po otrzymaniu potwierdzenia, że \u200b\u200boprogramowanie przeszło wszystkie testy i jest gotowe do użycia.
Zajmuje to tyle czasu, ile programowanie.
IV. Korzystanie z oprogramowania.Jeśli analiza systemów jest sygnałem do bitwy, projektowanie to atak i powrót ze zwycięstwem, to używanie oprogramowania jest codzienną obroną, niezbędną, ale zwykle nie honorową dla programistów.
Takie porównanie jest właściwe, biorąc pod uwagę fakt, że podczas użytkowania produktu programowego błędy, które wkradły się w trakcie jego projektowania, są korygowane.
Faza użytkowania elementu oprogramowania rozpoczyna się w momencie przeniesienia elementu do systemu dystrybucji.
To czas, w którym produkt działa i jest efektywnie używany.
W tym czasie prowadzone są szkolenia personelu, wdrażanie, konfiguracja, utrzymanie i ewentualnie rozbudowa oprogramowania - tzw. Projektowanie ciągłe.
Faza użytkowania kończy się, gdy produkt zostaje wycofany z użytku, a powyższe czynności zakończone. Należy jednak pamiętać, że oprogramowanie może być używane przez inną osobę przez długi czas i po zakończeniu zdefiniowanej tutaj fazy użytkowania. Ponieważ ten ktoś może owocnie korzystać z oprogramowania w domu, nawet bez pomocy programisty.
Korzystanie z oprogramowania zależy od jego obsługi i konserwacji.
Działanie oprogramowania polega na jego wykonaniu, funkcjonowaniu na komputerze w celu przetwarzania informacji i uzyskiwania wyników będących celem ich tworzenia, a także zapewnienia rzetelności i rzetelności podawanych danych.
Konserwacja oprogramowania polega na utrzymaniu, rozwoju funkcjonalności i poprawie charakterystyk operacyjnych produktu programowego, na replikacji i transferze oprogramowania do różnego rodzaju obiektów obliczeniowych.
Utrzymanie pełni rolę niezbędnej informacji zwrotnej z fazy operacyjnej.
Podczas pracy oprogramowania możliwe jest wykrycie błędów w programach, konieczna staje się ich modyfikacja oraz rozszerzenie ich funkcji.
Te ulepszenia są zwykle wprowadzane jednocześnie z działaniem bieżącej wersji oprogramowania. Po sprawdzeniu przygotowanych poprawek na jednej z kopii programów, kolejna wersja oprogramowania zastępuje wcześniej używane lub niektóre z nich. W takim przypadku proces obsługi oprogramowania może być prawie ciągły, ponieważ wymiana wersji oprogramowania jest krótkotrwała. Okoliczności te prowadzą do tego, że proces obsługi wersji oprogramowania zwykle przebiega równolegle i niezależnie od etapu utrzymania.
Nakładanie się faz cyklu życia oprogramowania
Nakładanie się różnych faz cyklu życia oprogramowania jest możliwe i zwykle pożądane. Nie powinno jednak zachodzić na siebie nieciągłych procesów.
Możliwe jest sprzężenie zwrotne między fazami. Na przykład podczas jednego z etapów projektowania zewnętrznego mogą zostać wykryte błędy w formułowaniu celów, a następnie należy je natychmiast zwrócić i poprawić.
Rozważany model cyklu życia oprogramowania z pewnymi zmianami może służyć jako model dla małych projektów.
Na przykład podczas projektowania pojedynczego programu często rezygnuje się z architektury systemu i
projektowanie baz danych; procesy wstępnego i szczegółowego projektowania zewnętrznego często łączą się ze sobą itp.
Standardy cyklu życia oprogramowania
- GOST 34.601-90
- ISO / IEC 12207: 1995 (rosyjski analog - GOST R ISO / IEC 12207-99)
Metodologie tworzenia oprogramowania
- Rational Unified Process (RUP).
- Microsoft Solutions Framework (MSF). Obejmuje 4 fazy: analiza, projektowanie, rozwój, stabilizacja, obejmuje zastosowanie modelowania obiektowego.
- Ekstremalne programowanie ( Ekstremalne programowanieXP). Metodologia oparta jest na pracy zespołowej, efektywnej komunikacji pomiędzy klientem a wykonawcą podczas całego projektu rozwoju IS. Rozwój odbywa się przy użyciu konsekwentnie udoskonalanych prototypów.
Standardowy GOST 34.601-90
Norma GOST 34.601-90 przewiduje następujące etapy i etapy tworzenia zautomatyzowanego systemu:
- Formowanie wymagań dla UA
- Badanie terenu i uzasadnienie potrzeby utworzenia elektrowni jądrowej
- Formowanie wymagań użytkownika dla mówcy
- Rejestracja sprawozdania z postępu prac i wniosku o rozwój UA
- Opracowanie koncepcji głośnika
- Badanie obiektu
- Przeprowadzenie niezbędnych prac badawczych
- Opracowanie wariantów koncepcji głośnika i wybór wersji koncepcji głośnika spełniającej wymagania użytkowników
- Raportowanie wykonanej pracy
- Zadanie techniczne
- Opracowanie i zatwierdzenie specyfikacji technicznych w celu utworzenia jednostki AU
- Projekt wstępny
- Opracowanie wstępnych rozwiązań projektowych dla systemu i jego części
- Projekt techniczny
- Opracowanie rozwiązań projektowych dla systemu i jego części
- Opracowanie dokumentacji dla elektrowni jądrowej i jej części
- Opracowanie i wykonanie dokumentacji dostaw komponentów
- Opracowanie zadań projektowych w powiązanych częściach projektu
- Dokumentacja robocza
- Opracowanie dokumentacji roboczej dla elektrowni jądrowej i jej części
- Tworzenie i adaptacja programów
- Uruchomienie
- Przygotowanie obiektu automatyki
- Szkolenie personelu
- Kompletny zestaw głośników wraz z dostarczonymi produktami (oprogramowanie i sprzęt, systemy oprogramowania i sprzętu, produkty informacyjne)
- Roboty budowlane i instalacyjne
- Uruchomienie
- Testy wstępne
- Operacja próbna
- Test wstępny
- Eskorta AC.
- Wykonanie pracy zgodnie z gwarancją
- Serwis pogwarancyjny
Szkice, projekty techniczne i dokumentacja wykonawcza to konsekwentna konstrukcja coraz dokładniejszych rozwiązań projektowych. Dopuszczalne jest wyłączenie etapu „Projekt wstępny” i oddzielnych etapów prac na wszystkich etapach, połączenie etapów „Projekt techniczny” i „Dokumentacja wykonawcza” w „Projekt robót technicznych”, aby jednocześnie wykonywać różne etapy i prace, w tym dodatkowe.
Ten standard nie nadaje się obecnie do opracowania: wiele procesów nie jest dostatecznie odzwierciedlonych, a niektóre przepisy są nieaktualne.
Norma ISO / IEC 12207 / i jej zastosowanie
ISO / IEC 12207: 1995 „Technologia informacyjna - procesy cyklu życia oprogramowania” jest głównym dokumentem normatywnym regulującym skład procesów cyklu życia oprogramowania. Określa strukturę cyklu życia zawierającą procesy, czynności i zadania, które należy wykonać podczas tworzenia oprogramowania.
Każdy proces jest podzielony na zestaw działań, a każde działanie na zestaw zadań. Każdy proces, akcja lub zadanie jest inicjowane i wykonywane w razie potrzeby przez inny proces i nie ma predefiniowanych sekwencji wykonywania. W takim przypadku połączenia danych wejściowych są zachowane.
Procesy cyklu życia oprogramowania
- Podstawowy:
- Zakup (czynności i zadania klienta kupującego oprogramowanie)
- Dostawa (czynności i zadania dostawcy, który dostarcza klientowi oprogramowanie lub usługę)
- Rozwój (czynności i zadania wykonywane przez dewelopera: tworzenie oprogramowania, dokumentacja projektowa i eksploatacyjna, przygotowanie materiałów testowych i szkoleniowych itp.)
- Eksploatacja (czynności i zadania operatora - organizacji obsługującej system)
- Escort (czynności i zadania wykonywane przez organizację eskortującą, czyli usługę towarzyską). Konserwacja - wprowadzanie zmian w oprogramowaniu w celu naprawienia błędów, poprawy wydajności lub dostosowania do zmienionych warunków pracy lub wymagań.
- Pomocniczy
- Dokumentacja (sformalizowany opis informacji powstałych podczas cyklu życia oprogramowania)
- Zarządzanie konfiguracją (stosowanie procedur administracyjnych i technicznych przez cały cykl życia oprogramowania w celu określenia stanu komponentów oprogramowania, zarządzania jego modyfikacjami).
- Zapewnienie jakości (zapewnienie, że SI i procesy jego cyklu życia są zgodne z określonymi wymaganiami i zatwierdzonymi planami)
- Weryfikacja (ustalenie, że oprogramowanie, które jest wynikiem jakiejś czynności, w pełni spełnia wymagania lub warunki spowodowane poprzednimi czynnościami)
- Certyfikacja (określenie kompletności zgodności określonych wymagań i stworzonego systemu z ich określonym celem funkcjonalnym)
- Ocena wspólna (ocena stanu prac nad projektem: kontrola planowania i zarządzania zasobami, personelem, sprzętem, narzędziami)
- Audyt (ustalenie zgodności z wymaganiami, planami i warunkami kontraktu)
- Rozwiązywanie problemów (analizowanie i rozwiązywanie problemów, niezależnie od ich pochodzenia lub źródła, wykrytych podczas projektowania, eksploatacji, utrzymania lub innych procesów)
- Organizacyjny
- Kontrola (działania i zadania, które może wykonać dowolna strona kontrolująca własne procesy)
- Tworzenie infrastruktury (wybór i utrzymanie technologii, standardów i narzędzi, dobór i instalacja sprzętu i oprogramowania służącego do rozwoju, obsługi lub utrzymania oprogramowania)
- Doskonalenie (ocena, pomiary, kontrola i doskonalenie procesów cyklu życia)
- Szkolenie (wstępne szkolenie i późniejszy ciągły rozwój zawodowy personelu)
Każdy proces obejmuje szereg działań. Na przykład proces przejęcia obejmuje następujące kroki:
- Inicjowanie przejęcia
- Przygotowanie wniosków aplikacyjnych
- Przygotowanie i zmiana umowy
- Nadzór dostawcy
- Odbiór i zakończenie prac
Każda akcja zawiera szereg zadań. Przykładowo przygotowanie ofert ofertowych powinno obejmować:
- Tworzenie wymagań systemowych
- Utworzenie listy produktów oprogramowania
- Ustalanie warunków i umów
- Opis ograniczeń technicznych (środowisko funkcjonowania systemu itp.)
Etapy cyklu życia oprogramowania, relacje między procesami i etapami
Model cyklu życia oprogramowania - struktura, która definiuje kolejność wykonywania oraz relacje procesów, działań i zadań w całym cyklu życia. Model cyklu życia zależy od specyfiki, skali i złożoności projektu oraz specyfiki warunków, w których system jest tworzony i działa.
GOST R ISO / IEC 12207-99 nie oferuje określonego modelu cyklu życia. Jej postanowienia są wspólne dla wszystkich modeli cyklu życia, metod i technologii tworzenia własności intelektualnej. Opisuje strukturę procesów cyklu życia bez określania, jak wdrożyć lub wykonać czynności i zadania zawarte w tych procesach.
Model oprogramowania cyklu życia obejmuje:
- Gradacja;
- Wyniki pracy na każdym etapie;
- Kluczowe wydarzenia to punkty zakończenia i podejmowania decyzji.
Etap - fragment procesu wytwarzania oprogramowania, ograniczony w określonym czasie i kończący się wydaniem określonego produktu (modele, komponenty oprogramowania, dokumentacja), określony przez wymagania stawiane na tym etapie.
Na każdym etapie można wykonać kilka procesów zdefiniowanych w normie GOST R ISO / IEC 12207-99 i odwrotnie, ten sam proces można przeprowadzić na różnych etapach. Zależność między procesami i etapami jest również określana przez zastosowany model cyklu życia oprogramowania.
Modele cyklu życia oprogramowania
Model cyklu życia rozumiany jest jako struktura, która określa kolejność wykonywania oraz związek procesów, działań i zadań wykonywanych w całym cyklu życia. Model cyklu życia zależy od specyfiki systemu informatycznego oraz specyfiki warunków, w których ten ostatni jest tworzony i funkcjonuje.
Do chwili obecnej najbardziej rozpowszechnione stały się następujące główne modele cyklu życia:
- Model problemu;
- model kaskadowy (lub systemowy) (70-85 lat);
- model spiralny (obecny).
Model problemu
Przy opracowywaniu systemu „od dołu do góry” od poszczególnych zadań do całego systemu (model zadaniowy) nieuchronnie zanika jedno podejście do rozwoju, pojawiają się problemy z informacyjnym dokowaniem poszczególnych komponentów. Z reguły wraz ze wzrostem liczby zadań, narastającymi trudnościami, trzeba stale zmieniać istniejące programy i struktury danych. Tempo rozwoju systemu zwalnia, co spowalnia rozwój samej organizacji. Jednak w niektórych przypadkach taka technologia może być odpowiednia:
- Pilna potrzeba (musisz jakoś rozwiązać problemy; potem musisz wszystko powtórzyć);
- Eksperyment i dostosowanie się do klienta (algorytmy nie są jasne, rozwiązania są po omacku \u200b\u200bmetodą prób i błędów).
Wniosek ogólny: nie da się w ten sposób stworzyć wystarczająco dużego efektywnego systemu informatycznego.
Model kaskadowy
Model kaskadowy cykl życia został zaproponowany w 1970 roku przez Winstona Royce'a. Przewiduje sekwencyjną realizację wszystkich etapów projektu w ściśle określonej kolejności. Przejście do kolejnego etapu oznacza całkowite zakończenie prac na poprzednim etapie (rys. 1). Wymagania, ustalane na etapie tworzenia wymagań, są ściśle dokumentowane w postaci specyfikacji technicznych i są ustalane na cały okres realizacji projektu. Każdy etap kończy się wydaniem pełnego zestawu dokumentacji, wystarczającego do dalszego rozwoju przez inny zespół programistów.
Korzyści wynikające ze stosowania metody kaskadowej są następujące:
- na każdym etapie tworzony jest komplet dokumentacji projektowej spełniającej kryteria kompletności i spójności;
- etapy pracy wykonywane w logicznej kolejności pozwalają zaplanować czas zakończenia wszystkich prac i odpowiadające im koszty.
Etapy projektu według modelu wodospadu:
- Tworzenie wymagań;
- Projekt;
- Realizacja;
- Testowanie;
- Realizacja;
- Obsługa i konserwacja.
Figa. 1. Schemat rozwoju wodospadu
Podejście kaskadowe sprawdziło się przy budowaniu systemów informatycznych, dla których na samym początku rozwoju wszystkie wymagania mogą być sformułowane w sposób precyzyjny i na tyle wyczerpujący, aby dać programistom swobodę ich wdrażania jak najlepiej z technicznego punktu widzenia. Do tej kategorii należą złożone systemy rozliczeń, systemy czasu rzeczywistego i inne podobne zadania. Jednak w trakcie stosowania tego podejścia odkryto szereg jego niedociągnięć, spowodowanych przede wszystkim tym, że rzeczywisty proces tworzenia systemów nigdy w pełni nie mieści się w tak sztywnym schemacie. W procesie tworzenia istniała ciągła potrzeba powrotu do poprzednich etapów i wyjaśnienia lub rewizji wcześniej podjętych decyzji. W efekcie faktyczny proces tworzenia oprogramowania przybrał następującą postać (rys. 2):
Figa. 2. Rzeczywisty proces wytwarzania oprogramowania w schemacie kaskadowym
Główną wadą podejścia kaskadowego jest znaczne opóźnienie w uzyskaniu wyników. Rezultaty uzgadniane są z użytkownikami tylko w punktach zaplanowanych po zakończeniu każdego etapu prac, wymagania dla systemów informatycznych są „zamrażane” w postaci zadania technicznego na cały okres jego tworzenia. Dlatego użytkownicy mogą zgłaszać swoje uwagi dopiero po zakończeniu prac nad systemem. W przypadku niedokładnego określenia wymagań lub ich zmiany w długim okresie rozwoju oprogramowania, użytkownicy otrzymują system, który nie spełnia ich potrzeb. Modele (zarówno funkcjonalne, jak i informacyjne) zautomatyzowanego obiektu mogą stać się nieaktualne wraz z ich zatwierdzeniem. Istota systematycznego podejścia do rozwoju SI polega na jego dekompozycji (partycjonowaniu) na zautomatyzowane funkcje: system dzieli się na podsystemy funkcjonalne, które z kolei dzielą się na podfunkcje, zadania i tak dalej. Proces partycjonowania jest kontynuowany do określonych procedur. Jednocześnie zautomatyzowany system zachowuje całościowy pogląd, w którym wszystkie elementy składowe są ze sobą połączone. Tak więc ten model ma główną zaletę w postaci systematycznego rozwoju, a główne wady są powolne i kosztowne.
Model spiralny
Zaproponowano, aby rozwiązać wymienione problemy model spiralny cykl życia (ryc. 3), który został opracowany w połowie lat osiemdziesiątych XX wieku przez Barry'ego Boehma. Opiera się na początkowych etapach cyklu życia: analizie i projektowaniu. Na tych etapach wykonalność rozwiązań technicznych jest weryfikowana poprzez prototypowanie.
Prototyp - aktywny składnik oprogramowania, który implementuje poszczególne funkcje i interfejsy zewnętrzne. Każda iteracja odpowiada utworzeniu fragmentu lub wersji oprogramowania, określa cele i charakterystykę projektu, ocenia jakość uzyskanych wyników, planuje pracę kolejnej iteracji.
Każda iteracja reprezentuje pełny cykl rozwoju prowadzący do wydania wewnętrznej lub zewnętrznej wersji produktu (lub podzbioru produktu końcowego), który jest ulepszany od iteracji do iteracji, aby stać się kompletnym systemem.
Każdy obrót spirali odpowiada utworzeniu fragmentu lub wersji oprogramowania, określane są cele i cechy projektu, określana jest jego jakość i planowana jest praca kolejnego zwoju spirali. W ten sposób szczegóły projektu są pogłębione i konsekwentnie doprecyzowane, w wyniku czego wybierana jest rozsądna opcja, która jest wprowadzana do realizacji.
Rozwój poprzez iteracje odzwierciedla obiektywnie istniejący spiralny cykl tworzenia systemu. Niepełne zakończenie prac na każdym etapie pozwala na przejście do kolejnego etapu bez czekania na całkowite zakończenie prac na obecnym. W przypadku iteracyjnej metody programowania brakującą pracę można ukończyć w następnej iteracji. Głównym zadaniem jest jak najszybsze pokazanie użytkownikom systemu działającego produktu, a tym samym uruchomienie procesu doprecyzowania i uzupełnienia wymagań.
Głównym problemem cyklu spiralnego jest określenie, kiedy przejść do następnego etapu. Aby go rozwiązać, konieczne jest wprowadzenie ograniczeń czasowych dla każdego etapu cyklu życia. Przejście przebiega zgodnie z planem, nawet jeśli nie wszystkie zaplanowane prace zostały zakończone. Plan jest tworzony na podstawie danych statystycznych uzyskanych w poprzednich projektach oraz osobistych doświadczeń deweloperów.
Rys. 3. Spiralny model cyklu życia IS
Jednym z możliwych podejść do tworzenia oprogramowania w ramach spiralnego modelu cyklu życia jest szeroko rozpowszechniona ostatnio metodologia szybkiego tworzenia aplikacji RAD (Rapid Application Development). Termin ten zwykle odnosi się do procesu tworzenia oprogramowania, który zawiera 3 elementy:
- mały zespół programistów (od 2 do 10 osób);
- krótki, ale dobrze rozwinięty harmonogram produkcji (od 2 do 6 miesięcy);
- powtarzalny cykl, w którym programiści, gdy aplikacja zaczyna nabierać kształtu, żądają i wdrażają w produkcie wymagania uzyskane w wyniku interakcji z klientem.
Cykl życia oprogramowania RAD składa się z czterech faz:
- definiowanie wymagań i faza analizy;
- faza projektowania;
- faza implementacji;
- faza implementacji.
W każdej iteracji oceniane są następujące elementy:
- ryzyko przekroczenia terminów i kosztów projektu;
- potrzeba wykonania kolejnej iteracji;
- stopień kompletności i dokładności zrozumienia wymagań dla systemu;
- wykonalność zakończenia projektu.
Zalety podejścia iteracyjnego:
- Rozwój iteracyjny znacznie upraszcza zmiany w projekcie, gdy zmieniają się wymagania klienta.
- Przy zastosowaniu modelu spiralnego poszczególne elementy systemu informacyjnego są stopniowo integrowane w jedną całość. Przy podejściu iteracyjnym integracja jest praktycznie ciągła. Ponieważ integracja zaczyna się od mniejszej liczby elementów, podczas jej wdrażania jest znacznie mniej problemów (według niektórych szacunków przy zastosowaniu modelu kaskadowego integracja pochłania do 40% wszystkich kosztów na koniec projektu).
- Rozwój iteracyjny zapewnia większą elastyczność w zarządzaniu projektami, umożliwiając wprowadzanie zmian taktycznych w opracowywanym produkcie.
- Podejście iteracyjne upraszcza ponowne użycie komponentów (implementuje podejście do programowania komponentów). Wynika to z faktu, że znacznie łatwiej jest zidentyfikować (zidentyfikować) części wspólne projektu, gdy są one już częściowo opracowane, niż próbować je wyodrębnić na samym początku projektu. Analiza projektu po kilku początkowych iteracjach ujawnia typowe komponenty wielokrotnego użytku, które zostaną ulepszone w kolejnych iteracjach.
- Model spiralny zapewnia bardziej niezawodny i stabilny system. Wynika to z faktu, że wraz z rozwojem systemu błędy i słabości są wykrywane i korygowane w każdej iteracji. Jednocześnie można regulować krytyczne parametry wydajnościowe, które w przypadku modelu kaskadowego są dostępne tylko przed wdrożeniem systemu.
- Podejście iteracyjne daje możliwość usprawnienia procesu rozwoju - analiza przeprowadzana na końcu każdej iteracji pozwala na ocenę tego, co należy zmienić w organizacji rozwoju i ulepszyć w kolejnej iteracji.
Pojęcie cyklu życia oprogramowania (cykl życia oprogramowania) jest jednym z podstawowych pojęć w inżynierii oprogramowania. Koło życia jest definiowany jako okres, który rozpoczyna się od momentu podjęcia decyzji o potrzebie stworzenia oprogramowania, a kończy w momencie całkowitego wycofania go z usługi.
Zgodnie z normą ISO / IEC 12207 wszystkie procesy cyklu życia podzielono na trzy grupy (rysunek 2.1).
Pod model cyklu życia Oprogramowanie rozumiane jest jako struktura, która określa kolejność wykonywania oraz relacje procesów, działań i zadań w całym cyklu życia. Zależy to od specyfiki, skali i złożoności projektu oraz specyfiki warunków, w jakich system jest tworzony i funkcjonuje. Cykl życia oprogramowania obejmuje zwykle następujące etapy:
1. Tworzenie wymagań programowych.
2. Projekt.
3. Wdrożenie.
4. Testowanie.
5. Uruchomienie.
6. Eksploatacja i konserwacja.
7. Wycofanie z eksploatacji.
Obecnie najbardziej rozpowszechnione są następujące podstawowe modele cyklu życia oprogramowania:
a) kaskadowe i
b) spirala (ewolucyjna).
Pierwszy był używany do programów o niewielkiej objętości, reprezentujących jedną całość. Główna cecha podejście wodospadowe polega na tym, że przejście do kolejnego etapu następuje dopiero po całkowitym zakończeniu prac nad obecnym i nie ma już powrotu do minionych etapów. Jego schemat pokazano na ryc. 2.2.
Zalety korzystania z modelu wodospadu są następujące:
Na każdym etapie tworzony jest komplet dokumentacji projektowej;
Wykonane etapy prac pozwalają zaplanować termin ich zakończenia i związane z tym koszty.
Model ten jest stosowany w systemach, dla których wszystkie wymagania można precyzyjnie sformułować na początku rozwoju. Należą do nich na przykład systemy, w których rozwiązywane są głównie problemy typu obliczeniowego. Rzeczywiste procesy mają zwykle charakter iteracyjny: wyniki kolejnego etapu często powodują zmiany w rozwiązaniach projektowych opracowanych na wcześniejszych etapach. Tak więc bardziej powszechny model ma sterowanie pośrednie, co pokazano na ryc. 2.3.
Główną wadą podejścia kaskadowego jest znaczne opóźnienie w uzyskaniu wyników, a co za tym idzie dość duże ryzyko stworzenia systemu, który nie będzie odpowiadał zmienionym potrzebom użytkowników.
Te problemy zostały rozwiązane w spiralny model cyklu życia (rys. 2.4). Jego podstawową cechą jest to, że oprogramowanie aplikacyjne nie jest tworzone od razu, jak w przypadku podejścia kaskadowego, ale w częściach przy użyciu metody prototypowanie ... Przez prototyp rozumie się aktywny komponent oprogramowania, który implementuje poszczególne funkcje i zewnętrzny interfejs opracowywanego oprogramowania. Prototypowanie odbywa się w kilku iteracjach - zwojach spiralnych.
Model wodospadu (ewolucyjny) można przedstawić w postaci diagramu, który pokazano na rysunku 2.5.
Jednym z rezultatów zastosowania spiralnego modelu cyklu życia jest szeroko stosowana metoda tzw szybki rozwój aplikacji lub RAD (Szybkie tworzenie aplikacji). Zgodnie z tą metodą cykl życia oprogramowania obejmuje cztery etapy:
1) analiza i planowanie wymagań;
2) projekt;
3) wdrożenie;
4) wdrożenie.
Analiza cyklu życia programów pozwala doprecyzować zawartość i wskazać kolejne procesy projektowania złożonych systemów.
1) Strategia;
2) Analiza;
3) projekt;
4) Wdrożenie;
5) Testowanie;
6) Wdrożenie;
7) Obsługa i wsparcie techniczne.
Strategia
Definiowanie strategii wymaga zbadania systemu. Głównym zadaniem badania jest ocena realnej wielkości projektu, jego celów i założeń, a także uzyskanie definicji podmiotów i funkcji na wysokim poziomie. Na tym etapie zaangażowani są wysoko wykwalifikowani analitycy biznesowi, którzy mają stały dostęp do kierownictwa firmy. Ponadto oczekuje się bliskiej interakcji z głównymi użytkownikami systemu oraz ekspertami biznesowymi. Głównym zadaniem takiej interakcji jest uzyskanie jak największej ilości informacji o systemie, jednoznaczne zrozumienie wymagań klienta oraz przekazanie informacji otrzymanych w sformalizowanej formie do analityków systemu. Zazwyczaj informacje o systemie można uzyskać w trakcie serii rozmów (lub seminariów) z kierownictwem, ekspertami i użytkownikami.
Efektem etapu definiowania strategii jest dokument, w którym jasno sformułowano:
Co dokładnie jest należne klientowi, jeśli zgodzi się sfinansować projekt;
Kiedy będzie mógł otrzymać gotowy produkt (harmonogram prac);
Ile będzie go to kosztowało (harmonogram finansowania etapów prac przy dużych projektach).
Dokument powinien odzwierciedlać nie tylko koszty, ale także korzyści, na przykład okres zwrotu projektu, oczekiwany efekt ekonomiczny (jeśli można go oszacować).
Rozważany etap cyklu życia oprogramowania można przedstawić w modelu tylko raz, zwłaszcza jeśli model ma strukturę cykliczną. Nie oznacza to, że planowanie strategiczne w modelach cyklicznych odbywa się raz na zawsze. W takich modelach etapy definiowania strategii i analizy są niejako połączone, a ich wyodrębnienie istnieje dopiero na pierwszym etapie, kiedy kierownictwo przedsiębiorstwa podejmuje zasadniczą decyzję o rozpoczęciu projektu. Generalnie etap strategiczny poświęcony jest opracowaniu dokumentu na poziomie zarządzania przedsiębiorstwem.
Etap analizy polega na szczegółowym badaniu procesów biznesowych (funkcji zdefiniowanych w poprzednim etapie) oraz informacji potrzebnych do ich realizacji (podmioty, ich atrybuty i powiązania (relacje)). Ten etap zapewnia model informacyjny, a kolejnym etapem projektowania jest model danych.
Wszystkie informacje o systemie, zebrane na etapie określania strategii, są sformalizowane i dopracowane na etapie analizy. Szczególną uwagę zwraca się na kompletność otrzymywanych informacji, ich analizę pod kątem spójności, a także poszukiwanie niewykorzystanych lub powielonych informacji. Z reguły klient najpierw stawia wymagania nie dla systemu jako całości, ale dla jego poszczególnych elementów. I w tym konkretnym przypadku cykliczne modele cyklu życia oprogramowania mają tę zaletę, że z czasem bardzo prawdopodobne jest, że konieczna będzie ponowna analiza, ponieważ klient często ma apetyt na jedzenie. Na tym samym etapie określane są niezbędne elementy planu testów.
Analitycy zbierają i rejestrują informacje w dwóch powiązanych ze sobą formach:
a) funkcje - informacje o zdarzeniach i procesach zachodzących w biznesie;
b) Podmioty - informacje o pozycjach, które są istotne dla organizacji io których coś jest znane.
Tworzy diagramy komponentów, przepływów danych i cykli życia, które opisują dynamikę systemu. Zostaną omówione później.
Projekt
Na etapie projektowania tworzony jest model danych. Projektanci przetwarzają dane analityczne. Produktem końcowym fazy projektowania jest schemat bazy danych (jeśli taki istnieje w projekcie) lub schemat hurtowni danych (model ER) oraz zestaw specyfikacji modułów systemu (model funkcji).
W małym projekcie (na przykład w projekcie kursu) te same osoby mogą działać jako analitycy, projektanci i programiści. Wymienione powyżej schematy i modele pomagają znaleźć np. W ogóle nieopisane, niejasno opisane, sprzeczne opisane elementy systemu i inne niedociągnięcia, co pomaga zapobiegać potencjalnym błędom.
Wszystkie specyfikacje muszą być bardzo dokładne. Plan testów systemu jest również finalizowany na tym etapie rozwoju. W wielu projektach wyniki fazy projektowej dokumentowane są w jednym dokumencie - tzw. Specyfikacji technicznej. Jednocześnie UML jest szeroko stosowany, co pozwala na jednoczesne uzyskiwanie zarówno dokumentów analitycznych, które są mniej szczegółowe (ich konsumentami są kierownicy produkcji), jak i dokumentów projektowych (ich konsumentami są kierownicy grup deweloperskich i testowych). Ten język zostanie omówiony później. Oprogramowanie zbudowane przy użyciu języka UML ułatwia generowanie kodu - przynajmniej hierarchii klas, a także niektórych części kodu samych metod (procedur i funkcji).
Zadania projektowe to:
Przegląd wyników analiz i weryfikacja ich kompletności;
Seminaria z klientem;
Identyfikacja krytycznych obszarów projektu i ocena jego ograniczeń;
Określenie architektury systemu;
Podejmowanie decyzji o korzystaniu z produktów firm trzecich, a także o sposobach integracji i mechanizmach wymiany informacji z tymi produktami;
Projekt hurtowni danych: model bazy danych;
Projektowanie procesów i kodu: ostateczny dobór narzędzi programistycznych, definiowanie interfejsów programowych, mapowanie funkcji systemu na jego moduły i definiowanie specyfikacji modułów;
Określenie wymagań dotyczących procesu testowania;
Określenie wymagań bezpieczeństwa systemu.
Realizacja
Podczas realizacji projektu szczególnie ważna jest koordynacja zespołu / zespołów programistycznych. Wszyscy programiści muszą przestrzegać ścisłych wytycznych dotyczących kontroli źródła. Po otrzymaniu projektu technicznego przystępują do pisania kodu modułu. Głównym zadaniem programistów jest zrozumienie specyfikacji: projektant napisał, co ma zrobić, a deweloper określa, jak to zrobić.
W fazie rozwoju istnieje ścisła interakcja między projektantami, programistami i zespołami testującymi. W przypadku intensywnego rozwoju tester jest dosłownie nierozłączny z deweloperem, skutecznie stając się członkiem zespołu deweloperskiego.
Najczęściej interfejsy użytkownika zmieniają się w fazie rozwoju. Wynika to z okresowej demonstracji modułów klientowi. Może również znacząco modyfikować zapytania o dane.
Faza rozwoju jest powiązana z fazą testowania i oba procesy przebiegają równolegle. System śledzenia błędów synchronizuje działania testerów i programistów.
Błędy należy klasyfikować według priorytetów. Dla każdej klasy błędów należy zdefiniować jasną strukturę działań: „co robić”, „jak pilne”, „kto jest odpowiedzialny za wynik”. Każdy problem powinien być śledzony przez projektanta / programistę / testera odpowiedzialnego za jego naprawienie. To samo dotyczy sytuacji, gdy zostaną naruszone planowane warunki rozwoju i oddania modułów do testów.
Dodatkowo należy zorganizować repozytoria gotowych modułów projektowych oraz biblioteki, które są wykorzystywane przy składaniu modułów. To repozytorium jest stale aktualizowane. Jedna osoba powinna nadzorować proces aktualizacji. Jedno repozytorium jest tworzone dla modułów, które przeszły testy funkcjonalne, drugie dla modułów, które przeszły pomyślnie testy łącza. Pierwsza to wersje robocze, druga to coś, z czego można już skompletować zestaw dystrybucyjny systemu i zademonstrować go klientowi do testów kontrolnych lub do realizacji dowolnych etapów pracy.
Testowanie
Zespoły testowe mogą być zaangażowane we współpracę na wczesnym etapie tworzenia projektu. Zwykle złożone testowanie jest podzielone na oddzielny etap rozwoju. W zależności od złożoności projektu testowanie i naprawianie błędów może zająć jedną trzecią, połowę całkowitego czasu projektu, a nawet więcej.
Im bardziej złożony projekt, tym większa potrzeba zautomatyzowania systemu śledzenia błędów, który zapewnia następujące funkcje:
Zapamiętanie komunikatu o błędzie (do którego elementu systemu należy błąd, kto go znalazł, jak go odtworzyć, kto jest odpowiedzialny za jego naprawienie, kiedy należy to naprawić);
System powiadamiania o nowych błędach, o zmianach statusu błędów znanych w systemie (powiadomienia mailowe);
Raporty o rzeczywistych błędach poszczególnych elementów systemu;
Informacje o błędzie i jego historii;
Zasady dostępu do błędów niektórych kategorii;
System śledzenia błędów ograniczony interfejs dostępu dla użytkownika końcowego.
Takie systemy zajmują się wieloma problemami organizacyjnymi, w szczególności kwestią automatycznego powiadamiania o błędach.
Rzeczywiste testy systemu są zwykle podzielone na kilka kategorii:
za) testy offline moduły; są wykorzystywane już na etapie tworzenia elementów systemu i pozwalają na śledzenie błędów poszczególnych elementów;
b) testy łącza elementy systemu; testy te są również wykorzystywane na etapie rozwoju, pozwalają na śledzenie prawidłowej interakcji i wymiany informacji pomiędzy komponentami systemu;
do) test systemu; jest głównym kryterium akceptacji systemu; Zazwyczaj jest to grupa testów, która obejmuje zarówno testy samodzielne, jak i testy powiązań i modele; taki test powinien odtwarzać działanie wszystkich komponentów i funkcji systemu; jego głównym celem jest wewnętrzna akceptacja systemu i ocena jego jakości;
re) test akceptacyjny; jego głównym celem jest przekazanie systemu klientowi;
mi) testy wydajności i obciążenia; ta grupa testów jest zawarta w systemie, to ona jest głównym narzędziem do oceny niezawodności systemu.
Każda grupa musi koniecznie zawierać testy dotyczące błędów modelowania. Sprawdzają reakcję komponentu, grupy komponentów i systemu jako całości na następujące awarie:
Oddzielny element systemu informacyjnego;
Grupy elementów systemu;
Główne moduły systemu;
System operacyjny;
Twarda awaria (awaria zasilania, dyski twarde).
Testy te pozwalają na ocenę jakości podsystemu przywracania prawidłowego stanu systemu informatycznego oraz służą jako główne źródło informacji do opracowywania strategii zapobiegania negatywnym konsekwencjom awarii podczas eksploatacji przemysłowej.
Innym ważnym aspektem programu testowania systemów informatycznych jest dostępność generatorów danych testowych. Służą do testowania funkcjonalności, niezawodności i wydajności systemu. Problemu oceny charakterystyk zależności działania systemu informatycznego od przyrostu ilości przetwarzanych informacji nie da się rozwiązać bez generatorów danych.
Realizacja
Operacja próbna pokrywa się z procesem testowania. System rzadko jest w pełni wdrażany. Zwykle jest to proces stopniowy lub iteracyjny (w przypadku cyklicznego cyklu życia).
Uruchomienie przebiega co najmniej w trzech etapach:
2) gromadzenie informacji;
3) osiągnięcie zdolności projektowej (czyli faktyczne przejście do etapu eksploatacji).
informacje mogą powodować dość wąski zakres błędów: głównie niedopasowanie danych podczas ładowania i własne błędy bootloadera. Metody kontroli jakości danych służą do ich identyfikacji i eliminacji. Takie błędy należy jak najszybciej poprawić.Podczas miesiączki gromadzenie informacji system informacyjny wykrywa największą liczbę błędów związanych z dostępem wielu użytkowników. Druga kategoria poprawek związana jest z tym, że użytkownik nie jest zadowolony z interfejsu. Jednocześnie modele cykliczne i etapowe mogą obniżyć koszty. Ten etap to także najpoważniejszy test - testy akceptacyjne klienta.
System osiąga możliwości projektowe w dobry sposób jest to dopracowywanie drobnych błędów i rzadkich poważnych błędów.
Obsługa i wsparcie techniczne
Na tym etapie ostatecznym dokumentem dla deweloperów jest świadectwo odbioru technicznego. Dokument określa wymagany personel i sprzęt niezbędny do obsługi systemu, a także warunki zakłócenia działania produktu oraz obowiązki stron. Ponadto warunki wsparcia technicznego są zwykle sporządzane jako osobny dokument.
