Cykl życia aplikacji. Cykl życia programu

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.

Wdrożenie (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.

Witam drodzy mieszkańcy Chabrowska! Myślę, że ciekawie będzie dla kogoś przypomnieć sobie, jakie modele tworzenia, wdrażania i użytkowania oprogramowania istniały wcześniej, jakie modele są obecnie głównie stosowane, dlaczego i czym właściwie są. To będzie mój mały temat.

Właściwie, co to jest cykl życia oprogramowania- ciąg zdarzeń zachodzących z systemem w trakcie jego tworzenia i dalszego użytkowania. Innymi słowy, jest to czas od początkowego momentu powstania dowolnego oprogramowania do zakończenia jego rozwoju i wdrożenia. Cykl życia oprogramowania można przedstawić w formie modeli.

Model cyklu życia oprogramowania- struktura zawierająca procesy działań i zadania realizowane podczas opracowywania, użytkowania i konserwacji oprogramowania.
Modele te można podzielić na 3 główne grupy:

1. Podejście inżynieryjne
2. Biorąc pod uwagę specyfikę zadania
3. Nowoczesne technologie szybkiego rozwoju

Przyjrzyjmy się teraz istniejącym modelom (podklasom) i oceńmy ich zalety i wady.

Model kodowania i eliminacji błędów

Całkiem prosty model, typowy dla studentów. Według tego modelu większość studentów rozwija, powiedzmy, pracę laboratoryjną.
Model ten ma następujący algorytm:

1. Sformułowanie problemu
2. Wydajność
3. Sprawdzanie wyniku
4. Jeśli to konieczne, przejdź do pierwszego punktu

Modelka również straszny przestarzały. Jest typowy dla lat 60-70-tych, więc praktycznie nie ma przewagi nad kolejnymi modelami z naszego testu, ale wady są oczywiste. Należy do pierwszej grupy modeli.

Model cyklu życia oprogramowania wodospadowego (kaskada)

Algorytm tej metody, który pokazuję na schemacie, ma szereg zalet w stosunku do algorytmu poprzedniego modelu, ale ma także szereg istotne niedociągnięcia.

Zalety:

• Sekwencyjna realizacja etapów projektu w ściśle ustalonej kolejności
• Pozwala ocenić jakość produktu na każdym etapie

Wady:

• Brak informacji zwrotnej pomiędzy etapami
• Nie odpowiada rzeczywistym warunkom rozwoju oprogramowania

Należy do pierwszej grupy modeli.

Model kaskadowy ze sterowaniem pośrednim (jacuzzi)

Model ten jest niemal identyczny algorytmicznie z modelem poprzednim, jednakże ma sprzężenie zwrotne z każdym etapem cyklu życia i powoduje bardzo istotną wadę: 10-krotny wzrost kosztów rozwoju. Należy do pierwszej grupy modeli.

Model V (rozwój oparty na testach)

Model ten ma algorytm bliższy nowoczesnym metodom, ale nadal ma szereg wad. Jest to jedna z głównych praktyk programowania ekstremalnego.

Model oparty na opracowaniu prototypu

Model ten opiera się na opracowywaniu prototypów i prototypowaniu produktu.
Prototypowanie stosowane na wczesnych etapach cyklu życia oprogramowania:

1. Wyjaśnij niejasne wymagania (prototyp interfejsu użytkownika)
2. Wybierz jedno z szeregu rozwiązań koncepcyjnych (realizacja scenariuszy)
3. Przeanalizuj wykonalność projektu

Klasyfikacja prototypów:

1. Poziomy i pionowy
2. Jednorazowe i ewolucyjne
3. papier i scenorysy

Poziomy prototypy - modeluje wyłącznie interfejs użytkownika bez wpływu na logikę przetwarzania i bazę danych.
Pionowy prototypy - testowanie rozwiązań architektonicznych.
Jednorazowe prototypy - do szybkiego rozwoju.
Ewolucyjny prototypy są pierwszym przybliżeniem systemu ewolucyjnego.

Model należy do drugiej grupy.

Model cyklu życia oprogramowania spiralnego

Model spiralny to proces tworzenia oprogramowania, który łączy projektowanie i prototypowanie przyrostowe, aby połączyć zalety koncepcji oddolnych i odgórnych.

Zalety:

• Szybko uzyskaj wyniki
• Zwiększona konkurencyjność
• Zmiana wymagań nie stanowi problemu

Wady:

• Brak regulacji scenicznej

Do trzeciej grupy zaliczają się takie modele jak ekstremalne programowanie(XP) SCRUM, model przyrostowy(RUP), ale chciałbym o nich porozmawiać w osobnym temacie.

Dziękuję bardzo za uwagę!

Adnotacja.

Wstęp.

1. Cykl życia oprogramowania

Wstęp.

Etapy procesu programowania Riley

Wstęp.

1.1.1. Sformułowanie problemu.

1.1.2. Projekt rozwiązania.

1.1.3. Kodowanie algorytmiczne.

1.1.4. Wsparcie programu.

1.1.5. Dokumentacja oprogramowania.

Wniosek do punktu 1.1

1.2. Wyznaczanie LCPO według Lehmana.

Wstęp.

1.2.1 Definicja systemu.

1.2.2. Realizacja.

1.2.3. Praca.

Wniosek do punktu 1.2.

1.3. Fazy ​​i działanie LCPO według Boehma

1.3.1. Model kaskadowy.

1.3.2. Ekonomiczne uzasadnienie modelu kaskadowego.

1.3.3. Udoskonalenie modelu kaskadowego.

1.3.4. Wyznaczanie faz cyklu życia.

1.3.5. Główna praca nad projektem.

Literatura.

Wstęp

Przemysłowe wykorzystanie komputerów i rosnące zapotrzebowanie na programy spowodowały pilne wyzwania, które należy znacznie zwiększyć produktywność tworzenia oprogramowania, rozwój przemysłowych metod planowania i projektowania programów, transfer technik, wzorców i metod organizacyjnych, technicznych, technicznych, ekonomicznych i społeczno-psychologicznych ze sfery produkcji materialnej do sfery zastosowań komputerów. Złożone podejście do procesów tworzenia, eksploatacji i utrzymania oprogramowania, postawił szereg palących problemów, których rozwiązanie wyeliminuje wąskie gardła w projektowaniu programów, skróci czas realizacji prac, usprawni wybór i adaptację istniejących programów, a być może określi losy systemów z komputerami wbudowanymi.

W praktyce tworzenia dużych projektów oprogramowania często nie ma takiej możliwości jednolite podejście do oceny kosztów pracy, terminów prac i kosztów materiałów, co utrudnia zwiększenie produktywności wytwarzania oprogramowania, a w efekcie efektywne zarządzanie cyklem życia oprogramowania. Ponieważ produkt dowolnego typu staje się produktem (z wyjątkiem być może programów edukacyjnych, prototypowych), podejście do jego produkcji powinno pod wieloma względami przypominać podejście do wytwarzania produktów przemysłowych, a kwestie projektowania programu stają się niezwykle istotne. Idea ta leży u podstaw książki B.W. Boehma „Inżynieria oprogramowania”, z której korzystaliśmy podczas pisania tego kursu. W tej książce projektowanie oprogramowania odnosi się do procesu tworzenia projektu oprogramowania.

1 Cykl życia oprogramowania

WSTĘP

LCPO to proces ciągły, który rozpoczyna się od momentu podjęcia decyzji o konieczności tworzenia oprogramowania, a kończy w momencie jego całkowitego wycofania z użytku.

Istnieje kilka podejść do wyznaczania faz i czynności cyklu życia oprogramowania (SLC), etapów procesu programowania, modeli kaskadowych i spiralnych. Ale wszystkie zawierają wspólne podstawowe komponenty: określenie problemu, projekt rozwiązania, wdrożenie, konserwację.

Być może najbardziej znaną i kompletną jest struktura procesu cyklu życia według Boehma, która obejmuje osiem faz. Zostanie to zaprezentowane bardziej szczegółowo w przyszłości.

Jedną z możliwych opcji mógłby być według Lehmana opis najwyższego poziomu, który obejmuje trzy główne fazy i w najbardziej ogólnym przypadku reprezentuje opis cyklu życia.

A dla urozmaicenia przedstawiamy etapy procesu programowania przedstawione przez D. Rileya w książce „Using the Modula-2 Language”. Pomysł ten moim zdaniem jest bardzo prosty i znajomy i od niego zacznijmy.

1.1 Kroki w procesie programowania Riley

Proces programowania składa się z czterech kroków (rysunek 1):

przedstawienie problemu, tj. uzyskanie odpowiedniego zrozumienia, jakie zadanie program ma realizować;

zaprojektowanie rozwiązania postawionego już problemu (z reguły takie rozwiązanie jest mniej formalne niż ostateczny program);

kodowanie programu, czyli przełożenie zaprojektowanego rozwiązania na program możliwy do wykonania na maszynie;

wsparcie programowe, tj. ciągły proces rozwiązywania problemów w programie i dodawania nowych funkcji.

Ryż. 1. Cztery kroki programowania.

Programowanie rozpoczyna się od momentu kiedy użytkownik, tj. ktoś, kto potrzebuje programu do rozwiązania problemu, przedstawia problem Analityk systemu. Użytkownik i analityk systemu wspólnie definiują opis problemu. Następnie transmitowany jest ten ostatni algorytmista, który jest odpowiedzialny za zaprojektowanie rozwiązania. Rozwiązanie (lub algorytm) reprezentuje sekwencję operacji, których wykonanie prowadzi do rozwiązania problemu. Ponieważ algorytm często nie nadaje się do wykonania na maszynie, należy go przetłumaczyć na program maszynowy. Operację tę wykonuje koder. Za późniejsze zmiany w programie odpowiedzialny jest towarzyszący programista. Analityk systemowy, algorytmista, koder i towarzyszący mu programista – wszyscy są programistami.

W przypadku dużego projektu oprogramowania liczba użytkowników, analityków systemowych i algorytmistów może być znacząca. Dodatkowo, ze względu na nieprzewidziane okoliczności może zaistnieć konieczność powrotu do poprzednich kroków. Wszystko to stanowi dodatkowy argument za ostrożnym projektowaniem oprogramowania: wyniki każdego kroku powinny być kompletne, dokładne i zrozumiałe.

1.1.1 Opis problemu

Jednym z najważniejszych kroków w programowaniu jest zdefiniowanie problemu. Funkcjonuje jako umowa pomiędzy użytkownikiem a programistą(-ami). Podobnie jak źle sporządzona umowa z prawnego punktu widzenia, źle napisane określenie problemu jest bezużyteczne. Dzięki dobremu określeniu problemu zarówno użytkownik, jak i programista jasno i jednoznacznie przedstawiają zadanie, które należy wykonać, tj. w tym przypadku brane są pod uwagę interesy zarówno użytkownika, jak i programisty. Użytkownik może zaplanować wykorzystanie oprogramowania, które nie zostało jeszcze stworzone, bazując na wiedzy o tym, co potrafi. Dobre sformułowanie problemu stanowi podstawę do sformułowania jego rozwiązania.

Sformułowanie problemu (specyfikacja programu); zasadniczo oznacza dokładny, kompletny i zrozumiały opis tego, co dzieje się, gdy wykonywany jest określony program. Użytkownik zwykle patrzy na komputer jak na czarną skrzynkę: dla niego nie jest ważne, jak komputer działa, ale ważne jest to, co komputer potrafi zrobić, co go interesuje. W tym przypadku główna uwaga skupiona jest na interakcji człowieka z maszyną.

Charakterystyka dobrego opisu problemu:

Dokładność, tj. eliminując wszelkie niejasności. Nie powinno być wątpliwości, jaki będzie wynik programu dla danych danych wejściowych.

Kompletność, tj. rozważenie wszystkich opcji dla danego wejścia, w tym błędnych lub niezamierzonych danych wejściowych, i określenie odpowiedniego wyjścia.

Przejrzystość, tj. musi być zrozumiałe zarówno dla użytkownika, jak i analityka systemu, ponieważ określenie problemu jest jedyną umową między nimi.

Często wymagania dotyczące dokładności, kompletności i przejrzystości są ze sobą sprzeczne. Tym samym wiele dokumentów prawnych jest trudnych do zrozumienia, gdyż są napisane językiem formalnym, co pozwala na sformułowanie niektórych przepisów z niezwykłą precyzją, wykluczając drobne rozbieżności. Na przykład niektóre pytania w arkuszach egzaminacyjnych są czasami sformułowane tak precyzyjnie, że student spędza więcej czasu na zrozumieniu pytania, niż na udzieleniu na nie odpowiedzi. Co więcej, ze względu na dużą liczbę szczegółów uczeń może nawet nie zrozumieć głównego znaczenia pytania. Najlepsze sformułowanie problemu to takie, które zapewnia równowagę wszystkich trzech wymagań.

Standardowa forma opisu problemu.

Rozważmy następujące sformułowanie problemu: „Wprowadź trzy liczby i wypisz je w podanej kolejności”.

Oświadczenie takie nie spełnia powyższych wymagań: nie jest ani dokładne, ani pełne, ani zrozumiałe. Rzeczywiście, czy liczby należy wpisywać po jednej w każdym wierszu, czy wszystkie w jednym wierszu? Czy wyrażenie „w kolejności” oznacza uporządkowanie od największego do najmniejszego, od najmniejszego do największego, czy też tę samą kolejność, w jakiej zostały wprowadzone.

Oczywiście takie stwierdzenie nie daje odpowiedzi na wiele pytań. Jeśli weźmiemy pod uwagę odpowiedzi na wszystkie pytania, sformułowanie problemu stanie się pełne i trudne do zrozumienia. Dlatego D. Riley sugeruje zastosowanie standardowego formularza do postawienia problemu, który zapewnia maksymalną dokładność, kompletność, przejrzystość i obejmuje:

nazwa zadania (definicja schematyczna);

opis ogólny (krótkie streszczenie zadania);

błędy (wyszczególnione są nietypowe opcje wprowadzania danych, aby pokazać użytkownikom i programistom, jakie działania podjęłaby maszyna w takich sytuacjach);

przykład (dobry przykład może przekazać istotę problemu, a także zilustrować różne przypadki).

Przykład. Opis problemu w standardowej formie.

NAZWA

Sortowanie trzech liczb całkowitych.

OPIS

Wejście i wyjście trzech liczb całkowitych, posortowanych od najmniejszej do największej liczby.

Wprowadzono trzy liczby całkowite, po jednej w każdym wierszu. Liczba całkowita to jedna lub więcej kolejnych cyfr dziesiętnych, które mogą być poprzedzone znakiem plusa „+” lub znakiem minusa „–”.

Drukowane są trzy wprowadzone liczby całkowite, a wszystkie trzy w tym samym wierszu. Numery sąsiadujące oddziela się spacją. Liczby są wyświetlane od najmniejszej do największej, od lewej do prawej.

1) Jeżeli wprowadzono mniej niż trzy liczby, program oczekuje na dodatkowe wprowadzenie.

