Proces tworzenia
oprogramowania
y
ródło: Ian Sommerville; "Inżynieria oprogramowania"; WNT W-wa 2003
Cele
Celem tego rozdziału jest przedstawienie idei procesu tworzenia oprogramowania - spójnego
zbioru czynności w produkcji oprogramowania. Po przeczytaniu tego rozdziału będziesz:
żð znać pojÄ™cie procesu tworzenia oprogramowania i modelu procesu tworzenia
oprogramowania;
żð znać kilka różnych modeli procesów tworzenia oprogramowania oraz wiedzieć, kiedy
należy ich używać;
żð ogólnie rozumieć modele procesów inżynierii wymagaÅ„ stawianych oprogramowaniu,
tworzeniu oprogramowania, testowaniu i ewolucji;
żð wiedzieć, czym jest technologia CASE wspomagajÄ…ca proces tworzenia
oprogramowania.
Zawartość
żð Modele procesu tworzenia oprogramowania
żð Iteracja procesu
żð Specyfikowanie oprogramowania
żð Projektowanie i implementowanie oprogramowania
żð Zatwierdzanie oprogramowania
żð Ewolucja oprogramowania
żð Zautomatyzowane wspomaganie procesu
1
Jak napisałem w rozdziale 1, proces tworzenia oprogramowania jest zbiorem czynności i
związanych z nimi wyników, które prowadzą do powstania produktu programowego. Może to
być tworzenie oprogramowania od zera, ale coraz częściej nowe oprogramowanie powstaje
przez rozszerzanie i modyfikowanie istniejących systemów.
Procesy tworzenia oprogramowania są złożone i zależą od opinii ludzi, podobnie jak
wszystkie procesy intelektualne. Rozsądek i twórczość są niezbędne, dlatego rezultaty prób
automatyzacji procesów tworzenia oprogramowania są raczej niewielkie.
Narzędzia CASE (por. p. 3.7) mogą wspomóc niektóre czynności procesu, ale nie jest
możliwe (przynajmniej w ciągu kilku następnych lat) zwiększenie automatyzacji tam, gdzie
oprogramowanie wymaga twórczego projektowania w wykonaniu inżynierów biorących udział
w procesie tworzenia oprogramowania.
Jedną z przyczyn ograniczonych możliwości automatyzacji procesu jest niezmierna
różnorodność procesów tworzenia oprogramowania. Nie ma idealnego procesu, a różne firmy
wypracowały całkowicie odmienne podejścia do tworzenia oprogramowania. Procesy
ewoluowały, aby jak najlepiej wykorzystywać umiejętności pracowników firmy i
charakterystyczne cechy tworzonych systemów. Nawet w jednym przedsiębiorstwie mogą
zatem być używane różne procesy tworzenia oprogramowania.
Chociaż jest wiele różnych procesów tworzenia oprogramowania, pewne zasadnicze
czynności są wspólne dla wszystkich procesów. Oto one:
1. Specyfikowanie oprogramowania. Funkcjonalność oprogramowania i ograniczenia
jego działania muszą być zdefiniowane.
2. Projektowanie i implementowanie oprogramowania. Oprogramowanie, które spełnia
specyfikację, musi być stworzone.
3. Zatwierdzanie oprogramowania. Oprogramowanie musi być zweryfikowane, aby
zapewnić, że robi to, czego oczekiwał klient.
4. Ewolucja oprogramowania. Oprogramowanie musi ewoluować, aby spełniać
zmieniające się potrzeby użytkowników.
Chociaż nie ma  idealnego" procesu tworzenia oprogramowania, jest wiele możliwości
poprawy procesów stosowanych w wielu firmach. Te procesy mogą obejmować przestarzałe
techniki lub nie korzystać z najlepszych doświadczeń przemysłowej inżynierii
oprogramowania. W istocie wiele przedsiębiorstw ciągle polega na procesach tworzonych ad
hoc i nie używa metod inżynierii oprogramowania w swojej działalności.
Poprawa procesu tworzenia oprogramowania może być przeprowadzona na kilka
różnych sposobów. Może polegać na standaryzacji procesu, gdy redukuje się różnorodność
procesów stosowanych w firmie. Powoduje to poprawę komunikacji, skrócenie czasu szkoleń i
zwiększenie opłacalności automatycznego wspomagania procesu. Standaryzacja jest również
pierwszym ważnym krokiem do wprowadzania nowych metod i technik oraz sprawdzonych
2
praktyk inżynierii oprogramowania. Powrócę do tematu poprawiania procesu tworzenia
oprogramowania w rozdziale 25.
3.1. Modele procesów tworzenia oprogramowania
Model procesu tworzenia oprogramowania jest abstrakcyjnÄ… reprezentacjÄ… procesu
tworzenia oprogramowania. W każdym takim modelu przedstawiono proces z konkretnego
punktu widzenia, a zatem model zawiera jedynie częściową informację o tym procesie. W tym
punkcie omówię kilka bardzo ogólnych modeli (czasem zwanych paradygmatami procesów) i
skomentuję je z punktu widzenia architektury. Oznacza to, że zobaczymy zrąb procesu, ale nie
szczegóły konkretnych czynności.
Te ogólne modele nie są ostatecznym opisem procesów tworzenia oprogramowania. Są
raczej użytecznymi abstrakcjami, które mogą służyć do wyjaśnienia różnych podejść do
tworzenia oprogramowania. W wypadku wielu ogromnych systemów nie użyto tylko jednego
wybranego procesu. Do stworzenia różnych części systemu użyto różnych procesów. Oto
modele procesów:
1. Model kaskadowy. W tym modelu podstawowe czynności specyfikowania, tworzenia,
zatwierdzania i ewolucji są odrębnymi fazami procesu takimi jak specyfikowanie
wymagań, projektowanie oprogramowania, implementacja, testowanie itd.
2. Tworzenie ewolucyjne. W tym procesie czynności specyfikowania, projektowania i
zatwierdzania przeplatajÄ… siÄ™. Pierwsza wersja systemu powstaje bardzo szybko na
podstawie abstrakcyjnych specyfikacji. Póz
niej jest udoskonalana zgodnie z
informacjami otrzymanymi od klienta. Prowadzi to do stworzenia systemu, który
spełnia oczekiwania klienta.
3. Tworzenie formalne systemu. To podejście jest oparte na budowaniu formalnych
matematycznych specyfikacji systemu i przekształcaniu tych specyfikacji w program
za pomocą metod matematycznych. Weryfikacja komponentów systemu polega na
wnioskowaniu matematycznym o ich zgodności ze specyfikacją.
4. Tworzenie z użyciem wielokrotnym. W tym podejściu zakłada się istnienie dużej
liczby komponentów zdatnych do ponownego użycia. Proces budowy systemu polega
głównie na integrowaniu tych fragmentów, a nie na tworzeniu ich od początku.
Procesy oparte na modelu kaskadowym i tworzeniu ewolucyjnym sÄ… szeroko stosowane
w praktyce do tworzenia oprogramowania. Tworzenie formalne systemów z powodzeniem
wykorzystano w kilku przedsięwzięciach (Mills i inni, 1987; Linger, 1994), ale procesy oparte
na tym modelu nadal są używane jedynie w niewielu firmach. Nieformalne wielokrotne użycie
często zdarza się w wielu procesach w dużej liczbie przedsiębiorstw; większość z nich nie
nastawia jawnie swoich procesów na użycie wielokrotne. To podejście będzie jednak
prawdopodobnie najbardziej znaczące w XXI wieku, ponieważ składanie systemów z
3
komponentów użycia wielokrotnego jest podstawowym warunkiem szybkiego tworzenia
oprogramowania..
3.1.1. Model kaskadowy
Pierwszy opublikowany model procesu tworzenia oprogramowania opracowano na
podstawie innych procesów inżynierii (Royce, 1970). Zilustrowano to na rys. 3.1. Z powodu
kaskadowego następstwa faz ten model jest znany jako kaskadowy cykl życia
oprogramowania. Zasadnicze kroki tego modelu odpowiadają podstawowym czynnościom
tworzenia:
1. Definiowanie i analiza wymagań. Usługi, ograniczenia i cele systemu są ustalane w
czasie narad z użytkownikami systemu. Są póz
niej szczegółowo definiowane i służą
jako specyfikacja systemu.
2. Projektowanie systemu i oprogramowania. Proces projektowania systemu prowadzi
do podziału wymagań na systemy sprzętu i oprogramowania. Ustala ogólną
architekturÄ™ systemu. Projektowanie oprogramowania obejmuje identyfikowanie i
opisywanie zasadniczych abstrakcji systemu oprogramowania i związki między nimi.
3. Implementacja i testowanie jednostek. W tym kroku projekt oprogramowania jest
realizowany w postaci zbioru programów albo jednostek programów. Testowanie
jednostek polega na sprawdzeniu, czy każda jednostka spełnia swoją specyfikację.
4. Integracja i testowanie systemu. Jednostki programów albo programy są integrowane
i testowane jako kompletne systemy, aby upewnić się, czy spełniono wymagania. Po
zakończeniu testowania system jest dostarczany klientowi.
5. Działanie i pielęgnacja. Zwykle (chociaż niekoniecznie) jest to najdłuższa faza cyklu
życia. System jest zainstalowany i przekazany do praktycznego użytkowania.
Pielęgnacja obejmuje poprawianie błędów, których nie wykryto we wcześniejszych
fazach cyklu życia, poprawianie implementacji jednostek systemu i wzbogacanie
usług systemu w miarę odkrywania nowych wymagań.
4
W zasadzie wynikiem każdej fazy jest co najmniej jeden dokument, który podlega
akceptacji (podpisywaniu). Następnej fazy nie powinno się rozpoczynać, jeśli poprzednia się
nie zakończy. W praktyce te etapy zazębiają się i przekazują nawzajem informacje. W trakcie
projektowania identyfikuje siÄ™ problemy z wymaganiami. Ten proces tworzenia
oprogramowania nie jest prostym liniowym modelem, ale obejmuje ciąg iteracji czynności
tworzenia.
Koszty opracowania i akceptacji dokumentów są wysokie i dlatego iteracje są również
kosztowne oraz wymagajÄ… powtarzania wielu prac. Po wykonaniu kilku iteracji zwykle
zamraża się zatem niektóre wyniki prac, na przykład specyfikacje, i prowadzi się prace
póz
niejszych etapów procesu. Problemy zostawia się do póz
niejszego rozstrzygnięcia, pomija
albo oprogramowuje. Takie wczesne ustalenie wymagań może sprawić, że system nie będzie
robił tego, czego chce użytkownik. Może to również spowodować złą strukturę systemu,
ponieważ problemy projektowe są wtedy rozwiązywane za pomocą sztuczek
programistycznych.
W trakcie ostatniej fazy cyklu życia (działanie i pielęgnacja) oprogramowanie jest
przekazywane do użytku. Odkrywa się wówczas błędy i zaniedbania w pierwotnych
wymaganiach. Wyłaniają się błędy w projekcie i programach. Identyfikuje się nowe potrzebne
funkcje. System musi zatem ewoluować, aby pozostać użytecznym. Dokonywanie
odpowiednich zmian (pielęgnacja oprogramowania) może oznaczać powtarzanie niektórych
lub nawet wszystkich czynności procesu.
Wadą modelu kaskadowego jest zawarty w nim nieelastyczny podział na rozłączne etapy.
Zobowiązania muszą być podejmowane w bardzo wczesnej fazie procesu. Oznacza to
trudności z reagowaniem na zmieniające się wymagania klienta.
Model kaskadowy powinien być używany jedynie wówczas, gdy wymagania są jasne i
zrozumiałe. Ten model odzwierciedla jednak normalną praktykę inżynierską. Procesy
tworzenia oprogramowania oparte na tym modelu są ciągle często używane, a szczególnie
wtedy, kiedy są częściami większych przedsięwzięć inżynierii systemów.
3.1.2. Tworzenie ewolucyjne
Tworzenie ewolucyjne polega na opracowaniu wstępnej implementacji, pokazaniu jej
użytkownikowi z prośbą o komentarze i udoskonalaniu jej w wielu wersjach aż do powstania
odpowiedniego systemu (rys. 3.2). Nie ma tu oddzielnych czynności specyfikacji, tworzenia i
zatwierdzania, a są one raczej przeprowadzane równolegle z szybkim reagowaniem na
informacje zwrotne.
IstniejÄ… dwa typy tworzenia ewolucyjnego:
1. Tworzenie badawcze, w którym celem procesu jest praca z klientem, polegająca na
badaniu wymagań i dostarczeniu ostatecznego systemu. Tworzenie rozpoczyna się od
5
tych części systemu, które są dobrze rozpoznane. System ewoluuje przez dodawanie
nowych cech, które proponuje klient.
2. Prototypowanie z porzuceniem, w którym celem procesu tworzenia ewolu- cyjnego
jest zrozumienie wymagań klienta i wypracowanie lepszej definicji wymagań
stawianych systemowi. Budowanie prototypu ma głównie na celu eksperymentowanie
z tymi wymaganiami użytkownika, które są niejasne.
Podejście ewolucyjne do tworzenia oprogramowania jest zwykle bardziej efektywne niż
podejście kaskadowe. Umożliwia produkowanie systemów, które najdokładniej odpowiadają
potrzebom użytkowników. Zaletą procesu tworzenia oprogramowania opartego na podejściu
ewolucyjnym jest przyrostowe opracowywanie specyfikacji. Wypracowanie coraz lepszego
zrozumienia przez użytkowników ich problemu znajduje swoje odzwierciedlenie w systemie
oprogramowanym. Z punktu widzenia inżynierii i zarządzania istnieją w tym podejściu trzy
problemy:
1. Proces nie jest widoczny. Menedżerowie potrzebują regularnych wyników, aby
mierzyć postęp prac. Jeśli systemy są tworzone szybko, nie opłaca się generować
dokumentów opisujących każdą wersję systemu.
2. System ma złą strukturę. Nieustające modyfikacje przyczyniają się do psucia
struktury oprogramowania. Wprowadzanie nowych zmian w programach staje siÄ™
coraz trudniejsze i bardziej kosztowne.
3. Konieczne mogą być specjalne narzędzia i techniki. Ułatwiają szybkie tworzenie, ale
mogą być niekompatybilne z innymi narzędziami lub technikami. Prawdopodobnie
niewiele osób potrafi się nimi posługiwać.
Uważa się, że w wypadku systemów małych (mniej niż 100000 wierszy kodu) lub
średnich (do 500000 wierszy kodu) z krótkim czasem życia podejście ewolucyjne jest
najlepsze. W wypadku dużych systemów o długim czasie życia wady tworzenia ewolucyjnego
ujawniają się jednak z całą ostrością. Radzę zastosować wówczas proces mieszany, który ma
najlepsze cechy modelu kaskadowego i modelu ewolucyjnego.
6
Może to być na przykład opracowanie porzucanego prototypu za pomocą podejścia
ewolucyjnego, co pozwoli usunąć niejasności ze specyfikacji systemu. System może być
póz
niej ponownie zaimplementowany w bardziej zorganizowanym procesie. Części systemu,
które są dobrze rozpoznane, można wyspecyfikować i utworzyć za pomocą procesu opartego
na kaskadzie. Inne części, na przykład interfejs użytkownika, które trudno jest z góry
wyspecyfikować, powinny być tworzone za pomocą badawczego podejścia do programowania.
3.1.3. Tworzenie formalne systemów
Tworzenie formalne systemów jest podejściem, które ma wiele wspólnego z modelem
kaskadowym. Proces tworzenia jest tu jednak oparty na matematycznych przekształceniach
specyfikacji systemu w program wykonywalny. Taki proces pokazano na rys. 3.3. Aby
uprościć rozważania, nie omówiłem tu iteracji obecnej w tym modelu.
Rys. 3.3 Tworzenie formalne systemów
Zasadnicze cechy odróżniające to podejście od modelu kaskadowego to:
1. Specyfikacja wymagań stawianych oprogramowaniu jest zapisywana w postaci
szczegółowej formalnej specyfikacji wyrażonej za pomocą notacji matematycznej.
2. Procesy projektowania, implementacji i testowania jednostek sÄ… zastÄ…pione przez
proces tworzenia z przekształceniem, w którym specyfikacja formalna jest
udoskonalana przez ciąg przekształceń, które prowadzą do powstania programu. Ten
proces udoskonalania pokazano na rys. 3.4
W procesie przekształcania formalna matematyczna reprezentacja systemu jest
metodycznie przekształcana w bardziej szczegółowe, ale wciąż matematycznie poprawne
reprezentacje systemu. Każdy krok dodaje nowe detale i trwa to do chwili, w której
specyfikacja formalna stanie się równoważnym jej programem. Przekształcenia są
odpowiednio małe, co oznacza, że wysiłek poświęcony na ich sprawdzenie nie jest nadmierny.
Można zatem zagwarantować, że jeśli nie było błędów weryfikacji, to otrzymany program jest
naprawdę implementacją wyjściowej specyfikacji.
7
Przewagą podejścia z przekształcaniem w porównaniu z dowodzeniem, że program
spełnia specyfikację, jest to, że odległość między poszczególnymi przekształceniami jest
mniejsza niż odległość między specyfikacją i programem. Dowody poprawności programów są
bardzo długie i niepraktyczne w wypadku dużych systemów. Podejście z przekształcaniem
złożone z ciągu małych kroków jest łatwiejsze w użyciu. Wybór, które przekształcenie
zastosować, wymaga jednak dużych umiejętności. Podobnie jest z dowodem zgodności
przekształceń.
Najlepiej znanym przykładem takiego formalnego procesu tworzenia jest Cleanroom,
pierwotnie opracowany przez IBM (Mills i inni, 1987; Selby i inni, 1987; Linger 1994; Prowell
i inni, 1999). Proces Cleanroom jest oparty na przyrostowym tworzeniu oprogramowania, gdy
formalnie wykonuje się każdy krok i dowodzi jego poprawności. Nie ma testowania w
poszukiwaniu usterek w procesie, a testowanie systemu koncentruje siÄ™ na zapewnieniu
niezawodności systemu.
Zarówno Cleanroom, jak i inny proces tworzenia formalnego oparty na metodzie B
(Wordsworth, 1996) zastosowano z powodzeniem w praktyce. Liczba defektów w
dostarczonym systemie była niewielka. Koszty tworzenia nie różniły się istotnie od kosztów
innych podejść. Taki proces jest szczególnie przydatny do tworzenia systemów z surowymi
wymaganiami bezpieczeństwa, niezawodności i zabezpieczeń. Podejście formalne upraszcza
generowanie przypadków testujących bezpieczeństwo i zabezpieczenia, które służą do
wykazywania klientom i instytucjom certyfikującym, że system rzeczywiście spełnia
wymagania dotyczące bezpieczeństwa i zabezpieczeń.
Oprócz takich specjalistycznych dziedzin procesy oparte na przekształceniach
formalnych są używane rzadko. Wymagają specjalistycznej wiedzy i w praktyce okazuje się, że
w wypadku większości systemów nie powodują zmniejszenia kosztów lub polepszenia jakości
w porównaniu z innymi podejściami. Główną tego przyczyną jest fakt, że interakcje systemów
nie poddają się łatwo specyfikowaniu formalnemu, a to właśnie jest bardzo duża część wysiłku
tworzenia w większości systemów oprogramowanych.
3.1.4. Tworzenie z użyciem wielokrotnym
W większości przedsięwzięć programistycznych występuje użycie wielokrotne
oprogramowania. Dzieje siÄ™ to zwykle nieformalnie, gdy zatrudnione osoby znajÄ… projekty lub
kody programów podobne do tych wymaganych. Szukają ich, modyfikują zgodnie z
wymaganiami i włączają do swojego systemu. W podejściu ewolucyjnym omówionym w p.
3.1.2 użycie wielokrotne jest często uważane za podstawę szybkiego tworzenia systemów.
Takie nieformalne użycie wielokrotne ma miejsce niezależnie od użytego procesu. W
ostatnich kilku latach wyłoniło się jednak nowe podejście do tworzenia oprogramowania
8
(inżynieria oprogramowania komponentowego) oparte na użyciu wielokrotnym. Jest ono coraz
szerzej stosowane.
W tej metodzie z użyciem wielokrotnym zakłada się istnienie wielkiego zbioru
dostępnych komponentów programowych użycia wielokrotnego oraz integrującej je struktury.
Niekiedy komponenty te sÄ… same w sobie systemami (Commercial Off-The-Shelf, COTS),
które dostarczają specyficznej funkcjonalności, np. formatowanie tekstu, obliczenia
numeryczne. Na rysunku 3.5 przedstawiono ogólny model procesu opartego na użyciu
wielokrotnym.
Początkowa faza specyfikacji wymagań i faza zatwierdzania są podobne do innych
procesów; etapy pośrednie w procesie opartym na użyciu wielokrotnym są inne. Oto one:
1. Analiza komponentów. Na podstawie specyfikacji wymagań poszukuje się
komponentów implementujących tę specyfikację. Zwykle nie można znalez
ć idealnie
pasujących komponentów; te, które można wykorzystać, dostarczają jedynie część
wymaganej funkcjonalności.
2. Modyfikacja wymagań. W trakcie tej fazy analizuje się wymagania pod kątem
uzyskanych komponentów. Następnie modyfikuje się wymagania, aby
odzwierciedlały dostępne komponenty. Jeśli modyfikacje nie są możliwe, to czynność
analizy komponentów może być powtórzona w celu poszukiwania innych rozwiązań.
3. Projektowanie systemu z użyciem wielokrotnym. W trakcie tej fazy projektuje się
zrąb systemu lub ponownie wykorzystuje istniejące zręby. Projektanci biorą pod
uwagę ponownie użyte komponenty i tworzą zrąb zgodnie z ich wymaganiami. Pewne
nowe fragmenty oprogramowania mogą być potrzebne, jeśli nie są dostępne
komponenty użycia wielokrotnego.
4. Tworzenie i integracja. Tworzy się oprogramowanie, którego nie można było kupić.
Integruje siÄ™ w system komponenty i zakupione systemy COTS. W tym modelu
integracja systemu może być częścią procesu tworzenia, a nie oddzielną czynnością.
Model oparty na użyciu wielokrotnym ma oczywistą przewagę nad innymi - redukuje
ilość tworzonego oprogramowania, zmniejsza zatem koszt i zagrożenia. Zwykle powoduje
także szybsze dostarczenie oprogramowania. Kompromisy związane z wymaganiami są tu
jednak nieodzowne, co może oznaczać, że system nie będzie spełniał rzeczywistych potrzeb
9
użytkowników. Co więcej, traci się część kontroli nad ewolucją systemu, ponieważ firma
korzystająca z komponentów użycia wielokrotnego nie ma wpływu na ich nowe wersje.
3.2. Iteracja procesu
Wszystkie omówione dotychczas modele procesów mają wady i zalety. W wypadku
większości dużych systemów trzeba zastosować różne podejścia do innych części systemu.
Należy więc użyć modelu hybrydowego. Co więcej, potrzebne jest także wspomaganie iteracji
procesu, która polega na powtarzaniu fragmentów procesu w miarę ewolucji wymagań
stawianych systemowi. Prace projektowe i implementacyjne muszą być ponownie wykonane,
aby spełnić zmienione wymagania.
W tym punkcie omówię dwa takie hybrydowe modele, które dotyczą różnych podejść do
tworzenia, i które specjalnie opracowano, aby wspomagać iterację procesu. Są nimi:
1. Tworzenie przyrostowe, w którym specyfikacja, projektowanie i implementacja
są podzielone na ciąg po kolei realizowanych przyrostów.
2. Tworzenie spiralne, w którym system rozwija się ruchem spiralnym na zewnątrz
od początkowego szkicu do końcowego systemu.
Istotą procesu iteracyjnego jest to, że specyfikacja jest opracowywana w połączeniu z
oprogramowaniem. Stoi to jednak w sprzeczności z modelem zaopatrzenia wielu firm, w
których pełna specyfikacja systemu jest częścią kontraktu na jego tworzenie. W wypadku
tworzenia przyrostowego nie ma pełnej specyfikacji aż do chwili wyspecyfikowania ostatniego
przyrostu. To wymaga nowej formuły kontraktów, która może być trudna do zaakceptowania
przez poważnych klientów, na przykład agencje rządowe.
3.2.1. Tworzenie przyrostowe
Model kaskadowy tworzenia zmusza klientów do zatwierdzenia pewnego zbioru
wymagań, zanim rozpocznie się projektowanie. Zmusza również projektantów do
zatwierdzenia konkretnych strategii projektowych przed przystÄ…pieniem do implementacji.
Zmiany wymagań zgłoszone w trakcie tworzenia powodują powtórzenie prac nad
wymaganiami, projektem i implementacjÄ…. ZaletÄ… modelu kaskadowego jest prostota modelu
zarządzania, a rozdzielenie projektowania i implementacji powinno prowadzić do zbudowania
solidnego i Å‚atwo poddajÄ…cego siÄ™ zmianom systemu.
Podejście ewolucyjne do tworzenia umożliwia odłożenie w czasie decyzji projektowych i
dotyczących wymagań, ale prowadzi do zbudowania oprogramowania o złej strukturze,
trudnego do zrozumienia i pielęgnacji. Tworzenie przyrostowe jest podejściem pośrednim,
które łączy w sobie zalety obu tych modeli.
10
Podejście przyrostowe do tworzenia (rys. 3.6) zaproponował Mills (Mills i inni, 1980)
jako sposób na ograniczenie powtarzania prac w procesie tworzenia oraz danie klientom
pewnych możliwości odkładania decyzji o szczegółowych wymaganiach do czasu, aż zdobędą
pewne doświadczenia w pracy z systemem.
W procesie przyrostowym klienci identyfikują w zarysie usługi, które system ma
oferować. Wskazują, które z nich są dla nich najważniejsze, a które najmniej ważne. Definiuje
się następnie pewną liczbę przyrostów, które mają być dostarczone. Każdy z nich zawiera część
funkcjonalności systemu. Przyporządkowanie usług do przyrostów zależy od priorytetu tych
usług. Usługi o najwyższym priorytecie są dostarczane klientowi jako pierwsze.
Gdy tylko zidentyfikuje się przyrosty, szczegółowo definiuje się wymagania stawiane
usługom dostarczanym w pierwszym przyroście. Przyrost ten jest następnie tworzony za
pomocą najbardziej odpowiedniego procesu. W trakcie tej czynności prowadzi się dalszą
analizę wymagań dla następnych przyrostów; zmiany wymagań w stosunku do bieżącego
przyrostu nie są już jednak akceptowane.
Gdy przyrost jest już gotowy i dostarczony, klienci mogą go uruchomić. Oznacza to, że
szybko otrzymują część funkcjonalności systemu. Mogą eksperymentować z systemem, dzięki
czemu mogą ustalić wymagania w stosunku do następnych przyrostów i następnych wersji
obecnego przyrostu. Po zakończeniu prac nad kolejnymi wymaganiami, integruje się je z
istniejącymi przyrostami. Funkcjonalność systemu poprawia się z każdym dostarczonym
przyrostem. Najczęściej używane usługi mogą być zaimplementowane w tym procesie
najwcześniej lub być implementowane przyrostowo w miarę wymagań kolejnych przyrostów.
Nie ma konieczności, aby tworzenie każdego przyrostu odbywało się zgodnie z tym
samym procesem. Gdy usługi w pewnym przyroście mają staranną specyfikację, model
kaskadowy może być użyty w tym przyroście. Gdy specyfikacja jest niejasna, lepiej
zastosować tworzenie ewolucyjne.
Proces tworzenia przyrostowego ma kilka zalet:
11
1. Klienci nie muszą czekać na dostarczenie całego systemu, zanim zaczną czerpać z
niego korzyści. Pierwszy przyrost spełnia ich najbardziej istotne wymagania,
oprogramowanie może być więc natychmiast używane.
2. Klienci mogą używać wstępnych przyrostów jako rodzaju prototypu i zdobywać
doświadczenia, które inspirują wymagania wobec póz
niejszych przyrostów.
3. Ryzyko całkowitej porażki przedsięwzięcia jest mniejsze. Chociaż mogą pojawić
się problemy w niektórych przyrostach, prawdopodobnie wiele usług będzie z
powodzeniem dostarczone klientowi.
4. Usługi o najwyższym priorytecie będą dostarczone jako pierwsze, a póz
niejsze
przyrosty będą z nimi integrowane, a zatem najważniejsze usługi systemu będą
najdokładniej przetestowane. Oznacza to, że klienci mają mniejszą szansę doznać
awarii oprogramowania najbardziej istotnych części systemu.
Istnieją jednak pewne problemy z tworzeniem przyrostowym. Przyrosty powinny być
stosunkowo małe (nie więcej niż 20000 wierszy kodu), a każdy przyrost powinien dostarczać
pewną funkcjonalność systemu. Może być zatem trudno przypisać wymagania klienta do
przyrostów odpowiedniej wielkości. Co więcej, większość systemów wymaga zbioru
podstawowych udogodnień, które są używane przez różne części systemu. Skoro wymagania
nie są szczegółowo zdefiniowane przed implementacją przyrostu, trudno jest zidentyfikować
wspólne udogodnienia potrzebne wszystkim przyrostom.
Ewolucja podejścia przyrostowego doprowadziła ostatnio do powstania tzw.
 programowania ekstremalnego" (Beck, 1999). Opiera siÄ™ ono na tworzeniu i dostarczaniu
