Cykl życia oprogramowania. Cykl życia oprogramowania Etapy cyklu życia oprogramowania

Powinniśmy zacząć od zdefiniowaniaCykl życia oprogramowania(Software Life Cycle Model) to okres, który rozpoczyna się od momentu podjęcia decyzji o stworzeniu oprogramowania, a kończy w momencie jego całkowitego wycofania z eksploatacji. Ten cykl to proces budowania i rozwijania oprogramowania.

Modele cyklu życia oprogramowania

Cykl życia można przedstawić w postaci modeli. Obecnie najczęstsze to:kaskadowe, przyrostowe (model etapowy z kontrolą pośrednią ) oraz spiralamodele cyklu życia.

Model kaskadowy

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

Proces rozwoju realizowany jest przy użyciu uporządkowanej sekwencji niezależnych kroków. Model przewiduje, że każdy kolejny krok rozpoczyna się po zakończeniu kroku poprzedniego. Na wszystkich etapach modelu realizowane są procesy i prace pomocnicze i organizacyjne, w tym zarządzanie projektami, zarządzanie oceną i jakością, weryfikacja i certyfikacja, zarządzanie konfiguracją, tworzenie dokumentacji. W wyniku realizacji kroków powstają produkty pośrednie, których nie można zmienić w kolejnych krokach.

Cykl życia tradycyjnie dzieli się na następujące głównegradacja:

Analiza wymagań,
Projekt,
Kodowanie (programowanie),
Testowanie i debugowanie,
Obsługa i konserwacja.

Zalety modelu:

stabilność wymagań w całym cyklu życia rozwoju;
na każdym etapie tworzony jest komplet dokumentacji projektowej spełniającej kryteria kompletności i spójności;
pewność i zrozumiałość kroków modelu oraz prostota jego zastosowania;
etapy pracy wykonywane w logicznej kolejności pozwalają zaplanować terminy zakończenia wszystkich prac i odpowiadające im zasoby (pieniężne, materialne i ludzkie).

Wady modelu:

złożoność jasnego formułowania wymagań i niemożność ich dynamicznej zmiany w trakcie pełnego cyklu życia;
mała elastyczność w zarządzaniu projektami;
podciąg struktura liniowa proces rozwoju, w wyniku powrotu do poprzednich kroków w celu rozwiązania pojawiających się problemów prowadzi do wzrostu kosztów i zakłócenia harmonogramu prac;
nieprzydatność półproduktu do użycia;
brak możliwości elastycznego modelowania unikalnych systemów;
późne wykrywanie problemów związanych z kompilacją dzięki jednoczesnej integracji wszystkich wyników pod koniec rozwoju;
niewystarczający udział użytkownika w tworzeniu systemu – na samym początku (podczas tworzenia wymagań) i na końcu (podczas testów akceptacyjnych);
użytkownicy nie mogą być przekonani o jakości opracowanego produktu do końca całego procesu rozwoju. Nie mają możliwości oceny jakości, ponieważ nie mogą zobaczyć gotowego produktu rozwoju;
użytkownik nie ma możliwości stopniowego przyzwyczajania się do systemu. Proces uczenia następuje pod koniec cyklu życia, kiedy oprogramowanie zostało już uruchomione;
każda faza jest warunkiem koniecznym do wykonania kolejnych czynności, co sprawia, że taka metoda jest ryzykownym wyborem dla systemów, które nie mają analogów, ponieważ. nie nadaje się do elastycznego modelowania.

Trudno jest wdrożyć model cyklu życia wodospadu ze względu na złożoność rozwoju PS bez powrotu do poprzednich kroków i zmiany ich wyników w celu wyeliminowania pojawiających się problemów.

Zakres modelu kaskadowego

Ograniczenie zakresu modelu kaskadowego determinują jego wady. Jego zastosowanie jest najskuteczniejsze w następujących przypadkach:

przy opracowywaniu projektów z jasnymi, niezmiennymikoło życia wymagania zrozumiałe przez implementację i metodologie techniczne;
przy opracowywaniu projektu nastawionego na zbudowanie systemu lub produktu tego samego typu, co wcześniej opracowany przez programistów;
przy opracowywaniu projektu związanego z tworzeniem i wydaniem nowej wersji istniejącego produktu lub systemu;
przy opracowywaniu projektu związanego z przeniesieniem istniejącego produktu lub systemu na nową platformę;
przy realizacji dużych projektów angażujących kilka dużych zespołów programistycznych.

model przyrostowy

(model etapowy z kontrolą pośrednią)

model przyrostowy(pol. przyrost- wzrost, przyrost) oznacza rozwój oprogramowania z liniową sekwencją etapów, ale w kilku przyrostach (wersjach), tj. z planowanymi ulepszeniami produktów tak długo, jak długo cykl życia oprogramowania dobiega końca.

Tworzenie oprogramowania odbywa się w iteracjach z pętlami sprzężenia zwrotnego między etapami. Dostosowania międzyetapowe pozwalają na uwzględnienie rzeczywistego wzajemnego oddziaływania wyników rozwoju na różnych etapach, żywotność każdego z etapów wydłuża się na cały okres rozwoju.

Na początku pracy nad projektem ustalane są wszystkie podstawowe wymagania dla systemu, z podziałem na mniej i bardziej istotne. Następnie rozwój systemu odbywa się w sposób przyrostowy, aby programista mógł wykorzystać dane uzyskane podczas tworzenia oprogramowania. Każdy przyrost powinien dodać pewną funkcjonalność do systemu. W takim przypadku wydanie rozpoczyna się od składników o najwyższym priorytecie. Po zdefiniowaniu części systemu weź pierwszą część i zacznij ją szczegółowo opisywać, stosując najbardziej odpowiedni do tego proces. Jednocześnie możliwe jest doprecyzowanie wymagań dla innych części, które zostały zamrożone w aktualnym zestawie wymagań tej pracy. W razie potrzeby możesz wrócić do tej części później. Jeśli część jest gotowa, dostarczana jest do klienta, który może wykorzystać ją w swojej pracy. Umożliwi to klientowi wyjaśnienie wymagań dla następujących komponentów. Następnie opracowują kolejną część systemu. Kluczowe kroki w tym procesie to po prostu implementacja podzbioru wymagań dotyczących oprogramowania i udoskonalanie modelu w serii kolejnych wydań, aż do wdrożenia całego oprogramowania.

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

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

Zalety oraz ograniczeniatego modelu (strategia) są takie same jak kaskady (klasyczny model cyklu życia). Ale w przeciwieństwie do klasycznej strategii, klient może zobaczyć rezultaty wcześniej. Na podstawie wyników opracowania i wdrożenia pierwszej wersji może nieznacznie zmienić wymagania dotyczące rozwoju, zrezygnować z niego lub zaproponować opracowanie bardziej zaawansowanego produktu wraz z zawarciem nowej umowy.

Zalety:

koszty ponoszone w związku ze zmieniającymi się wymaganiami użytkowników są zredukowane, ponowna analiza i gromadzenie dokumentacji są znacznie zredukowane w porównaniu z modelem kaskadowym;
łatwiej jest uzyskać informację zwrotną od klienta na temat wykonanej pracy - klienci mogą zgłaszać swoje uwagi dotyczące gotowych części i mogą zobaczyć, co już zostało zrobione. Ponieważ pierwsze części systemu są prototypem systemu jako całości.
klient ma możliwość szybkiego nabycia i opanowania oprogramowania – klienci mogą uzyskać realne korzyści z systemu szybciej niż byłoby to możliwe w modelu kaskadowym.

Wady modelu:

menedżerowie muszą stale mierzyć postęp procesu. w przypadku szybkiego rozwoju nie warto tworzyć dokumentów dla każdej minimalnej zmiany wersji;
struktura systemu ma tendencję do pogarszania się, gdy dodawane są nowe komponenty - ciągłe zmiany zakłócają strukturę systemu. Aby tego uniknąć, refaktoryzacja wymaga dodatkowego czasu i pieniędzy. Słaba struktura sprawia, że późniejsze modyfikacje oprogramowania są trudne i kosztowne. A przerwany cykl życia oprogramowania prowadzi do jeszcze większych strat.

Schemat nie pozwala na szybkie uwzględnienie pojawiających się zmian i doprecyzowania wymagań oprogramowania. Koordynacja wyników rozwoju z użytkownikami odbywa się tylko w zaplanowanych punktach po zakończeniu każdego etapu prac oraz Ogólne wymagania do oprogramowania ustalane są w postaci specyfikacji technicznych na cały czas jego tworzenia. W ten sposób użytkownicy często otrzymują oprogramowanie, które nie spełnia ich rzeczywistych potrzeb.

model spiralny

Model spiralny:Cykl życia – na każdym obrocie spirali tworzona jest kolejna wersja produktu, określane są wymagania projektu, określana jest jego jakość, planowana jest praca kolejnego tury. Szczególną uwagę przywiązuje się do początkowych etapów rozwoju - analizy i projektowania, gdzie wykonalność określonych rozwiązań technicznych jest testowana i uzasadniana poprzez tworzenie prototypów.

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