W ogólnym przypadku system oprogramowania oprócz samych programów zawiera również sprzęt i zwykle uważa się, że jest otoczony innym oprogramowaniem i systemami sprzętowymi.

Cykl życia systemu oprogramowania jest zwykle rozumiany jako cały okres istnienia systemu oprogramowania, począwszy od momentu opracowania wstępnej koncepcji systemu, a skończywszy, gdy system stanie się przestarzały. Pojęcie „cykl życia” stosowane, gdy oczekuje się, że system oprogramowania będzie miał dość długą żywotność, w przeciwieństwie do programowania eksperymentalnego, w którym programy są uruchamiane kilka razy i nie są używane ponownie.

Cykl życia jest tradycyjnie modelowany jako pewna liczba kolejnych etapów (lub etapów, faz). Obecnie nie ma ogólnie przyjętego podziału cyklu życia systemu oprogramowania na etapy. Czasami scena jest wyróżniona jako oddzielny punkt, czasami jest włączana jako integralna część większej sceny. Działania wykonywane na tym lub innym etapie mogą się różnić. Nazwy tych etapów nie są jednolite. Dlatego najpierw spróbujemy opisać jakiś uogólniony cykl życia systemu oprogramowania, a następnie zademonstrować kilka przykładów różnych cykli życia, wskazując analogie z tym uogólnionym cyklem.