bardzo małych przyrostów funkcjonalności, włączeniu klienta w cały proces, ustawicznym
poprawianiu kodu i programowaniu pozbawionym indywidualizmu. Artykuł Becka zawiera
kilka raportów o sukcesach tego podejścia, ale jest jeszcze za wcześnie, aby stwierdzić, czy ta
metoda jest wiodącym podejściem do tworzenia oprogramowania.
3.2.2. Tworzenie spiralne
Model spiralny procesu tworzenia oprogramowania (rys. 3.7) po raz pierwszy
zaproponowany przez Boehma (1998) jest obecnie szeroko znany. Proces nie jest tu
przedstawiany jako ciąg czynności z pewnymi nawrotami od jednej do drugiej, ale ma postać
spirali. Każda pętla tej spirali reprezentuje jedną fazę procesu. Najbardziej wewnętrzna pętla
może być więc poświęcona wykonalności systemu, następna definicji wymagań stawianych
systemowi, kolejna projektowaniu systemu itd. Każda pętla spirali jest podzielona na cztery
sektory:
1. Ustalanie celów. Definiuje się konkretne cele tej fazy przedsięwzięcia. Identyfikuje
się ograniczenia, którym podlega proces i produkt. Rysuje się szczegółowe plany
zarządzania. Rozpoznaje zagrożenia przedsięwzięcia. Można zaplanować inne
strategie zależne od tych zagrożeń.
2. Rozpoznanie i redukcja zagrożeń. Przeprowadza się szczegółową analizę każdego z
rozpoznanych zagrożeń przedsięwzięcia. Podejmuje się kroki zmierzające do
12
redukcji tych zagrożeń. Jeśli zagraża nam na przykład to, że wymagania są
nieodpowiednie, można opracować prototyp systemu.
3. Tworzenie i zatwierdzanie. Po ocenie zagrożeń wybiera się model tworzenia
systemu. Jeśli najpoważniejsze zagrożenie jest związane z interfejsem użytkownika,
to odpowiednim modelem tworzenia może być prototypowanie ewolucyjne. Jeśli
najbardziej zagrożone jest bezpieczeństwo, to tworzenie oparte na przekształceniach
formalnych może być najwłaściwsze itd. Model kaskadowy może być uzasadniony
w wypadku, gdy głównym rozpoznanym ryzykiem jest integracja podsystemów.
4. Planowanie. Recenzuje się przedsięwzięcie i podejmuje decyzję, czy rozpoczynać
następną pętlę spirali. Jeśli jest ona pozytywna, to planuje się następną fazę
przedsięwzięcia.
Rys. 3.7 Model spiralny procesu tworzenia oprogramowania
Ważną cechą odróżniającą model spiralny od innych modeli procesów jest występujące
w tym modelu jawne potraktowanie zagrożeń. Nieformalnie, zagrożenie to po prostu coś, co
może pójść z
le. Jeśli mamy na przykład zamiar użyć nowy język programowania, to
zagrożeniem jest zawodność dostępnych kompilatorów lub to, że mogą generować nie dość
efektywny kod pośredni. Kłopoty przedsięwzięcia, na przykład przekroczenie kosztów lub
harmonogramu, również powodują zagrożenie. Zmniejszenie zagrożeń jest więc bardzo ważną
czynnością zarządzania każdym przedsięwzięciem.
Cykl spirali rozpoczyna się od opracowania celów, np. wydajność, funkcjonalność itd.
Następnie wylicza się różne sposoby osiągnięcia tych celów oraz ograniczenia na każdą z
różnych opcji. Każdą opcję ocenia się względem każdego celu. Wynikiem tego jest zwykle
identyfikacja z
ródeł zagrożeń przedsięwzięcia. Następnym krokiem jest oszacowanie tych
13
zagrożeń w takich czynnościach jak szczegółowa analiza, prototypowanie, symulacja itd. Gdy
zagrożenia są już oszacowane, następuje kolejny etap poprzedzony planowaniem następnej
fazy procesu.
W modelu spiralnym nie ma stałych faz takich jak specyfikowanie albo projektowanie.
Model spiralny obejmuje inne procesy. W jednej z pętli można użyć prototypowania, aby
rozstrzygnąć niejasności w wymaganiach i tym samym zmniejszyć zagrożenia. Potem może
następować konwencjonalne tworzenie kaskadowe. Przekształcenia formalne mogą służyć do
tworzenia tych części systemu, które podlegają surowym wymaganiom bezpieczeństwa.
3.3. Specyfikowanie oprogramowania
W tym i następnych trzech punktach omówię podstawowe czynności specyfikowania,
tworzenia, zatwierdzania i ewolucji oprogramowania. Pierwsza z tych czynności,
specyfikowanie oprogramowania, ma na celu określenie, jakich usług wymaga się od systemu i
jakim ograniczeniom podlega tworzenie i działanie oprogramowania. Ta czynność jest obecnie
bardzo często nazywana inżynierią wymagań. Jest to szczególnie istotna faza procesu
tworzenia oprogramowania, ponieważ błędy w tej fazie nieuchronnie prowadzą do
póz
niejszych kłopotów w trakcie projektowania i implementacji.
Na rysunku 3.8 przedstawiono proces inżynierii wymagań. Prowadzi on do opracowania
dokumentacji wymagań, która jest specyfikacją systemu. W tym dokumencie wymagania
zwykle przedstawia się na dwóch poziomach szczegółowości. Użytkownicy i klienci
potrzebują wykazu wymagań na wysokim poziomie abstrakcji, podczas gdy programiści muszą
mieć bardziej szczegółową specyfikację systemu.
W procesie inżynierii wymagań możemy wyróżnić cztery główne fazy:
1. Studium wykonalności. Ocenia się, czy rozpoznane potrzeby użytkowników mogą
być spełnione przy obecnych technologiach sprzętu i oprogramowania. Studium
pozwoli zdecydować, czy proponowany system będzie opłacalny z punktu
widzenia ekonomii oraz czy można system ten zbudować w ramach założonego
budżetu. Studium wykonalności powinno być dość krótkie i tanie. Jego wynik
powinien umożliwić decyzję, czy przystąpić do bardziej szczegółowej analizy.
2. Określanie i analiza wymagań. Jest to proces określania wymagań stawianych
systemowi na podstawie obserwacji istniejących systemów, rozmów z
potencjalnymi użytkownikami i zaopatrzeniowcami, analizy zadań itd. Może
obejmować opracowanie jednego lub kilku rożnych modeli systemu i prototypów
pomagających analitykom zrozumieć system, który mają wyspecyfikować.
3. Specyfikowanie wymagań. Jest czynnością polegającą na zapisywaniu informacji
zebranych w czasie analizy w dokumencie definiującym zbiór wymagań. Mogą w
nim pojawić się dwa rodzaje wymagań. Wymagania użytkownika są
abstrakcyjnymi określeniami wymagań stawianych systemowi spisanymi dla
14
klienta i użytkownika. Wymagania systemowe są bardziej szczegółowym opisem
funkcjonalności, którą należy dostarczyć.
4. Zatwierdzanie wymagań. W tej czynności sprawdza się realizm, spójność i
kompletność wymagań. W jej trakcie niemal pewne jest wykrycie błędów.
Następnie należy zmodyfikować dokumentację wymagań tak, aby usunąć te błędy.
Czynności procesu inżynierii wymagań nie są wykonywane w tak ścisłej kolejności.
Analiza wymagań trwa w czasie definicji i specyfikacji; w trakcie całego procesu ciągle
pojawiają się nowe wymagania. Czynności analizy, definicji i specyfikacji nakładają się zatem
na siebie.
3.4. Projektowanie i implementowanie oprogramowania
Faza implementowania w tworzeniu oprogramowania to proces przekształcania
specyfikacji systemu w działający system. Obejmuje zawsze projektowanie i programowanie,
ale jeśli zastosowano podejście ewolucyjne, to może również zawierać udoskonalanie
specyfikacji oprogramowania.
Projekt oprogramowania to opis struktury oprogramowania, które ma być
zaimplementowane, danych, które są częścią systemu, interfejsów między komponentami
systemu i użytych algorytmów. Projektanci nie tworzą od razu końcowego projektu, ale
opracowują go iteracyjnie poprzez wiele różnych wersji. Proces projektowania obejmuje
dodawanie formalizmu i szczegółów w miarę postępu prac oraz nawrotów w celu poprawy
wcześniej wykonanych fragmentów projektu.
Proces projektowania może obejmować opracowanie kilku modeli systemu na różnych
poziomach abstrakcji. W miarę dekompozycji projektu odkrywa się błędy i przeoczenia z
poprzednich faz. Powoduje to sprzężenie zwrotne umożliwiające poprawę wcześniej
powstałych modeli projektowych. Na rysunku 3.9 przedstawiono model takiego procesu, który
15
obrazuje opisy projektu opracowywane w różnych fazach projektowania. Ten diagram
sugeruje, że fazy procesu projektowania są sekwencyjne. W rzeczywistości nakładają się na
siebie. Sprzężenie zwrotne między fazami i wynikające z niego powtarzanie prac jest
nieuniknione w każdym procesie projektowania.
Specyfikacja następnej fazy jest wynikiem każdej czynności projektowej. Może to być
abstrakcyjna, formalna specyfikacja tworzona dla wyjaśnienia wymagań. Może też być
specyfikacją, jak należy zrealizować pewną część systemu. W miarę postępów projektowania
te specyfikacje stają się coraz bardziej szczegółowe. Końcowym wynikiem tego procesu jest
precyzyjna specyfikacja algorytmów i struktur danych, które należy zaimplementować.
Charakterystycznymi czynnościami procesu projektowania są:
1. Projektowanie architektury. Identyfikuje i dokumentuje siÄ™ podsystemy tworzÄ…ce
system oraz związki między nimi.
2. Specyfikowanie abstrakcyjne. Opracowuje się abstrakcyjną specyfikację usług
każdego podsystemu oraz ograniczeń, w ramach których musi pracować.
3. Projektowanie interfejsów. Projektuje i dokumentuje się interfejsy każdego
podsystemu z innymi podsystemami. Specyfikacja interfejsów musi być
jednoznaczna, ponieważ umożliwia korzystanie z podsystemów bez znajomości ich
działania. Na tym etapie można użyć metod specyfikacji formalnej.
4. Projektowanie komponentów. Przypisuje się usługi do różnych komponentów i
projektuje interfejsy tych komponentów.
5. Projektowanie struktur danych. Szczegółowo specyfikuje się i projektuje
struktury danych użyte w implementacji systemu.
6. Projektowanie algorytmów. Szczegółowo specyfikuje się i projektuje algorytmy
służące do realizacji usług.
Jest to bardzo ogólny model procesu projektowania, a rzeczywiste, praktyczne procesy
mogą go adaptować na rozmaite sposoby. Ostatnie dwie fazy, projektowanie algorytmów i
struktur danych, mogą być na przykład częścią projektowania albo częścią implementacji. Jeśli
16
są dostępne obiekty zdatne do użycia wielokrotnego, może to ograniczyć architekturę systemu i
interfejsy jego modułów. Może to oznaczać, że liczba komponentów, które należy
zaprojektować, istotnie się zmniejszy. Można też zastosować podejście badawcze i definiować
interfejsy systemu po wyspecyfikowaniu struktur danych.
3.4.1. Metody projektowania
W wielu przedsięwzięciach programistycznych projektowanie oprogramowania ciągle
jest działaniem ad hoc. Na podstawie zbioru wymagań, najczęściej zapisanego w języku
naturalnym, przygotowuje siÄ™ nieformalny projekt. Rozpoczyna siÄ™ kodowanie, a projekt jest
modyfikowany w miarÄ™ implementacji systemu. Prawie albo wcale nie prowadzi siÄ™ formalnej
kontroli zmian ani zarządzania projektowaniem. Gdy faza implementacji jest już ukończona,
projekt zwykle zmienił się już tak bardzo w stosunku do początkowej specyfikacji, że
pierwotna dokumentacja projektowa jest niepoprawnym i niepełnym opisem systemu.
Bardziej metodyczne podejścia do projektowania oprogramowania zaproponowano w
 metodach strukturalnych", które są zbiorami notacji i porad dla projektantów
