Proces wytwarzania oprogramowania

Proces wytwarzania
oprogramowania
Proces wytwarzania
oprogramowania
• Proces wytwarzania oprogramowania (zwany również
cyklem wytwarzania oprogramowania) to proces tworzenia
lub rekonstrukcji systemu informatycznego wraz z modelami
i metodologiami używanymi w jego realizacji
• Wybrane etapy procesu wytwarzania oprogramowania:
–
–
–
–
–
–
Specyfikacja wymagań
Analiza
Projektowanie
Implementacja
Testowanie
Wdrożenie i pielęgnacja
Motywacja
• Programy z początku ery informatyki były nieskomplikowane,
tworzone zazwyczaj do celów naukowych przez przyszłych
użytkowników
• Rozwój sprzętu komputerowego i języków programowania
sprawił, że zaczęto tworzyć bardziej złożone systemy
przeznaczone dla szerszego grona odbiorców
• Na pewnym etapie zauważono, że o sukcesie projektu
informatycznego decydują nie tylko umiejętności programistów,
ale i praca całego zespołu oraz w dużej mierze organizacja
samego procesu wytwarzania oprogramowania
Motywacja
• Konkurencja wymusiła poszukiwanie nowych sposobów na
poprawę efektywności procesu wytwarzania
oprogramowania
• W efekcie powstało wiele modeli opisujących cykl życia
systemu informatycznego i sposób realizacji procesu
wytwórczego
• Na bazie tych modeli powstały tzw. metodyki projektowe
(zestaw metod i procedur pozwalających zespołowi
projektowemu realizować cykl życia systemu)
Cykle życia i wytwarzania
• Cykl życia systemu informatycznego – szereg wzajemnie
zależnych etapów, począwszy od ujawnienia potrzeby budowy
systemu informatycznego, prezentacji jego idei, konstrukcję,
użytkowanie, przystosowane do ewentualnych zmian
funkcjonowania a kończąc na wycofaniu z eksploatacji
• Cykl wytwarzania systemu informatycznego – fragment cyklu
życia SI związany z procesem wytwórczym oprogramowania
• Cykl życia projektu – okres od początku do zakończenia
projektu informatycznego
Przeznaczenie modeli cyklu
wytwarzania SI
• Formalnie określony sposób realizacji projektu (plan
projektu, metodologia budowy systemu)
• Uporządkowanie przebiegu prac
• Ułatwienie planowania zadań
• Monitorowanie przebiegu realizacji zadań
Podstawowe modele cyklu
życia SI
•
•
•
•
•
•
Kaskadowy
Przyrostowy
Spiralny
Prototypowanie
Programowanie odkrywcze
Montaż z gotowych elementów
Model kaskadowy
(wodospadu)
Specyfikacja
wymagań
Analiza
Projektowanie
Implementacja
Testowanie
Wdrożenie
Model kaskadowy
(wodospadu)
• Stosowany w projektach o dobrze zdefiniowanych
wymaganiach
• Etapy realizowane są w ściśle określonej kolejności
• Etap musi być zakończony przed przejściem do następnego
• Modele, projekty, kod lub dokumentacja wytworzone w
danym etapie przekazywane są do następnego etapu
Model kaskadowy
Zalety
• Naturalny zrozumiały i
dobrze zdefiniowany ciąg
kroków oraz dokumentów
i produktów, które należy
wytworzyć w każdym
kroku
• Łatwość zarządzania
projektem (ułatwia
planowanie,
harmonogramowanie
oraz monitorowanie)
Wady
• Silnie zależy od
stabilności wymagań
• Weryfikacja zgodności z
wymaganiami dopiero w
końcowych etapach
• Marginalizacja roli klienta
• Wysokie koszty naprawy
błędów
Model kaskadowy z
iteracjami
Specyfikacja
wymagań
W modelu kaskadowym z
iteracjami jest możliwość
powrotu do każdego z
wcześniejszych etapów.
Zaleca się by iteracje były z góry
zaplanowane
Analiza
Projektowanie
Implementacja
Testowanie
Wdrożenie
Model kaskadowy kierowany
dokumentami
•
•
•
•
Model opracowany przez armię amerykańską
Bazuje na modelu kaskadowym
Każdy etap kończy się opracowaniem dokumentacji
W tradycyjnym modelu kaskadowym dokumentacja jest
warunkiem przejścia do kolejnego etapu
• W modelu kierowanym dokumentami potrzebna jest jeszcze
akceptacja klienta
• Dodatkową zaletą jest możliwość przerwania realizacji projektu w
jednej firmie i wznowienie realizacji w innej (po przekazaniu jej
kompletu dokumentów)
• Dodatkowe wady polegają na przestojach związanych z analizą
dokumentacji przez klienta oraz dużym nakładzie pracy na
opracowanie dokumentów
Model przyrostowy
• Rozpoczyna się od specyfikacji wymagań i wykonania
wstępnego projektu (architektury)
• Następnie wybierany jest pewien podzbiór wymagań i
następuje jego realizacja (przyrost), czyli szczegółowa
analiza, projektowanie, implementacja i testowanie
• W efekcie powstaje wersja systemu, która może być
dostarczona i wdrożona u klienta
• W kolejnej iteracji wybierany jest kolejny podzbiór wymagań
i następuje jego realizacja
• Iterację wykonywane są do momentu realizacji wszystkich
wymagań
Model przyrostowy
Proces realizowany
iteracyjnie
Określenie wymagań
Projekt ogólny
Wybór podzbioru
funkcji
Projekt szczegółowy,
implementacja i testy
Dostarczenie
zrealizowanej
części systemu
Model przyrostowy
Zalety
• Szybka implementacja
funkcjonalności
priorytetowych lub
obarczonych dużym
ryzykiem
• Możliwość wczesnego
wdrożenie
• Skrócenie przerw w
kontaktach z klientem w
porównaniu do modelu
kaskadowego
Wady
• Problem z
wyodrębnieniem w miarę
niezależnych grup
funkcjonalności
• Konieczność wytworzenia
dodatkowych modułów
niezbędnych do działania
kolejnej wersji
Model spiralny
• Planowanie – nakreślenie możliwych opcji (alternatyw)
kolejnego wydania systemu na podstawie wymagań
wstępnych lub celów wyznaczonych przez klienta
• Analiza ryzyka – identyfikacja źródeł ryzyka i szacownie
wielkości ryzyka dla każdej z możliwych alternatyw
kolejnego wydania systemu
• Konstrukcja – wytworzenie kolejnego wydania systemu
(„mały” wodospad – analiza, projektowanie, implementacja,
test i wdrożenie)
• Testowanie – ocena kolejnego wydania systemu i
wskazanie nowych wymagań lub modyfikacja istniejących
Model spiralny
PLANOWANIE
ANALIZA RYZYKA
Wymagania
początkowe
Planowanie na
podstawie wyniku
oceny klienta
Ocena klienta
TESTOWANIE
Analiza ryzyka dla
wymagań początkowych
Analiza ryzyka w
oparciu o reakcję
klienta
Kolejne wydania
KONSTRUKCJA
(„mini” model kaskadowy)
Model spiralny
Zalety
• Szybka reakcja na
pojawiające się ryzyka i
oczekiwania klienta
• Ciągła weryfikacja
produktu przez klienta
zwiększa szanse na
wytworzenie
satysfakcjonującego
rozwiązania
Wady
• Wymagana umiejętność
szacowania ryzyka
projektu informatycznego
Prototypowanie
• Polega na budowaniu kolejnych przybliżeń systemu aż
prototyp stanie się w pełni funkcjonalnym systemem
• Każdy kolejny prototyp jest oceniany przez klienta i wynik tej
oceny trafia do projektantów
• Po akceptacji prototypu przez klienta następuje pełna
specyfikacja wymagań i realizacja systemu w modelu
kaskadowym
• Ponieważ podstawowym zadaniem prototypu jest pomoc w
lepszym określeniu wymagań, budowę i weryfikację
prototypu można uznać za specyficzny sposób realizacji
fazy określania wymagań tradycyjnego modelu
kaskadowego.
Prototypowanie
Ogólne określenie
wymagań
Budowa
prototypu
nie
Weryfikacja
przez klienta
tak
Pełne określenie
wymagań
Realizacja pełnego
systemu
Prototypowanie
Zalety
Wady
• Pozwala uściślić wymagania i
uniknąć błędu ich niewłaściwej
specyfikacji
• Możliwe do stosowania w
przypadku, gdy są problemy w
jednoznacznym ustaleniu
wymagań
• Wczesne wykrycie
ewentualnych nieporozumień
pomiędzy klientem a wytwórcą
• Dodatkowy koszt budowy
prototypu (tylko niewielkie
fragmenty prototypu można
wykorzystać w właściwym
systemie)
• Nieporozumienia z klientem
wynikające z długiego czasu
oczekiwania na działający
system w porównaniu z bardzo
krótkim okresem wytwarzania
prototypu
Metody budowy prototypu
• Realizacja tylko „trudnych” funkcjonalności
• Języki wysokiego poziomu (Lisp, Smalltalk, Prolog) i
specjalizowane języki prototypowania
• Wykorzystanie gotowych komponentów
• Generatory interfejsu użytkownika, generatory
oprogramowania, narzędzia typu CASE,
• Szybkie programowanie, tj. tylko kod, bez testowania
Programowanie odkrywcze
•
•
•
•
Rozpoczyna się od bardzo ogólnego określenia wymagań
Następnie budowany jest system (nie prototyp!)
System jest weryfikowany przez klienta
W przypadku negatywnej oceny tworzona jest nowa wersja
na bazie poprzedniej
• Proces kończy się z chwilą gdy jedna z wersji zostanie
zaakceptowana przez klienta
Programowanie odkrywcze
Ogólne określenie
wymagań
Budowa
systemu
Przetestuj
system
nie
System
działa
poprawnie
tak
Dostarcz system
Programowania odkrywcze
Zalety
• Możliwość stosowania
nawet w przypadku
trudności w ustaleniu
wstępnych wymagań
Wady
• Problem z zachowaniem
sensownej struktury
systemu praktycznie
uniemożliwia realizację
większych, niezawodnych
systemów
• Konieczność testowania
przy współudziale klienta,
bo model nie przewiduje
pełnego określenia
wymagań
Montaż z gotowych
elementów
• Polega na wykorzystywaniu gotowych elementów w
tworzonym systemie
• Gotowe elementy mogą być wykorzystywane na dowolnym
etapie projektu
• Zwykle gotowe elementy wykorzystuje się na etapie
implementacji
• Istnieje również możliwość wykorzystania gotowych modeli
funkcjonowania pewnych typów organizacji (tzw.
designware)
• Gotowym elementem mogą być modele, projekty,
komponenty stworzone w ramach wcześniejszych projektów
• Gotowe elementy można też nabyć od innych dostawców
Montaż z gotowych elementów
Zalety
• Wysoka niezawodność
• Redukcja kosztów
• Efektywne wykorzystanie
specjalistów
Wady
• Konieczność
przygotowania gotowego
elementu do użycia w
nowym systemie
• Możliwość uzależnienia
od dostawcy gotowego
elementu
Który model wybrać?
• Model odkrywczy – prosty problem, system na własny
użytek
• Model kaskadowy lub montaż z gotowych elementów –
wymagania dobrze wyspecyfikowane, doświadczenie w
realizacji podobnych projektów
• Prototypowanie – problem ze specyfikacją wymagań
Rational Unified Process
• Rational Unified Process (RUP) to proces iteracyjnego
wytwarzania oprogramowania opracowany przez firmę
Rational Software Corporation (firma została obecnie
przejęta przez IBM)
• Proces RUP nie jest pojedynczym, ściśle określonym
procesem, ale raczej szablonem procesu
Rational Unified Process
• Został zaprojektowany w celu przystosowania do charakteru
konkretnej organizacji, konkretnego zespołu projektowego
lub nawet charakteru konkretnego projektu
• Z szablonu RUP można wybrać elementy w zależności od
konkretnych potrzeb
Rational Unified Process
• Rational Unified Process (RUP) to także nazwa
oprogramowania, opracowanego przez Rational Software
(obecnie dostępnego w IBM) zawierającego hipertekstową
bazę wiedzy z przykładowymi artefaktami oraz
szczegółowymi opisami wielu typów czynności
• Process RUP definiowany jest także w produkcie Rational
Method Composer (RMC), który pozwala na tworzenie
spersonalizowanych wersji RUP
Iteracyjne wytwarzanie
oprogramowania
• Wytwarzanie oprogramowania w kolejnych iteracjach,
pozwala skupić się w pierwszej kolejności na obszarach
najbardziej ryzykownych (np. najmniej rozpoznanych)
• W idealnym przypadku każda iteracja kończy się
stworzeniem wykonywalnego artefaktu - pomaga to
zredukować ryzyko w projekcie, otrzymujemy szybciej
opinie od odbiorców oprogramowania a programistom
pozwalamy skupić się na węższej dziedzinie
Architektura bazująca na
komponentach
• Pozwala na stworzenie systemu, który jest łatwo
rozszerzalny, intuicyjnie zrozumiały i wspomaga ponowne
użycie (komponent to zbiór powiązanych obiektów)
• RUP skupia się na stworzeniu prostej architektury w
początkowych iteracjach
• Ewoluuje ona w każdej iteracji zbliżając się do architektury
finalnej
• Poprzez iteracyjne wytwarzanie oprogramowania zyskujemy
możliwość stopniowej identyfikacji komponentów, które
mogą być w dalszej części: zakupione, zbudowane, lub
użyte ponownie
Wizualne modelowanie
oprogramowania
• Abstrakcja projektowania od kodu i przedstawienie
koncepcji za pomocą bloków graficznych może być
efektywnym sposobem aby pokazać perspektywę
rozwiązania
• Reprezentacja graficzna jest produktem pośrednim
pomiędzy analizą procesu biznesowego, a implementacją
• Model w tym kontekście jest formą wizualizacji oraz
uproszczeniem bardziej skomplikowanego projektu
• RUP specyfikuje wymagane modele i opisuje dlaczego są
wymagane
Kontrola i weryfikacja
jakości oprogramowania
• Ocena jakości jest najczęstszym słabym punktem projektów
programistycznych ponieważ jest często planowana po
fakcie budowy systemu i czasami obsługiwana przez inny
zespół
• RUP pomaga w planowaniu kontroli jakości i jej ocenie
poprzez wbudowanie jej w cały proces i zaangażowanie w
nią wszystkich członków zespołu
• Proces koncentruje się na spełnieniu wymaganego poziomu
jakości i zapewnia mechanizmy do pomiaru tego poziomu
Zarządzanie zmianami w
oprogramowaniu
• RUP definiuje metody śledzenia, ewidencji i kontroli zmian
• Zdefiniowane są także tzw. secure workspaces (bezpieczne
przestrzenie robocze), które pozwalają na
zagwarantowanie, że zmiany w innych systemach nie
wpłyną na system tworzony
• Koncepcja ta jest ściśle powiązana z tworzeniem
architektury zorientowanej komponentowo
Struktura organizacyjna
• RUP proponuje strukturę zespołów w dwóch obszarach
– biznesowym (business unit)
– projektowym
• Zadaniem zespołu biznesowego jest koordynowanie funkcji i
zasobów wykorzystywanych w wielu projektach z
zastosowaniem wspólnej technologii i zasad
Zalety RUP
• RUP jest procesem iteracyjnym zakładającym budowanie
systemu w kolejnych przebiegach
• Po zakończeniu iteracji produkowany jest fragment systemu
spełniający wymagania klienta, jest on następnie
udostępniany
• W ten sposób zespół analityczno-projektowy otrzymuje
szybko sygnał zwrotny od klienta, który umożliwia bieżącą
ocenę ryzyka niepowodzenia projektu jak również pozwala
stwierdzić czy zespół analityczno-projektowy dobrze
zrozumiał wymagania klienta wobec systemu
Zalety RUP
• W razie wystąpienia problemów zostaną one szybko
wykryte i zespół analityczno-projektowy będzie mógł
wdrożyć odpowiednie postępowanie zaradcze
• Podejście iteracyjne powoduje gwałtowną redukcję ryzyka
niepowodzenia projektu już po zakończeniu pierwszej
iteracji
Wady RUP
•
•
•
•
•
Rup to metodyka ciężka i kosztowna
Wymaga obszernego dokumentowania procesu
Ogranicza inicjatywę i samodzielność
Wysokie koszty administracyjne
Sztywne procedury (np. audytu)
Metodyka PRINCE2
• Projects in a Controlled Environment tzn. Projekty w
sterowanym środowisku
• 1989 - brytyjska agenda rządowa Central Computer and
Telecommunications Agency (CCTA) opublikowało standard
pod nową nazwą – PRINCE
• 1996 - PRINCE2 opublikowany jako ogólna metoda
zarządzania projektami niezależna od dziedziny biznesowej
zastosowania
• 2005 - ostatnie zmiany opublikowane przez Office for
Government Commerce (OGC) – następcę CCTA
Uruchamianie projektu
• Przygotowanie projektu do uruchomienia
• Ma zapewnić, że projekt będzie wart ponoszonych kosztów i
że da się go zrealizować
• Informacją wejściową dla procesu jest Zlecenie
Przygotowania Projektu (Project Mandate)
• W proces zaangażowane jest wyższe kierownictwo
organizacji, które ustanawia i wybiera Komitet Sterujący
(Project Board), który nadzoruje projekt i wybiera
Kierownika Projektu
Zarządzanie strategiczne
projektem
• Realizuje funkcje, za które odpowiedzialny jest Komitet
Sterujący
• Kierownik Projektu informuje Komitet Sterujący w raportach
okresowych o stanie projektu
• Bieżące zarządzanie pozostawione jest w wyłącznej
kompetencji Kierownika Projektu
Zarządzanie wytwarzaniem
produktów
• PRINCE2 to metodyka oparta na produktach; produktem
może być rzecz materialna np. książka
• Może nim być też rzecz bardziej niematerialna np. poziom
usług serwisowych
• W zasadzie wszystko, co zostało wytworzone przez projekt
zgodny z PRINCE2, włączając w to dokumenty jest
produktem
• Produkt może być wytworzony przez kogokolwiek, także
przez zewnętrznego dostawcę.
Zamykanie projektu
• Według metodyki PRINCE2 projekty muszą być zamykane
w sposób uporządkowany i kontrolowany
• Wszystkie doświadczenia zdobyte w trakcie prowadzenia
projektu są rejestrowane, tworzony jest dokument
przekazania i planowany jest przegląd powdrożeniowy
• Po zakończeniu projektu w zaplanowanym momencie
pozwalającym na należytą ocenę skutków biznesowych
projektu przeprowadzany jest przegląd poprojektowy
Jakość w środowisku
projektowym
• Celem projektu jest wytworzenie produktów, zgodnych z ich
przeznaczeniem, zaspokajających potrzeby oraz
oczekiwania jakościowe klienta
• Oczekiwania jakościowe są określone w Zleceniu Projektu
(Project Mandate), Założeniach Projektu (Project Brief) oraz
Dokumencie Inicjującym Projekt (Project Initiation
Document)
Sterowanie zmianami
• W PRINCE2 wszystkie zmiany są traktowane jako
zagadnienia projektowe:
– wnioski o zmianę – dotyczące zmiany w wymaganiach albo
produkcie
– odstępstwo – rejestrowane kiedy produkt nie spełnia wymagań.
– sugestie
– zapytania
– zagadnienia ogólne
Sterowanie zmianami
• Obsługa wszystkich zagadnień projektowych jest w gestii Kierownika
Projektu
• Ich zgłoszenia muszą być udokumentowane w Rejestrze zagadnień
(Issue Log)
• Wnioski o zmianę muszą być zaakceptowane przez Komitet Sterujący
lub Komitet ds. zmian (Change Authority)
• Przed akceptacją zmiany musi być wykonana analiza wpływu zmiany
• Odstępstwa (Off specification) mogą być załatwiane w ramach działań
korygujących przez Kierownika Projektu o ile nie wykraczają one poza
określone dla projektu granice tolerancji
• Komitet Sterujący może zaakceptować odstępstwa bez uruchamiania
działań korygujących definiując je jako ustępstwo
Mocne strony PRINCE2
• Stosowanie tej metodyki zapewnia wysoką standaryzację i
powtarzalność projektów o wspólnym podejściu, terminologii
i dokumentacji co zapewnia możliwość doskonalenia
kompetencji
• Metodyka w sposób racjonalny opiera się na najlepszych
praktykach w zarządzaniu projektami
• Wprowadza management by exception jako podstawową
zasadę, która zapewnia Kierownikowi Projektów swobodę
działania bez zbędnej ingerencji, zapewniając jednocześnie
zaangażowanie wyższego kierownictwa, wtedy kiedy projekt
jest zagrożony wykroczeniem poza granice tolerancji lub
przestaje realizować uzasadnienie biznesowe
Mocne strony PRINCE2
• Sprawuje kontrolę nad startem, realizacją i końcem projektu
• Każdy z dokumentów wymaganych przez PRINCE2 jest
dostarczony jako szablon zawierający wymagane metrykę,
rozdziały i pola informacyjne co zapewnia przejrzystość,
standaryzację i kompletność dokumentacji
• Przewiduje możliwość adaptacji do specjalnych potrzeb
organizacji, programu lub projektu
• Jej stosowanie nie wymaga opłat autorskich
• Materiały PRINCE2 są opublikowane i szeroko dostępne co
ogranicza prace nad wypracowywaniem własnych
standardów i przygotowaniem materiałów szkoleniowych
Słabości PRINCE2
• Dużo organizacji cierpi na syndrom PINO (Prince In Name
Only tzn. PRINCE2 tylko z nazwy), wybierając bez głębszej
analizy tylko niektóre składniki metodyki nie zwracając
uwagi na podstawowe zasady
• PRINCE2 kładzie duży nacisk na dokumentowanie jako
narzędzie sprawnej kontroli sposobu realizacji projektu
• W niektórych organizacjach dokumenty stają się jednak
celem samym w sobie, a rzeczywiste projekty kończą się
niepowodzeniem
Słabości PRINCE2
• Podobnie uwaga jaką zwraca PRINCE2 na potrzebę dobrej
organizacji i regularną wymianę informacji pomiędzy
zainteresowanymi odbierana jest niesłusznie jako zachęta
do ciągłych bezproduktywnych spotkań zabierających czas
niezbędny na rzeczywistą pracę
• PRINCE2 nie definiuje wprost analizy wymagań tak więc
może prowadzić do niepowodzenia projektu z uwagi na
przyjęcie fałszywych założeń (z drugiej strony jasno jest
określone, kto ponosi odpowiedzialność za przyjęcie złych
założeń i akceptację nietrafnego uzasadnienia biznesowego
a przesłanki tych decyzji są udokumentowane i mogą
stanowić nauczkę na przyszłość)
Słabości PRINCE2
• Zbyt ścisłe przestrzeganie PRINCE2 bez odpowiedniej
adaptacji do realiów biznesowych może być zbyt
pracochłonne w zastosowaniu do małych projektów
• Niezbyt "zwinna"
Krytyka podejścia
zorientowanego na procedury
i dokumenty
• Zbyt dużo czasu poświęca się na tzw. „papierkową robotę”
zamiast na tworzenie oprogramowania
• Dokumenty nie zawsze odzwierciedlają stan faktyczny,
powstają tylko dlatego że są wymagane
• Pracownicy koncentrują się na realizacji procesu a nie na
poprawie jakości tworzonego produktu
• Brak możliwości (lub zbyt duże koszty) zmian procedur (np.
po uzyskaniu określonego certyfikatu)
• Dyscyplina zabija inicjatywę i elastyczność
Narodziny programowania
ekstremalnego (XP)
• Jak odchudzić procesy wytwarzania oprogramowania przy
zachowaniu lub nawet polepszeniu jakości tworzonego
systemu?
• Powstanie lekkich (zwinnych, ang. Agile) metodyk rozwoju
oprogramowania
• Programowanie Ekstremalne (ang. Extreme Programming)
jako przykład lekkiej metodyki – Kent Beck – 1996-99
Charakterystyka lekkich
metodyk
• XP i inne lekkie podejścia, wyrosły na pragmatycznym
gruncie sukcesu tzw. "dobrych praktyk" programistycznych
• Praktyki te obejmują m. in.:
– aktywny udział klienta w pracach rozwojowych
– szybkie sprzężenie zwrotne pomiędzy formułowaniem wymagań
biznesowych a ich realizacją
– nieustanną pielęgnację jakości wytwarzanego oprogramowania
poprzez intensywne testowanie
– refaktoryzację* oraz konstrukcję efektywnego zespołu
Manifest zwinności (rok
2001)
• Kent Beck - twórca metody kart CRC stosowanej podczas
analizy obiektowej, autor narzędzi xUnit - wspomagających
testowanie jednostkowe oraz twórca XP
• Alistair Cockburn - autor rodziny zwinnych metodyk
Crystal, oraz książek poświęconych inżynierii wymagań
(głównie przypadkom użycia)
• Martin Fowler - twórca pomysłu refaktoryzacji, autor
świetnej książki „UML Distilled” (UML w kropelce)
• i inni…
Manifest zwinności
• Jednostki i interakcje są ważniejsze niż procesy i narzędzia
• Działające oprogramowanie jest ważniejsze niż obszerna
dokumentacja
• Współpraca z klientem jest ważniejsza niż negocjacja
kontraktu
• Nadążanie ze zmianami jest ważniejsze niż trzymanie się
planu
Wartości XP
•
•
•
•
•
Komunikacja
Prostota
Sprzężenie zwrotne
Odwaga
Szacunek
Komunikacja
• Budowanie systemów informatycznych wymaga
przekazania wymagań od klienta do programistów
• W tradycyjnych metodykach wykorzystuje się w tym celu
dokumenty (specyfikację wymagań)
• XP posługuje się komunikacją werbalną, dzięki czemu
wiedza o systemie bardzo szybko rozprzestrzenia się w
zespole
• Dzięki komunikacji wszyscy członkowie zespołu mają takie
samo wyobrażenie przyszłego systemu i wiedzą w jakim
kierunku projekt dąży
Prostota
• XP zachęca do rozpoczęcia najprostszym możliwym
rozwiązaniem problemu (minimalnym, spełniającym pewne
początkowe wymagania)
• Dopiero kiedy się upewnimy że idziemy w prawidłowym
kierunku, na tej podstawie dobudowujemy resztę
• Dzięki refaktoryzacji jakość produktu jest stale na
najwyższym poziomie
• Dzięki prostocie programiści skupiają się na projektowaniu i
kodowaniu na potrzeby bieżącego dnia, a nie robią nic na
wyrost
Sprzężenie zwrotne
• System – ważna jest odpowiedź systemu, otrzymywana w
procesie testowania jednostkowego
• Klient – przygotowuje testy akceptacyjne wraz z testerem;
dzięki takim testom można sprawdzić w jakim stanie
znajduje się aktualnie budowany system
• Zespół – w momencie kiedy klient proponuje nowe
wymagania zespół podaje szacunki ile czasu zajmie ich
zaimplementowanie; dzięki temu klient może podjąć
decyzje, czy wymaganie będzie realizowane od razu, w
przyszłości lub też w ogóle
Odwaga
• Odwaga jest potrzebna, aby przestrzegać zasady
projektowania i kodowania wg aktualnych potrzeb, bez
zastanawiania się co będzie potrzebne w przyszłości
• Odwaga, aby nie angażować się za bardzo w projektowanie
i od razu przejść do kodowania
• Odwaga jest potrzebna, aby zrefaktoryzować kod, wtedy
kiedy to jest potrzebne, aby nie bać się refaktoryzacji
• Jeżeli okaże się, że pewien fragment kodu jest już
nieprzydatny, lub musi zostać zmieniony, do podjęcia
decyzji o wyrzuceniu takiego kodu potrzeba dużo odwagi
Szacunek
• Nie można wysyłać do repozytorium zmian, które nie dają
się skompilować lub powodują błędy w testach
jednostkowych, gdyż przez to praca innych osób będzie
utrudniona, lub niemożliwa i stracą one dużo czasu
• Dzięki dążeniu do najwyższej jakości i szukanie najlepszych
rozwiązań projektowych (dzięki refaktoryzacji) innym
osobom będzie dużo łatwiej wykorzystać kod napisany
przez nas
Struktura zespołu
• XP nie pokazuje wprost struktury zespołu
• Dwie główne role w zespole pełnią:
– programiści
– klient
• Klient uważany jest za członka zespołu, więc musi przez
cały czas pracować razem z informatykami (w jednym
pomieszczeniu); czasem nie występuje w tej roli osobiście,
lecz za pośrednictwem przedstawiciela klienta
Struktura zespołu
• Role pomocnicze pełnią:
– tester, którego zadaniem jest napisanie skryptów testowych na
podstawie rozmów z klientem
– coach, to osoba, która pomaga rozwiązywać napotkane problemy
– tracker natomiast zbiera statystyki dotyczące wykonanych zadań,
czasu pracy i tworzy podsumowania postępów projektu
Opowieści użytkowników
• Przedstawiciel klienta jest ciągłym źródłem wymagań
• Wymagania są dyskutowane z nim na bieżąco, natomiast
ślad z tych dyskusji jest przechowywany w formie opowieści
użytkowników
• Każda opowieść jest zapisana w kilku zdaniach na małej
kartce papieru
• Może być oznaczona dodatkowymi atrybutami (np. data
utworzenia, typ, numer, rozmiar)
Przykład opowieści
Numer opowieści: 102
OPOWIEŚĆ: System przechowuje artykuły w formacie PDF. Umożliwia
ich dodawanie, listowanie, a także pobieranie.
Rozmiar: 3 dni
•
•
•
•
Opowieści są krótkie
Opisują funkcję systemu
Mają wartość dla klienta
Są testowalne
Hydrodynamiczny model
projektu
Hydrodynamiczny model
projektu
Cykl życia
Cykl życia w XP
Wydania i przyrosty
• Każde wydanie ma wartość użytkową i trafia do
użytkowników końcowych, dzięki czemu programiści dostają
sprzężenie zwrotne
• Należy stosować częste i krótkie wydania
• Przyrosty mają charakter wewnętrzny
• Pośrednie przyrosty niekoniecznie stanowią produkt, z
którego klient byłby w stanie skorzystać
• Każdy przyrost powinien trwać 2-3 tygodnie, oraz zawierać
kilka opowieści użytkownika
Planowanie
• Na początku podczas rozmów dotyczących wymagań
systemu klient spisuje opowieści użytkownika
• Informatycy szacują rozmiar opowieści, podając liczbę
osobo-dni potrzebnych do jej zrealizowania
• Jeżeli opowieść jest za duża (np. wykracza poza jeden
przyrost), wówczas dzieli się ją na mniejsze
• Jeżeli opowieść jest też zbyt mała wtedy łączy się ją z inną
opowieścią
Planowanie
• W momencie kiedy spisane są wstępne opowieści i
oszacowane przez informatyków, klient wybiera zakres
kolejnych przyrostów
• Klient zna koszt każdej opowieści i może zadecydować czy
będzie ona realizowana czy też nie, oraz kiedy będzie
realizowana, czyli do którego dwutygodniowego przyrostu
należy ją przypisać
Zarządzanie zmianami
• Klient w dowolnym momencie może zmienić zdanie i
zaproponować zmianę wymagań
• Klient płaci na bieżąco za wykonaną pracę i wie, że zmiana
elementów już zaimplementowanych będzie go kosztowała
dodatkowo
• Działa to również w drugą stronę - jeżeli programiści
dostrzegą pewien problem i zaproponują rozwiązanie, które
zmienia wymagania - klient ma do nich zaufanie i również
zgadza się na przedstawione rozwiązanie
Zapewnienie jakości
• XP stawia na prostotę rozwiązań (optymalizować kod należy
tylko wtedy, gdy jest to konieczne)
• Przed rozpoczęciem kodowania należy przygotować
przypadki testowe (ang. test-first-coding)
• Tak przygotowane testy są następnie jak najczęściej
wykonywane automatycznie - dzięki czemu na bieżąco
wychwytywane są błędy
• Do poprawy czytelności kodu stosuje się refaktoryzację
Zapewnienie jakości
• Zanim udostępni się zmiany dla innych programistów,
należy dokładnie przetestować go za pomocą testów
jednostkowych
• Klient przygotowuje testy akceptacyjne w których dokładnie
określa, jak system musi się zachować w określonych
warunkach, aby zaspokoić jego potrzeby
• Na podstawie stopnia wykonania testów akceptacyjnych
można ocenić postęp prac
Programowanie parami
• W tym podejściu, przy jednym komputerze siedzą 2 osoby
jednocześnie: autor i recenzent
• Autor pisze kod, natomiast recenzent na bieżąco go
przegląda i wychwytuje defekty
• Autor jest bardzo skupiony na tworzeniu kodu, a recenzent
ma więcej czasu na myślenie; może się okazać zatem, że
znajdzie lepszy sposób na rozwiązanie problemu, lub np.
dostrzeże problemy związane z testowaniem obecnego
kodu, lub po prostu wychwyci błąd w programie
Programowanie parami
• XP zaleca, żeby każdy fragment kodu powstał poprzez
programowanie parami
• Potrzebny jest wspólny standard kodowania dla całego
zespołu
• XP zakłada, że będą następować częste zmiany w parach,
tak aby każda osoba pracowała nad każdym fragmentem
systemu co ma dodatkową zaletę w postaci przepływania
wiedzy pomiędzy poszczególnymi programistami
• Dodatkowo w momencie kiedy jeden programista odejdzie
z zespołu, dla każdego fragmentu kodu znajdziemy inną
osobę, która będzie znała ten fragment
Programowanie parami
• W XP nie ma osoby odpowiedzialnej za każdą część kodu kod jest własnością całego zespołu
• Nie da się wydajnie pracować parami, jeżeli nie ma w firmie
systemu zarządzania wersjami, np. CVS
• Wymagana jest również otwarta przestrzeń pracy dla
zespołu - aby poszczególne osoby mogły się łatwo
komunikować
Czynniki ryzyka
• Założenie, że klient przez cały czas pracuje z zespołem
może się okazać nierealne - rzadko który klient może sobie
pozwolić na oddelegowanie jednego pracownika na kilka
miesięcy (gdyż tyle może trwać projekt)
• Brak dokumentacji z jednej strony powoduje przyspieszenie
projektu, lecz czasem może się okazać, że po pewnym
czasie trzeba wrócić do prac nad systemem (np. dodać
nową funkcjonalność); wtedy, bez odpowiedniej
dokumentacji, trudno przypomnieć sobie za co
poszczególne fragmenty kodu były odpowiedzialne
Czynniki ryzyka
• Niektórzy zarzucają również brak fazy projektowania twierdzą, że rozwiązania powstają za bardzo ad hoc
• Krótka perspektywa planowania (planuje się tylko kolejne
wydanie) nie pozwala przewidzieć, kiedy system będzie
ukończony
Literatura
• K. Beck: Extreme Programming Explained, AddisonWesley, 1999
• Andrzej Jaszkiewicz: Inżynieria oprogramowania, Helion,
1997
• Wykłady z inżynierii oprogramowania:
http://wazniak.mimuw.edu.pl/images/3/31/Io-12-wyk-bw.pdf