Etapy cyklu życia oprogramowania

Cykl życia oprogramowania to okres rozwoju i eksploatacji oprogramowania, który zazwyczaj obejmuje następujące etapy: -1- pojawienie się i badanie pomysłu; -2- analiza i projektowanie wymagań; -3- programowanie; -4- testowanie i debugowanie; -5- wprowadzenie programu w życie; -6- obsługa i konserwacja; -7- koniec pracy.

Należy zauważyć, że podzielenie cyklu życia na etapy czasami pomaga przyćmić pewne ważne aspekty tworzenia oprogramowania; Dotyczy to zwłaszcza tak niezbędnego procesu, jak iteracyjna realizacja różnych etapów cyklu życia w celu skorygowania błędów, zmiany decyzji, które okazały się błędne, czy uwzględnienia zmian w ogólnych wymaganiach wobec systemu.

Przykłady opisów cykli życia

Przyjrzyjmy się kilku opisom cyklu życia oprogramowania, które posłużą jako swego rodzaju komentarz do etapów uogólnionego cyklu życia.

W krajowych dokumentach regulacyjnych (na przykład GOST ESPD) przyjmuje się następujący podział na etapy, który podaje się ze wskazaniem analogii z listy podanej na początku rozdziału:

opracowanie specyfikacji technicznych (etap 1 i 2);