Na etapie analizy i projektowania sprawdzamy wykonalność rozwiązań technicznych oraz stopień zaspokojenia potrzeb klienta tworząc prototypy. Każdy obrót spirali odpowiada stworzeniu działającego fragmentu lub wersji systemu. Pozwala to doprecyzować wymagania, cele i cechy projektu, określić jakość rozwoju i zaplanować pracę kolejnego zakrętu spirali. W ten sposób szczegóły projektu zostają pogłębione i konsekwentnie skonkretyzowane, w wyniku czego wybierana jest rozsądna opcja, spełniająca rzeczywiste wymagania klienta i doprowadzana do realizacji.

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

Zalety modelu:

pozwala szybko pokazać użytkownikom systemu działający produkt, tym samym uruchamiając proces wyjaśniania i uzupełniania wymagań;
umożliwia zmiany wymagań podczas tworzenia oprogramowania, co jest typowe dla większości opracowań, w tym standardowych;
model przewiduje możliwość elastycznego projektowania, ponieważ zawiera zalety modelu kaskadowego, a jednocześnie dozwolone są iteracje we wszystkich fazach tego samego modelu;
pozwala uzyskać bardziej niezawodny i stabilny system. Wraz z rozwojem oprogramowania, błędy i słabości są znajdowane i naprawiane w każdej iteracji;
model ten pozwala użytkownikom aktywnie uczestniczyć w planowaniu, analizie ryzyka, rozwoju, a także w wykonywaniu czynności ewaluacyjnych;
zmniejszyć ryzyko klienta. Klient może, przy minimum dla siebie Straty finansowe zakończyć rozwój mało obiecującego projektu;
informacje zwrotne od użytkowników do programistów są przeprowadzane z dużą częstotliwością i na wczesnym etapie modelu, co zapewnia wysoką jakość pożądanego produktu.

Wady modelu:

jeśli projekt jest mało ryzykowny lub mały, model może być kosztowny. Ocena ryzyka po każdej spirali jest kosztowna;
Cykl życia modelu ma skomplikowaną strukturę, więc jego zastosowanie przez programistów, menedżerów i klientów może być trudne;
spirala może trwać w nieskończoność, ponieważ odpowiedź każdego klienta na utworzoną wersję może generować nowy cykl, co opóźnia zakończenie projektu;
duża liczba cykli pośrednich może prowadzić do konieczności przetworzenia dodatkowej dokumentacji;
korzystanie z modelu może być kosztowne, a nawet nieopłacalne, ponieważ czas. wydatki na planowanie, ponowne ukierunkowanie, przeprowadzanie analizy ryzyka i prototypowanie mogą być nadmierne;
może być trudno zdefiniować cele i kamienie milowe wskazujące na gotowość do kontynuacji procesu rozwoju w kolejnym i

Głównym problemem cyklu spiralnego jest określenie momentu przejścia do kolejnego etapu. Aby go rozwiązać, dla każdego z etapów wprowadzane są limity czasowe.koło życia a przejście przebiega zgodnie z planem, nawet jeśli nie wszystkie zaplanowane prace zostaną zakończone.Planowanieopracowane na podstawie danych statystycznych uzyskanych w poprzednich projektach oraz osobiste doświadczenie programiści.

Zakres modelu spiralnego

Użycie modelu spiralnego jest wskazane w następujących przypadkach:

przy opracowywaniu projektów z wykorzystaniem nowych technologii;
przy opracowywaniu nowej serii produktów lub systemów;
przy opracowywaniu projektów z oczekiwanymi istotnymi zmianami lub uzupełnieniami wymagań;
do realizacji projektów długoterminowych;
przy opracowywaniu projektów, które wymagają wykazania jakości i wersji systemu lub produktu w krótkim czasie;
przy opracowywaniu projektów. dla których konieczne jest obliczenie kosztów związanych z oceną i rozwiązaniem ryzyka.

Cykl życia oprogramowania. Etapy i etapy

Cykl życia SI to ciąg zdarzeń zachodzących w systemie w trakcie jego tworzenia i użytkowania.

Scena- część procesu tworzenia oprogramowania, ograniczona pewnymi ramami czasowymi i kończąca się wydaniem konkretnego produktu (modele, komponenty oprogramowania, dokumentacja), określona wymaganiami określonymi dla tego etapu.

Cykl życia jest tradycyjnie modelowany jako szereg następujących po sobie etapów (lub etapów, faz). Obecnie nie ma ogólnie przyjętego podziału cyklu życia system oprogramowania na etapy. Czasem scena jest wyodrębniana jako osobna rzecz, czasem włączana jako integralna część większej sceny. Czynności wykonywane na tym czy innym etapie mogą się różnić. W nazwach tych etapów nie ma jednolitości.

Tradycyjnie wyróżnia się następujące główne etapy cyklu życia oprogramowania:

Analiza wymagań,

Projekt,

Kodowanie (programowanie),

Testowanie i debugowanie,

Obsługa i konserwacja.

Cykl życia oprogramowania. Model kaskadowy

model kaskadowy (70-80s) ≈ zakłada przejście do kolejnego etapu po zakończeniu prac nad poprzednim etapem,

Głównym osiągnięciem modelu wodospadu jest kompletność etapów. Umożliwia to planowanie kosztów i czasu. Dodatkowo powstaje dokumentacja projektowa, która ma kompletność i spójność.

Model kaskadowy ma zastosowanie do małych projektów oprogramowania o dobrze zdefiniowanych i niezmiennych wymaganiach. Prawdziwy proces może ujawnić awarie na każdym etapie, co prowadzi do cofnięcia się do jednego z poprzednich etapów. Model takiej produkcji oprogramowania jest kaskadowo-zwrotny

Cykl życia oprogramowania. Model etapowy z kontrolą pośrednią

model etapowy ze sterowaniem pośrednim (80-85) ≈ iteracyjny model wytwarzania oprogramowania z pętlami sprzężenia zwrotnego między etapami. Zaletą tego modelu jest to, że korekty między etapami są mniej pracochłonne niż model kaskadowy; jednak czas życia każdego z etapów jest rozciągnięty na cały okres rozwoju,

Główne etapy rozwiązywania problemów

Celem programowania jest opisanie procesów przetwarzania danych (zwanych dalej po prostu procesami).

Dane (dane) to prezentacja faktów i pomysłów w sformalizowanej formie nadającej się do przekazania i przetwarzania w jakimś procesie, a informacja (informacja) to znaczenie, jakie nadaje się danym podczas ich prezentacji.

Przetwarzanie danych to wykonywanie systematycznej sekwencji działań na danych. Dane prezentowane są i przechowywane na nośnikach danych.

Zbiór nośników danych wykorzystywanych w dowolnym przetwarzaniu danych nazywany jest nośnikiem informacji (nośnikiem danych).

Zbiór danych zawartych w dowolnym momencie w środowisku informacyjnym jest stanem środowiska informacyjnego.

Proces można zdefiniować jako ciąg następujących po sobie stanów pewnego środowiska informacyjnego.

Opis procesu oznacza określenie kolejności stanów środowiska informacyjnego. Aby wymagany proces został automatycznie wygenerowany na jakimś komputerze zgodnie z podanym opisem, opis ten musi być sformalizowany.

Kryteria jakości oprogramowania

Produkt handlowy (produkt, usługa) musi spełniać wymagania konsumenta.

Jakość to obiektywna cecha produktu (produktu, usługi), pokazująca stopień zadowolenia konsumenta

Cechy jakościowe:

występ- system działa i realizuje wymagane funkcje.

Niezawodność– system działa bezawaryjnie i bezawaryjnie.

Odzyskiwalność.

Efektywność- system najlepiej realizuje swoje funkcje.

Wydajność ekonomiczna- minimalny koszt produktu końcowego przy maksymalnym zysku.

Cechy jakościowe:

Rachunkowość czynnika ludzkiego- łatwość obsługi, szybkość nauki pracy z oprogramowaniem, łatwość utrzymania, wprowadzania zmian.

Ruchliwość(mobilność) - przenoszenie kodu na inną platformę lub system.

Funkcjonalna kompletność– być może najpełniejsza realizacja funkcji zewnętrznych.

Dokładność obliczeń

Właściwości algorytmu.

Efektywność oznacza możliwość uzyskania wyniku po wykonaniu skończonej liczby operacji.

Pewność polega na zbieżności uzyskanych wyników, niezależnie od użytkownika i zastosowanych środków technicznych.

charakter masowy polega na możliwości zastosowania algorytmu do całej klasy zadań tego samego typu, różniących się określonymi wartościami danych początkowych.

dyskrecja - możliwość podzielenia procesu obliczeń nakazanych przez algorytm na odrębne etapy, możliwość wyróżnienia fragmentów programu o określonej strukturze.

Sposoby opisywania algorytmów

