Inżynieria
oprogramowania
Część 2: Proces tworzenia
oprogramowania
Ian Sommerville
Software Engineering 9. wyd.
Inżynieria
oprogramowania
Część 2: Proces tworzenia
oprogramowania
Ian Sommerville
Software Engineering 9. wyd.
Zawartość
Modele procesu tworzenia oprogramowania
Czynności procesu tworzenia
oprogramowania
Inżynieria zmian w trakcie procesu
tworzenia oprogramowania
Ulepszanie procesu tworzenia
oprogramowania
Proces tworzenia
oprogramowania
Ustrukturalizowany zbiór czynności prowadzący
do powstania produktu programistycznego
Następujące czynności są wspólne dla wszystkich
procesów:
Specyfikowanie – funkcje systemu i dodatkowe
oczekiwania
Projektowanie i implementacja – zdefiniowanie struktury
systemu i jego implementacja.
Zatwierdzanie systemu – sprawdzenie, że system działa
zgodnie ze specyfikacją i oczekiwaniem klienta
Pielęgnacja (ewolucja) – zmienianie systemu w trakcie
jego użycia.
Model procesu tworzenia
oprogramowania
Stanowi abstrakcyjny opis procesu z pewnego
punktu widzenia, zawiera zatem częściową
informację o procesie.
Opisując proces, mówimy zwykle o czynnościach
w nim występujących i ich kolejności. Opis może
jednak dodatkowo zawierać:
Produkty, które są wynikiem kolejnych kroków.
Role poszczególnych członków zespołu wytwórczego.
Warunki wstępne i końcowe poszczególnych kroków
(np. akceptacja specyfikacji przez klienta przed
projektowaniem architektury, zatwierdzenie diagramów
UML po zakończeniu tego kroku).
Procesy zaplanowane i
procesy zwinne
Procesy zaplanowane (ang. plan driven processes) są to
procesy, w których wszystkie czynności są zaplanowane
z góry i plan ten jest podstawą miary postępu prac.
W procesach zwinnych (ang. agile processes)
planowanie odbywa się w sposób przyrostowy, co
ułatwia zmiany w specyfikacji.
Wiele procesów stosowanych w praktyce łączy obie
powyższe metodologie.
Wybór procesu tworzenia oprogramowania zależy w
dużej mierze od specyfiki zadania. W izolacji o żadnym z
istniejących procesów nie można powiedzieć ani, że jest
dobry, ani, że jest zły.
Modele procesów
Model kaskadowy
Model zaplanowany. Kolejny krok następuje po zakończeniu
poprzedniego.
Model przyrostowy
Fazy specyfikacji, implementacji i zatwierdzania przeplatają
się. Może być zaplanowany lub zwinny.
Model z użyciem wielokrotnym
Oprogramowanie buduje się przy użyciu gotowych
komponentów.
W praktyce większość dużych systemów tworzy się przy
użyciu procesów będących kombinacji powyższych modeli.
Model kaskadowy (ang. waterfall
model)
Definiowanie
wymagań
Projektowanie
systemu
i oprogramowania
Implementacja
i testowanie
jednostek
Integracja
i zatwierdzanie
systemu
Działanie
i pielęgnacja
Fazy modelu kaskadowego
W modelu kaskadowym wyróżniamy pięć rozłącznych faz
Definiowanie wymagań
Projektowanie systemu i oprogramowania
Implementacja i testowanie jednostek
Integracja i zatwierdzanie systemu
Działanie i pielęgnacja
Główną wadą modelu kaskadowego jest wysoki koszt
zmian. Kolejna faza zakłada zakończenie fazy
poprzedniej.
Problemy modelu
kaskadowego
Twardy podział na kolejne fazy utrudnia wszelkie
zmiany w trakcie procesu.
Dlatego model kaskadowy jest właściwy, jeśli
wymagania są dobrze określone i nie oczekuje się wielu
zmian.
Niewiele systemów o charakterze biznesowym spełnia
ten warunek.
Model kaskadowy jest najczęściej używany przy
tworzeniu wielkich systemów, gdy zespół
wytwórczy jest rozproszony w wielu miejscach.
Fakt, że model ten jest modelem zaplanowanym ułatwia
koordynację prac
Model przyrostowy
Ogólny opis
Specyfikowanie
Tworzenie
Zatwierdzanie
Wersja
początkowa
Wersje
pośrednie
Wersja
końcowa
Równoległe czynności
Zalety modelu
przyrostowego
Zredukowany jest koszt zmian zachodzących w
toku procesu
Koszt analizy i dokumentacji, którą trzeba powtórzyć jest
dużo mniejszy.
Współpraca między klientem a zespołem
wytwórczym istnieje w trakcie całego cyklu
budowy systemu
Klient może na bieżąco komentować tworzenie
oprogramowania i widzi postęp prac.
Możliwe jest wczesne dostarczenie „częściowej”
wersji systemu
Klient może stosunkowo wcześnie używać fragmentów
systemu
Wady modelu
przyrostowego
Proces nie jest widoczny
Menedżerowie potrzebują konkretnych wyników, aby
mierzyć postęp prac. Jeśli systemy są tworzone
szybko, n ie opłaca się generować dokumentów
opisujących każdą wersję systemu.
System ma złą strukturę
Nieustające modyfikacje przyczyniają się do psucia
struktury oprogramowania. Wprowadzanie nowych
zmian staje się coraz trudniejsze i bardziej
kosztowne.
Model z użyciem
wielokrotnym
W większości dyscyplin inżynieryjnych proces
tworzenia oparty jest o komponenty
ponownego użycia.
W przypadku inżynierii oprogramowania
możliwe jest podobne podejście.
Problemem jest, że aby dany komponent
można było wielokrotnie użyć, trzeba to
uwzględnić w fazie jego projektowania.
Elementy wielokrotnego
użycia
Użycie wielokrotne systemów
Cały system można ponownie użyć poprzez
włączenie go do innego ststemu (COTS – Commercial
Off The Shelf).
Użycie wielokrotne komponentów
Podsystemy, moduły, pojedyncze obiekty.
Użycie wielokrotne funkcji
Biblioteki funkcji używane od kilkudziesięciu lat.
Użycie wielokrotne idei
Wzorce programowe, wzorce architektoniczne.
Tworzenie z użyciem
wielokrotnym
Specyfikacja
wymagań
Analiza
komponentów
Modyfikacja
wymagań
Projekt systemu
Tworzeni
e
i
integracj
a
Zatwierdzanie
systemu
Zalety i wady modelu z
użyciem wielokrotnym
Mniejszy koszt i mniejsze zagrożenie projektu.
Szybsze dostarczenie oprogramowania.
Nieodzowność pewnych kompromisów, co
może oznaczać, że system nie w pełni będzie
spełniać oczekiwania klienta.
Możliwa strata panowania nad pielęgnacją
systemu, ponieważ firma korzystająca z
gotowych komponentów nie ma wpływu na ich
nowe wersje.
Czynności procesu
tworzenia
oprogramowania
Realne procesy tworzenia oprogramowania to
przeplatające się sekwencje czynności
zarówno o charakterze technicznym, jak i
związanych z pracą zespołową i zarządzaniem.
Cztery podstawowe czynności o charakterze
technicznym, czyli specyfikowanie, tworzenie,
zatwierdzanie i pielęgnacja są różnie
zorganizowane w różnych procesach.
Na przykład w modelu kaskadowym
przebiegają one sekwencyjnie, podczas gdy w
modelu przyrostowym przeplatają się.
Proces specyfikacji
wymagań
Studium
wykonalności
Raport
o wykonalności
Określanie i
analiza wymagań
Modele
systemu
Wymagania
użytkownika
Specyfikowanie
wymagań
Zatwierdzanie
wymagań
Dokumentacja
wymagań
Specyfikowanie wymagań
Określenie wymaganych funkcji systemu
(wymagania funkcjonalne) i ograniczeń
nakładanych na system.
Proces inżynierii wymagań
Studium wykonalności
Ocenia się, czy potrzeby klienta mogą być spełnione.
Określanie i analiza wymagań
Określenie wymagań stawianych systemowi. Może
obejmować opracowanie kilku modeli systemu,
pozwalających zrozumieć system.
Specyfikowanie wymagań
Szczegółowa definicja wymagań.
Zatwierdzenie wymagań
Sprawdzenie spójności i kompletności wymagań
Ogólny model procesu
projektowania
Informacje wejściowe
Czynności projektowe
Projekt
Platforma
Specyfikacja
wymagań
Dane
Projektowanie
architektury
Projektowanie
interfejsu
Projektowanie
komponentów
Projektowanie
struktur danych
Architektura
systemu
Specyfikacja
struktur danych
Specyfikacja
interfejsu
Specyfikacja
komponentów
Czynności projektowe
Projektowanie architektury
Definiowanie ogólnej struktury systemu, głównych
komponentów (podsystemów, modułów), relacji
między nimi i ich rozmieszczenie.
Projektowanie interfejsu
Definiowanie interfejsu między komponentami.
Projektowanie struktur danych
Definiowanie struktur danych (być może bazy
danych)
Projektowanie komponentów
Przypisanie usług do komponentów. Ewentualnie
poszukiwanie komponentów wielokrotnego użycia.
Implementacja systemu
Implementacja polega albo na programowaniu
komponentów albo konfigurowaniu gotowego systemu.
W większości przypadków implementacja i
projektowanie przeplatają się.
Programowanie jest czynnością indywidualną i nie
istnieje żaden ogólny proces postępowania. Niektórzy
programiści zaczynają od komponentów, które najlepiej
rozumieją, inni postępują odwrotnie. Niektórzy
programiści lubią jak najszybciej definiować struktury
danych, inni pozostawiają dane bez specyfikacji tak
długo, jak to jest możliwe.
Programiści wykonują pewne testy kodu i usuwają błędy.
Zatwierdzanie systemu
Zatwierdzanie systemu, lub ogólniej weryfikacja i
zatwierdzanie (W & Z) mają wykazać, że system jest zgodny
ze swoją specyfikacją (W) i spełnia oczekiwania klienta (Z).
Istnieją dwie metody, z których można skorzystać w trakcie
procesu W & Z: kontrole oprogramowania i testowanie.
Kontrole oprogramowania polegają na analizie treści
programu. Jest to metoda statyczna.
Testowanie polega na uruchamianiu implementacji
oprogramowania na danych testowych. Jest to metoda
dynamiczna.
Kontrole oprogramowania i testowanie nie wykluczają się.
Fazy testowania
Testowanie
jednostek
Testowanie
modułów
Testowanie
podsystemów
Testowanie
systemu
Testowanie
odbiorcze
Fazy testowania
Testowanie jednostek
Testowanie poszczególnych komponentów. Każdy z nich jest
testowany oddzielnie.
Testowanie modułów
Moduł jest kolekcją niezależnych komponentow. Mogą to być
klasy obiektów lub zbiorem procedur i funkcji.
Testowanie podsystemów
Testujemy kolekcje modułów. Głównym problemem są interfejsy.
Testowanie systemu
Ma wykryć błędy wynikające z nieprzewidzianych interakcji
między podsystemami.
Testowanie odbiorcze
Testowanie przy użyciu danych dostarczonych przez klienta.
Dwie zasady
Poza testowaniem jednostek, procesu
testowania nie powinni wykonywać
twórcy oprogramowania.
Testowanie jest procesem destrukcyjnym!
Testowanie powinno odbywać się na
prawdziwych danych.
To nie zawsze jest możliwe.
Fazy testowania w zaplanowanym
procesie tworzenia oprogramowania
Plan testów
integracji
systemu
Plan testów
integracji
podsystemów
Plan
testów
odbiorczy
ch
Specyfikacja
wymagań
Specyfikacja
systemu
Projekt
szczegółowy
Projekt
systemu
Kod jednostek
i modułów oraz
ich test
Test integracji
podsystemu
Test integracji
systemu
Test
odbiorczy
Działanie
Pielęgnacja
oprogramowania
Pielęgnacja (ewolucja) oprogramowania dotyczy jego
modyfikacji po oddaniu do użycia.
Dwa rodzaje modyfikacji:
Poprawa błędów.
Zmieniające się wymagania stawiane systemowi.
Chociaż istnieje rozgraniczenie pomiędzy procesem
tworzenia oprogramowania a procesem jego ewolucji,
warto oba procesy traktować łącznie.
Budżet przeznaczony na oprogramowanie w dużych
firmach na pielęgnację istniejących programów jest dużo
większy niż budżet przeznaczony na nowe systemy
informatyczne.
Pielęgnacja systemu
Zdefiniuj
wymagania
stawiane
systemowi
Zbadaj istniejące
systemy
Istniejące
systemy
Zaproponuj zmiany
Zmodyfikuj
system
Nowy system
Inżynieria zmian
Zmiany w oprogramowaniu są nieuniknione.
Użytkowanie oprogramowania może wymuszać nowe
wymagania.
Następują zmiany w firmie używającej oprogramowanie.
Istnieje potrzeba poprawy błędów.
Może nastąpić zmiana sprzętu.
Może istnieć potrzeba poprawy efektywności.
Zmiany mogą wymagać przerobienia istniejących
fragmentów systemu, jak i zaimplementowanie
nowych funkcjonalności.
Redukowanie kosztu zmian
Przewidywanie możliwości zmian w
procesie tworzenia oprogramowania
Na przykład konstruowanie prototypów
(makiet) pokazujących klientowi kluczowe
własności systemu.
Tolerowanie zmian polegające na
wyborze procesu, w którym zmiany są
stosunkowo tanie.
To podejście realizowane jest przez procesy
przyrostowe. Kolejnym zmianom
odpowiadają kolejne wersje systemu.
Prototypowanie
Prototyp jest początkową wersją oprogramowania,
która służy do prezentacji założeń oraz
wypróbowania różnych wariantów projektu, a
bardziej ogólnie do coraz lepszego poznawania
problemu i jego możliwych rozwiązań.
Bardzo ważne jest szybkie stworzenie prototypu,
ponieważ umożliwia użytkownikom eksperymenty z
systemem we wczesnej fazie jego budowy.
Prototyp jest przydatny w procesie specyfikacji
wymagań, w projektowaniu interfejsu użytkownika
oraz w procesie testowania (testowanie różnicowe –
ang. back-to-back testing).
Korzyści z prototypowania
Zwiększona użyteczność systemu
Lepsze dostosowanie systemu do
potrzeb użytkowników.
Zwiększona jakość projektu.
Większa zdatność do pielęgnacji.
Zmniejszony wysiłek twórczy.
Prototypowanie
Prototypowanie nie musi oznaczać zwiększenia
kosztów systemu.
Prototypowanie zwiększa zwykle koszty we
wczesnej fazie budowy oprogramowania, ale za to
zmniejsza je w późniejszym okresie. Przyczyną tego
faktu jest uniknięcie powtarzania prac wytwórczych,
ponieważ klienci zgłaszają mniej zmian.
Negatywną konsekwencją prototypowania może być
mniejsza efektywność, jeśli przy tworzeniu
ponownie wykorzysta się nieefektywny rdzeń
prototypu.
Proces budowy prototypu
Plan
prototypowania
Zdefiniuj
funkcjonalność
prototypu
Określ cele
prototypu
Zbuduj prototyp
Oceń prototyp
Ogólna
definicja
Wykonywalny
prototyp
Raport o ocenie
prototypu
Proces budowy prototypu
Określanie celów prototypu
Celem może być opracowanie prototypu interfejsu użytkownika,
budowa prototypu w celu zatwierdzenia wymagań
funkcjonalnych lub wykazania kierownictwu, że system jest
wykonalny.
Definiowanie funkcjonalności prototypu
Co uwzględnić i, co ważniejsze, czego nie uwzględniać w
prototypowym systemie.
Warto skupić się na najmniej zrozumiałych elementach
budowanego oprogramowania. Można pominąć większość
wymagań niefunkcjonalnych.
Ocena prototypu
Negatywna ocena będzie wymagać powtórzenia pewnych prac
nad systemem, na przykład specyfikacji wymagań.
Porzucanie prototypów
Po wypełnieniu swej funkcji, prototyp powinien
być porzucony, ponieważ nie jest dobrą bazą dla
budowanego oprogramowania:
Konstrukcja prototypu może uniemożliwiać jego
rozbudowę tak, aby spełnić wszystkie wymagania
niefunkcjonalne.
Prototypy zwykle są słabo udokumentowane.
Prototypy mają często zdegradowaną strukturę
ponieważ są szybko budowane i przez to narażone na
liczne zmiany w trakcie budowy.
Proces budowy prototypu na ogół nie spełnia
standardów wymaganych w firmie wytwórczej.
Przyrostowe dostarczanie
oprogramowania
Polega na dostarczaniu użytkownikowi
kolejnych wersji systemu. Nowa wersja
rozszerza funkcjonalność wersji poprzedniej.
Wymaganiom użytkownika
przyporządkowuje się priorytety. Wymagania
o wysokich priorytetach realizowane są przez
wczesne wersje.
Rozpoczęcie budowy kolejnej wersji
powoduje „zamrożenie” dalszych wymagań.
Przyrostowe tworzenie vs.
przyrostowe dostarczanie
oprogramowania
Przyrostowe tworzenie oprogramowania
Oprogramowanie tworzone jest etapami. Kolejny
przyrost realizowany jest po ocenie poprzedniej wersji.
Metodologia stosowana w programowaniu zwinnym.
Ocenę przeprowadzają reprezentanci klienta i firmy
wytwórczej.
Przyrostowe dostarczanie oprogramowania
Wersja uzyskana poprzez realizacji kolejnego przyrostu
dostarczana jest użytkownikom do eksploatacji.
Ułatwia definiowanie nie zrealizowanych jeszcze
wymagań.
Pozwala rozpocząć pracę bez konieczności dokładnej
specyfikacji wymagań.
Przyrostowe dostarczanie
oprogramowania
Zdefiniuj zarys
wymagań
Przypisz
wymagania
do przyrostów
Zaprojektuj
architekturę
systemu
Wytwórz przyrost
systemu
Zatwierdź
przyrost
Zintegruj
przyrost
Zatwierdź
system
Dostarcz
system
System
ukończony
System
nieukończony
System
Zalety przyrostowego
dostarczania
oprogramowania
Klienci nie muszą czekać na dostarczenie całego
systemu. Pierwszy przyrost spełnia najbardziej
istotne wymagania, oprogramowanie może więc
być natychmiast uzywane.
Wstępne przyrosty mogą być używane jako
prototyp służący do redefiniowania dalszych
przyrostów.
Zmniejsza się ryzyko całkowitej porażki
przedsięwzięcia.
Najważniejsze usługi będą dostarczane jako
pierwsze, a wię będą najlepiej przetestowane.
Wady
przyrostowego
dostarczania
oprogramowania
Większość systemów wymaga podstawowych
funkcjonalności, używanych przez różne części
systemu.
Skoro wymagania nie są szczegółowo zdefiniowane
przed implementacją przyrosty, trudno jest
zidentyfikować funkcjonalności potrzebne wszystkim
przyrostom.
Esencją procesów przyrostowych jest równoległe
wytwarzanie oprogramowania i jego specyfikacji.
W wielu przypadkach jest to nieakceptowalne, ponieważ
specyfikacja wymagań jest częścią kontraktu.
Ulepszanie procesu
wytwarzania
oprogramowania
W wielu firmach programistycznych pojawiło
się w ostatnich znaczne zainteresowanie
ulepszaniem procesu wytwórczego.
Ulepszanie procesu polega na analizie dotąd
stosowanych procesów i ich modyfikacji w
taki sposób, aby poprawić jakość produktu
lub zmniejszyć koszt lub czas tworzenia.
Podejścia do ulepszania
procesu
Podejście klasyczne (ang. process maturity
approach), które opiera się na ciągłym
wprowadzaniu dobrych praktyk do klasycznych
metod wytwarzania oprogramowania i
przestrzegania, że te praktyki są stosowane w
firmie. Podejście to nastawione jest przede
wszystkim na zwiększenie niezawodności produktu,
często kosztem pewnych dodatkowych narzutów.
Podejście zwinne, które opiera się na iteracyjnym
wytwarzaniu oprogramowania i redukowaniu
pewnych elementów w procesie wytwórstwa.
Podejście to nastawione jest przede wszystkim na
przyspieszenie budowy produktu.
Cykl ulepszania procesu
Miernictwo
procesu
Analiza
Zmiany
Czynności ulepszania
procesu
Miernictwo procesu
Mierzymy jeden lub kilka atrybutów procesu. Miary
mają pomóc w ocenie, czy dotychczasowe zmiany
procesu są efektywne.
Analiza
Próba identyfikacji słabości procesu.
Zmiany
Propozycja przedefiniowania procesu wytwarzania
oprogramowania, aby wyeliminować słabości
procesu. Następnie cykl ulepszania procesu powtarza
się.
Miernictwo procesu
Miernictwo procesu daje ilościowe dane o
procesie tworzenia oprogramowania.
Miernictwo procesu zakłada, precyzyjną definicję
samego procesu. W przeciwnym przypadku nie
bardzo wiadomo co powinno być mierzone.
Miary związane z procesem stanowią jedynie
wskazówkę o potrzebnych zmianach. Kluczową
rolę odgrywają tu potrzeby i cele firmy tworzącej
oprogramowanie.
Klasy miar procesowych
Czas potrzebny na ukończenie procesu lub
jego etapów.
Może to być czas całkowity, czas kalendarzowy, czas
spędzony przez konkretnych inżynierów.
Zasoby niezbędne w konkretnym procesie.
Mogą to być osobo-dni, koszty podróży, zasoby
komputerowe, zasoby w postaci narzędzi
pomocniczych.
Liczba wystąpień konkretnego zdarzenia.
Na przykład liczba defektów odkrytych w trakcie
kontroli kodu, liczba żądanych zmian wymagań,
średnia liczba wierszy kodu zmodyfikowanego w
odpowiedzi na zmianę wymagań.
SEI CMMI
Software Engineering Institute (SEI) w Cornegie-Mellon
University jest instytutem utworzonym przez
Departament Obrony Stanów Zjednoczonych.
Instytut został stworzony, aby zwiększyć zdolności
przemysłu informatycznego w Stanach Zjednoczonych, a
w szczególności tych przedsiębiorstw, które otrzymują od
Departamentu Obrony fundusze na wielkie
przedsięwzięcia wojskowe.
Jednym z wczesnych przedsięwzięć SEI był SEI CMM
(Capability Maturity Model – model dojrzewania
zdolności). Model ten wywarł ogromny wpływ na
przekonanie społeczności inżynierów oprogramowania do
poważnego traktowania ulepszania procesu. Prace nad
modelem rozpoczęły się w połowie lat 90. W 2001
powstała uaktualniona wersja modelu, znana jako CMMI
(Capability Maturity Model Integration). W 2013 w SEI
został wyodrębniony instytut zajmujący się wyłącznie tym
modelem.
Model dojrzewania zdolności
CMM
Firmy wytwórcze podzielono na pięć różnych
poziomów
Poziom początkowy.
Firma na tym poziomie nie ma skutecznych procedur
zarządzania. Wytworzone oprogramowanie jest
nieprzewidywalne.
Poziom powtarzalny.
Firma na tym poziomie wdrożyła już formalne
zarządzanie, zapewnienie jakości i zarządzanie
konfiguracjami. Firma może z powodzeniem powtarzać
przedsięwzięcia tego samego rodzaju. Brakuje jednak
formalnego modelu procesu. Powodzenie
przedsięwzięcia zależy od tego jak menedżerowie
umotywowali zespół i od firmowego folkloru, który
stanowi intuicyjny opis procesu.
Model dojrzewania zdolności
CMM
Poziom zdefiniowany.
Firma na tym poziomie zdefiniowała już swój proces, ma
więc podstawy do ilościowego ulepszania procesu.
Wdrożono formalne procedury zapewniania, że ten
zdefiniowany proces jest przestrzegany we wszystkich
przedsięwzięciach realizowanych w firmie.
Poziom zarządzany.
Firma na tym poziomie zdefiniowała już swój proces i
formalny program zbierania danych ilościowych.
Gromadzi się pomiary procesu i produktów, które są
podstawą ulepszania procesu.
Poziom optymalizowany.
Firma na tym poziomie jest zaangażowana w ustawiczne
ulepszanie procesu. Ulepszanie ma swój budżet oraz
plan i jest integralną częścią procesu przedsiębiorstwa.
Podsumowanie
Procesy tworzenia oprogramowania to czynności
zmierzające do wyprodukowania systemu. Modele
procesów tworzenia oprogramowania to abstrakcyjne
reprezentacje tych procesów.
Inżynieria wymagań to proces opracowywania specyfikacji
oprogramowania.
Proces projektowania i implementowania polega na
przekształceniu specyfikacji wymagań w działający system.
Zatwierdzanie oprogramowania to proces sprawdzaia, czy
system jest zgodny ze swoją specyfikacją oraz czy spełnia
rzeczywiste potrzeby użyrkowników.
Pielęgnacja oprogramownia polega na modyfikowaniu
istniejącego systemu, tak aby usunąć błędy lub
dodać/zmodyfikować wymagania.
Podsumowanie
Prototypowanie oraz przyrostowe dostarczanie
oprogramowania to podstawowe techniki
redukujące koszt zmian w trakcie budowy
oprogramowania.
Model dojrzewania zdolności CMM pozwala
podzielić firmy programistyczne na pięć
kategorii względem jakości ich procesów
wytwórczych.