projekt techniczny (etap trzeci do 3.2.1 włącznie);

projekt roboczy (3.2.2, 4.2.1 i częściowo 4.2, 4.3);

wdrożenie pilotażowe (4.2 i 4.3);

oddanie do eksploatacji komercyjnej (etap 5);

eksploatacja przemysłowa (etap 6).

Opis taki opiera się na technologii tworzenia sprzętu i dlatego nie uwzględnia w pełni wszystkich charakterystycznych cech projektowania oprogramowania. Bardziej odpowiednim opisem cyklu życia oprogramowania wydaje się być 12 etapów, które są bardzo podobne do etapów uogólnionego cyklu życia (patrz rysunek 1.1). W nawiasach po nazwie fazy wskazany jest analog z uogólnionego cyklu. Prawie wszystkie etapy kończą się weryfikacją wyników uzyskanych na odpowiednim etapie.

Ryż. 1.1 Przykład cyklu życia systemów oprogramowania

Inicjowanie i planowanie projektu (etap 1). Określane są niezbędne działania, plany i organizacja zarządzania projektem. Określane są środki zapewniające ciągłą realizację faz cyklu życia.

Analiza wymagań docelowych (2.1). Określa się ogólną charakterystykę systemu, jaką musi on spełniać, bez uwzględnienia sposobów realizacji. Ustalono, co system powinien robić i jak powinien to robić.

Analiza wymagań systemowych (2.2). Opisuje, w jaki sposób powinny być realizowane żądania użytkownika, pod kątem konkretnych koncepcji funkcjonalnych, działania proponowanego systemu, przechowywanych danych, wykorzystywanego interfejsu - wszystko to bez uwzględnienia fizycznej implementacji. Testowana jest przydatność tych konkretnych koncepcji.