Istnieją następujące sposoby opisywania (reprezentowania) algorytmów:

1. opis słowny;

2. opis algorytmu za pomocą wzorów matematycznych;

3. graficzny opis algorytmu w postaci schematu blokowego;

4. opis algorytmu z wykorzystaniem pseudokodu;

5. łączona metoda przedstawiania algorytmu za pomocą metod werbalnych, graficznych i innych; .

6. używanie sieci Petriego.

Opis słowny algorytm to opis struktury algorytmu w języku naturalnym. Na przykład dla urządzeń sprzęt AGD z reguły dołączona jest instrukcja obsługi, tj. słowny opis algorytmu, zgodnie z którym należy używać tego urządzenia.

Opis graficznyalgorytm w postaci schematu blokowego jest opisem struktury algorytmu z wykorzystaniem kształtów geometrycznych z liniami komunikacyjnymi.

Schemat blokowy algorytmu jest graficzną reprezentacją metody rozwiązywania problemu, która wykorzystuje znaki specjalne do wyświetlania operacji.

Symbole tworzące schemat blokowy algorytmu są zdefiniowane przez GOST 19.701-90. Ten GOST odpowiada Międzynarodowy standard projektowanie algorytmów, dlatego schematy blokowe algorytmów, zaprojektowane zgodnie z GOST 19.701-90, są rozumiane jednoznacznie w różnych krajach.

Pseudo kod– opis budowy algorytmu w języku naturalnym, ale częściowo sformalizowanym. Pseudokod wykorzystuje pewne konstrukcje formalne i powszechną symbolikę matematyczną. Nie ma ścisłych reguł składniowych dotyczących pisania pseudokodu.

Rozważać najprostszy przykład. Niech konieczne będzie opisanie algorytmu wyświetlania największej wartości dwóch liczb na ekranie monitora.

Rysunek 1 - Przykład opisu algorytmu w postaci schematu blokowego

Opis tego samego algorytmu w pseudokodzie:

2. Wprowadzanie liczb: Z, X

3. Jeśli Z > X to Wniosek Z

4. W przeciwnym razie wyjście X

Każda z powyższych metod obrazowania algorytmów ma zarówno zalety, jak i wady. Na przykład metoda werbalna jest gadatliwa i niejasna, ale pozwala lepiej opisać poszczególne operacje. Metoda graficzna jest bardziej wizualna, ale często konieczne staje się opisanie niektórych operacji w formie słownej. Dlatego przy opracowywaniu złożonych algorytmów lepiej jest zastosować metodę kombinowaną.

Rodzaje algorytmów

liniowy;

rozgałęzienie;

cykliczny.

· Algorytm liniowy- zestaw poleceń (instrukcji) wykonywanych sekwencyjnie jedna po drugiej.

· Algorytm rozgałęziania- algorytm zawierający co najmniej jeden warunek, w wyniku sprawdzenia, który komputer zapewnia przejście do jednego z dwóch możliwych kroków.

· Algorytm cykliczny- algorytm, który przewiduje wielokrotne powtarzanie tej samej akcji (te same operacje) na nowych danych początkowych. Większość metod obliczeniowych i wyliczania opcji sprowadza się do algorytmów cyklicznych. Cykl programu - sekwencja poleceń (seria, treść pętli), które mogą być wykonywane wielokrotnie (dla nowych danych początkowych) aż do spełnienia określonego warunku.

C. Typy danych.

Typ danych to opis zakresu wartości, jakie może przyjąć zmienna określonego typu. Każdy typ danych charakteryzuje się:
1. liczba zajętych bajtów (rozmiar)
2. zakres wartości, jakie może przyjąć zmienna tego typu.

Wszystkie typy danych można podzielić na następujące typy:
1. typy proste (skalarne) i złożone (wektorowe);
2. podstawowy (system) i użytkownika (zdefiniowany przez użytkownika).
W języku C podstawowy system typów składa się z czterech typów danych:
1. symboliczne,
2. liczba całkowita,
3. prawdziwa pojedyncza precyzja,
4. prawdziwa podwójna precyzja.

Struktura programu w C.

1. Operatory języka C++

Operatorzy kontrolują wykonanie programu. Zestaw operatorów języka C++ zawiera wszystkie konstrukcje sterujące programowania strukturalnego.
Instrukcja złożona jest oddzielona nawiasami klamrowymi. Wszystkie inne stwierdzenia kończą się średnikiem.
Pusty operator - ;
Pusta instrukcja to instrukcja składająca się tylko ze średnika. Może pojawić się w dowolnym miejscu programu, w którym składnia wymaga instrukcji. Wykonanie pustej instrukcji nie zmienia stanu programu.
Operator złożony - (...)
Działanie instrukcji złożonej polega na sekwencyjnym wykonywaniu zawartych w niej instrukcji, z wyjątkiem przypadków, w których dowolna instrukcja jawnie przenosi sterowanie do innego miejsca w programie.
Operator obsługi wyjątków

próbować(<операторы> }
łapać(<объявление исключения>) { <операторы> }
łapać(<объявление исключения>) { <операторы> }
...
łapać(<объявление исключения>) { <операторы> }

Operator warunkowy

jeśli (<выражение>) <оператор 1>

przełącznik operatora

przełącznik(<выражение>)
( walizka<константное выражение 1>: <операторы 1>
walizka<константное выражение 2>: <операторы 2>
...
walizka<константное выражение N>: <операторы N>
}
Instrukcja switch służy do wyboru jednego z kilku alternatywnych sposobów wykonania programu. Obliczanie instrukcji switch rozpoczyna się od oceny wyrażenia, po czym kontrola jest przekazywana do operatora oznaczonego stałym wyrażeniem równym ocenianej wartości wyrażenia. Instrukcja switch jest zamykana przez instrukcję break. Jeżeli wartość wyrażenia nie jest równa żadnemu wyrażeniu stałemu, to kontrola jest przekazywana operatorowi oznaczonemu słowem kluczowym default, jeśli istnieje.
Instrukcja pętli z warunkiem wstępnym

chwila (<выражение>) <оператор>

Instrukcja pętli z warunkiem końcowym

robić<оператор>chwila<выражение>;
W C++ ten operator różni się od klasycznej implementacji pętli z warunkiem końcowym tym, że gdy wyrażenie jest prawdziwe, pętla jest kontynuowana, a nie wychodzi z pętli.
Operator pętli krokowej

dla([<начальное выражение>];
[<условное выражение>];
[<выражение приращения>])
<оператор>
Treść instrukcji for jest wykonywana, dopóki wyrażenie warunkowe nie stanie się fałszywe (równe 0). Wyrażenie początkowe i wyrażenie przyrostu są powszechnie używane do inicjowania i modyfikowania parametrów pętli i innych wartości. Wyrażenie początkowe jest oceniane raz przed pierwszym testem wyrażenia warunkowego, a wyrażenie inkrementacji jest oceniane po każdym wykonaniu instrukcji. Każde z trzech wyrażeń nagłówka pętli, a nawet wszystkie trzy, można pominąć (pamiętaj tylko o pozostawieniu średników). Jeśli wyrażenie warunkowe zostanie pominięte, to jest uważane za prawdziwe, a pętla staje się nieskończona.
Operator pętli krok po kroku w języku C++ jest konstrukcją elastyczną i wygodną, więc operator pętli z warunkiem while jest używany bardzo rzadko w języku C++, ponieważ w większości przypadków wygodniej jest użyć instrukcji for.
Przerwij operator

złamać;
Instrukcja break przerywa wykonywanie instrukcji while, do, for i switch. Może być zawarte tylko w treści tych stwierdzeń. Sterowanie jest przekazywane do instrukcji programu następującej po przerwanej. Jeśli instrukcja break jest napisana wewnątrz instrukcji zagnieżdżonych while, do, for, switch, to kończy ona tylko instrukcję, która natychmiast ją obejmuje.
operator kontynuacji

kontyntynuj;
Operator kontynuacji przenosi kontrolę do następnej iteracji w instrukcjach pętli while, do. Może być zawarte tylko w treści tych stwierdzeń. W instrukcjach do i while następna iteracja rozpoczyna się od oceny wyrażenia warunkowego. W instrukcji for następna iteracja rozpoczyna się od oceny wyrażenia inkrementacji, a następnie obliczane jest wyrażenie warunkowe.
oświadczenie zwrotne

zwrócić [<выражение>];
Instrukcja return kończy wykonywanie funkcji, która ją zawiera i zwraca kontrolę do funkcji wywołującej. Kontrola jest przekazywana do punktu funkcji wywołującej

if (wyrażenie logiczne)

operator;

if (wyrażenie logiczne)

operator_1;

operator_2;

<логическое выражение> ? <выражение_1> : <выражение_2>;

Jeśli wartość wyrażenia logicznego jest prawdziwa, obliczane jest wyrażenie_1, w przeciwnym razie oceniane jest wyrażenie_2.

przełącznik (wyrażenie typu całkowitego)

wartość sprawy_1:

sekwencja_operatorów_1;

wartość sprawy_2:

sekwencja_operatorów_2;

przypadek wartość_n:

sekwencja_operatorów_n;

domyślna:

sekwencja_operatorów_n+1;

Oddział domyślna mogą nie być opisane. Jest wykonywany, jeśli żadne z powyższych wyrażeń nie jest spełnione.

operator pętli.

Turbo C dostarcza następujące konstrukcje dla pętli programowania: chwilę, zrób chwilę oraz dla . Ich strukturę można opisać następująco:

Pętla z kontrolą stanu u góry:

Wybierz oświadczenie

Jeżeli akcje do wykonania w programie zależą od wartości jakiejś zmiennej, można użyć instrukcji select. Jednocześnie w C++ tylko zmienne numeryczne mogą być używane jako zmienne w instrukcji SELECT. Ogólnie zapis instrukcji select wygląda tak:

przełącznik (zmienna)
{
wartość przypadku1:
działania1
złamać;

wartość przypadku2:
działania2
złamać;
...

domyślna:
domyślne działania
}

Słowo kluczowe break należy dodać na końcu każdej gałęzi. Zatrzymuje wykonywanie operacji wyboru. Jeśli tego nie napiszesz, po wykonaniu akcji z jednej gałęzi selekcji, wykonywanie akcji z kolejnych gałęzi będzie kontynuowane. Czasami jednak taka właściwość selekcji przydaje się, na przykład, gdy trzeba wykonać te same czynności dla różnych wartości zmiennej.

przełącznik (zmienna)
{
wartość przypadku1:
wartość przypadku2:
działania1
złamać;

wartość przypadku3:
działania2
złamać;
...
}

Przykładowe użycie Select:

int n, x;
...
przełącznik(n)
{
przypadek 0:
złamać; //jeśli n wynosi 0, to nic nie rób

przypadek 1:
przypadek 2:
przypadek 3:
x = 3 * n; //jeśli n jest równe 1, 2 lub 3, wykonaj kilka czynności
złamać;

przypadek 4:
x=n; //jeśli n jest równe 4, wykonaj inne czynności
złamać;

domyślna:
x = 0; //dla wszystkich pozostałych wartości n wykonaj domyślne działania
}

C. Cykl: pętla z parametrem

Notacja ogólna

for (inicjalizacja parametrów; kontrola stanu końcowego; korekta parametrów) (

blok operacji;

for - pętla parametryczna (pętla ze stałą liczbą powtórzeń). Aby zorganizować taki cykl, konieczne jest wykonanie trzech operacji:

§ inicjalizacja parametrów- przypisanie wartości początkowej do parametru cyklu;

§ sprawdzanie stanu końca- porównanie wartości parametru z pewną wartością graniczną;

§ korekta parametrów- zmiana wartości parametru przy każdym przejściu ciała pętli.

Te trzy operacje są zapisane w nawiasach i oddzielone średnikiem (;). Z reguły parametr pętli jest zmienną całkowitą.
Inicjalizacja parametrów jest wykonywana tylko raz - kiedy pętla for zaczyna działać. Warunek zakończenia jest sprawdzany przed każdym możliwym wykonaniem ciała pętli. Gdy wyrażenie staje się fałszywe (równe zero), pętla się kończy. Korekta parametrów jest przeprowadzana na końcu każdego wykonania ciała pętli. Parametr może się zwiększać lub zmniejszać.

Przykład

#włączać
int main() (

for(liczba = 1; liczba< 5; num++)

printf("liczba = %d\n",liczba);

Si. Pętla z warunkiem wstępnym

Notacja ogólna

podczas (wyrażenie) (

blok operacji;
}

Jeśli wyrażenie jest prawdziwe (różne od zera), to wykonywany jest blok operacji ujęty w nawiasy klamrowe, a następnie wyrażenie jest sprawdzane ponownie. Sekwencja czynności, polegająca na sprawdzeniu i wykonaniu bloku operacji, jest powtarzana, aż wyrażenie stanie się fałszywe (równe zero). W takim przypadku pętla zostaje zakończona, a operacja po wykonaniu instrukcji loop.

Przykład

ink=5;
int i=1;
insum=0;
podczas gdy ja<=k) {

Podczas konstruowania pętli while konieczne jest uwzględnienie konstrukcji, które zmieniają wartość sprawdzanego wyrażenia tak, aby ostatecznie stało się ono fałszywe (równe zero). W przeciwnym razie pętla będzie wykonywana w nieskończoność (pętla nieskończona), na przykład

blok operacji;
}

while jest pętlą z warunkiem wstępnym, więc jest całkiem możliwe, że ciało pętli nie zostanie wykonane ani razu, jeśli podczas pierwszego sprawdzenia testowany warunek jest fałszywy.

Si. Pętla z warunkiem końcowym

Pętla z do...gdy warunek końcowy

Notacja ogólna

blok operacji;

) while(wyrażenie);

Pętla z warunkiem końcowym

Pętla do...while to pętla z warunkiem końcowym, w której prawdziwość wyrażenia jest sprawdzana po wykonaniu wszystkich operacji zawartych w bloku ograniczonym nawiasami klamrowymi. Treść pętli jest wykonywana do momentu, gdy wyrażenie stanie się fałszywe, czyli oznacza to, że treść pętli z warunkiem końcowym jest wykonywana, nawet jeśli zrobiłaby to raz.

Lepiej jest używać pętli do...while w przypadkach, gdy musi zostać wykonana co najmniej jedna iteracja lub gdy inicjalizacja obiektów biorących udział w teście warunku następuje wewnątrz ciała pętli.

Przykład. Wpisz liczbę od 0 do 10

#włączać
#włączać
int main() (

system("chcp 1251");

printf("Wprowadź liczbę od 0 do 10: ");

scanf("%d", &num);

) while((liczba< 0) || (num > 10));

printf("Wpisałeś liczbę %d", num);

getchar(); getchar();

Definicja funkcji

Rozważ definicję funkcji na przykładzie funkcji sumy.

W C i C++ funkcje nie muszą być definiowane do momentu ich użycia, ale muszą być zadeklarowane wcześniej. Ale nawet po tym wszystkim w końcu ta funkcja musi zostać zdefiniowana. Następnie prototyp funkcji i jej definicja są połączone i można z niej korzystać.

Jeśli funkcja została wcześniej zadeklarowana, musi być zdefiniowana z tą samą wartością zwracaną i typami danych, w przeciwnym razie zostanie utworzona nowa, przeciążona funkcja. Zauważ, że nazwy parametrów funkcji nie muszą być takie same.

Rozwój CT stale poszerza klasy zadań do rozwiązania, związanych z przetwarzaniem informacji o różnym charakterze.

Są to w zasadzie trzy rodzaje informacji i odpowiednio trzy klasy zadań, do których wykorzystywane są komputery:

1) Zadania obliczeniowe związane z przetwarzaniem informacji liczbowych. Należą do nich np. problem rozwiązywania układu równań liniowych o dużym wymiarze. Kiedyś był to główny, dominujący obszar użytkowania komputerów.

2) Zadania przetwarzania informacji symbolicznych związane z tworzeniem, edycją i transformacją danych tekstowych. Z rozwiązywaniem takich problemów wiąże się praca np. sekretarki-maszynistki.

3) Zadania przetwarzania informacji graficznych tj. diagramy, rysunki, wykresy, szkice itp. Do takich zadań należy na przykład zadanie opracowania rysunków nowych produktów przez projektanta.

4) Zadania przetwarzania informacji alfanumerycznych - IS. Obecnie stał się jednym z głównych obszarów zastosowań komputerów, a zadania stają się coraz bardziej skomplikowane.

Komputerowe rozwiązywanie problemów każdej klasy ma swoją specyfikę, ale można je podzielić na kilka etapów, które są typowe dla większości problemów.

Technologia programowaniabada procesy technologiczne i kolejność ich przebiegu (etapów) z wykorzystaniem wiedzy, metod i środków.

Technologie są wygodnie scharakteryzowane w dwóch wymiarach - pionowym (reprezentującym procesy) i poziomym (reprezentującym etapy).

Zdjęcie

Proces to zestaw powiązanych ze sobą działań (operacji technologicznych), które przekształcają niektóre dane wejściowe w dane wyjściowe. Procesy składają się z zestawu czynności (operacji technologicznych), a każda czynność składa się z zestawu zadań i metod ich rozwiązywania. Wymiar pionowy odzwierciedla statyczne aspekty procesów i operuje takimi pojęciami, jak procesy pracy, czynności, zadania, wyniki wydajności, wykonawcy.

Etap to część działań związanych z tworzeniem oprogramowania, ograniczona pewnymi ramami czasowymi i kończąca się wydaniem konkretnego produktu, zdeterminowana wymaganiami stawianymi dla tego etapu. Czasami etapy są łączone w większe ramy czasowe zwane fazami lub kamieniami milowymi. Tak więc wymiar poziomy reprezentuje czas, odzwierciedla dynamiczne aspekty procesów i operuje pojęciami takimi jak fazy, etapy, etapy, iteracje i punkty kontrolne.

