Reference: Sommerville, Software Engineering, 10 ed., Chapter 2

Proces oprogramowania to uporządkowany zestaw czynności wymaganych do opracowania systemu oprogramowania. Zauważ, że mówimy o „procesie oprogramowania” — nie o „procesie tworzenia oprogramowania”.”

Istnieje wiele różnych rodzajów procesów oprogramowania, ale każdy z nich obejmuje te cztery rodzaje podstawowych działań:

• Specyfikacja oprogramowania – określenie, co system powinien robić;
• Projektowanie i wdrażanie oprogramowania – określenie organizacji systemu i wdrożenie systemu;
• Weryfikacja oprogramowania – sprawdzenie, czy robi to, czego chce klient;
• Ewolucja oprogramowania – zmiana systemu w odpowiedzi na zmieniające się potrzeby klienta.

Model procesu oprogramowania jest abstrakcyjną reprezentacją procesu. Przedstawia on opis procesu z pewnej określonej perspektywy. Kiedy opisujemy i omawiamy procesy oprogramowania, zwykle mówimy o czynnościach w tych procesach, takich jak określanie modelu danych, projektowanie interfejsu użytkownika itp. oraz o kolejności tych czynności.Opisy procesów mogą również zawierać:

• Produkty, które są wynikami działania procesu;
• Role, które odzwierciedlają obowiązki osób zaangażowanych w proces;
• Warunki wstępne i końcowe, które są stwierdzeniami, które są prawdziwe przed i po wykonaniu działania procesu lub wytworzeniu produktu.

Procesy kierowane planem to procesy, w których wszystkie działania procesowe są planowane z wyprzedzeniem, a postępy są mierzone względem tego planu. W procesach zwinnych planowanie jest przyrostowe i łatwiej jest zmienić proces, aby odzwierciedlić zmieniające się wymagania klienta. W praktyce większość praktycznych procesów zawiera elementy zarówno podejścia opartego na planie, jak i zwinnego.

Model wodospadowy Model sterowany planem. Oddzielne i odrębne fazy specyfikacji, projektowania oprogramowania, implementacji, testowania i utrzymania. Rozwój inkrementalny Specyfikacja, rozwój i walidacja są przeplatane. System jest rozwijany jako seria wersji (przyrostów), z każdą wersją dodającą funkcjonalność do poprzedniej wersji. Może być oparte na planie lub zwinne. Integracja i konfiguracja Bazuje na istnieniu znaczącej liczby komponentów/systemów wielokrotnego użytku. Proces rozwoju systemu koncentruje się na integracji tych komponentów w system, zamiast rozwijać je od podstaw. Może być sterowany planem lub zwinny.

W praktyce większość dużych systemów jest rozwijana przy użyciu procesu, który zawiera elementy wszystkich tych modeli.

W modelu wodospadowym wyróżnia się oddzielne fazy:

Analiza i definicja wymagań Usługi, ograniczenia i cele systemu są ustalane w drodze konsultacji z użytkownikami systemu. Następnie są one szczegółowo definiowane i służą jako specyfikacja systemu. Projektowanie systemu i oprogramowania Proces projektowania systemów przypisuje wymagania do systemów sprzętowych lub programowych poprzez ustanowienie ogólnej architektury systemu. Projektowanie oprogramowania polega na zidentyfikowaniu i opisaniu podstawowych abstrakcji systemu oprogramowania oraz ich relacji. Implementacja i testowanie jednostkowe Podczas tego etapu projekt oprogramowania jest realizowany jako zestaw programów lub jednostek programowych. Testowanie jednostkowe polega na sprawdzeniu, czy każda jednostka spełnia swoją specyfikację. Integracja i testowanie systemu Poszczególne jednostki programu lub programy są integrowane i testowane jako kompletny system, aby zapewnić, że wymagania dotyczące oprogramowania zostały spełnione. Po testach system oprogramowania jest dostarczany do klienta. Eksploatacja i utrzymanie Zwykle (choć nie zawsze) jest to najdłuższa faza cyklu życia. System jest instalowany i oddawany do praktycznego użytku. Konserwacja polega na poprawianiu błędów, które nie zostały wykryte we wcześniejszych fazach cyklu życia, ulepszaniu realizacji jednostek systemu i zwiększaniu usług systemu w miarę odkrywania nowych wymagań.