Projekt systemu (3.1). Strukturę systemu, czyli inaczej jego architekturę ustala się pod kątem głównych komponentów tego systemu i ich zamierzonej implementacji (sprzęt, oprogramowanie, wykorzystanie środowiska itp.). Ustalono wymagania dla każdego komponentu, a także strategię testowania i integracji.

Wstępny projekt oprogramowania (3.2.1). Określenie konkretnych komponentów oprogramowania, które zostaną opracowane i zaimplementowane w finalnym systemie. Sprawdzenie tego zestawu komponentów pod kątem zgodności z ogólnymi wymaganiami oprogramowania. Określenie wymagań funkcjonalnych, eksploatacyjnych i testowych dla każdego konkretnego komponentu.

Szczegółowy projekt oprogramowania (3.2.2). Jeśli chodzi o użyte konstrukcje oprogramowania, opisano sposób opracowywania każdego konkretnego komponentu. Opisano sposoby wykorzystania poszczególnych komponentów systemu.

Kodowanie i testowanie oprogramowania (4.1.1 i 4.1.2). Tworzenie, testowanie poszczególnych modułów, dokumentacja i akceptacja komponentów oprogramowania tworzących system oprogramowania.

Integracja oprogramowania (część 4.2). Testowanie wydajności i kompletności funkcjonalnej części oprogramowania systemu w przewidywalnym środowisku (sprzęt i środowisko).

Integracja systemu (4.3). Testowanie wydajności i kompletności funkcjonalnej części całego systemu jako całości.

Odbiór i dostawa systemu (5). System zostaje zaakceptowany przez Klienta i system zostaje mu dostarczony.

Eksploatacja i konserwacja systemu (6). Wydawanie kolejnych wersji lub wersji systemu, których potrzeba wynika z eliminacji defektów, testowania zmienionych wymagań itp.

Zakończenie projektu (7). Stworzenie modelu post-original działań projektowych z analizą zalet, wad itp. i wykorzystanie ich jako podstawy do ulepszenia procesu rozwoju.

Jako następny przykład rozważmy niepełny cykl życia oprogramowania, bez etapów eksploatacji i konserwacji (patrz rys. 1.2). Ta opcja nie ustala kolejności faz ani etapów, ale raczej proponuje listę działań, które należy wykonać w całym cyklu życia oprogramowania. Działania te można podzielić lub, odwrotnie, pogrupować w różne etapy, w zależności od konkretnych warunków. Można wyróżnić następujące etapy cyklu życia systemów oprogramowania (w nawiasach, jak poprzednio, analogie z uogólnionego modelu cyklu):

etap planowania, który określa i koordynuje działania mające na celu rozwój systemu oprogramowania (etap 1);

etap rozwoju, na którym powstaje system oprogramowania:

sformułowanie problemu (etap 2),

projekt (3),

kodowanie (4.1.1),

uzyskanie kodu wykonywalnego (4.1.1, 4.3);

zintegrowany etap zapewniający korektę, weryfikację i określenie kompletności systemu oprogramowania, a także jego wydanie. Etap ten obejmuje weryfikację, monitorowanie konfiguracji systemu, ocenę jakości oraz sprawdzenie interakcji pomiędzy etapami. Z nazwy tego etapu jasno wynika, że ​​jest on wykonywany w połączeniu z innymi etapami w całym cyklu życia systemu.

Ryż. 1.2 Opcja uproszczonego cyklu życia systemu oprogramowania.

Brak zintegrowanego etapu w ogólnym cyklu życia nie oznacza, że ​​weryfikację przeprowadza się tylko wtedy, gdy jest to wyraźnie wskazane w nazwie etapu (na przykład 4.2.1 i 4.2). Każdy etap można uznać za zakończony dopiero wtedy, gdy wyniki uzyskane na tym etapie zostaną uznane za zadowalające, a w tym celu konieczne jest sprawdzenie wyników na każdym etapie. W podsumowaniu cyklu życia niektóre kontrole zostały wyróżnione jako osobne pozycje, aby wykazać zwiększoną liczbę, złożoność i znaczenie tych kontroli.

Kolejność etapów cyklu życia różnych systemów oprogramowania zależy od takich cech, jak funkcjonalność, złożoność, rozmiar, stabilność, wykorzystanie wcześniej uzyskanych wyników, opracowywana strategia i sprzęt.

Na ryc. 1.3. pokazuje kolejność etapów tworzenia oprogramowania dla poszczególnych komponentów jednego systemu oprogramowania o różnych cyklach życia.

Ryż. 1.3 Kolejność etapów rozwoju komponentów oprogramowania