Rozwój oprogramowania przebiega zgodnie z określonym cyklem życia.

Koło życia Oprogramowanie to ciągły i uporządkowany zestaw czynności wykonywanych i zarządzanych w ramach każdego projektu rozwoju i eksploatacji oprogramowania, począwszy od momentu pojawienia się pomysłu (koncepcji) na stworzenie oprogramowania i podjęcia decyzji o jego konieczności jej stworzenia, a kończy się z chwilą jej całkowitego wycofania z eksploatacji z przyczyn:

a) starzenie się;

b) utrata konieczności rozwiązania odpowiednich zadań.

Podejścia technologiczne to mechanizmy realizacji cyklu życia.

Podejście technologiczne jest zdeterminowane specyfiką łączenia etapów i procesów, skoncentrowanych na różnych klasach oprogramowania oraz na charakterystyce zespołu programistycznego.

Cykl życia definiuje etapy (fazy, etapy), aby produkt oprogramowania przechodził z jednego etapu na drugi, od koncepcji produktu do etapu jego składania.

Cykl życia tworzenia oprogramowania można przedstawić z różnym stopniem szczegółowości etapów. Najprostsza reprezentacja cyklu życia obejmuje etapy:

Projekt

Realizacja

Testowanie i debugowanie

Wdrażanie, eksploatacja i konserwacja.

Najprostsza reprezentacja cyklu życia programu (kaskadowe podejście technologiczne do zarządzania cyklem życia):

Procesy

Projekt

Programowanie

Testowanie

Eskorta

Analiza Projekt Wdrożenie Testowanie Wdrożenie Operacja

oraz debugowanie i konserwacja

W rzeczywistości na każdym etapie działa tylko jeden proces. Oczywiście przy opracowywaniu i tworzeniu dużych programów taki schemat nie jest wystarczająco poprawny (nie dotyczy), ale można go traktować jako podstawę.

Etap analizy skupia się na wymaganiach systemowych. Wymagania są zdefiniowane i sprecyzowane (opisane). Trwa rozwój i integracja modeli funkcjonalnych oraz modeli danych dla systemu. Ponadto naprawione zostały niefunkcjonalne i inne wymagania systemowe.

Faza projektowania podzielona jest na dwie główne podfazy: projekt architektoniczny i projekt wykonawczy. W szczególności dopracowano projekt programu, interfejs użytkownika i struktury danych. Problemy projektowe, które wpływają na zrozumiałość, łatwość konserwacji i skalowalność systemu, są zgłaszane i naprawiane.

Faza implementacji obejmuje pisanie programu.

Różnice w sprzęcie i oprogramowaniu są szczególnie widoczne na scenie eksploatacja. Jeśli dobra konsumpcyjne przechodzą przez etapy wprowadzania na rynek, wzrostu, dojrzałości i upadku, życie oprogramowania przypomina bardziej historię niedokończonego, ale stale uzupełnianego i aktualizowanego budynku (samolot). (Abonent).

Cykl życia oprogramowania jest regulowany przez wiele standardów, w tym międzynarodowych.

Celem standaryzacji cyklu życia złożonego PS:

Podsumowanie doświadczeń i wyników badań wielu specjalistów;

Praca w trybie off procesy technologiczne i technik rozwojowych, a także metodologiczne podstawy ich automatyzacji.

Normy obejmują:

Zasady opisywania wstępnych informacji, metod i metod wykonywania operacji;

Ustal zasady kontroli procesu;

Ustal wymagania dotyczące prezentacji wyników;

Regulować treść dokumentów technologicznych i operacyjnych;

Określić strukturę organizacyjną zespołu programistycznego;

Zapewnij dystrybucję i harmonogram zadań;

Zapewnij kontrolę nad postępem tworzenia PS.

W Rosji obowiązują normy regulujące cykl życia:

Etapy rozwoju oprogramowania - GOST 19.102-77

Etapy tworzenia AS - GOST 34.601-90;

TK do stworzenia AS - GOST 34.602-89;

Rodzaje testów AS - GOST 34,603-92;

Tworzenie, utrzymywanie i rozwój oprogramowania aplikacyjnego dla IP w tych standardach nie są jednak dostatecznie odzwierciedlone, a niektóre ich zapisy są nieaktualne z punktu widzenia budowania nowoczesnych rozproszonych systemów wysokiej jakości programów aplikacyjnych w systemach sterowania i przetwarzania danych z różne architektury.

W związku z tym należy zwrócić uwagę na międzynarodową normę ISO / IEC 12207-1999 - „ Technologia informacyjna– Procesy cyklu życia oprogramowania”.

ISO - Międzynarodowa Organizacja Normalizacyjna - organizacja międzynarodowa normalizacji, IEC – Międzynarodowa Komisja Elektrotechniczna – Międzynarodowa Komisja Elektrotechniczna.

Określa strukturę cyklu życia oprogramowania i jego procesów.

Tych. tworzenie oprogramowania nie jest łatwym zadaniem, dlatego istnieją standardy, w których wszystko jest napisane: co należy zrobić, kiedy i jak.

Struktura cyklu życia oprogramowania według międzynarodowej normy ISO/IEC 12207-95 oparta jest na trzech grupach procesów:

1) główne procesy cyklu życia oprogramowania (nabycie, dostawa, rozwój, eksploatacja, utrzymanie). Skupimy się na tym drugim.

2) procesy pomocnicze zapewniające realizację procesów głównych ( dokumentacja, zarządzanie konfiguracją, zapewnienie jakości, weryfikacja, walidacja, wspólny przegląd (ocena), audyt, rozwiązywanie problemów).

1. Zarządzanie konfiguracjąTen proces wspierający główne procesy cyklu życia oprogramowania, przede wszystkim procesy rozwoju i utrzymania. Przy opracowywaniu złożonych projektów oprogramowania składających się z wielu komponentów, z których każdy może mieć odmiany lub wersje, pojawia się problem uwzględnienia ich relacji i funkcji, stworzenia jednolitej (czyli pojedynczej) struktury i zapewnienia rozwoju całego systemu. Zarządzanie konfiguracją pozwala organizować, systematycznie uwzględniać i kontrolować zmiany w różnych komponentach oprogramowania na wszystkich etapach jego cyklu życia.

2. Weryfikacja to proces określania, czy obecny stan oprogramowania został osiągnięty ten etap, wymagania tego etapu.

3. Certyfikacja– potwierdzenie poprzez badanie i przedstawienie obiektywnych dowodów, że specyficzne wymagania dla konkretnych obiektów są w pełni wdrożone.

4. Wspólna analiza (ocena) – systematyczne określanie stopnia zgodności obiektu z ustalonymi kryteriami.

5. Audyt– audyt przeprowadzony przez właściwy organ (osobę) w celu zapewnienia niezależnej oceny stopnia zgodności produktów lub procesów oprogramowania z ustalonymi wymaganiami. Badanie pozwala ocenić zgodność parametrów rozwoju z wymaganiami wstępnymi. Weryfikacja pokrywa się z testowaniem, które jest przeprowadzane w celu określenia różnic między rzeczywistymi i oczekiwanymi wynikami oraz oceny, czy charakterystyka oprogramowania spełnia pierwotne wymagania. W procesie realizacji projektu ważne miejsce zajmują kwestie identyfikacji, opisu i kontroli konfiguracji poszczególnych komponentów oraz całego systemu jako całości.

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

Zarządzanie projektami związane z zagadnieniami planowania i organizacji pracy, tworzenia zespołów programistów oraz monitorowania terminów i jakości wykonywanych prac. Wsparcie techniczne i organizacyjne projektu obejmuje dobór metod i narzędzi do realizacji projektu, określenie metod opisu stanów pośrednich rozwoju, opracowanie metod i narzędzi do testowania stworzonego oprogramowania, szkolenie personelu itp. . Zapewnienie jakości projektu związane jest z problematyką weryfikacji, weryfikacji i testowania komponentów oprogramowania.

Rozważymy cykl życia oprogramowania z punktu widzenia dewelopera.

Proces rozwoju zgodny ze standardem obejmuje czynności i zadania wykonywane przez programistę oraz obejmuje tworzenie oprogramowania i jego komponentów zgodnie z określonymi wymaganiami, w tym przygotowanie dokumentacji projektowej i operacyjnej, a także przygotowanie materiały niezbędne do sprawdzenia funkcjonalności i zgodności jakości oprogramowania, materiały potrzebne do szkolenia personelu itp.

Zgodnie ze standardem cykl życia oprogramowania IP obejmuje następujące kroki:

1) pojawienie się i badanie idei (koncepcji);

2) etap przygotowawczy - dobór modelu cyklu życia, standardów, metod i narzędzi rozwoju oraz sporządzenie planu pracy.

3) analiza wymagań systemu informatycznego - zdefiniowanie tego

