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.