pobierz

Modele implementacji
oprogramowania
Michał Tomal
Proces wytwórczy oprogramowania (Software development process)
lub Cykl życia oprogramowania (Software development lifecycle)
Jest to struktura określająca sposób wytwarzania/rozwoju oprogramowania.
Istnieje wiele modeli takich procesów, opisujących różne podejścia do rozmaitych
zadań i działań, które zachodzą podczas wytwarzania oprogramowania.
Istnieje także podejście , które proces wytwórczy od cyklu życia, uznając, że
cykl jest bardziej pojęciem bardziej ogólnym, natomiast proces bardziej
szczegółowym. Np. niektóre procesy wytwórcze „pasują” do spiralnego modelu
cyklu życia oprogramowania.
ISO 12207
To międzynarodowy standard do opisywania metod wyboru, implementacji
i kontroli cyklu życia oprogramowania.
Opisuje on 23 procesy, 95 czynności (activities), 325 zadań (tasks) oraz 224
wyników (outcomes) powiązanych z procesami. Nowsza wersja ISO 12207:2008
definiuje 43 procesy.
5 podstawowych procesów
•
Zbieranie informacji (Acquisition)
•
Dostarczanie (Supply)
•
Tworzenie (Development)
•
Wdrażanie (Operation)
•
Wpieranie (Maintenance)
Modele procesów wytwórczych oprogramowania
1.
Model kaskadowy (Waterfall)
2.
Model spiralny (Spiral)
3.
Model przyrostowy (Iterative and Incremental)
4.
RUP (Rational Unified Process)
5.
Programowanie zwinne (Agile)
Model kaskadowy (Waterfall)
Wprowadzony w 1970 roku w artykule „Managing the Development of Large
Software Systems” autorstwa Winstona W. Royca.
Polega on na sekwencyjnym wykonywaniu podstawowych czynności,
będącymi kolejnymi fazami projektu. Każda z faz musi być dokładnie
udokumentowana i ukończona przed przejściem do następnej.sd
1.
2.
3.
4.
5.
6.
7.
Specyfikacja wymagań
Projektowanie
Implementacja
Integrowanie
Testowanie
Instalacja
Konserwacja
Specyfikacja
wymagań
Projektowanie
Implementacja
Integrowanie
Testowanie
Instalacja
Konserwacja
Zalety
• Każda faza ukończona bezbłędnie i
w 100% minimalizuje ryzyko
porażki i błędów
• Pełna i dokładna dokumentacja
sprawia, że w przypadku odejścia
pracowników wiedza nie jest
tracona
• Proste i zdyscyplinowane podejście,
łatwe do zrozumienia i wyjaśnienia
• Pozwala w łatwy sposób określić
„kamienie milowe”
Wady
• Trudny do zastosowania w praktyce
zwłaszcza dla złożonych projektów ,
w których klienci mogą nie umieć
precyzyjnie sformułować wymagań
• Projektanci mogą nie przewidzieć
przyszłych problemów
implementacji we wczesnych fazach
• Każdy błąd we wcześniejszych
fazach może spowodować
kosztowne powroty poprzednich faz
• Nadaje się tylko do stabilnych
projektów, w których projektanci
mogą przewidzieć zakresy
problemów i stworzyć poprawny
projekt przed rozpoczęciem
implementacji
• Nieelastyczny podział na fazy
• Duże koszty i czasochłonność
podczas powtarzania poszczególnej
fazy
Model spiralny (Spiral)
Zdefiniowany przez Barry’ego Boehm’a w 1989 roku w artykule „A Spiral
Model of Software Development and Enhancement”
Model ten łączy cechy modelu kaskadowego oraz prototypowego. Proces ten
ma postać spirali, w której każda pętla przedstawia kolejne fazy procesu. Każda
faza składa się z czterech etapów.
1.
2.
3.
4.
Ustalenie celów
Rozpoznanie i redukcja zagrożeń
Tworzenie i testowanie
Planowanie następnej iteracji.
Narastanie kosztów
1. Ustalenie celów
2. Rozpoznanie
i redukcja zagrożeń
Plan
wymagań
Koncepcja
działań
Prototyp 1
Prototyp 2
Prototyp 3
Prototyp 4
Koncepcja
wymagań
Wymagania
Koncepcja
ogólna
Koncepcja
szczegółowa
Plan
tworzenia
Weryfikacja
i walidacja
Plan
testowania
i integracji
Weryfikacja
i walidacja
Implementacja
Integracja
Testowanie
Oddanie
4. Planowanie następnej
iteracji
3. Tworzenie
i testowanie
Zalety
• Duży nacisk na rozpoznawanie i
eliminowanie zagrożeń, skutkujący
wysoką niezawodnością i szansą
realizacji projektu
• Bodowa prototypów pozwala na
lepszą ocenę zgodności i weryfikacji
wymagań
• Nadaje się do dużych projektów
• Pozwala szybko reagować na
zmieniające się czynniki i
wymagania
• Software jest wytwarzany już we
wczesnych etapach
Wady
• Wymaga bardzo dobrze
wyszkolonych i doświadczonych
ekspertów do analizy ryzyka,
planowania, relacji z klientem itd.
• Iteracyjność powoduje, że model jest
kosztowny i czasochłonny
• Sukces projektu zależy w znacznej
mierze od analizy ryzyka (poważne
konsekwencje błędów)
• Nie nadaje się do małych projektów
• Złożoność, ciężki do ścisłego
przestrzegania
Model przyrostowy (Iterative and incremental)
Został zdefiniowany w celu wyeliminowania wad modelu wodospadowego.
Stosowany do tworzenia początkowo małych, ale z czasem „rozrastających” się
części oprogramowania. Pozwala na osiąganie celów projektowych klientów, którzy
nie potrafią dokładnie określić własnych potrzeb.
W modelu tym funkcjonalność systemu jest dzielona na porcje. W każdej
z iteracji część funkcjonalności jest dostarczana poprzez pracę w różnych
dziedzinach (wymagania, implementacja, testy itd.). Takie działanie jest dzielona
na fazy:
1.
2.
3.
4.
Rozpoczęcie (Inception)
Opracowanie (Elaboration)
Konstrukcja (Constuction)
Przekazania (Transition)
Każda z faz może zostać podzielona na kilka iteracji, które są określone
ramami czasowymi, a nie funkcjonalnymi.
Modelowanie
biznesowe
Wymagania
Analiza i
projekt
Implementacja
Testowanie
Wdrażanie
Czas
Zalety
• Częsty kontakt z klientem
• Nie trzeba od razu definiować
pełnych wymagań
• Wczesne dostarczenie klientowi
pierwszych wersji/fragmentów
oprogramowania
• Opóźnienia dotyczące tylko pewnych
fragmentów nie mają wpływu na
czas ukończenia całego projektu
• Możliwość korzystania z
doświadczeń wyniesionego podczas
tworzenia i użytkowania
wcześniejszych części/wersji
systemu
• Pozwala na wczesne wykrywanie
problemów lub złych założeń, zanim
spowodują poważne straty
Wady
• Wzrost kosztów związanych z
uniezależnieniem realizacji
fragmentów systemu
• Trudne wyodrębnianie niezależnych
funkcjonalności
• Dodatkowy nakład pracy związany z
koniecznością implementacji
interface’ów aby zapewnić zgodność
z docelowym systemem
RUP (Rational Unified Process)
To iteracyjny struktura procesu wytwórczego oprogramowania stworzona
przez Rational Software Corporation, część IMB od 2003. Nie jest to pojedynczy
proces, a raczej szablon procesu. Zamierzeniem twórców było, aby organizacje
developerskie i zespoły projektowe same dostosowywały go do własnych potrzeb.
Zawiera on hipertekstową bazę wiedzy z przykładowymi artefaktami i
szczegółowymi opisami różnych typów czynności. Bazuje on na sześciu
podstawowych „najlepszych praktykach”
1. Iteracyjne wytwarzanie oprogramowania z ryzykiem będącym podstawą
kierowania iteracjami (Iterative Development)
2. Zarządzanie wymaganiami (Requirements Management)
3. Korzystanie z architektury opartej na komponentach (Component-based
architecture)
4. Graficzne projektowanie oprogramowania (Model software visuality)
5. Ciągłej kontroli jakości (Quality Assurance)
6. Kontroli zmian (Change Management)
Cykl życia RUP oparty jest na przyrostowym modelu cyklu życia
oprogramowania, więc tak samo wyróżnia się cztery fazy:
1.
2.
3.
4.
Rozpoczęcie (Inception)
Opracowanie (Elaboration)
Konstrukcja (Constuction)
Przekazania (Transition)
Konstrukcja RUP bazuje na „klockach” (building blocks lub content elements)
opisujących co ma być stworzone, jakie umiejętności są wymagane oraz jak krokpo-kroku jak trzeba osiągać poszczególne cele. Głównymi klockami są;
1. Role (kto) – definiuje zestaw wymaganych umiejętności, kompetencji i
odpowiedzialności
2. Produkty (co) – reprezentuje wyniki zadań wraz z wszelkimi dokumentami
i modelami stworzonymi podczas działania procesu
3. Zadania (jak) - opisuje jednostkę pracy przypisaną roli, dającą znaczący
wynik
W każdej iteracji otrzymywane są wyniki prac z sześciu dziedzin (dyscyplin)
inżynierskich (Engineering Disciplines) oraz trzech dziedzin pomocniczych
(Supporting Disciplines):
1.
2.
3.
4.
5.
6.
Modelowanie biznesowe (Business Modeling Discipline)
Wymagania (Requirements Discipline)
Analiza i projektowani (Analysis and Design Discipline)
Implementacja (Implementation Discipline)
Testowanie (Test Discipline)
Wdrażanie (Deployment Discipline)
a. Środowisko (Environment discipline)
b. Zarządzanie konfiguracją i zmianami (Configuration and Change
management discipline)
c. Zarządzanie projektem (Project management discipline)
Modelowanie
biznesowe
Wymagania
Analiza i
projekt
Implementacja
Testowanie
Wdrażanie
Czas
Open Unified Process (OpenUP)
Jest częścią open-source’owego szablonu procesów Eclipsa (Ecipse Process
Framework) stworzonego przez fundację Eclispe. Jego celem ułatwienie
przyswojenia podstaw RUP.
Zachował on najważniejsze cechy RUP takie jak:
1.
2.
3.
4.
Iteracyjne wytwarzanie oprogramowania
Wytwarzanie sterowane przypadkami użycia oraz scenariuszami
Zarządzanie ryzykiem
Skoncentrowanie na architekturze (architecture-centric approach)
OpenUP/Basic
Jest najbardziej zwinną i lekką formą OpenUP. Wywodzi się wkładu w open
source procesu zwanego Basic Unified Process (BUP) stworzonego przez IBM.
Został on zmieniony w Eclipse Foundation w 2005 roku i zmienił nazwę na
OpenUP/Basic w 2006.
Zachował on najważniejsze cechy RUP, podobnie jak OpenUP, dodatkowo
odrzucając najbardziej opcjonalne jego elementy, jednocześnie część z nich łącząc.
Tym sposobem jest znacznie prostszym procesem, który ciągle jest zgodny z jego
zasadami.
Nadaje się do małych projektów, których tworzenie zajmuje od 3 do 6
miesięcy tworzenia przez 3 do 6 osób.
Manifest Zwinnego Wytwarzania Oprogramowania (Agile Manifesto)
To deklaracja wspólnych zasad dla zwinnych metodyk tworzenia
oprogramowania. Została opracowana podczas spotkania jakie miało miejsce
11-13 lutego 2001 roku w ośrodku wypoczynkowym Snowbird w Utah.
Uczestniczyli w nim reprezentanci nowych metodyk tworzenia oprogramowania
będących alternatywą dla tradycyjnego podejścia opartego na modelu
kaskadowym. Na spotkaniu pod manifestem podpisało się 17 osób, a na stronie
internetowej jemu poświęconej możliwe jest także podpisanie się pod nim.
Treść Manifestu Agile
Poprzez wytwarzanie oprogramowania oraz pomaganie innym w tym zakresie
odkrywamy lepsze sposoby realizowania tej pracy. W wyniku tych doświadczeo
zaczęliśmy przedkładad:
Ludzi i ich wzajemne interakcje (współdziałanie) ponad procedury i narzędzia.
Działające oprogramowanie nad wyczerpującą dokumentację.
Współpracę z klientem nad negocjację umów.
Reagowanie na zmiany nad realizowanie planu.
Oznacza to, że wprawdzie doceniamy to co wymieniono po prawej stronie, to jednak
bardziej cenimy to co wymieniono po lewej
Programowanie zwinne (Agile software development)
Opiera się ono przyrostowym (i iteracyjnym) modelu cyklu życia
oprogramowania, gdzie wymagania i rozwiązania ewoluują przy współpracy
samoorganizujących się zespołów wytwarzających oprogramowanie. Kieruje się
następującymi zasadami:
1. Satysfakcja klienta poprzez szybkie dostarczenie użytecznego softwaru
2. Przyjmowanie zmian wymagań, nawet w późnych etapach powstawania
3. Częste dostarczanie działającego oprogramowania (tygodnie nie miesiące)
4. Działające oprogramowanie jest najważniejszą miarą postępu
5. Zrównoważone wytwarzanie, zdolność utrzymania ciągłego tempa
6. Bliska, codzienna współpraca między biznesmenami, a twórcami oprog.
7. Bezpośrednie konwersacje są najlepszą formą komunikacji
8. Projekty budowane wokół zmotywowanych jednostek, godnych zaufania
9. Ciągła uwaga zwracana na aspekty techniczne i dobry projekt
10. Prostota
11. Samoorganizujące się zespoły
12. Regularne przystosowywanie się do zmiennych okoliczności
Scrum
To metodyka zarządzania projektem wywodząca się od programowania
zwinnego. Pomimo, że została stworzona do zarządzania projektami wytwarzania
oprogramowania, to może być również wykorzystywana przez zespoły
konserwujące oprogramowanie lub jako ogólne podejście do zarządzanie
programem/projektem.
Pomysł przedstawili Hirotaka Takeuchi i Ikujiro Nonaka w artykule z 1986
zatytułowanym „The New New Product Development Game”. W 1995 r. Jeff
Sutherland i Ken Schwaber zaprezentowali dokument opisujący Scrum podczas
warsztatów „Business Object Design and Implementation” na konferencji OOPSLA
w Austin w Teksasie.
Nazwa Scrum pochodzi od terminu występującego w grze rugny,
tłumaczonego powszechnie jako "młyn" lub "przepychanka"
Scrum to szkielet procesu zawierający zestaw praktyk oraz predefiniowane
role. Głównymi rolami są:
1. Mistrz (ScrumMaster), który zarządza procesami (zamiast PMa)
2. Właściciel Produktu (Product Owner) reprezentujący klienta,interesariuszy
3. Zespół (Team) – grupa około 7 osób, faktycznie zajmująca się analizą,
projektowaniem, implementacją, testowaniem, itd.;
W pierwszym etapie tworzona jest lista wymagań użytkownika, są one
gromadzone w postaci "historyjek”, opisujących jedną cechę systemu.
Zespół pracuje zwykle w 2-4 tygodniowym przedziale czasowym zwanym
sprintem, którego efektem powinien być dostarczenie kolejnego działającego
fragmentu produktu. Zestaw funkcjonalności do wykonania w sprincie pochodzi
z rejestru produktu (product backlog), który zawiera listę zadań wraz z ich
priorytetem. O tym, które z zadań zostanie wyznaczone do kolejnego sprintu,
rozstrzygane jest podczas spotkań, na których Właściciel Produktu informuje
zespół czego oczekuje. Drużyna następnie ustala ile z tego jest w stanie zrobić
podczas kolejnego sprintu i zapisuje to w rejestrze sprintu (sprint backlog).
Podczas przebiegu nikt nie ma prawa modyfikować rejestru sprintu, więc
wymagania są zamrożone. Wytwarzanie jest ograniczone ramami czasowymi i
sprint musi zakończyć się w wyznaczonym terminie. Jeśli jakieś zadanie nie jest
zakończone, z jakiegoś powodu, jest pozostawiane i wraca do rejestru produktu. Po
zakończeniu drużyna demonstruje, jak korzystać ze stworzonego oprogramowania.
Bardzo ważnym aspektem metodyki Scrum jest bliska, codzienna współpraca
między poszczególnymi osobami. Stąd konieczność odbywania się następujących
spotkań:
1. Codzienny młyn (Daily Scrum)– codziennie, podczas sprintu,
charakteryzuje się:
• Zaczyna się punktualnie
• Każdy może w nim uczestniczyć, jednak zabierać głos może tylko
Drużyna i ScrumMaster
• Spotkanie może trwać tylko 15 min.
• Powinno się odbywać zawsze w tym samym miejscu i porze dnia
• Każdy członek zespołu odpowiada na pytania: Co zrobiłeś od wczoraj?
Co planujesz zrobić dzisiaj? Czy masz jakieś problemy powstrzymujące
Cię przed osiągnięciem celu?
2. Planowanie Sprintu (Sprint Planning Meeting) – przed rozpoczęciem
każdego sprintu , charakteryzuje się:
• Wybieranie co ma być zrobione
• Przygotowanie rejestru sprintu zawierającego czas potrzebny na
wykonanie
• Stwierdzenie ile z roboty jest wykonalne w czasie aktualnego przebiegu
• Może trwać maksymalnie 8 godz. (jedna połowa na ustalenie
priorytetów zadań między Drużyną a Właścicielem, a druga dla Drużyna
na przygotowanie rejestru sprintu)
3. Inspekcja Sprintu (Sprint Review Meeting) – na koniec każdego sprintu
• Sprawdzenie, czy plan został wykonany
• Prezentacja ewentualnych rezultatów interesariuszom (Demo)
• Maksymalnie 4 godz.
4. Spotkanie Retrospektywne (Sprint Retrospective) – po skończeniu
sprintu
• Wszyscy członkowie drużyny wymieniają uwagi nt. minionego sprintu
• Tworzenie ciągłego ulepszanie procesu
• Zadanie dwóch podstawowych pytań: Co poszło dobrze podczas
sprintu?; Co może być poprawione podczas następnego?
• Maksymalnie 3 godz.
Feature Driven Development (FDD)
Jest zwinnym procesem wytwarzania oprogramowania, opartym na
przyrostowym modelu cyklu życia oprogramowania. Jego głównymi celami jest
umożliwienie wytwarzania użytecznego oprogramowania w powtarzalny i
efektywny sposób, zapewniając wiarygodne informacje o stanie projektu
informatycznego do wszystkich jego uczestników, z minimalnym narzutem na
pracę programistyczną.
Pierwotnie został on wymyślony przez Jeff’a De Luca w 1997 roku, przy
okazji tworzenia oprogramowania dla dużego banku w Singapurze. Pierwszy opis
FDD ukazał się w 1999 roku w książce „ Java Modeling in Color with UML” Peter’a
Coad’a, Eric’a Lefebvre’a i Jeff’a De Luca. Bardziej ogólny opis umieszczony został w
książce „A Practical Guide to Feature-Driven Development” Steve’a Palmera w 2002
roku.
Proces FDD bazuje na pięciu podstawowych czynnościach:
1. Budowa ogólnego modelu (Develop Overall Model) – Na początku
projektu zespół projektowy opracowuje model systemu, zapewniający
wspólne rozumienie jego architektury i stanowiący przewodnik do jego
budowy podczas następnych faz.
2. Budowa listy cech (Build Feature List) – Na podstawie wiedzy
zgromadzonej podczas pierwszego etapu, tworzona jest lista cech, będącymi
funkcjonalnościami systemu. Cechy te są małymi kawałkami, pełniącymi
funkcje użytkowe, wyrażane poprzez pojedyncze zdanie np.: „Sprawdź
poprawność hasła użytkownika”, czy „Oblicz sumę wszystkich wartości”.
Każda taka cech nie powinna zająć więcej niż 2 tygodnie tworzenia.
3. Planowanie wg cech (Plab by Feature) – Na podstawie listy cech
konstruowany jest plan tworzenia oprogramowania. Głównym
programistom przyporządkowywane są cechy lub zestawy cech jako klasy.
Każda z klas ma właściciela.
4. Projekt wg cech (Design by Feature) – Tworzone są zespoły złożone z
właścicieli klas. Zespoły wykonują szczegółowe projekty, dopracowując
ogólny model. Następnie, przeprowadzane są inspekcje projektów.
5. Implementacja wg cech (Build by Feature) – zaakceptowane projekty są
kodowane przez właścicieli klas. Po przejściu testów dodawane są do
głównego systemu, który prezentowany jest klientowi.
Dwa ostatnie punkty powtarza się iteracyjnie do końca projektu.
Ponieważ poszczególne cechy są relatywnie prostymi zadaniami, w celu
śledzenia rozwoju projektu i dokładnego raportowania stanu definiowane są tzw.
kamienie milowe. FDD definiuje sześć kamieni milowych dla każdej cechy, które
muszą być ukończone sekwencyjnie.
Pierwsze trzy zawierają się w fazie Projekt wg cech, kolejne trzy zaś w fazie
Implementacja wg cech. Do każdego kamienia milowego przypisywany jest procent
ukończenia cechy:
1.
2.
3.
4.
5.
6.
Przegląd dziedziny (Domain Walkthrough) – 1%
Projekt (Design) – 40%
Inspekcja projektu (Design Inspection) – 3%
Kod (Code) – 45%
Inspekcja kodu (Code Inspection) – 10%
Dodanie do wersji (Promote to Build) – 1%
Dobre praktyki składające się na FDD:
1. Domain Object Modeling (DOM) - składa się z badania i wyjaśniania
dziedziny rozwiązywanego problemu. Wynikowy model dostarcza ogólnego
szablonu, do którego dodawane są cechy.
2. Tworzenie wg cech (Developing by Feature) – Każda funkcja, której nie da
się zaimplementować w 2 tygodnie jest rozkładana na mniejsze problemy.
3. Indywidualni właściciele klas (Individual Class Ownership) – oznacza,
że odrębne fragmenty kodu są przypisane do pojedynczych właścicieli,
odpowiedzialnych za zgodność, wydajność i integralność klas.
4. Zespoły przypisywane do cech (Feature Teams) – są małe, dynamicznie
formowane, przez co nad każdą decyzją projektową zastanawia się wiele
osób.
5. Inspekcje – zapewniają wysoką jakość projektów i kodów źródłowych.
6. Zarządzanie konfiguracją (Configuration Management) – pomaga przy
identyfikacji kodów źródłowych ukończonych cech oraz rejestrowaniu
historii zmian dokonywanych w cechach.
7. Regularnie wypuszczane wersje (Regular Builds) – zapewniają, że
zawsze istnieje aktualna wersja systemu, którą można pokazać klientowi, a
także pomaga wcześnie odnajdować błędy integracji kodu źródłowego
8. Widoczność postępów (Visibility of progress and results) – dzięki
częstym i celnym raportom na wszystkich poziomach; pomocne przy
kierowaniu projektem.
Test Driven Development (TDD)
Jest techniką tworzenia oprogramowania zaliczaną do metodyk zwinnych.
Została stworzona przez Kenta Becka. Pierwotnie była częścią programowania
ekstremalnego (Extreme Programming), lecz obecnie stanowi samodzielną
technikę.
Polega na wielokrotnym powtarzaniu kilku kroków.
1. Najpierw programista pisze automatyczny test sprawdzający dodawaną
funkcjonalność. Test w tym momencie nie powinien się udać.
2. Później następuje implementacja funkcjonalności. W tym momencie
wcześniej napisany test powinien się udać.
3. W ostatnim kroku, programista dokonuje refaktoryzacji napisanego kodu,
żeby spełniał on oczekiwane standardy.
Cykl wytwórczy TDD składa się z następujących kroków:
1. Dodaj test – każda nowa funkcjonalność rozpoczyna się od napisania testu,
który musi na początku się nie udać. Aby stworzyć test twórca musi
dokładnie zrozumieć specyfikę funkcjonalności oraz jej wymagania. Dzięki
temu skupia się on na wymaganiach jeszcze przed napisaniem kodu.
Możliwy jest wariant, w którym twórca tylko modyfikuje istniejący test.
2. Przeprowadź wszystkie testy i sprawdź, czy nowy się nie udał – dzięki
temu można się przekonać czy nowy test działa poprawnie i błędnie nie
akceptuje poprzedniego kodu bez wprowadzonych zmian.
3. Napisz trochę kodu – taki aby przeszedł test. Nie musi on być idealny. Jest
to dopuszczalne, ponieważ dalsze kroki to poprawią.
4. Przeprowadź testy i sprawdź czy się powiodły – jeśli tak, to kod spełnia
wymagania.
5. Refaktoryzuj kod – dzięki czemu będzie „czystszy”. Poprzez ponowne
przeprowadzanie testów, można się upewnić, że wprowadzone zmiany nie
niszczą istniejącej funkcjonalności.
6. Powtórz – zaczynając od kolejnego nowego testu, cykl się powtarza, aby
rozszerzać funkcjonalność.
Powtórz
(Prze)Twórz test
Udaje się
Przeprowadź
testy
Nie udaje się
Napisz trochę kodu
Nie udaje się
Przeprowadź
testy
Udaje się
Wyczyść kod
Programowanie ekstremalne (Extreme Programming, XP)
Jest techniką tworzenia oprogramowania zaliczaną do metodyk zwinnych,
która w zamierzeniach ma poprawę jakości oprogramowania oraz reakcje na
zmiany wymagań klienta.
Została ona stworzona przez Kenta Becka i opisana w jego książce „Extreme
Programming Explained” z 1999 roku.
XP próbuje zredukować koszty zmian wymagań poprzez wiele krótkich cykli
wytwarzania oprogramowania, zamiast jednego jak np. w kaskadowym modelu.
Według tej metodyki zmiany są naturalnym, nieuniknionym i wskazanym
aspektem projektu oraz powinny być włączone w plany projektu, zamiast próby
stworzenia niezmiennego zestawu wymagań.
Ekstremalne programowanie opisuje 4 podstawowe czynności podczas
procesu wytwarzania oprogramowania:
1. Tworzenie kodu źródłowego – według zwolenników XP jedynym
naprawdę istotnym produktem procesu wytwarzania systemu jest kod
źródłowy. Czynność ta może być dodatkowo wykorzystana do wynajdywania
najbardziej odpowiadających rozwiązań, a także do komunikacji.
Programista, który nie potrafi słownie wytłumaczyć sposobu rozwiązania
jakiegoś problemu, może użyć kodu źródłowego do zademonstrowania
innym programistom.
2. Testowanie – nie można być pewnym czy dana funkcja działa poprawnie
dopóki nie zostanie przetestowana. Poprzez testowanie można wykryć wiele
błędów. Wyróżnia się dwa rodzaje testów:
• Testy jednostkowe – sprawdzające czy dana funkcjonalność działa
poprawnie. Programista pisze tak wiele zautomatyzowanych testów, jak
tylko potrafi wymyśleć. Jeśli kod przejdzie wszystkie testy jest
akceptowany.
• Testy akceptacyjne – weryfikujące czy wymagania zrozumiane przez
programistów spełniają właściwe wymagania klientów
3. Słuchanie – programiści muszą słuchać, czego klienci oczekują od
systemów, jaka logika biznesowa jest potrzebna. Muszą rozumieć te
potrzeby na tyle, aby móc przedstawić klientom techniczne aspekty tego, jak
dane problemy mogą być rozwiązane lub nie.
4. Projektowanie – Z punktu widzenia prostoty, może wydawać się, że
projektowanie jest zbędne i wystarczą tylko pierwsze trzy czynności.
Jednak w praktyce jednak, bez projektu, kiedy system staje się zbyt złożony,
a zależności przestają być wyraźne. Dobry projekt organizujący logikę w
systemie, pozwoli na uniknięcie wielu zależności, dzięki czemu zmiana
jednej części systemu nie będzie miała wpływu na działanie innych.
Ekstremalne programowanie wyróżnia 4 wartości:
1. Komunikacja – Technika ekstremalnego programowania może być
postrzegana jako metody szybkiego tworzenia oprogramowania i
rozszerzania formalnej wiedzy pomiędzy członkami zespołów
programistycznych. Celem jest danie wszystkim twórcom współdzielonego
spojrzenia na system, pokrywającego się ze spojrzeniem z perspektywy
użytkowników systemu. XP wspiera więc, proste projekty, współpracę
między użytkownikami, a programistami, częstą słowną komunikację oraz
opinie zwrotne.
2. Prostota – XP zachęca do zaczynania od najprostszych rozwiązań, a każde
dodatkowa funkcjonalność, może być dodana później. Różnica między
programowaniem ekstremalnym, a bardziej konwencjonalnymi
metodykami jest koncentracja na potrzebach aktualnych, dzisiejszych, a nie
tych jutrzejszych, przyszłego tygodnia czy miesiąca. Prosty projekt i kod
źródłowy może być dobrze zrozumiany przez większość programistów z
zespołu.
3. Opinie zwrotne (Feedback) – odnosi się do różnych wymiarów tworzenia
systemu
• od systemu – poprzez pisanie testów jednostkowych lub
przeprowadzanie okresowych testów integralności
• od klienta – poprzez testy akceptacyjne
• od zespołu – kiedy zachodzą zmiany wymagań klientów, zespół
bezpośrednio przekazuje oszacowany czas wymagany do implementacji
4. Odwaga – przykładami na wymaganie posiadania odwagi jest rozumienie
kiedy należy wyrzucić kod, odwaga by usunąć przestarzały kod, bez
względu na to jak wiele pracy zostało włożone w jego stworzenie, odwaga
oznaczająca wytrwałość, kiedy programista utknie przy jakimś złożonym
problemie, jednak powróci do niego następnego dnia, aby go rozwiązać
5. Szacunek – zarówno do innych jak i do siebie. Szanowanie własnej pracy,
poprzez staranie się o jak najlepszą jakość i najlepsze rozwiązania. Kiedy
nikt nie jest ignorowany, albo niedoceniany wzbudzany jest wysoki poziom
motywacji, co także zachęca do lojalności wobec współpracowników.
Opis programowanie ekstremalnego zawiera dwanaście praktyk zgrupowanych
w kategorie
1. Fine scale feedback
• Programowanie w parach (Pair programming)
• Gra w planowanie (Planning game)
• Test-driven development
• Cała drużyna (Whole team)
1. Ciągły proces (Continuous process)
• Ciągłe integrowanie (Continuous integration)
• Refaktoryzowanie (Refactoring)
• Małe wydania (Small releases)
1. Wspólne rozumienie (Shared understanding)
• Standardy programowania (Coding standards)
• Wspólna własność kodu (Collective Code Ownership)
• Prosty projekt (Simple design)
• Metafora systemu (System methaphor)
1. Programing welfare
• Zrównoważone tempo (Sustainable pace)