funkcjonalność, wymagania użytkownika, wymagania dotyczące niezawodności i bezpieczeństwa, wymagania dotyczące interfejsów zewnętrznych itp.

4) projektowanie architektury systemu informacyjnego - określenie składu niezbędny sprzęt, oprogramowanie i operacje wykonywane przez personel serwisowy.

5) analiza wymagań oprogramowania- definicja funkcjonalności, w tym charakterystyka wydajności, środowisko operacyjne komponentów, interfejsy zewnętrzne, specyfikacje niezawodności i bezpieczeństwa, wymagania ergonomiczne, wymagania dotyczące wykorzystania danych, instalacji, akceptacji, dokumentacji użytkownika, obsługi i konserwacji.

6) projektowanie architektury oprogramowania - zdefiniowanie struktury oprogramowania, udokumentowanie interfejsów jego komponentów, opracowanie wstępnej wersji dokumentacji użytkownika oraz wymagań testowych i planu integracji.

7) szczegółowy projekt oprogramowania - szczegółowy

opis komponentów oprogramowania i interfejsów między nimi, aktualizacja dokumentacji użytkownika, opracowanie i udokumentowanie wymagań testowych oraz planu testów, komponentów oprogramowania, aktualizacja planu integracji komponentów.

8) kodowanie oprogramowania -– opracowanie i dokumentacja

każdy składnik oprogramowania;

9)Testowanie oprogramowania – opracowanie zestawu procedur testowych i danych do ich testowania, testowanie komponentów, aktualizacja dokumentacji użytkownika, aktualizacja planu integracji oprogramowania;

10) integracja oprogramowania–montaż komponentów oprogramowania zgodnie z

plan integracji i testowania oprogramowania pod kątem zgodności z wymaganiami kwalifikacyjnymi, czyli zbiór kryteriów lub warunków, które muszą być spełnione, aby produkt programowy został zakwalifikowany jako spełniający jego specyfikacje i gotowy do użycia w określonych warunkach pracy;

11) testowanie kwalifikacji oprogramowania – testowanie oprogramowania w

obecność klienta w celu wykazania jego zgodności

wymagania i gotowość do działania; jednocześnie sprawdzana jest również gotowość i kompletność dokumentacji technicznej i użytkowej;

12) integracja systemu – montaż wszystkich elementów System informacyjny, w tym oprogramowanie i sprzęt;

13) Testy kwalifikacyjne IP – testowanie systemu dla

spełnienie wymagań w tym zakresie oraz weryfikacja projektu i kompletności dokumentacji;

14) instalacja oprogramowania – instalacja oprogramowania na sprzęcie klienta i sprawdzenie jego działania;;

15) akceptacja oprogramowania – ocena wyników kwalifikowanego

testowanie oprogramowania i systemów informatycznych ogólnie i

dokumentacja wyników oceny wraz z klientem, certyfikacja i ostateczne przekazanie oprogramowania klientowi.

16) Zarządzanie i opracowywanie dokumentacji;

17) operacja

18) eskorta - proces tworzenia i wdrażania nowych wersji

Produkt oprogramowania.;

19) zakończenie operacji.

Działania te można pogrupować, warunkowo podkreślając następujące główne etapy tworzenia oprogramowania:

oświadczenie o zadaniu (TOR) (zgodnie z GOST 19.102-77 etap „Zakres zadań”)

Pojęcie „cyklu życia” oznacza coś, co się rodzi, rozwija i umiera. Podobnie jak żywy organizm, oprogramowanie jest tworzone, obsługiwane i ewoluuje w czasie.

Koło życia oprogramowanie obejmuje wszystkie etapy jego rozwoju: od powstania potrzeby do całkowitego zaprzestania jego użytkowania z powodu przestarzałości lub utraty potrzeby rozwiązywania istotnych problemów.

Istnieje kilka faz istnienia oprogramowania w trakcie jego cyklu życia. Jak dotąd nie ma ogólnie przyjętych nazw tych faz i ich liczby. Ale w tej kwestii nie ma szczególnej różnicy zdań. Dlatego istnieje kilka opcji podziału cyklu życia oprogramowania na etapy. Pytanie, czy dana partycja jest lepsza od innych, nie jest głównym. Najważniejsze jest, aby odpowiednio zorganizować tworzenie oprogramowania z uwzględnieniem ich.

W zależności od czasu trwania cyklu życia oprogramowanie można podzielić na dwie klasy: mały oraz świetny czas życia. Te klasy programów odpowiadają elastycznemu (miękkiemu) podejściu do ich tworzenia i użytkowania oraz sztywnemu przemysłowemu podejściu do regulowanego projektowania i obsługi oprogramowania. Na przykład w organizacjach naukowych i na uniwersytetach dominuje rozwój najwyższej klasy programów, podczas gdy w projektowaniu i organizacje przemysłowe- druga.

Produkty programowe o krótkiej żywotności tworzone są głównie w celu rozwiązywania problemów naukowych i inżynierskich, uzyskiwania określonych wyników obliczeń. Takie programy są zwykle stosunkowo niewielkie. Są opracowywane przez jednego specjalistę lub małą grupę. Główną ideę programu omawia jeden programista i użytkownik końcowy. Część szczegółów zostaje przelana na papier, a projekt jest realizowany w ciągu kilku dni lub tygodni. Nie są przeznaczone do replikacji i przenoszenia do późniejszego wykorzystania w innych zespołach. Jako takie, takie programy są częścią projektu badawczego i nie powinny być uważane za jednorazowy produkt programowy.

Na ich cykl życia składa się długi okres analizy systemowej i formalizacji problemu, istotny etap projektowania programu 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 programowych. Ich wskaźniki jakości są kontrolowane wyłącznie przez programistów zgodnie z ich nieformalnymi pomysłami.

Produkty programowe o krótkiej żywotności

Konserwacja i modyfikacja takich programów nie jest obowiązkowa, 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 w rezultacie trwają od miesiąca do 1…2 lat

że cykl życia oprogramowania rzadko przekracza 3 lata.

Produkty programowe o długiej żywotności stworzony do regularnego przetwarzania i zarządzania informacjami. Struktura takich programów jest złożona. Ich rozmiary mogą się różnić w szerokim zakresie (1...1000 tys. poleceń), ale wszystkie mają właściwości rozpoznawalności i możliwości modyfikacji w procesie długotrwałej konserwacji i użytkowania przez różnych specjalistów. Oprogramowanie tej klasy można powielać, towarzyszy im dokumentacja jako produkty przemysłowe i jest to oprogramowanie wyobcowane od dewelopera.

Produkty programowe o długiej żywotności

Ich projektowanie i eksploatacja realizowane są przez duże zespoły specjalistów, co wymaga sformalizowania systemu oprogramowania, a także sformalizowanego testowania i określenia osiąganych wskaźników jakości produktu finalnego. Ich cykl życia wynosi 10...20 lat. Aż 70...90% tego czasu przypada na obsługę i konserwację. Ze względu na masową replikację i długoterminowe utrzymanie, łączne koszty eksploatacji i utrzymania takiego oprogramowania znacznie przewyższają koszty analizy i projektowania systemu.

Wszystkie kolejne prezentacje skupiają się na rozwoju dużych (złożonych) narzędzi programowych do zarządzania i przetwarzania informacji.

Model uogólniony koło życia Oprogramowanie może wyglądać tak:

I. Analiza systemu:

badanie;

b) studium 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;

Projektowanie wewnętrzne modułów oprogramowania;

Kodowanie;

Programy do debugowania;

Układ programu;

c) debugowanie oprogramowania.

III. Ocena (testowanie) oprogramowania.

IV. Korzystanie z oprogramowania:

a) operacja;

b) wsparcie.

I. Analiza systemu. Na początku tworzenia oprogramowania przeprowadzana jest analiza systemu (jego projekt wstępny), podczas której określa się jego zapotrzebowanie, cel i główne cechy funkcjonalne. Szacuje się koszty i możliwą wydajność aplikacji przyszłego oprogramowania.

Na tym etapie opracowywana jest lista wymagań, czyli jasne określenie tego, czego użytkownik oczekuje od gotowego produktu. Tutaj wyznaczane są cele i zadania, dla których rozwijany jest sam projekt. W fazie analizy systemowej można wyróżnić dwa kierunki: badawczy i analizę wykonalności.

Rozpoczęcie badań od momentu, w którym kierownik rozwoju zdaje sobie sprawę z potrzeby oprogramowania.

Praca polega na zaplanowaniu i koordynowaniu działań niezbędnych do przygotowania formalnej, odręcznej listy wymagań dla tworzonego oprogramowania.

Kończy się badanie 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 istnieje techniczna część badań i zaczyna się, gdy intencja kierownictwa jest na tyle silna, że wyznacza się kierownika projektu, który organizuje projektowanie i dystrybucję zasobów (pracy).

Praca polega na badaniu proponowanego produktu programowego w celu uzyskania praktycznej oceny możliwości realizacji projektu, w szczególności określa się:

- wykonalność operacyjna , Czy produkt będzie wystarczająco wygodny do praktycznego użytkowania?

- wykonalność ekonomiczna , Czy koszt opracowanego produktu jest akceptowalny? Jaki jest ten koszt? Czy produkt będzie opłacalnym narzędziem w rękach użytkownika?

- wykonalność komercyjna, Czy produkt będzie atrakcyjny, dostępny na rynku, łatwy w instalacji, serwisowalny, łatwy do nauczenia?

Na te i inne pytania należy odpowiedzieć głównie przy rozważaniu powyższych wymagań.

Studium wykonalności kończy się po zebraniu i zatwierdzeniu wszystkich wymagań.

Przed kontynuowaniem dalsza praca w projekcie musisz upewnić się, że uzyskano wszystkie niezbędne informacje. Informacje te muszą być dokładne, zrozumiałe i możliwe do wyegzekwowania. Powinien to być kompletny zestaw wymagań satysfakcjonujących użytkownika dla tworzonego oprogramowania, sporządzony w formie specyfikacji.

Jeśli ten wymóg nie zostanie spełniony, możliwe jest znaczne spowolnienie realizacji projektu w przyszłości z powodu powtarzających się próśb do użytkownika o wyjaśnienie błędnie zinterpretowanych szczegółów, nieokreślonych warunków i w efekcie konieczne będzie przerobić już opracowane 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 produkt programowy, a 90% uzyskuje swoją ostateczną formę.

Ta faza życia obejmuje różne działania projektu i można ją podzielić na trzy główne etapy: projektowanie, programowanie i debugowanie oprogramowania.

Budowa Tworzenie oprogramowania zwykle rozpoczyna się już w fazie studium wykonalności, gdy tylko wstępne cele i wymagania dla niego zostaną ustalone na papierze.

Do czasu zatwierdzenia wymagań prace w fazie projektowania będą w pełnym toku.

W tym segmencie życia oprogramowania wykonywane są następujące czynności:

Funkcjonalna dekompozycja rozwiązywanego problemu, na podstawie której określana jest architektura systemu tego problemu;

Projekt oprogramowania zewnętrznego, wyrażony w postaci jego zewnętrznej interakcji z użytkownikiem;

Projekt bazy danych, jeśli to konieczne;

Projektowanie architektury oprogramowania - definicja obiektów, modułów i ich powiązania.

Rozpoczyna się programowanie już na etapie budowy, gdy tylko główne specyfikacje dla poszczególnych komponentów produktu oprogramowania staną się dostępne, ale nie przed zatwierdzeniem umowy dotyczącej wymagań. Nakładanie się faz programowania i budowy skutkuje oszczędnościami w ogólnym czasie opracowywania, a także zapewnia walidację decyzji projektowych, aw niektórych przypadkach wpływa na kluczowe kwestie.

Na tym etapie wykonywane są prace związane z montażem oprogramowania. Polega na szczegółowym, wewnętrznym zaprojektowaniu produktu programowego, opracowaniu wewnętrznej logiki każdego modułu systemu, która następnie wyrażana jest w tekście konkretnego programu.

Faza programowania kończy się, gdy programiści zakończą dokumentowanie, debugowanie i łączenie poszczególnych części oprogramowania w całość.

Debugowanie oprogramowania jest przeprowadzany po tym, jak wszystkie jego komponenty zostaną osobno debugowane i zmontowane w jednym produkcie programowym.

III. Ocena (testowanie) oprogramowania. W tej fazie oprogramowanie jest poddawane rygorystycznym testom systemowym przez grupę nie-programistów.

Ma to na celu zapewnienie, że gotowy produkt oprogramowania spełnia wszystkie wymagania i specyfikacje, może być używany w środowisku użytkownika, jest wolny od wszelkich wad i zawiera niezbędną dokumentację, która dokładnie i kompletnie opisuje produkt oprogramowania.

Faza oceny rozpoczyna się po złożeniu i przetestowaniu wszystkich komponentów (modułów), tj. po całkowitym debugowaniu gotowego oprogramowania. Kończy się po otrzymaniu potwierdzenia, że oprogramowanie przeszło wszystkie testy i jest gotowe do pracy.

Trwa tak długo, jak programowanie.

IV. Korzystanie z oprogramowania. Jeśli analiza systemu jest wezwaniem do działania, projektowanie jest atakiem i zwrotem ze zwycięstwem, to używanie oprogramowania jest codzienną obroną, niezbędną, ale zwykle niehonorową dla programistów.

Takie porównanie jest słuszne z uwagi na to, że podczas użytkowania produktu programowego korygowane są błędy, które zakradły się podczas jego projektowania.

Faza użytkowania oprogramowania rozpoczyna się w momencie przeniesienia produktu do systemu dystrybucji.

Jest to czas, w którym produkt działa i jest efektywnie wykorzystywany.

W tym czasie przeprowadzane są szkolenia personelu, wdrożenia, konfiguracja, utrzymanie i ewentualnie rozbudowa oprogramowania – tzw. projektowanie bieżące.

Faza użytkowania kończy się wraz z wycofaniem produktu z użytkowania i zaprzestaniem czynności, o których mowa powyżej. Należy jednak pamiętać, że oprogramowanie może być używane przez kogoś innego przez długi czas po zakończeniu zdefiniowanej tutaj fazy użytkowania. Ponieważ ten ktoś może owocnie korzystać z oprogramowania, nawet bez pomocy programisty.

Korzystanie z oprogramowania jest uwarunkowane jego obsługą i konserwacją.

Działanie oprogramowania polega na jego wykonaniu, funkcjonowaniu na komputerze w celu przetwarzania informacji i uzyskaniu wyników, które są celem jej powstania, a także zapewnieniu rzetelności i rzetelności wydawanych danych.

Konserwacja oprogramowania polega na utrzymywaniu, rozwijaniu funkcjonalności i doskonaleniu charakterystyki operacyjnej produktu programowego, replikacji i przenoszeniu produktu programowego na różnego rodzaju obiekty obliczeniowe.

Konserwacja pełni rolę niezbędnego sprzężenia zwrotnego z fazy eksploatacji.

W trakcie działania oprogramowania możliwe jest wykrycie błędów w programach, konieczne staje się ich modyfikowanie i rozszerzanie ich funkcji.

Te ulepszenia z reguły są przeprowadzane jednocześnie z działaniem aktualnej wersji oprogramowania. Po sprawdzeniu przygotowanych korekt na jednej z instancji oprogramowania, następna wersja oprogramowania zastępuje poprzednio używane lub niektóre z nich. Jednocześnie proces obsługi oprogramowania może być praktycznie ciągły, ponieważ wymiana wersji oprogramowania jest krótkoterminowa. Okoliczności te prowadzą do tego, że proces obsługi wersji oprogramowania zwykle przebiega równolegle i niezależnie od fazy utrzymania.

Nakładanie się faz cyklu życia oprogramowania

Możliwe i zwykle pożądane jest nakładanie się różnych faz cyklu życia oprogramowania. Jednak procesy nieciągłe nie powinny się pokrywać.

Możliwe jest sprzężenie zwrotne między fazami. Na przykład podczas jednego z zewnętrznych etapów projektowania mogą zostać wykryte błędy w formułowaniu celów, wtedy trzeba je natychmiast zwrócić i poprawić.

Rozważany model cyklu życia oprogramowania, z pewnymi zmianami, może również służyć jako model dla małych projektów.

Na przykład, gdy projektowany jest pojedynczy program, często odbywa się to bez projektowania architektury systemu i

projekt bazy danych; procesy wstępnego i szczegółowego projektowania zewnętrznego często łączą się ze sobą itp.

Cykl życia oprogramowania – okres, który rozpoczyna się od momentu podjęcia decyzji o potrzebie stworzenia oprogramowania i kończy się w momencie jego całkowitego wycofania z eksploatacji.

Procesy cyklu życia oprogramowania:

Podstawowy,

Pomocniczy,

Organizacyjny.

Główny:

1. Akwizycja – czynności i zadania klienta nabywającego oprogramowanie;

2. Dostawa – czynności i zadania dostawcy, który dostarcza klientowi produkt programowy lub usługę;

3. Development - czynności i zadania wykonywane przez dewelopera: tworzenie oprogramowania, wykonanie dokumentacji projektowej i operacyjnej, przygotowanie testów i materiały dydaktyczne;

4. Eksploatacja – czynności i zadania operatora organizacji obsługującej system;

5. Utrzymanie - wprowadzanie zmian w oprogramowaniu w celu poprawienia błędów, poprawy wydajności lub dostosowania do zmieniających się warunków pracy lub wymagań.

Pomocniczy:

1. Dokumentacja – sformalizowany opis informacji powstałych w trakcie cyklu życia oprogramowania;

2. Zarządzanie konfiguracją – stosowanie procedur administracyjnych i technicznych w całym cyklu życia oprogramowania w celu określenia stanu komponentów oprogramowania, zarządzania jego modyfikacjami;