oprogramowania. Przykładami metod strukturalnych są Structured Design (Constantine i
Yourdon, 1979), Structured Systems Analysis (Gane i Searson, 1997), Jackson System
Development (Jackson, 1983) oraz różne podejścia do projektowania obiektowego (Robinson,
1992; Booch, 1994; Rumbaugh i inni, 1991; Booch i inni, 1999; Rumbaugh i inni, 1999a,
1999b).
Użycie metod strukturalnych polega zwykle na opracowaniu graficznych modeli systemu
i prowadzi do utworzenia ogromnej ilości dokumentacji projektowej. Opracowano narzędzia
CASE (por. p. 3.7), które wspomagają konkretne metody. Metody strukturalne były z
powodzeniem używane w wielu ogromnych przedsięwzięciach. Mogą doprowadzić do
istotnego zmniejszenia kosztów, ponieważ obejmują standardowe notacje i zapewniają
powstanie standardowej dokumentacji projektowej. Nie ma metody, o której można by
powiedzieć, że jest wyraz
nie lepsza albo gorsza od innych. Powodzenie lub porażka metody
zależy często od jej dopasowania do konkretnej dziedziny zastosowań.
Metoda strukturalna zawiera model procesu projektowania, notacje do zapisu projektu,
formaty raportów, zasady i porady dla projektantów. Chociaż istnieje bardzo wiele metod, mają
one wiele wspólnych cech. Metody strukturalne mogą obejmować wszystkie poniższe modele
systemu lub tylko niektóre z nich:
1. Model przepływu danych, w którym system jest opisywany za pomocą
przekształceń danych wykonywanych w trakcie ich przetwarzania.
2. Model encja-związek, który służy do opisu podstawowych encji w projekcie i
związków między nimi. Modele encja-związek są przyjętą techniką opisu struktury
baz danych.
3. Model strukturalny, w którym dokumentuje się komponenty systemu i ich
interakcje.
17
4. Metody obiektowe zawierajÄ… model dziedziczenia w systemie, modele statycznych
i dynamicznych związków między obiektami oraz modele interakcji obiektów w
czasie działania systemu.
Poszczególne metody wzbogacają tę listę o inne modele systemu, na przykład diagramy
stanów, historie życia encji, które obrazują, jak encje są przekształcane w trakcie przetwarzania
itd. Z większości metod wynika, aby używać słownika danych albo scentralizowanego
repozytorium na informacje o systemie.
W praktyce porady wynikające z metod są nieformalne, a zatem różni projektanci mogą
opracować inne projekty. Te  metody" są w istocie standardami notacji i uosobieniem
sprawdzonej praktyki. Stosując się do tych metod i słuchając ich porad, powinniśmy opracować
sensowne projekty. Kreatywność projektanta jest jednak ciągle potrzebna, aby decydować o
dekompozycji systemu i zapewnić, że projekt odpowiednio realizuje specyfikację systemu. Z
badań empirycznych dotyczących projektantów (Bansler i B0dker, 1993) wynikło, że bardzo
rzadko stosują oni te metody bezkrytycznie. Projektanci wybierają konkretne porady zależnie
od lokalnych warunków.
3.4.2. Programowanie i wyszukiwanie błędów
Tworzenie programu, który implementuje system, następuje zwykle po procesie
projektowania systemu. Chociaż pewne klasy programów, takie jak np. w systemach
krytycznych, są szczegółowo projektowane przed rozpoczęciem implementacji, zwykle
póz
niejsze fazy projektowania i tworzenia programów przeplatają się. Narzędzi CASE można
użyć do wygenerowania szkieletu programu na podstawie projektu. Obejmuje on kod, w
którym definiuje i implementuje się interfejsy. W wielu wypadkach programista musi dodać
jedynie szczegóły operacji każdego komponentu programu.
Programowanie jest indywidualną czynnością i nie istnieje żaden ogólny proces, zgodnie
z którym się postępuje. Niektórzy programiści zaczną od komponentów, które rozumieją,
utworzą je, a potem przejdą do pracy z mniej zrozumiałymi komponentami. Inni postąpią
odwrotnie, pozostawiając znajome komponenty na koniec, ponieważ wiedzą, jak je utworzyć.
Niektórzy programiści lubią wcześnie definiować dane, a potem używać ich do kierowania
pisaniem programów. Inni pozostawią dane bez specyfikacji tak długo, jak to tylko jest
możliwe.
Programiści wykonują pewne testy kodu, który napisali. Często prowadzi to do wykrycia
błędów, które należy usunąć z programu. Czynność ta nosi nazwę usuwania błędów.
Testowanie usterek i usuwanie błędów to dwa różne procesy. Testowanie wykazuje istnienie
błędów. Usuwanie błędów polega na ich lokalizacji i poprawieniu.
Na rysunku 3.10 przedstawiono jeden z możliwych procesów usuwania błędów. Usterki
w kodzie należy zlokalizować i zmodyfikować program tak, aby spełnił wymagania.
18
Testowanie należy powtarzać, aby zapewnić właściwe wprowadzenie zmian. Proces usuwania
błędów jest zatem częścią zarówno tworzenia, jak i testowania oprogramowania.
Rys.3.10 Proces usuwania błędów
Osoba usuwająca błędy musi formułować hipotezy na temat obserwowanego zachowania
systemu i póz
niej sprawdzać te hipotezy w nadziei znalezienia usterki, która powoduje
nieprawidłowość wyniku. Weryfikacja hipotezy może polegać na ręcznym śledzeniu kodu
programu. Lokalizacja błędu może wymagać nowych przypadków testowych. Proces usuwania
błędów może być wsparty przez interakcyjne narzędzia do usuwania błędów, które wyświetlają
pośrednie wartości zmiennych programu i ślad wykonanych instrukcji.
3.5. Zatwierdzanie oprogramowania
Zatwierdzanie oprogramowania lub bardziej ogólnie weryfikacja i zatwierdzanie (W &
Z) mają wykazać, że system jest zgodny ze swoją specyfikacją i spełnia oczekiwania klienta,
który go kupuje. Obejmuje proces sprawdzania, m.in. kontrole i recenzje w każdym kroku
procesu tworzenia od definicji wymagań użytkownika do pisania programów. Większość
kosztów zatwierdzania powstaje po zaimplementowaniu, gdy testuje się działający system
Z wyjątkiem małych programów, nie należy testować systemu jako pojedynczej,
monolitycznej całości. Wielkie systemy buduje się z podsystemów, te są z kolei składane z
modułów, w skład których wchodzą procedury i funkcje. Proces testowania powinien być
zatem wykonywany w wielu krokach, w których testuje się przyrostowo jednocześnie z
implementowaniem systemu.
19
Na rysunku 3.11 przedstawiono pięcioetapowy proces testowania, w którym testuje się
komponenty, póz
niej zintegrowany system, a na końcu jeszcze raz system za pomocą danych
dostarczonych przez klienta. Najlepiej jest, aby wady komponentów były wykryte we wczesnej
fazie procesu, a problemy z interfejsami w fazie integracji systemu. Znalezienie defektów
powoduje jednak, że programy muszą być oczyszczone z błędów, a to może wymagać
powtórzenia innych faz procesu testowania. Błędy w komponentach programów mogą objawić
się także w trakcie testowania integracji. Cały ten proces jest więc iteracyjny ze zwrotnym
przekazywaniem informacji do wcześniejszych części z faz póz
niejszych.
Fazy procesu testowania są następujące:
1. Testowanie jednostek. Testuje się poszczególne komponenty, aby zapewnić, że
działają poprawnie. Każdy komponent jest niezależnie testowany bez udziału innych
komponentów systemu.
2. Testowanie modułów. Moduł jest kolekcją niezależnych komponentów takich jak
klasy obiektów, abstrakcyjne typy danych, albo bardziej luz
nÄ… kolekcjÄ… procedur i
funkcji. Moduł zamyka w sobie powiązane komponenty, można go zatem testować
bez udziału innych modułów systemu.
3. Testowanie podsystemów. Ta faza obejmuje testowanie kolekcji modułów, które
zintegrowano w podsystemie. W wypadku wielkich systemów głównymi
napotykanymi tu problemami są niezgodności interfejsów. Proces testowania
podsystemu powinien zatem prowadzić do wykrycia błędów w interfejsach modułów
przez intensywne próbkowanie tych interfejsów.
4. Testowanie systemu. Podsystemy zintegrowano już w system. Ten proces testowania
ma wykryć błędy wynikające z nie przewidzianych interakcji między podsystemami i
problemów z interfejsami podsystemów. W tej fazie sprawdza się także, czy system
spełnia stawiane mu wymagania funkcjonalne i niefunkcjonalne. Bada się także
pojawiające się właściwości systemu.
5. Testowanie odbiorcze. Jest to końcowa faza procesu testowania przed przyjęciem
systemu do użytkowania. System testuje się za pomocą danych dostarczonych przez
użytkownika, a nie danych symulowanych. Testowanie odbiorcze może doprowadzić
do wykrycia błędów i zaniedbań w definicji wymagań stawianych systemowi,
ponieważ prawdziwe dane wypróbowu- ją system w zupełnie inny sposób niż dane
testowe. Testowanie odbiorcze może również ujawnić problemy z wymaganiami
polegające na tym, że udogodnienia systemu nie w pełni odpowiadają potrzebom
użytkowników lub efektywność systemu jest nie do zaakceptowania.
Za testowanie jednostek i testowanie modułów zwykle odpowiadają programiści, którzy
utworzyli komponent. Programiści opracowują własne dane testowe i przyrostowo testują swój
kod w miarę jego tworzenia. Takie podejście jest sensowne ekonomicznie, ponieważ to właśnie
programista zna najlepiej swój komponent, jest zatem najwłaściwszą osobą do wygenerowania
danych testowych. Testowanie jednostek jest częścią procesu implementacji. Oczekuje się, że
w wyniku tego procesu będzie dostarczony komponent zgodny ze swoją specyfikacją.
20
Póz
niejsze fazy testowania obejmują integrację prac wielu programistów; należy je
uprzednio zaplanować. Powinien je wykonywać niezależny zespół testerów na podstawie
wcześniej zapisanych planów testów opracowanych na podstawie specyfikacji i projektu
systemu. Na rysunku 3.12 pokazano, jak plany testów stanowią połączenie między
czynnościami tworzenia i testowania.
Testowanie odbiorcze jest czasem nazywane testowaniem alfa. Systemy na zamówienie
są tworzone dla jednego klienta. Proces testowania alfa trwa do chwili, w której wytwórca
systemu i klient zgodzą się, że dostarczony system jest możliwą do przyjęcia implementacją
wymagań stawianych systemowi.
Jeśli system jest sprzedawany jako produkt programowy, często stosuje się proces
testowania zwany testowaniem beta. Testowanie beta polega na dostarczeniu systemu pewnej
liczbie potencjalnych klientów, którzy zgodzili się z niego korzystać. Informują oni
wytwórców o pojawiających się problemach. Sprawia to, że produkt podlega prawdziwemu
użytkowaniu i umożliwia wykrycie błędów, których nie przewidzieli budowniczowie systemu.
Po otrzymaniu tych zwrotnych informacji modyfikuje się system i udostępnia do dalszego
testowania beta lub do ogólnego użytku.
3.6. Ewolucja oprogramowania
Elastyczność systemów oprogramowanych jest jedną z głównych przyczyn, że coraz
więcej i więcej oprogramowania włącza się do wielkich, złożonych systemów. Po podjęciu
decyzji o wyprodukowaniu sprzętu zmiany w jego projekcie są bardzo kosztowne. W wypadku
oprogramowania zmiany mogą być jednak wprowadzane w każdej chwili tworzenia lub nawet
po jego zakończeniu. Koszt tych zmian może być bardzo wysoki, ale wciąż będzie niższy niż
odpowiednie zmiany w sprzęcie systemu.
Od dawna istniało wyraz
ne rozgraniczenie między procesem tworzenia oprogramowania
a procesem ewolucji oprogramowania (pielęgnacji oprogramowania). Tworzenie
oprogramowania jest uważane za czynność twórczą, w której system oprogramowany ze
21
wstępnego pomysłu staje się działającym systemem. Pielęgnacja oprogramowania to proces
zmieniania systemu po przekazaniu go do użytku. Chociaż koszty  pielęgnacji" są zwykle
wielokrotnie wyższe niż koszt wstępnego tworzenia, proces pielęgnacji jest uważany za
mniejsze wyzwanie niż tworzenie oprogramowania.
To rozgraniczenie staje się coraz bardziej nieistotne. Niewiele systemów
oprogramowanych jest obecnie tworzonych od nowa. Znacznie lepiej jest postrzegać tworzenie
i pielęgnację jako kontinuum. Nie są to dwa rozłączne procesy. Należy raczej myśleć o
inżynierii oprogramowania jako o procesie ewolucyjnym, w którym oprogramowanie jest w
trakcie swojego życia ustawicznie modyfikowane w odpowiedzi na zmieniające się wymagania
i potrzeby klienta. Na rysunku 3.13 pokazano ten ewolucyjny proces.
3.7. Zautomatyzowane wspomaganie procesu
Komputerowo wspomagana inżynieria oprogramowania (Computer-aided Software
Engineering, CASE) jest nazwą oprogramowania używanego do wspomagania czynności
procesu tworzenia oprogramowania, takich jak inżynieria wymagań, projektowanie,
programowanie i testowanie. Narzędzia CASE obejmują zatem edytory projektów, słowniki
danych, kompilatory, programy do usuwania błędów, narzędzia do budowania systemu itd.
Technologia CASE wspomaga proces tworzenia oprogramowania przez automatyzacjÄ™
niektórych czynności procesu i dostarczanie informacji o tworzonym oprogramowaniu.
Przykładami czynności, które można zautomatyzować za pomocą CASE, są:
1. Opracowywanie graficznych modeli systemu jako części specyfikacji wymagań i
projektu oprogramowania.
2. Czytanie projektu za pomocą słownika danych, który przechowuje informacje o
encjach i zwiÄ…zkach w projekcie.
3. Generowanie interfejsu użytkownika na podstawie graficznego opisu interfejsu
opracowanego interaktywnie przez użytkownika.
4. Śledzenie błędów przez udostępnienie informacji o wykonującym się programie.
5. Automatyczne tłumaczenie programów ze starych wersji języków programowania
(np. COBOL) na ich bardziej aktualne wersje.
22
Technologia CASE jest obecnie dostępna dla większości rutynowych czynności procesu
tworzenia oprogramowania. Doprowadziło to do pewnej poprawy jakości oprogramowania i
produktywności, chociaż okazała się ona znacznie mniejsza, niż wcześniej spodziewali się
zwolennicy CASE. Sugerowali oni polepszenie o rzędy wielkości w wypadku używania
zintegrowanych środowisk CASE. W rzeczywistości uzyskana poprawa była nie większa niż
40% (Huff, 1992). Chociaż taki postęp jest istotny, CASE nie zrewolucjonizowały inżynierii
oprogramowania w takim stopniu, jak siÄ™ tego spodziewano.
Ulepszenia wynikające z użycia CASE są ograniczone dwoma czynnikami:
1. Inżynieria oprogramowania jest głównie czynnością projektowania opartą na
kreatywnym myśleniu. Istniejące systemy CASE automatyzują rutynowe
czynności, ale próby zastosowania sztucznej inteligencji do wspomagania
projektowania nie były udane.
2. W większości firm inżynieria oprogramowania jest czynnością zespołową.
Inżynierowie spędzają więc sporo czasu na interakcji z innymi członkami zespołu.
Technologia CASE nie daje tu żadnego wsparcia.
Nie jest jasne, czy ta sytuacja zmieni się w przyszłości. Moim zdaniem, specyficzne
narzędzia CASE do projektowania oprogramowania i zespołowej inżynierii oprogramowania
są nierealne. Pojawią się jednak i będą używane w procesie tworzenia oprogramowania
systemy wspomagające ogólne projektowanie oraz pracę zespołową. Technologia CASE jest
obecnie dojrzała, a narzędzia i środowiska CASE są oferowane przez wielu dostawców. Nie
koncentrując się na konkretnych narzędziach, przedstawiłem tu raczej przegląd, a specyficzne
rodzaje wspomagania procesu omówiłem w odpowiednich rozdziałach tej książki. Dodałem
odsyłacze do bardziej szczegółowego materiału na temat integracji CASE i odsyłacze do
dostawców narzędzi CASE.
3.7.1. Klasyfikacja CASE
Klasyfikacja CASE pomaga zrozumieć różne typy narzędzi CASE oraz ich rolę we
wspomaganiu czynności procesu tworzenia oprogramowania. Istnieje wiele różnych sposobów
klasyfikacji narzędzi CASE, z których każda daje inny punkt widzenia na te narzędzia. W tym
miejscu omówię narzędzia CASE z trzech z tych perspektyw:
1. Perspektywa funkcjonalności, w której klasyfikuje się narzędzia CASE względem ich
specyficznej funkcji.
2. Perspektywa procesu, w której klasyfikuje się narzędzia CASE względem
wspomaganych przez nie czynności procesu.
3. Perspektywa integracji, w której klasyfikuje się narzędzia CASE względem sposobu
ich integracji w spójne jednostki, które oferują wspomaganie jednej lub więcej
czynności procesu.
23
Typ narzędzia Przykłady
Narzędzia do planowania Narzędzia PERT, narzędzia do szacowania, arkusze
kalkulacyjne
Narzędzia do edycji Edytory tekstowe, edytory diagramów, procesory tekstów
Narzędzia do zarządzania Narzędzia do śledzenia wymagań, systemy kontroli zmian
zmianami
Narzędzia do zarządzania System zarządzania wersjami, narzędzia do budowania
konfiguracjami systemów
Narzędzia do prototypowania Języki bardzo wysokiego poziomu, generatory interfejsu
użytkownika
Narzędzia do wspomagania Edytory projektów, słowniki danych i generatory kodu
metod
Narzędzia do przetwarzania Kompilatory, interpretery
języków
Narzędzia do analizy Generatory wzajemnych odwołań, analizatory statyczne,
programów analizatory dynamiczne
Narzędzia do testowania Generatory danych testowych, programy porównujące pliki
Narzędzia do usuwania błędów Systemy interakcyjnego usuwania błędów
Narzędzia do dokumentowania Programy składu, edytory rysunków
Narzędzia do inżynierii wstecz Systemy wyszukiwania wzajemnych odwołań, programy do
restrukturyzacji systemów
Rysunek 3.14 Klasyfikacja narzędzi CASE względem ich funkcji
Na rysunku 3.14 przedstawiono klasyfikację narzędzi CASE względem ich funkcji. W tej
tabeli wyliczono kilka różnych typów narzędzi CASE i dodano przykłady każdego z nich. Nie
jest to pełna lista narzędzi CASE. Nie zamieszczono w niej specyficznych narzędzi, na
przykład narzędzia do wspomagania użycia wielokrotnego.
Na rysunku 3.15 przedstawiono alternatywną klasyfikację narzędzi CASE. Zobrazowano
na nim fazy procesu wspomagane przez kilka różnych typów narzędzi CASE. W trakcie całego
procesu można używać narzędzi do planowania, szacowania, edycji tekstów i zarządzania
konfiguracjami.
24
Zakres wspomagania procesu tworzenia oprogramowania przez technologiÄ™ CASE jest
jeszcze innym możliwym kryterium klasyfikacji. Fuggetta (1993) zaproponował, aby podzielić
systemy CASE na trzy kategorie:
1. Narzędzia wspomagające poszczególne zadania w ramach procesu, np.
sprawdzanie spójności projektu, kompilacja programu, porównywanie wyników
testów itd. Mogą to być samodzielne narzędzia ogólnego przeznaczenia (np.
procesor tekstów), mogą też być pogrupowane w warsztaty.
2. Warsztaty wspomagają całe fazy procesów lub czynności, na przykład
specyfikowanie, projektowanie itd. Zwykle składają się ze zbioru narzędzi w
mniejszym lub większym stopniu zintegrowanych.
3. Środowiska wspomagają całość lub znaczącą część procesu tworzenia
oprogramowania. Zwykle składają się z kilku różnych warsztatów, które w
pewien sposób zintegrowano.
Na rysunku 3.16 przedstawiono tę klasyfikację oraz kilka przykładów narzędzi CASE z
różnych klas. Ten rysunek jest tylko poglądowym przykładem. Nie ma na nim wielu rodzajów
narzędzi i warsztatów.
Narzędzia ogólnego przeznaczenia są stosowane według uznania inżyniera
oprogramowania, który podejmuje decyzje, kiedy użyć ich do wsparcia procesu. Warsztaty
zwykle wspomagają jednak konkretną metodę, która definiuje model procesu oraz zbiór reguł i
porad stosujących się do budowanego oprogramowania. Środowiska podzieliłem na
środowiska zintegrowane oraz środowiska zbudowane dla procesu. Środowiska zintegrowane
zapewniajÄ… infrastrukturÄ™ wspomagania dla integracji danych, sterowania i prezentacji.
Środowiska zbudowane dla procesu są jeszcze bardziej ogólne. Obejmują wiedzę o procesie
25
tworzenia oprogramowania oraz udogodnienia, które, korzystając z modelu procesu, doradzają
inżynierom, jakich użyć narzędzi i warsztatów oraz kiedy należy to robić.
W praktyce różnice między tymi klasami narzędzi nie są wyraz
ne. Narzędzia mogą być
sprzedawane jako pojedynczy produkt, oferując jednocześnie wspomaganie innych czynności.
Obecnie większość procesorów tekstu zawiera na przykład wbudowany edytor diagramów.
Warsztaty CASE do projektowania mają coraz więcej udogodnień do programowania i
testowania, są więc bardziej podobne do środowisk niż do wyspecjalizowanych warsztatów.
Nie zawsze może być zatem łatwo sklasyfikować pewien produkt. Mimo tego takie
klasyfikacje są przydatną pomocą do zrozumienia rozmiaru wsparcia procesu, które
prawdopodobnie oferuje pewne narzędzie.
26
Główne tezy
żð Procesy tworzenia oprogramowania to czynnoÅ›ci zmierzajÄ…ce do
wyprodukowania systemu. Modele procesów tworzenia oprogramowania to
abstrakcyjne reprezentacje tych procesów.
żð Wszystkie procesy tworzenia oprogramowania obejmujÄ… specyfikowanie,
projektowanie, implementacjÄ™, zatwierdzanie i ewolucjÄ™ oprogramowania.
żð Ogólne modele procesów opisujÄ… organizacjÄ™ procesu tworzenia
oprogramowania. Przykładami takich modeli są: model kaskadowy, tworzenie
ewolucyjne, tworzenie formalne systemów oraz tworzenie z użyciem
wielokrotnym.
żð W modelach iteracyjnych procesów tworzenie oprogramowania przedstawia siÄ™
w postaci cyklu czynności. Zaletą tego podejścia jest uniknięcie zbyt wczesnego
zatwierdzania specyfikacji lub projektu. Przykładami modeli iteracyjnych są
tworzenie przyrostowe i model spiralny.
żð Inżynieria wymagaÅ„ to proces opracowywania specyfikacji oprogramowania.
Obejmuje przygotowanie specyfikacji zrozumiałej dla użytkowników systemu
oraz bardziej szczegółowej specyfikacji dla budowniczych systemu.
żð I Proces projektowania i implementowania polega na przeksztaÅ‚ceniu specyfikacji
wymagań w działający system oprogramowania. Metody systematycznego
projektowania mogą być elementem tego przekształcenia.
żð Zatwierdzanie oprogramowania to proces sprawdzania, czy system jest zgodny ze
swoją specyfikacją oraz czy spełnia rzeczywiste potrzeby użytkowników.
żð Ewolucja oprogramowania polega na modyfikowaniu istniejÄ…cego systemu
oprogramowanego tak, aby spełniał nowe wymagania. Takie podejście staje się
standardem tworzenia oprogramowania w wypadku małych i średnich
przedsięwzięć.
żð Technologia CASE zapewnia zautomatyzowane wspomaganie procesu tworzenia
oprogramowania. Narzędzia CASE wspomagają poszczególne czynności
procesu. Warsztaty CASE wspomagają zbiory powiązanych czynności.
Środowiska CASE wspomagają większość lub nawet wszystkie czynności
procesu tworzenia oprogramowania.
27
ĆWICZENIA
1. Uzasadniając swoje odpowiedzi zależnie od typu tworzonego systemu, zaproponuj
najbardziej odpowiedni ogólny model procesu, który mógłby być użyty jako
podstawa zarządzania produkcją następujących systemów:
a. system do sterowania nie blokujÄ…cymi siÄ™ hamulcami samochodu;
b. system rzeczywistości wirtualnej do wspomagania pielęgnacji
oprogramowania;
c. system księgowości uniwersytetu, który ma wejść w miejsce istniejącego
systemu;
d. interakcyjny system dla klientów kolei, który umożliwia wynajdowanie
czasów odjazdów pociągów poprzez terminale zainstalowane na stacjach.
2. Wyjaśnij, dlaczego programy tworzone za pomocą podejścia ewolucyjnego będą
prawdopodobnie trudne do pielęgnowania.
3. Wyjaśnij, w jaki sposób model kaskadowy procesu tworzenia oprogramowania i
prototypowanie mogą być elementami modelu spiralnego procesu.
4. Wyjaśnij, dlaczego w procesie inżynierii wymagań tak ważne jest rozróżnienie
między opracowywaniem wymagań użytkownika i opracowywaniem wymagań
systemu.
5. Opisz podstawowe czynności procesu projektowania oprogramowania oraz wyniki
tych czynności. Przedstaw na diagramie encja-związek możliwe relacje między
wynikami tych czynności.
6. Z jakich pięciu komponentów składa się metoda projektowania? Rozważ dowolną
znaną ci metodę i opisz jej komponenty. Oceń kompletność wybranej metody.
7. Zaprojektuj model procesu do przeprowadzania testów systemu i zapisywania ich
wyników.
8. Wyjaśnij, dlaczego system oprogramowania używany w środowisku świata
rzeczywistego musi się zmieniać lub stawać coraz mniej przydatny.
9. Zastanów się, w jaki sposób klasyfikacja technologii CASE może pomóc
menedżerom odpowiedzialnym za zaopatrywanie w systemy CASE.
10. Zbadaj dostępność narzędzi w twoim lokalnym środowisku wytwórczym;
sklasyfikuj te narzędzia za pomocą opisanych w tej książce parametrów (funkcja,
czynność, zakres wspomagania).
11. Historia zna wiele przypadków, gdy wprowadzenie nowej technologii
spowodowało znaczące zmiany na rynku pracy i na pewien czas pozbawiło ludzi
pracy. Rozważ, czy wprowadzenie technologii CASE może mieć te same
konsekwencje dla inżynierów oprogramowania. Jeśli sądzisz, że nie, wyjaśnij
dlaczego. Jeśli uważasz, że doprowadzi to do zmniejszenia liczby ofert pracy,
odpowiedz, czy aktywne albo pasywne sabotowanie wprowadzenia tej technologii
28