Dla komponentu W ze zbioru wymagań systemowych dla pojedynczego produktu tworzy się podzbiór wymagań związanych z tym komponentem, wymagania te wykorzystuje się przy tworzeniu projektu dla komponentu oprogramowania, projekt ten jest implementowany w kodzie źródłowym, a następnie komponent jest zintegrowany ze sprzętem. Komponent X pokazuje wykorzystanie wcześniej opracowanego oprogramowania. Komponent Y pokazuje zastosowanie prostej pojedynczej funkcji, którą można zakodować bezpośrednio w oparciu o wymagania oprogramowania. Komponent Z pokazuje zastosowanie strategii prototypu. Zazwyczaj celem prototypowania jest lepsze zrozumienie wymagań oprogramowania oraz zmniejszenie ryzyka technicznego i rozwojowego podczas tworzenia produktu końcowego. Wymagania wstępne stanowią podstawę do uzyskania prototypu. Prototyp ten jest przekształcany w środowisko typowe dla konkretnego zastosowania rozwojowego systemu. Wynikiem transformacji są dopracowane dane, które służą do stworzenia finalnego produktu programowego.

Prawie wszystkie etapy cyklu życia są połączone z weryfikacją.

Tworzenie oprogramowania nie jest możliwe bez zrozumienia tzw. cyklu życia oprogramowania. Przeciętny użytkownik może nie musi tego wiedzieć, ale wskazane jest opanowanie podstawowych standardów (później zostanie powiedziane, dlaczego jest to konieczne).

Czym jest cykl życia w sensie formalnym?

Przez cykl życia dowolnej aplikacji rozumie się zazwyczaj czas jej istnienia, począwszy od etapu rozwoju, aż do momentu całkowitego zaprzestania stosowania w wybranym obszarze zastosowań, aż do całkowitego wycofania aplikacji z użytkowania.

Mówiąc najprościej, systemy informacyjne w postaci programów, baz danych, a nawet „systemów operacyjnych” są poszukiwane tylko wtedy, gdy dane i możliwości, jakie dają, są aktualne.

Uważa się, że definicja cyklu życia nie dotyczy w żaden sposób aplikacji testowych, np. wersji beta, które są najbardziej niestabilne w działaniu. Sam cykl życia oprogramowania zależy od wielu czynników, wśród których jedną z głównych ról odgrywa środowisko, w którym program będzie używany. Można jednak wskazać ogólne warunki stosowane przy definiowaniu pojęcia cyklu życia.

Wymagania wstępne

• sformułowanie problemu;
• analiza wzajemnych wymagań przyszłego oprogramowania dla systemu;
• projekt;
• programowanie;
• kodowanie i kompilacja;
• testowanie;
• debugowanie;
• wdrożenie i utrzymanie oprogramowania.

Tworzenie oprogramowania składa się ze wszystkich wymienionych etapów i nie może obejść się bez choćby jednego z nich. Jednakże ustanowiono specjalne standardy kontroli takich procesów.

Standardy procesu cyklu życia oprogramowania

Wśród systemów, które z góry określają warunki i wymagania dla takich procesów, dziś możemy wymienić tylko trzy główne:

• GOST 34.601-90;
• ISO/IEC 12207:2008;
• Oracle CDM.

Dla drugiego międzynarodowego standardu istnieje rosyjski odpowiednik. Jest to GOST R ISO/IEC 12207-2010, który odpowiada za inżynierię systemów i oprogramowania. Jednak cykl życia oprogramowania opisany w obu zasadach jest zasadniczo identyczny. Wyjaśniono to po prostu.

Rodzaje oprogramowania i aktualizacji

Notabene, w przypadku większości znanych obecnie programów multimedialnych są one sposobem na zapisanie podstawowych parametrów konfiguracyjnych. Korzystanie z oprogramowania tego typu jest oczywiście dość ograniczone, ale zrozumienie ogólnych zasad pracy z samymi odtwarzaczami multimedialnymi nie zaszkodzi. I własnie dlatego.

Tak naprawdę uwzględniają cykl życia oprogramowania jedynie na poziomie aktualizacji wersji samego odtwarzacza lub instalacji kodeków i dekoderów. Transkodery audio i wideo są integralną cechą każdego systemu audio lub wideo.

Przykład oparty na FL Studio

Początkowo wirtualne studio-sekwenser FL Studio nosiło nazwę Fruity Loops. Cykl życia oprogramowania w pierwotnej modyfikacji dobiegł końca, jednak aplikacja uległa pewnym przekształceniom i uzyskała obecną formę.

Jeśli mówimy o etapach cyklu życia, najpierw na etapie stawiania problemu ustalono kilka obowiązkowych warunków:

• tworzenie modułu perkusyjnego podobnego do maszyn rytmicznych, takich jak Yamaha RX, ale przy użyciu jednorazowych sampli lub sekwencji w formacie WAV nagranych na żywo w studiach;
• integracja z systemami operacyjnymi Windows;
• możliwość eksportu projektu w formatach WAV, MP3 i OGG;
• Kompatybilność projektów z dodatkową aplikacją Fruity Tracks.

Na etapie rozwoju wykorzystano narzędzia języka programowania C. Ale platforma wyglądała dość prymitywnie i nie zapewniała użytkownikowi końcowemu wymaganej jakości dźwięku.