3. Zapewnienie jakości – zapewnienie, że oprogramowanie i jego procesy cyklu życia są zgodne z określonymi wymaganiami i zatwierdzonymi planami;

4. Weryfikacja – ustalenie, że produkty oprogramowania w pełni spełniają wymagania lub warunki wynikające z wcześniejszych działań;

5. Certyfikacja – określenie kompletności zgodności określonych wymagań i tworzonego systemu z ich określonym przeznaczeniem funkcjonalnym;

6. Wspólna ocena – ocena stanu prac nad projektem: kontrola planowania i zarządzania zasobami, personelem, sprzętem, narzędziami;

7. Audyt – ustalenie zgodności z wymaganiami, planami i warunkami umowy;

8. Rozwiązywanie problemów - analiza i rozwiązywanie problemów, niezależnie od ich pochodzenia lub źródła, które zostaną wykryte podczas rozwoju, eksploatacji, utrzymania lub innych procesów.

Organizacyjny:

1. Zarządzanie - czynności i zadania, które może wykonać każdy podmiot zarządzający jego procesami;

2. Tworzenie infrastruktury – wybór i utrzymanie technologii, standardów i narzędzi, wybór i instalacja sprzętu i oprogramowania wykorzystywanego do tworzenia, obsługi lub utrzymania oprogramowania;

3. Doskonalenie – ocena, pomiar, kontrola i doskonalenie procesów cyklu życia;

4. Szkolenie – szkolenie wstępne, a następnie ustawiczny rozwój zawodowy personelu.

W 2002 roku opublikowano normę dotyczącą procesów cyklu życia systemu (ISO/IEC 15288 Procesy cyklu życia systemu). W opracowanie normy zaangażowani byli eksperci z różnych dziedzin: inżynieria systemów, programowanie, zarządzanie jakością, przez zasoby ludzkie, bezpieczeństwa itp. Uwzględniono praktyczne doświadczenia w tworzeniu systemów w organizacjach rządowych, komercyjnych, wojskowych i akademickich. Norma ma zastosowanie do szerokiej klasy systemów, ale jej głównym celem jest wspomaganie tworzenia systemów skomputeryzowanych.

Zgodnie z serią ISO/IEC 15288 w strukturze cyklu życia należy uwzględnić następujące grupy procesów:

1. Procesy umowne:

Akwizycja (rozwiązania wewnętrzne lub rozwiązania dostawców zewnętrznych);

Dostawa (rozwiązania wewnętrzne lub rozwiązania dostawców zewnętrznych);

2. Procesy przedsiębiorstwa:

Kontrola środowisko przedsiębiorstwa;

Zarządzanie inwestycjami;

Zarządzanie cyklem życia IP;

Zarządzanie zasobami;

Kontrola jakości;

3. Procesy projektowe:

Planowanie;

Ocena projektu;

Kontrola projektu;

Zarządzanie ryzykiem;

Zarządzanie konfiguracją;

Zarządzanie przepływem informacji;

Podejmować decyzje.

4. Procesy techniczne:

Definicja wymagań;

Analiza wymagań;

Rozwój architektury;

realizacja;

Integracja;

Weryfikacja;

Przemiana;

Orzecznictwo;

Eksploatacja;

Eskorta;

Sprzedaż.

5. Procesy specjalne:

Definiowanie i ustalanie zależności wynikających z zadań i celów.

Ustanowienie podstawowych procesów cyklu życia oprogramowania IP (ISO/IEC 15288)

Proces (wykonawca procesu)	działania	Wejście	Wynik
Akwizycja (klient)	- Inicjacja - Przygotowanie ofert przetargowych - Przygotowanie kontraktu - Kontrola działalności dostawcy - Odbiór IP	- Decyzja o rozpoczęciu prac nad wdrożeniem IP - Wyniki badania działań klientów - Wyniki analizy rynku/przetargu IP - Plan dostawy/rozwoju - Kompleksowy test IP	- Studium wykonalności wdrożenia SI - SIWZ - Umowa na dostawę/zabudowę - Akty odbioru etapów robót - Akt prób odbiorowych
Dostawa (programista IS)	- Inicjacja - Odpowiedź na oferty - Przygotowanie umowy - Planowanie realizacji - Dostawa IP	- SIWZ - Decyzja kierownictwa o udziale w opracowaniu - Wyniki przetargu - SIWZ - Plan zarządzania projektem - Opracowana SI i dokumentacja	- Decyzja o udziale w rozwoju - Oferty handlowe / oferta - Umowa na dostawę / rozwój - Plan zarządzania projektem - Wdrożenie / dostosowanie - Raport z badań odbiorowych
Rozwój (programista IS)	- Przygotowanie - Analiza wymagań SI - Projektowanie architektury SI - Tworzenie wymagań dotyczących oprogramowania - Projektowanie architektury oprogramowania - Projekt szczegółowy oprogramowania - Kodowanie i testowanie oprogramowania - Integracja oprogramowania i testowanie kwalifikacyjne oprogramowania - Integracja oprogramowania i testowanie kwalifikowane SI	- Zakres odniesienia dla SI - Zakres odniesienia dla SI, model cyklu życia - Podsystemy SI - Specyfikacje wymagań dla komponentów oprogramowania - Architektura oprogramowania - Szczegółowe materiały do projektowania oprogramowania - Plan integracji oprogramowania, testy - Architektura SI, oprogramowanie, dokumentacja dla SI, testy	- Zastosowany model cyklu życia, standardy rozwoju - Plan pracy - Kompozycja podsystemów, komponentów sprzętowych - Specyfikacje wymagań dla komponentów oprogramowania - Kompozycja komponentów oprogramowania, interfejsy z bazą danych, plan integracji oprogramowania - Projekt bazy danych, specyfikacje dla interfejsów między komponentami oprogramowania, wymagania dla testów - Teksty modułów Oprogramowanie, akty autonomicznego testowania - Ocena zgodności kompleksu oprogramowania z wymaganiami TOR - Ocena zgodności oprogramowania, bazy danych, kompleks techniczny oraz komplet dokumentacji do wymagań TOR

Etapy rozwoju systemu (ISO/IEC 15288)

CPC: Stwórz warunki dla projektu „Kolejka” na stronie www.mastertz.ru

Modele cyklu życia oprogramowania:

1. kaskada,

2. spirala,

3. iteracyjne.

Model kaskadowy cykl życia („waterfall model”, angielski model wodospadu) został zaproponowany w 1970 roku przez Winstona Royce'a. Zapewnia 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.

Wymagania określone na etapie tworzenia wymagań są ściśle udokumentowane w formie specyfikacji istotnych warunków zamówienia i ustalone przez cały okres rozwoju projektu.

Każdy etap kończy się wydaniem kompletnego zestawu dokumentacji wystarczającego do dalszego rozwoju przez inny zespół programistów.

Opracowanie wymagań

Tworzenie

model spiralny(angielski model spiralny) został opracowany w połowie lat 80. przez Barry'ego Boehma. Opiera się na klasycznym cyklu PDCA Edwarda Deminga (planuj-wykonaj-sprawdź-działaj). W przypadku korzystania z tego modelu oprogramowanie tworzone jest w kilku iteracjach (zwojach helisy) metodą prototypowania.

Prototyp to aktywny komponent oprogramowania, który implementuje poszczególne funkcje i interfejsy zewnętrzne.

Każda iteracja odpowiada stworzeniu fragmentu lub wersji oprogramowania, doprecyzowuje cele i cechy projektu, ocenia jakość uzyskanych wyników i planuje pracę kolejnej iteracji.

Ryż. 21. Spiralny model cyklu życia oprogramowania

W każdej iteracji oceniane są:

1. Ryzyko przekroczenia warunków i kosztów projektu;

2. Konieczność wykonania kolejnej iteracji;

3. Stopień kompletności i dokładności zrozumienia wymagań dla systemu;

4. Celowość zakończenia projektu.

Jednym z przykładów implementacji modelu spiralnego jest RAD.

Podstawowe zasady RAD:

1. Zestaw narzędzi powinien mieć na celu skrócenie czasu opracowywania;

2. Stworzenie prototypu w celu wyjaśnienia wymagań klienta;

3. Cykl rozwoju: każda nowa wersja produktu opiera się na ocenie wyniku pracy poprzedniej wersji przez klienta;

4. Minimalizacja czasu tworzenia wersji poprzez przeniesienie gotowych modułów i dodanie funkcjonalności do nowej wersji;

5. Zespół programistów musi ściśle współpracować, każdy członek musi być chętny do wykonywania wielu obowiązków;

6. Zarządzanie projektem powinno minimalizować czas trwania cyklu rozwojowego.

Model iteracyjny: naturalny rozwój modeli kaskadowych i spiralnych doprowadził do ich zbieżności i powstania nowoczesnego podejścia iteracyjnego, które jest racjonalnym połączeniem tych modeli.

Ryż. 22. Iteracyjny model cyklu życia oprogramowania