Główną wadą modelu wodospadowego jest trudność w dostosowaniu się do zmian po rozpoczęciu procesu. W zasadzie faza musi być zakończona, zanim przejdzie się do następnej. Nieelastyczny podział projektu na odrębne etapy utrudnia reagowanie na zmieniające się wymagania klienta. Dlatego model ten jest odpowiedni tylko wtedy, gdy wymagania są dobrze rozumiane, a zmiany będą dość ograniczone w trakcie procesu projektowania. Niewiele systemów biznesowych ma stabilne wymagania. Bardzo niewiele zastosowań w świecie rzeczywistym Model wodospadowy jest stosowany głównie w dużych projektach inżynierii systemów, w których system jest rozwijany w kilku miejscach.W takich okolicznościach, oparta na planie natura modelu wodospadowego pomaga koordynować pracę.

Korzyści z rozwoju przyrostowego:

Niższy koszt zmian Koszt dostosowania się do zmieniających się wymagań klienta jest zredukowany. Ilość analiz i dokumentacji, które muszą być ponownie wykonane, jest znacznie mniejsza niż w przypadku modelu wodospadowego. Częsta informacja zwrotna Łatwiej jest uzyskać informację zwrotną od klienta na temat wykonanej pracy rozwojowej. Klienci mogą komentować demonstracje oprogramowania i sprawdzać, w jakim stopniu zostało ono wdrożone. Szybsze dostarczanie Możliwe jest szybsze dostarczanie i wdrażanie użytecznego oprogramowania do klienta. Klienci są w stanie używać i czerpać wartość z oprogramowania wcześniej, niż jest to możliwe w przypadku procesu wodospadowego.

Problemy z rozwojem przyrostowym (z perspektywy zarządzania):

Proces nie jest widoczny Menedżerowie potrzebują regularnych produktów, aby mierzyć postęp. Jeśli systemy są rozwijane szybko, nie jest opłacalne tworzenie dokumentów, które odzwierciedlają każdą wersję systemu. Struktura systemu ma tendencję do degradacji w miarę dodawania nowych przyrostów Jeśli nie poświęca się czasu i pieniędzy na refaktoryzację w celu ulepszenia oprogramowania, regularne zmiany mają tendencję do niszczenia jego struktury. Wprowadzanie kolejnych zmian w oprogramowaniu staje się coraz trudniejsze i bardziej kosztowne.

Podejście to jest oparte na systematycznym ponownym użyciu, gdzie systemy są integrowane z istniejących komponentów lub systemów COTS (Commercial-off-the-shelf).Etapy procesu obejmują:

• Analizę komponentów;
• Modyfikację wymagań;
• Projektowanie systemu z ponownym użyciem;
• Rozwój i integrację.

Reuse jest obecnie standardowym podejściem do budowy wielu typów systemów biznesowych.

Typy komponentów oprogramowania:

• Usługi sieci Web, które są tworzone zgodnie ze standardami usług i które są dostępne do zdalnego wywoływania.
• Zbiory obiektów, które są opracowywane jako pakiet do integracji z ramami komponentów, takimi jak .NET lub J2EE.
• Samodzielne systemy komercyjne z półki (COTS), które są skonfigurowane do użytku w określonym środowisku.

Prawdziwe procesy oprogramowania to wzajemnie powiązane sekwencje działań technicznych, zespołowych i kierowniczych, których ogólnym celem jest specyfikacja, projektowanie, wdrażanie i testowanie systemu oprogramowania.

Cztery podstawowe czynności procesu: specyfikacja, rozwój, walidacja i ewolucja są zorganizowane w różny sposób w różnych procesach rozwoju. W modelu wodospadowym są one zorganizowane w kolejności, podczas gdy w rozwoju przyrostowym są one przeplatane.

Specyfikacja oprogramowania Proces ustalania, jakie usługi są wymagane i jakie są ograniczenia na działanie i rozwój systemu. Proces inżynierii wymagań:

• Studium wykonalności: czy zbudowanie systemu jest technicznie i finansowo wykonalne?
• Elicytacja i analiza wymagań: czego wymagają lub oczekują od systemu interesariusze systemu?
• Specyfikacja wymagań: szczegółowe zdefiniowanie wymagań
• Walidacja wymagań: sprawdzenie poprawności wymagań

Projektowanie i implementacja oprogramowania Proces przekształcania specyfikacji systemu w system wykonywalny.

• Projektowanie oprogramowania: zaprojektowanie struktury oprogramowania realizującej specyfikację;
• Implementacja: przetłumaczenie tej struktury na program wykonywalny;

Czynności projektowania i implementacji są ściśle powiązane i mogą być przeplatane. Czynności projektowania obejmują:

• Projektowanie architektoniczne: zidentyfikuj ogólną strukturę systemu, główne komponenty (czasami nazywane podsystemami lub modułami), ich relacje i sposób ich rozmieszczenia.
• Projektowanie interfejsów: zdefiniuj interfejsy między komponentami systemu.
• Projektowanie komponentów: weź każdy komponent systemu i zaprojektuj, jak będzie działał.
• Projektowanie bazy danych: zaprojektuj struktury danych systemu i sposób ich reprezentacji w bazie danych.

Walidacja oprogramowania Weryfikacja i walidacja (V & V) ma na celu wykazanie, że system jest zgodny ze swoją specyfikacją i spełnia wymagania klienta systemu.

• Walidacja: czy budujemy właściwy produkt (czego chce klient)?
• Weryfikacja: czy budujemy właściwy produkt?

V & V obejmuje procesy sprawdzania i przeglądu oraz testowanie systemu. Testowanie systemu polega na wykonywaniu systemu za pomocą przypadków testowych, które są wyprowadzone ze specyfikacji rzeczywistych danych, które mają być przetwarzane przez system. Testowanie jest najczęściej stosowaną czynnością V & V i obejmuje następujące etapy:

• Testowanie rozwojowe lub testowanie komponentów: poszczególne komponenty są testowane niezależnie; komponenty mogą być funkcjami lub obiektami albo spójnymi zgrupowaniami tych bytów.
• Testowanie systemu: testowanie systemu jako całości, szczególnie ważne jest testowanie właściwości emergentnych.
• Testowanie akceptacyjne: testowanie z użyciem danych klienta w celu sprawdzenia, czy system spełnia jego potrzeby.

Ewolucja oprogramowania Oprogramowanie jest z natury elastyczne i może się zmieniać. W miarę jak wymagania zmieniają się w wyniku zmieniających się okoliczności biznesowych, oprogramowanie, które wspiera biznes, musi również ewoluować i zmieniać się.Chociaż istniało rozgraniczenie między rozwojem a ewolucją (konserwacją), jest ono coraz mniej istotne, ponieważ coraz mniej systemów jest całkowicie nowych.

Zmiana jest nieunikniona we wszystkich dużych projektach programistycznych.Zmiany biznesowe prowadzą do nowych i zmienionych wymagań systemowychNowe technologie otwierają nowe możliwości poprawy wdrożeń.Zmieniające się platformy wymagają zmian w aplikacjach.Zmiana prowadzi do przeróbek, więc koszty zmiany obejmują zarówno przeróbki (np.np. ponowną analizę wymagań), jak i koszty wdrożenia nowej funkcjonalności.

Dwie strategie zmniejszania kosztów przeróbek:

Unikanie zmian Proces wytwarzania oprogramowania obejmuje działania, które mogą przewidzieć możliwe zmiany, zanim będzie wymagana znacząca przeróbka. Na przykład, może zostać opracowany prototyp systemu, aby pokazać klientom pewne kluczowe cechy systemu. Tolerancja zmian Proces jest zaprojektowany tak, aby zmiany mogły być uwzględnione przy stosunkowo niskich kosztach.Zwykle obejmuje to jakąś formę rozwoju przyrostowego. Proponowane zmiany mogą być wdrażane w przyrostach, które nie zostały jeszcze opracowane. Jeśli jest to niemożliwe, wówczas tylko pojedynczy przyrost (mała część systemu) może być zmieniony w celu włączenia zmiany.

Prototyp to wstępna wersja systemu używana do demonstrowania koncepcji i wypróbowywania opcji projektowych. Prototyp może być używany w:

• procesie inżynierii wymagań, aby pomóc w elicytacji i walidacji wymagań;
• procesie projektowania, aby zbadać opcje i opracować projekt UI;
• procesie testowania, aby uruchomić testy back-to-back.

Korzyści z prototypowania:

• Poprawa użyteczności systemu.
• Bliższe dopasowanie do rzeczywistych potrzeb użytkowników.
• Poprawa jakości projektu.
• Poprawa łatwości utrzymania.
• Zmniejszenie nakładów na rozwój.

Prototypy mogą być oparte na językach lub narzędziach szybkiego prototypowania. Mogą one obejmować pomijanie funkcjonalności:

• Prototyp powinien skupiać się na obszarach produktu, które nie są dobrze rozumiane;
• Sprawdzanie błędów i odzyskiwanie może nie być uwzględnione w prototypie;
• Skupianie się raczej na wymaganiach funkcjonalnych niż niefunkcjonalnych, takich jak niezawodność i bezpieczeństwo.

Prototypy powinny być odrzucane po opracowaniu, ponieważ nie stanowią dobrej podstawy dla systemu produkcyjnego:

• Może być niemożliwe dostrojenie systemu w celu spełnienia wymagań niefunkcjonalnych;
• Prototypy są zwykle nieudokumentowane;
• Struktura prototypu jest zwykle degradowana przez szybkie zmiany;
• Prototyp prawdopodobnie nie spełni normalnych organizacyjnych standardów jakości.

Zamiast dostarczać system jako pojedynczą dostawę, rozwój i dostawa są podzielone na przyrosty, z których każdy dostarcza część wymaganej funkcjonalności.Wymagania użytkownika są uszeregowane pod względem ważności, a wymagania o najwyższym priorytecie są zawarte we wczesnych przyrostach.Po rozpoczęciu rozwoju przyrostu wymagania są zamrożone, chociaż wymagania dla późniejszych przyrostów mogą nadal ewoluować.

Wady dostarczania przyrostowego:

• Wartość dla klienta może być dostarczona z każdym przyrostem, więc funkcjonalność systemu jest dostępna wcześniej.
• Wczesne przyrosty działają jak prototyp, który pomaga określić wymagania dla późniejszych przyrostów.
• Niższe ryzyko niepowodzenia całego projektu.
• Usługi systemowe o najwyższym priorytecie zwykle otrzymują najwięcej testów.

Problemy związane z dostarczaniem przyrostowym:

• Większość systemów wymaga zestawu podstawowych obiektów, które są używane przez różne części systemu. Ponieważ wymagania nie są szczegółowo określane, dopóki nie zostanie zaimplementowany przyrost, może być trudno zidentyfikować wspólne obiekty, które są potrzebne we wszystkich przyrostach.
• Istotą procesów iteracyjnych jest to, że specyfikacja jest rozwijana w połączeniu z oprogramowaniem. Jednak jest to sprzeczne z modelem zamówień publicznych wielu organizacji, gdzie kompletna specyfikacja systemu jest częścią kontraktu na rozwój systemu.

Wiele firm programistycznych zwróciło się w stronę ulepszania procesów oprogramowania jako sposobu na podniesienie jakości swojego oprogramowania, obniżenie kosztów lub przyspieszenie procesów rozwoju. Ulepszanie procesów oznacza zrozumienie istniejących procesów i zmianę tych procesów w celu zwiększenia jakości produktu i/lub zmniejszenia kosztów i czasu rozwoju.

Podejście dojrzałości procesowej Koncentruje się na poprawie zarządzania procesami i projektami oraz wprowadzaniu dobrych praktyk inżynierii oprogramowania. Poziom dojrzałości procesowej odzwierciedla stopień, w jakim dobra praktyka techniczna i zarządcza została przyjęta w organizacyjnych procesach wytwarzania oprogramowania. Podejście zwinne Koncentruje się na rozwoju iteracyjnym i redukcji kosztów ogólnych w procesie wytwarzania oprogramowania. Podstawową cechą metod zwinnych jest szybkie dostarczanie funkcjonalności i reagowanie na zmieniające się wymagania klienta.

Działania związane z doskonaleniem procesów tworzą ciągły cykl z pętlą sprzężenia zwrotnego:

• Zmierz jeden lub więcej atrybutów procesu lub produktu oprogramowania. Te pomiary tworzą linię bazową, która pomaga zdecydować, czy ulepszenia procesu były skuteczne.
• Przeanalizuj bieżący proces i zidentyfikuj wszelkie wąskie gardła.
• Zmień proces, aby rozwiązać niektóre ze zidentyfikowanych słabości procesu. Są one wprowadzane, a cykl wznawiany w celu zebrania danych o skuteczności zmian.

Pomiar procesu

• Gdzie to możliwe, należy zbierać ilościowe dane o procesie.
• Pomiary procesu powinny być wykorzystywane do oceny usprawnień procesu.
• Pomiary mogą obejmować:
  • Czas potrzebny na wykonanie czynności procesowych, np.czas kalendarzowy lub wysiłek potrzebny do ukończenia czynności lub procesu.
  • Zasoby wymagane do procesów lub czynności, np. całkowity wysiłek w osobodniach.
  • Liczbę wystąpień danego zdarzenia, np. liczbę wykrytych defektów.

Model dojrzałości zdolności SEI

• Początkowe: Zasadniczo niekontrolowane
• Powtarzalne: Procedury zarządzania produktem zdefiniowane i stosowane
• Zdefiniowane: Procedury i strategie zarządzania procesem zdefiniowane i stosowane
• Zarządzane: Strategie zarządzania jakością zdefiniowane i stosowane
• Optymalizujące: Strategie doskonalenia procesów zdefiniowane i stosowane

.