W tym względzie na etapie testów i debugowania programiści musieli podążać ścieżką niemieckiej korporacji Steinberg i zastosować obsługę trybu Full Duplex w wymaganiach głównego sterownika dźwięku. Jakość dźwięku stała się wyższa i umożliwia zmianę tempa, wysokości dźwięku oraz dodawanie dodatkowych efektów FX w czasie rzeczywistym.

Za koniec cyklu życia tego oprogramowania uważa się wydanie pierwszej oficjalnej wersji FL Studio, które w odróżnieniu od swoich przodków posiadało już interfejs pełnoprawnego sekwencera z możliwością edycji parametrów na wirtualnym 64 -kanałowa konsola miksująca z nieograniczonym dodawaniem ścieżek audio i ścieżek MIDI.

To nie był koniec. Na etapie zarządzania projektem wprowadzono obsługę łączenia wtyczek w formacie VST (najpierw druga, potem trzecia wersja), który kiedyś był opracowany przez Steinberga. Z grubsza rzecz biorąc, każdy wirtualny syntezator obsługujący host VST może połączyć się z programem.

Nic dziwnego, że wkrótce każdy kompozytor mógł korzystać z analogów modeli „hardware”, na przykład kompletnych zestawów dźwięków popularnego niegdyś Korga M1. Ponadto. Zastosowanie modułów takich jak Addictive Drums czy uniwersalnej wtyczki Kontakt umożliwiło odtworzenie na żywo dźwięków prawdziwych instrumentów nagranych we wszystkich odcieniach artykulacji w profesjonalnych studiach.

Jednocześnie programiści starali się osiągnąć maksymalną jakość, tworząc obsługę sterowników ASIO4ALL, która okazała się przewyższać tryb Full Duplex. W związku z tym wzrosła również szybkość transmisji. Obecnie jakość eksportowanego pliku audio może wynosić 320 kb/s przy częstotliwości próbkowania 192 kHz. I to jest profesjonalne brzmienie.

Jeśli chodzi o pierwotną wersję, jej cykl życia można nazwać całkowicie kompletnym, ale takie stwierdzenie jest względne, ponieważ aplikacja zmieniła jedynie nazwę i zyskała nowe możliwości.

Perspektywy rozwoju

Wiadomo już, jakie są etapy cyklu życia oprogramowania. Ale o rozwoju takich technologii warto wspomnieć osobno.

Nie trzeba dodawać, że żaden twórca oprogramowania nie jest zainteresowany tworzeniem przelotnego produktu, który prawdopodobnie nie przetrwa na rynku przez kilka lat. W dłuższej perspektywie wszyscy patrzą na jego długotrwałe użytkowanie. Można to osiągnąć na różne sposoby. Ale z reguły prawie wszystkie sprowadzają się do wydania aktualizacji lub nowych wersji programów.

Nawet w przypadku systemu operacyjnego Windows takie trendy widać gołym okiem. Jest mało prawdopodobne, aby dziś choć jeden użytkownik korzystał z systemów takich jak modyfikacje 3.1, 95, 98 czy Millennium. Ich cykl życia zakończył się wraz z wydaniem XP. Jednak wersje serwerowe oparte na technologiach NT są nadal aktualne. Nawet dzisiejszy system Windows 2000 jest nie tylko bardzo istotny, ale pod niektórymi parametrami instalacji lub bezpieczeństwa przewyższa nawet najnowsze osiągnięcia. To samo dotyczy systemu NT 4.0, a także specjalistycznej modyfikacji systemu Windows Server 2012.

Ale w odniesieniu do tych systemów wsparcie nadal deklarowane jest na najwyższym poziomie. Ale niegdyś rewelacyjna Vista wyraźnie przeżywa schyłek swojego cyklu. Nie dość, że okazał się niedokończony, to jeszcze zawierał tyle błędów i luk w jego systemie bezpieczeństwa, że ​​można się tylko domyślać, jak tak nie do utrzymania rozwiązanie mogło zostać wypuszczone na rynek oprogramowania.

Jeśli jednak powiemy, że rozwój oprogramowania dowolnego rodzaju (sterującego czy aplikacyjnego) nie stoi w miejscu, to możemy jedynie powiedzieć, że dziś dotyczy to nie tylko systemów komputerowych, ale także urządzeń mobilnych, w których stosowane technologie często wyprzedzają sektor komputerowy. Pojawienie się chipów procesorowych opartych na ośmiu rdzeniach nie jest najlepszym przykładem? Jednak nie każdy laptop może pochwalić się posiadaniem takiego sprzętu.

Kilka dodatkowych pytań

Jeśli chodzi o zrozumienie cyklu życia oprogramowania, całkiem arbitralne jest stwierdzenie, że zakończył się on w pewnym momencie, ponieważ oprogramowanie nadal cieszy się wsparciem programistów, którzy je stworzyli. Końcówka odnosi się raczej do starszych aplikacji, które nie spełniają wymagań współczesnych systemów i nie mogą działać w ich środowisku.

Ale nawet biorąc pod uwagę postęp technologiczny, wiele z nich może wkrótce stać się nie do utrzymania. Następnie będziesz musiał podjąć decyzję o wydaniu aktualizacji lub całkowitej zmianie całej koncepcji pierwotnie zawartej w oprogramowaniu. Stąd nowy cykl, który wiąże się ze zmianą warunków początkowych, środowiska programistycznego, testowaniem i ewentualnym długotrwałym użytkowaniem w określonym obszarze.

Jednak w dzisiejszej technologii komputerowej preferowany jest rozwój zautomatyzowanych systemów sterowania (ACS), które są wykorzystywane w produkcji. Nawet systemy operacyjne w porównaniu ze specjalistycznymi programami tracą.

Środowiska oparte na Visual Basic pozostają znacznie bardziej popularne niż systemy Windows. I wcale nie mówimy o oprogramowaniu aplikacyjnym dla systemów UNIX. Co możemy powiedzieć, jeśli prawie wszystkie sieci komunikacyjne w tych samych Stanach Zjednoczonych działają wyłącznie dla nich. Nawiasem mówiąc, na tej platformie pierwotnie tworzono również systemy takie jak Linux i Android. Dlatego najprawdopodobniej UNIX ma znacznie większe perspektywy niż inne produkty razem wzięte.

Zamiast sumy

Pozostaje dodać, że w tym przypadku podane są jedynie ogólne zasady i etapy cyklu życia oprogramowania. W rzeczywistości nawet początkowo ustalone zadania mogą się znacznie różnić. W związku z tym różnice można zaobserwować na innych etapach.

Jednak podstawowe technologie tworzenia oprogramowania i ich późniejszego wsparcia powinny być jasne. Co do reszty, należy wziąć pod uwagę specyfikę tworzonego oprogramowania, środowiska, w jakich ma ono działać, możliwości programów udostępnianych użytkownikowi końcowemu lub produkcji i wiele więcej.

Ponadto czasami cykle życia mogą zależeć od przydatności narzędzi programistycznych. Jeśli np. język programowania stanie się przestarzały, nikt nie będzie pisał na jego podstawie programów, a tym bardziej nie wdrażał ich do zautomatyzowanych systemów kontroli produkcji. Tutaj na pierwszy plan wysuwają się nawet nie programiści, ale marketerzy, którzy muszą w odpowiednim czasie reagować na zmiany na rynku komputerowym. A takich specjalistów na świecie nie jest zbyt wielu. Najbardziej poszukiwana jest wysoko wykwalifikowana kadra, która potrafi trzymać rękę na pulsie rynku. Często są to tak zwani „szarzy kardynałowie”, od których zależy sukces lub porażka określonego oprogramowania w branży IT.

Być może nie zawsze rozumieją istotę programowania, ale wyraźnie potrafią określić modele cyklu życia oprogramowania i długości czasu jego użytkowania, bazując na światowych trendach w tym obszarze. Skuteczne zarządzanie często przynosi bardziej wymierne rezultaty. Tak, przynajmniej technologie PR, reklama itp. Użytkownik może nie potrzebować jakiejś aplikacji, ale jeśli jest aktywnie reklamowana, użytkownik ją zainstaluje. Jest to już, że tak powiem, poziom podświadomości (ten sam efekt co 25. klatka, gdy informacja jest wprowadzana do świadomości użytkownika niezależnie od niego).

Oczywiście takie technologie są na świecie zakazane, jednak wielu z nas nawet nie zdaje sobie sprawy, że nadal można je wykorzystać i w określony sposób oddziaływać na podświadomość. Wystarczy spojrzeć na koszt „zombifikacji” przez kanały informacyjne czy portale internetowe, nie mówiąc już o zastosowaniu silniejszych środków, jak na przykład ekspozycja na infradźwięki (wykorzystano to w jednym przedstawieniu operowym), w wyniku czego dana osoba może strach lub niewłaściwe emocje.

Wracając do oprogramowania, warto dodać, że niektóre programy podczas uruchamiania wykorzystują sygnał dźwiękowy, aby przyciągnąć uwagę użytkownika. I, jak pokazują badania, takie aplikacje są bardziej opłacalne niż inne programy. Naturalnie wydłuża się także cykl życia oprogramowania, niezależnie od tego, jaką funkcję mu początkowo przypisano. I niestety wielu programistów z tego korzysta, co budzi wątpliwości co do legalności takich metod.

Ale nie nam to oceniać. Niewykluczone, że w najbliższej przyszłości zostaną opracowane narzędzia umożliwiające identyfikację tego typu zagrożeń. Na razie to tylko teoria, ale zdaniem części analityków i ekspertów do praktycznego zastosowania pozostało już bardzo niewiele. Jeśli już tworzą kopie sieci neuronowych ludzkiego mózgu, to co możemy powiedzieć?