Wyższa Szkoła
Zarządzania i Bankowości
W Krakowie
Studia Inżynierskie
Wydział Informatyka
Tomasz Guzik
Analiza i porównanie trzech podejść produkcji i tworzenia oprogramowania: Podejście Kaskadowe, Podejście Extreme Programming, oraz Rational Unified Process.
Praca Inżynierska
napisana pod kierunkiem
dr inż. Wiesław Byrski
Kraków 2007
Spis treści:
Czym jest metodyka i po co się ją stosuje?
Wstęp.
Rozdział I - Metodologia Extreme Programming
1.1. Historia Extreme Programming - wprowadzenie . . . . . . . . . . . . . . . . . . . . 5
1.2. Opis metodyki - czym jest XP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Podstawowe cechy Extreme Programming . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3.1. Planowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3.2. Projekt i iteracja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3.3. XP - wspólnota kodu i programowanie parami . . . . . . . . . . . . . . . . 10
1.4. Cechy charakterystyczne Extreme Programming . . . . . . . . . . . . . . . . . . . 12
1.4.1. Planowanie - wskazówki i szczegóły . . . . . . . . . . . . . . . . . . . . . . . . 13
1.4.2. Projektowanie - wskazówki i szczegóły . . . . . . . . . . . . . . . . . . . . . 20
1.4.3. Implementacja - wskazówki i szczegóły . . . . . . . . . . . . . . . . . . . . . 22
1.4.4. Testowanie - wskazówki i szczegóły . . . . . . . . . . . . . . . . . . . . . . . 26
1.5. Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Rozdział II - Metodologia Rational Unified Process
2.1. Wprowadzenie do Rational Unified Process - krótka historia . . . . . . . . . 30
2.2. Opis metodyki . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.3. Cechy charakterystyczne, architektura i zasada działania RUP-a . . . . . . . 32
2.3.1. Iteracyjność . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.3.2. Zarządzanie wymaganiami . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.3.3. Architektura bazująca na komponentach . . . . . . . . . . . . . . . . . . . . 35
2.3.4. Wizualizacja modelowania . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.3.5. Bieżąca kontrola jakości . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.3.6. Zmiany kontrolne w oprogramowaniu . . . . . . . . . . . . . . . . . . . . . . 37
2.4. Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Rozdział III - Kaskadowe metody w tworzeniu oprogramowania
3.1. Co to kryje się pod pojęciem „model kaskadowy” . . . . . . . . . . . . . . . . . . 38
3.2. Ogólny opis cech podejścia kaskadowego . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.3. Model kaskadowy - rodzaje i zastosowanie . . . . . . . . . . . . . . . . . . . . . . . 39
3.3.1. Kaskadowy model bez iteracji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.3.2. Kaskadowy model z iteracjami . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.4. Porównania . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Rozdział IV - Porównanie trzech podejść produkcji i tworzenia oprogramowania
4.1. Porównanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.1.1. Szkielet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.1.2. Analiza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2. Wnioski i zakończenie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Czym jest metodyka i po co się ją stosuje?
Metodyka
[z gr. Metodol]
(w literaturze angielskojęzycznej określana jest mianem procesu)
„Jest to zbiór ustandaryzowanych, uporządkowanych i sprawdzonych zasad, odnoszących się do sposobów rozwiązania konkretnego zadania. Metodyka opisuje „metody” postępowania przy realizacji i dojściu do wyznaczonego celu”.
Właściwie metodyka stanowi niejako „zbiór narzędzi i rozwiązań” potrzebnych do realizacji konkretnego celu, stara się udzielić odpowiedź na pytanie „Jak należy rozwiązać konkretne zagadnienie?”, jest ona próbą wcielenia w życie pewnych sprawdzonych praktyk.
Metodyki stosowane są w celu zwiększenia efektywności przy realizacji postawionych zadań, umożliwiają obliczenie postępu dokonanego w trakcie prowadzonych prac i co najważniejsze wprowadzają schemat postępowania przy wykonywaniu owych prac!
Wstęp
Na przełomie dwudziestego i dwudziestego pierwszego wieku nastąpił gwałtowny rozwój informatyki. Początkowo z braku odpowiednich możliwości technologicznych, komputery potrafiły wykonywać tylko proste zadnia matematyczne. Dopiero z czasem, gdy moce obliczeniowe komputerów zaczęły radykalnie wzrastać zaczęły również powstawać coraz to nowsze i coraz bardziej wyrafinowane programy, które służyły już nie tylko nauce. W wyniku tak szybkiego rozwoju informatyki oraz wynikających z tego nowych potrzeb, zaczęły powstawać coraz to bardziej rozbudowane programy oraz systemy informatyczne. Dziedzina informatyki, która zajmowała się tworzeniem tego typu narzędzi została nazwana inżynierią oprogramowania. Od chwili jej powstania aż po dziś dzień inżynieria podąża krok w krok za rozwojem samej informatyki, często nawet wyprzedza ją, badając nowe możliwości i rozwiązania, które w przyszłości mogą znacznie uprościć nam codzienne życie.
Inżynieria zajmuje się wszystkimi aspektami produkcji oprogramowania od początkowych analiz aż do produktu końcowego, czyli ewolucji gotowego programu. Wraz z postępem i rozwojem nowych technologii oraz Internetu inżynierowie już na poziomie projektów zaczęli napotykać na swojej drodze na coraz to nowsze i coraz bardziej skomplikowane problemy, które musieli w jakiś sposób rozwiązać. W wyniku tychże piętrzących się problemów oraz chęci tworzenia coraz bardziej doskonalszych programów stworzono wiele ciekawych, przydatnych i rozbudowanych metodyk ułatwiających tworzenie różnego rodzaju oprogramowania.
W wyniku wprowadzenia nowego terminu a co za tym idzie i samych metodyk, tworzenie oprogramowania stało się bardziej uproszczone oraz zhierarchizowane i usystematyzowane. Można, zatem pokusić się o stwierdzenie, że w wyniku wprowadzenia w życie pierwszych metodyk, zaczęto wprowadzać pewne standardy do firm, które zajmowały się tworzeniem oprogramowania. Do takich często stosowanych metodyk tworzenia oprogramowania zaliczyć można np. podejście Kaskadowe, Extreme Programming, Rational Unifed Process, PRINCE2, XPrince czy TenStep.
Na poziomie tego dokumentu skupię się na analizie trzech głównych metodyk -XP, RUP oraz podejścia Kaskadowego. Dokonując tychże analiz podobieństw i różnic w/w metodyk spróbuję odpowiedzieć na pytanie, która z nich i w jakich warunkach są lepsze do zastosowanie przy produkcji oprogramowania.
I Rozdział - Metodologia Extreme Programming.
1.1 Historia Extreme Programming - wprowadzenie.
We wczesnych latach 90'tych Kent Back pracując przy tworzeniu oprogramowania zastanawiał się nad stworzeniem nowej, lepszej metody przy projektowaniu i produkcji systemu. Kent i jego zespół wiedzieli o niedoskonałościach metody kaskadowej, która była powszechnie stosowana w tamtych czasach. Chcieli oni stworzyć coś bardziej niezawodnego niż stosowana metodyka. Spędzili oni wiele czasu nad rozwiązaniem tego problemu. Razem próbowali stworzyć taką metodę, która uprościłaby, a co za tym idzie i usprawniła pewne kroki przy tworzeniu oprogramowania. Kent przy pracach skupił swoją uwagę na czynnikach, które usprawniają oraz utrudniają tworzenia oprogramowania. W marcu 1996 roku Kent Back podjął pracę projektowe w firmie samochodowej DaimlerChrysler, wykorzystując tam już nowo nabytą wiedzę oraz technikę przy tworzeniu oprogramowania. W rezultacie późniejszych prac powstała metodologia znana dziś pod pełną nazwą jako Extreme Programming (- w skrócie XP). W metodologii tej twórcy zaproponowali całkowicie nowe podejście do tworzenia oprogramowania akceptując prawo klienta do zmiany wymagań. Założenia leżące u podstaw tej metodyki okazały się w praktyce bardzo skuteczne, co potwierdziły prace wdrożeniowe w takich przedsiębiorstwach jak Bayerische Landesbank, Credit Swiss Life, DaimlerChrysler, First Union National Bank, Ford Motor Company czy UBS.
Kent i jego zespół uświadomili sobie w czasie prac, iż występują 4 czynniki (- zmienne), które w mniej lub bardziej bezpośredni sposób przyczyniają się do płynnej pracy przy tworzeniu oprogramowania. Zmiana lub poprawa jednej z nich potrafi usprawnić lub utrudnić pracę nad całym projektem np. - potrzebujemy usprawnić komunikację, szukamy najlepszej drogi do uproszczenia lub ulepszenia projektu, potrzebujemy dokonać sprzężenia, - na jakim etapie rozwoju znajduje się projekt i chcemy przy tym postępować odważnie bez przeszkód -w tym właśnie ma pomóc metodologia XP.
1.2 Opis metodyki - czym jest XP?
Metodykę tę stworzono, aby efektywniej zarządzać przedsięwzięciami realizowanymi w "produkcyjnych" i trudnych warunkach biznesowych, w których wymagania i potrzeby ciągle ulegają zmianom.
Jeżeli dany system informatyczny ma poprawnie realizować założone funkcje, wówczas kluczem do jego sukcesu jest wystarczająco wczesne aktywne zaangażowanie użytkowników w przedsięwzięcie, zwłaszcza w zakresie testowania systemu i dostarczenia odpowiedniego sprzężenia zwrotnego dla jego twórców. W momencie, gdy programista staje w obliczu zdefiniowanych procesów i ich ograniczeń, niezbędna okazuje się indywidualna kreatywność oraz grupowa "burze mózgów". Rozwiązania takie przynoszą różnego rodzaju zwinne metodyki, które koncentrują się głównie na członkach zespołu i tworzeniu prostych, a także użytecznych rozwiązań. Taką właśnie drogę w prowadzeniu projektu umożliwia również lekka metodyka Extreme Programming.
XP to zbiór prostych reguł oraz praktycznych uwag, trudnych do przyjęcia w codziennej praktyce bez wewnętrznej grupowej zgody. Metodologię tę wykorzystuje się w projektowaniu aplikacji bazodanowych ( -internetowych) oraz w projektowaniu oprogramowań informatycznych. XP jak już wcześniej wspomniałem powstała na drodze obserwacji i zbierania tych praktyk, które sprzyjały powstawaniu oprogramowania w sposób prosty, a zarazem i efektywny - przyjmując perspektywę programisty. Praca według tejże metodologii pozwala programistom na dużą swobodę, która zorientowana jest na szybkie dostarczanie korzyści dla klienta (użytkownika) -czyli po prostu szybkie dostarczenie gotowego produktu.
Programowanie ekstremalne to wytyczne i metody programowania mające na celu wydajne tworzenie małych i średnich "projektów wysokiego ryzyka", czyli takich, w których nie wiadomo do końca, co się tak naprawdę robi i jak to prawidłowo zrobić. Przyświeca temu koncepcja prowadzenia projektu informatycznego, wywodząca się z obserwacji innych projektów, które odniosły sukces.
"XP is a lightweight methodology for small to medium sized teams developing software in the face of vague or rapidly changing requiremente" - Kent Back
1.3 Podstawowe cechy Extreme Programming.
§1. Metodyka XP oparta jest na kilku prostych regułach rządzących czterema głównymi praktykami procesu produkcyjnego: planowanie, projektowanie, kodowanie, testowanie.
§2. Ważne jest, aby funkcjonalności dostarczane były w krótkich ( -maksymalnie do trzech tygodni) okresach projektowych ( -inkrementach), sterowanych częściowymi wymaganiami ( - tzw. opowieściami użytkowników).
§3. Wszystkie sprawy formalne ( -organizacyjne) załatwiane są w krótkich codziennych spotkaniach "na stojąco" trwających góra od 15 do 20 minut i na których omawia się bieżący plan zajęć oraz problemy, jakie dotychczas wynikły w projekcie!
§4. Bardzo istotną cechą jest "Refaktoryzacja", czyli tzw. upraszczanie kodu.
(* Opracowanie własne)
§5. Użytkownicy w XP są aktywnymi członkami zespołu projektowego, pomagając przy tym twórcom produktu, który aktualnie jest dla nich wytwarzany.
1.3.1 Planowanie
Planowanie jest jednym z podstawowych czynności w Extreme Programming. Dzięki niemu można łatwo i szybko zbudować harmonogram projektu w oparciu o opowiadania użytkowników. Poniższy rysunek przedstawia pętle procesu planowania (Rysunek I.).
Rys. 1 - Kolejne stopnie procesu planowania w XP.
Struktura:
Stworzenie planu -okres miesięcy, ↓
Plan iteracyjny - okres tygodni, ↓
Testy akceptacyjne - okres dni, ↓
Spotkanie „na stojąco” - okres dnia ↓
Negocjacje parami - okres godzin ↓
Pojedyncze testy - okres minut ↓
Programowanie parami - okres sekund ↓
KOD
(* Opracowanie własne)
Z kodu można z powrotem powrócić do konkretnego, wcześniejszego podpunktu i rozpocząć proces powtórnie -podobnie jak to ma miejsce w modelu kaskadowym z iteracjami, tyle, że tam jest możliwość powrotu z każdego podpunktu do poprzedniego, a nie dopiero z fazy końcowej projektu.
1.3.2 Projekt i iteracja
Dzięki odpowiedniemu planowaniu i iteracji można w szybki sposób dostarczać kolejne „kawałki” programu. W wyniku takich krótkich i przyrostowych kroków oraz planowaniu tylko następnych iteracji, niweluje się możliwość powstania wersji programu, która nie współgrałaby z odpowiadającą jej iteracjom, a co za tym idzie koszty błędów są radykalnie mniejsze niż w przypadku podejść kaskadowych.
Rys. 2 - Planowanie projektu w XP.
Główny cel wytwórczy:
Zbieranie wymagań (opowieści i historii użytkowników),
Planowanie kawałka programu,
Iteracja,
Testowanie akceptacyjne,
Oddanie kawałka funkcjonalności.
Rys. 3 - Planowanie i iteracyjne podejście w XP.
Pojedyncza iteracja:
Zaczyna się od planu iteracji uwzględniającego bieżące zadania i poprzednie problemy procesu wytwórczego,
Dostarczanie nowej wersji systemu - jego częściowej realizacji.
1.3.3 XP - wspólnota kodu i programowanie parami
Dzięki takiej technice podejścia do tworzenia oprogramowania, można zaprzęgnąć do pracy cały zespół, dodatkowo przy tym eliminując tzw. wąskie gardło kodowanie, gdzie tylko dana osoba pracująca nad daną częścią kodu wie, co ona robi. Ponadto dzięki spotkaniom na stojąco można w szybki i prosty sposób omówić najważniejsze problemy, z którymi w określonym momencie borykają się pracownicy.
Rys. 4 - Rozwój projektu według XP.
Proces wytwarzania to:
Praca dzień po dniu,
Zadania na jeden dzień ustalane są na krótkich spotkaniach,
Powstający kod jest wspólną własnością zespołu,
Powstają codziennie kawałki kodu,
Błędy są poprawiane na bieżąco.
Rys. 5 - Zastosowanie polityki wspólnego kodu w XP.
Wspólna własność kodu powstaje:
Dzięki programowaniu parami,
Dzięki nieustannemu upraszczaniu (refaktoryzacji) kodu przez wszystkich członków zespołu,
Dzięki bezustannej codziennej integracji.
1.4 Cechy charakterystyczne Extreme Programming.
Jak już wcześniej wspomniałem metodyka Extreme Programming opiera się na następujących wartościach, leżących u podstaw wszystkich wykonywanych czynności: komunikacja, prostota, sprzężenie zwrotne i odwaga. Wartości te łączy ze sobą efekt synergii, u podstaw, którego leży dążenie do szybkiego dostarczenia dobrej jakości oprogramowania zgodnego z oczekiwaniami klienta. Prosty produkt umożliwia łatwą komunikację, gdyż programiści nie mają problemu z rozszyfrowaniem sposobu jego działania, problem zaczyna się w bardziej skomplikowanych systemach. Wszechogarniająca komunikacja umożliwia natychmiastowe sprzężenie typu: oczekiwania klienta → system informatyczny → świat rzeczywisty. Odwaga natomiast sprawia, że praca posuwa się szybko, a nowe problemy i zmieniające się wymagania nie spowalniają pracy zespołu.
Planowanie
|
Kodowanie (implementacja)
|
Projektowanie
|
Testowanie
|
Tab. 1 - Podstawowe wartości XP i ich cechy charakterystyczne.
1.4.1 Planowanie - odpowiednie praktyki, wskazówki i szczegóły.
Opowiadania użytkowników.
Opowiadania te mają podobne ( -pomocnicze) zastosowanie, jak schematy tzw. przypadków użycia. Są używane m.in. po to, aby określić szacunkowy czas, jaki będziemy potrzebowali na spotkanie, które będą miały na celu opracowania planu nowej wersji systemu. Są one również używane zamiast obszernego dokumentu zawierającego wszystkie spisane wymagania.
Opowiadania użytkowników to nic innego jak notatki spisywane przez klientów po to, aby było wiadome, co dany system powinien robić dla nich. Notatki te są również podobne do scenariuszy przypadków użycia, lecz nie ograniczają się do opisywania samego interfejsu użytkownika, tylko przede wszystkim do funkcji, jakie dany system ma posiadać i co powinien robić.
Opowiadania użytkownika są przeważnie w formacie trój zdaniowych akapitów tekstu napisanych przez klienta, używając jego słownictwa, bez technicznej terminologii. Oprócz formy informacyjnej opowiadania pełnią również rolę do sterowania tworzeniem testów akceptacyjnych. Testy te mają za zadanie stwierdzić, czy oczekiwania użytkowników zostały poprawnie zrozumiane, a co za tym idzie i zaimplementowane.
Jednym z największych powodów nieporozumień podczas produkcji oprogramowania są różnice pomiędzy opowiadaniami, a specyfikacjami wymagań. Główną cechą odróżniającą te dwa wymienione podejścia jest poziom szczegółowości opisu. Opowiadania użytkowników powinny zapewniać tylko taką ilość szczegółów i informacji, jaka jest wystarczająca do rozsądnego oszacowania czasu potrzebnego na ich przetworzenie i implementację. Gdy nadejdzie czas implementacji danego opowiadania wykonawcy kontaktują się z klientem, aby następnie otrzymać dokładniejszy opis wymagań. W wyniku otrzymania dalszych informacji projektanci mogą ocenić jak długo będzie trwała implementacja oczekiwań. Każde opowiadanie zabiera od jednego do nawet trzech tygodni pracy (-oczywiście, jeśli wszystko pójdzie „idealnie”, tzn. z niewielką ilością przerw przy krótkim opowiadaniu i opisie klienta). Faktycznie plan ten ulega często zmianie ze względu na możliwość dłuższych przerw lub w przypadku, gdy opowiadanie klienta odnośnie danego systemu będą dłuższe, a co za tym idzie i cały system będzie bardziej drobiazgowy i dokładny. Inną cechą różniącą opowiadania i specyfikację wymagań jest akcent na potrzeby użytkownika. Powinno się unikać szczegółów, specyficznych technologii, struktury bazy danych i algorytmów. Powinno się próbować utrzymać historie skoncentrowane wokół potrzeb i korzyści klienta, nie wdając się na tym etapie w szczegóły samego interfejsu aplikacji.
Planowanie publikacji.
Zwołuje się okresowo spotkania w celu opracowania planu publikacji. Planowanie to służy do ustalenia kierunku rozwoju projektu oraz do określania kolejnych iteracji. Spotkaniem kieruje zbiór odpowiednich reguł, które zezwalają wszystkim ludziom zaangażowanym w tworzenie projektu, na podejmowanie decyzji w zależności od ich kompetencji. Zasady, które obowiązują podczas spotkania tworzą metody negocjacji planu projektu oraz jego zatwierdzenia. Zasadniczym punktem spotkania jest ocena każdego z opowiadań i przypisanie mu odpowiedniej liczby, określającej szacunkową ilość tygodni, jaka jest potrzebna do realizacji danego zadania. Liczba ta nie uwzględnia żadnych innych obowiązków i wynikłych z nich opóźnień, zakłada ona po prostu idealną sytuację, gdy możemy poświęcić cały dostępny czas na realizację danego przedsięwzięcia. Nie bierzemy tu pod uwagę żadnej dodatkowej pracy, jednakże dodatkowo wliczamy testowania.
Jak już wcześniej wspomniałem klient jest członkiem grupy projektowej dlatego też to on decyduje, które opowiadania są ważniejsze lub mają większy priorytet na wykonanie, a które mniejszy. Można planować określając czas lub zakres realizacji. Za pomocą wcześniej już wyliczonej szybkości projektowania można wyznaczyć ile opowiadań lub historii może powstać w ciągu zadanego czasu lub jak długo zajmie ukończenie prac nad danym zbiorem ( -zakresem) opowiadań. Jeśli planujemy określając przy tym czas, robimy to w ten sposób, iż mnożymy liczbę dostępnych iteracji przez prędkość projektowania obliczając w ten sposób ilość opowiadań zdolnych do realizacji w danej jednostce czasu. Jeśli z kolei planujemy określać zakres opowiadań, wtedy dzielimy sumę tygodni oszacowaną na ich podstawie przez prędkość projektowania. Uzyskujemy w ten sposób liczbę iteracji potrzebnych do ukończenia wersji. Poszczególne iteracje są planowane dokładnie tuż przed ich rozpoczęciem i nigdy nie ustala się z góry ich przebiegu.
Spotkania, które są przeprowadzane w celu opracowania odpowiedniego planu wersji, zwane także z angielskiego „grą planistyczną” mają swoje reguły, których opis można znaleźć w tzw. „repozytorium wzorców Portland”. Jeśli dany plan, został źle przyjęty przez kierownictwo wtedy opracowuje się nowy plan publikacji, akceptowalny przez wszystkie strony. Dany plan publikacji negocjuje się zarówno z developerami, klientem jak i kierownictwem, do czasu, aż wszyscy zgodzą się na jego przebieg.
Rys. 6 - Gra planistyczna.
Głównymi założeniami planowania publikacji jest opisywanie projektu czterema wielkościami:
1)zakresem - opisującym jak dużo jest do zrobienia.
2)zasobami - określa ile mamy do dyspozycji osób.
3)czasem - ukazuje nam, kiedy dany projekt, albo wersja będzie ukończona.
4)jakością - charakteryzuje jak dobre będzie oprogramowanie, nad, którym pracujemy, i jak dokładnie zostanie ono przetestowane.
Kierownictwo może określić tylko trzy z nich, nie koniecznie jednak wybiera wszystkie. Co do czwartej to dostajemy ją już zawsze podczas samej realizacji planu publikacji. Należy tu zauważyć, iż obniżenie jakości poniżej doskonałości ma nieprzewidywalny wpływ na trzy pozostałe cechy. W istocie mamy, więc do dyspozycji tylko 3 parametry, które aktualnie możemy chcieć zmienić.
Oprócz samego negocjowania i prac w projekcie developerzy powinni zapanować także nad klientami, którzy chcą, aby właśnie ich projekt został natychmiast ukończony poprzez zaangażowanie do pracy jak największej liczby ludzi.
Plan wydania.
Plan ten określa, które opowiadania mają zostać zaimplementowane w danej wydaniu systemu oraz w jakim terminie należy się spodziewać tego systemu. Dzięki takiemu podejściu daje się użytkownikom możliwość wyboru, który zestaw opowiadań zostanie zaimplementowany podczas najbliższego planowania iteracji. Wybrane przez klienta opowiadania są przekładane na odrębne ćwiczenia programistyczne do zaimplementowania w czasie odpowiedniej iteracji. Opowiadania takie oprócz samego przekładania na kod są również zamieniane na testy akceptacyjne, które tworzy się podczas iteracji. Testy te uruchamia się w czasie bieżącej, a także w późniejszych iteracjach w celu weryfikacji, które historie zostały ukończone prawidłowo. Dzięki temu można w szybki sposób stwierdzić, iż ukończyło się dany rozdział, a co za tym idzie można kontynuować dalszą pracę. Gdy tempo projektowania w sposób drastyczny ulegnie zmianie na gorsze, wyznacza się spotkania z klientem w celu ustalenia nowego planu wersji.
Regularna publikacja nowych wersji.
Producenci, czyli inaczej mówiąc twórcy projektu muszą uświadomić sobie, aby regularnie wypuszczać nowe wersje swojego systemu, nad którym pracują lub pracowali. Wynika to z faktu, iż dany producent stosuje iteracyjne podejścia do tworzenia oprogramowania.
Częste spotkania, które poświęca się planowaniu nowych ulepszonych lub poprawionych wersji służą do ujawnieniu drobnych elementów funkcjonalności, które mogą być w niedługim czasie zaimplementowane. Należy tu zaznaczyć, że klient posiada na bieżąco dostęp do aktualnej wersji środowiska, dzięki czemu może dzielić się spostrzeżeniami z wykonawcami projektu.
Szybkość projektowania.
Jest miarą określającą jak szybko może zostać ukończy dany projekt. Często zamiennie używa się również współczynnika obciążenia, jednakże prędkość projektowania wydaje się być znacznie użyteczniejsza. Jeśli ma być to pomocne, to można również używać współczynnika obciążenia, i na jego podstawie określać szacunkową prędkość projektowania, którą można wykorzystać. Aby określić tempo projektowania należy po prostu zliczać ile opowiadań użytkowników lub ile zadań do zaimplementowania zebraliśmy podczas aktualnej iteracji.
Podczas danego spotkania planującego wersję można zweryfikować ile pozostałych oraz nowych historii w najbliższym czasie zostanie zaimplementowanych, obliczając to na zasadzie ilości już zrobionych opowiadań, które wdrożono w życie. Ponadto w czasie takiego spotkania twórcy mogą przypisać odpowiednią liczbę dni do prac nad odpowiednim zadaniem, która to wartość równa jest prędkości projektowania zmierzonej podczas poprzednich iteracji. Ten zmyślny, a zarazem i prosty mechanizm pozwala producentowi odnaleźć się po trudnej iteracji. Podczas projektowania możliwa jest również kilkukrotna zmiana prędkości, zarówno w górę jak i w dół. Wynika to głównie z faktu czy developerzy mają obszerniejsze i bardziej skomplikowane historie do zaimplementowania czy nie. Kiedy szybkość rośnie, developerzy szybciej realizują zadane historie, a co za tym idzie mogą wcześnie dopytywać się klientów o dalsze opowiadania, które muszą wykonać. Natomiast, kiedy szybkość maleje znaczy to, że na dane zadania została przewidziana zbyt mała liczba jednostek czasu, przez co należy dokonać pewnych korekt w dalszym planowaniu
Współczynnik obciążenia.
Współczynnik ten jest równy rzeczywistym, kalendarzowym dniom, które są niezbędne do zrealizowania danego zadania, podzielone przez liczbę dni tzw. "idealnych".
Pod terminem „dni idealnych” rozumiemy dni, w które moglibyśmy się całkowicie poświęcić na zadany projekt (-bez przerwy), jednakże w rzeczywistych realiach nie jesteśmy w stanie tego zrobić. Współczynnik obciążeniowy opisuje liczbę dni, jaką będziemy musieli poświęcić na zrealizowanie danego zadania. Współczynniki od 2 do 5 oznacza normę. Współczynnik o numerze 2 przedstawia optymistyczną wizję projektu, z kolei 3 to technologia typowa. Czwórka i piątka natomiast stosowane są w projektach, które wymagają użycia technologii nietypowych. „Ron Jeffries radzi używania trójki w początkowej fazie nowego projektu.” Po wybraniu już odpowiedniego współczynnika należy mierzyć i śledzić go, dodatkowo przy tym zwracając uwagę na tempo programowania w trakcie całego projektu. Współczynnik obciążenia nie może stać się wyznacznikiem do porównywania dwóch projektów! Każdy z projektów, jak również zespołów, który nad nim pracował jest oryginalny i niepowtarzalny, dlatego też każdy projekt będzie miał inny współczynniki obciążenia! „Jeśli współczynnik zmieni się w sposób dramatyczny, należy zwołać spotkanie, aby ponownie ocenić i przenegocjować plan publikacji. Należy się spodziewać, że kiedy system ruszy, współczynnik ponownie ulegnie zmianie z powodu zdań podtrzymujących.”
Planowanie iteracji.
Spotkania poświęcone planowaniu są zwoływane na początku każdej z iteracji w celu opracowania jej jak najlepszego planu, który uwzględniłby zadania dla programistów. Każda iteracja może trwać od 1 do nawet 3 tygodni. Jak już wcześniej wspomniałem klient wybiera odpowiednie opowiadania z planu wersji, które mają być zaimplementowane jako pierwsze podczas bieżącej iteracji. Oprócz tego dodatkowo są wybierane do przerobienia testy akceptacyjne, które wcześniej zakończyły się niepowodzeniem. Każde z zadań powinno wymagać od 1 do 3 "idealnych dni" do wykonania. Pisząc "idealny dzień" należy mieć na myśli czas, który należy poświęcić (- bez przerw) bez uwzględnienia niespodziewanych sytuacji, jakie mogą spowodować przerwanie pracy. Zadania, które trwają krócej niż 1 dzień, mogą zostać połączone w jedną wspólną grupę. Natomiast zadania, które trwają dłużej niż 3 dni powinny zostać ponownie rozpatrzone. Po wybraniu odpowiednich zadań i testów programiści podpisują się pod wybranymi ćwiczeniami i oceniają ile czasu zajmie im ich ukończenie. Ważny jest fakt, iż dana osoba podejmująca się odpowiedniego zadania sama musi określić jak długo może zająć jej jego wykonanie.
Prędkość projektowania, która została wcześniej określona jest używana, aby wyliczyć czy iteracja jest już zakończona czy może jeszcze nie. Jeśli bieżąca iteracja jest zbyt duża, klient musi wybrać część opowiadań do odłożenia na później. Jeśli iteracja jest za mała można zaakceptować inne opowiadania. „Prędkość w dniach i zadaniach ( -planowanie iteracji) ma większe znaczenie niż prędkość w tygodniach i opowiadaniach ( -planowanie publikacji), gdyż jest bardziej dokładna.”
Przenoszenie ludzi między zadaniami.
Według praktyk, jakie stosuje się w metodologii XP należy zmieniać ludzi pracujących nad projektem, po to, aby uniknąć znaczącego odpływu wiedzy lub wystąpienia tzw. „wąskiego gardła kodowania”. Może zdarzyć się sytuacja taka, iż jedyna osoba, która pracuje nad wyznaczonym zadaniem, zdecyduje się odejść z zespołu. Wówczas można stwierdzić, że dany projekt wlecze się w „żółwim tempie”. Niektóre firmy często stosują tzw. "szkolenia poprzeczne", aby uchronić te obszary wiedzy, które łatwo mogą utracić. Kiedy zmienia się ludzi pracujących w obrębie głównego kodu programu, oraz dodatkowo łączy się to z programowaniem w parach, to stosuje się właśnie metodę "szkoleń poprzecznych". Sytuacja w takim przypadku zmienia się diametralnie z takiej, gdzie jedna osoba wie wszystko o danej sekcji kodu, na taką, gdzie wszyscy członkowie zespołu znają większą część tegoż kodu w poszczególnych sekcjach. W takim wypadku zespół jest o wiele bardziej "elastyczny”, oraz odporny na nieprzewidziane problemy związane chodź by z utratą jednego z członków grupy, ponieważ wszyscy posiadają wystarczającą ilość informacji o każdej części systemu, która jest opracowywana. Ponadto zamiast posiadać małą grupkę ludzi, którzy są przeciążeni pracą w trakcie, gdy reszta zespołu nie ma nic do roboty, można uczynić produktywnym cały zespół. Dowolna ilość programistów może zostać przypisania do najbardziej pracochłonnym i wymagających zadań. Płynne balansowanie takim przepływem ludzi jest spełnieniem marzeń większości menadżerów w firmach i korporacjach.
Tak jak wcześniej wspomniałem o zaletach szkoleń poprzecznych tak należy teraz wspomnieć o zastosowaniu programowania w parach. Dzięki stosowaniu tej metody mamy możliwość wymiany myśli i pomysłów, ponadto nie musimy martwić się o utratę produktywności pracy. Jeśli zajdzie taka potrzeba jedna osoba w parze może zawsze zostać wymieniona na inną, dzięki czemu nowa osoba wchodząca na miejsce poprzedniej ma możliwość zapoznania się z daną częścią kodu, nad, która dana para pracowała oraz dodatkowo może wprowadzić nowe i świeże pomysły do danego zadania.
Codzienne "spotkania na stojąco".
Głównym założeniem tej praktyki jest jak najefektywniejsza komunikacja pomiędzy członkami zespołu. Codzienne poranne spotkania, mają głównie na celu wymianę informacji o napotkanych już problemach, możliwościach ich rozwiązań, a także motywowania całego zespołu do koncentrowania się na sprawach najistotniejszych. Wszyscy zebrani członkowie grupy projektowej stoją w kole, co pozwala uniknąć długich dyskusji i jest bardzo efektywne. W projekcie ceni się czas, bo „czas to pieniądz”, dlatego powszechnie uważa się, iż lepiej zorganizować jedno krótkie, ale obowiązkowe spotkanie, niż urządzać ich wiele, na których obecnych jest zaledwie kilku developerów. Takie spotkania mogą również być urządzane spontanicznie, przed komputerem, gdzie można na miejscu testować kod, a nowe pomysły od razu wcielać w życie.
Naprawa XP, kiedy się zepsuje.
Inaczej mówiąc usprawnij (-napraw) ten proces, kiedy zawiedzie. Można również wprowadzać zmiany, jeśli coś nie funkcjonuje prawidłowo. Należy wtedy przestrzegać reguł do momentu, gdy nie zmieni ich zespół. Trzymanie się ustalonego zestawu zasad to jedyny sposób, aby sprostać odpowiednim wymaganiom. Należy odbywać spotkania, na których można ustalić, co działa, a co nie oraz obmyślić możliwości ulepszania Extreme Programming.
1.4.2 Projektowanie - odpowiednie praktyki, wskazówki i szczegóły.
Prostota stanowi klucz do sukcesu.
Nie od dziś wiadomo, iż ukończenie prostego projektu zawsze zabiera mniej czasu niż złożonego. Dlatego powszechnie uważa się, iż należy wykorzystać jak najprostszy wariant, który będzie działał zgodnie z naszymi założeniami. Jeśli zdarzy się, że natrafimy na coś skomplikowanego - powinno zamienić się to na jego prostszy odpowiednik. Zawsze szybciej i taniej jest pozbyć się złożonego kodu teraz, niż później, dzięki czemu możemy zaoszczędzić wiele czasu na późniejsze upraszczanie już wykorzystywanego kodu.
Odpowiedni wybór standardu nazewnictwa.
Przy pracach nad projektem często określa się system tzw. przenośni, aby zachować zgodność w nazywaniu klas i metod. To jak nazywane są obiekty jest bardzo ważne dla zrozumienia całego projektu systemu, a także późniejszego wielokrotnego używania kodu. Jeśli dzięki odpowiedniemu nazewnictwu możemy domyślić się jak coś zostało nazwane, zaoszczędzimy dużo czasu na jego zgadywanie. Opisy obiektów, powinny być tak nazwane, aby osoby, które chcą odnosić się do nich, mogły robić to bez potrzeby poznania dokładnej wiedzy na temat działania projektu. Przykładem takiego nazewnictwa był np. system rozliczeń firmy, Chrysler, który został zbudowany w oparciu o elementy linii produkcyjnej, z kolei u Forda samochody były sprzedawane jako struktury złożone z komponentów.
Utwórz rozwiązanie impulsowe.
Dzięki takiemu rozwiązaniu można znaleźć wiele odpowiedzi na trudne problemy techniczne lub dotyczące samego projektu. Rozwiązanie impulsowe to bardzo prosty program, którego zadaniem jest wyszukiwanie potencjalnych rozwiązań danego problemu. Można np. zbudować system, który zajmuje się wyłącznie analizą problemu i pomija inne aspekty, jednakże większość tego typu programów nie jest wystarczająco dobra, by używać ich przez dłuższy czas, tak, więc nie należy się spodziewać, że dany program będzie pracował dla nas wiecznie, ponieważ w końcu będzie trzeba się go pozbyć. Głównym założeniem systemu jest zmniejszenie, na ile to tylko możliwe samego ryzyka wystąpienia problemów typu technicznego, a także zwiększenia wiarygodności oceny opowieści użytkowników. Kiedy trudności techniczne zagrażają rozwojowi systemu, wybiera się dwójkę programistów, którzy zajmą się tym problemem przez tydzień lub dwa i spróbują zmniejszyć potencjalne ryzyko wystąpienia tej awarii.
Nie dodawaj funkcjonalności za wcześnie.
Większość ludzi kusi, aby dodać funkcjonalność teraz ( -wcześniej) niż później, ponieważ obecnie wie dokładnie jak jej użyć, a ponadto mogłoby to ulepszyć system. Takiej osobie wydaje się, że byłoby znacznie szybciej dodać ją właśnie teraz. Jednakże ludzie tacy muszą sobie cięgle powtarzać, że tak naprawę ta funkcjonalność nie będzie potrzebna. Dodatkowa funkcjonalność jedynie spowolni pracę takiej osobie, a możliwe również, iż całej grupie i dodatkowo zmarnuje zasoby.
1.4.3 Implementacja - odpowiednie praktyki, wskazówki i szczegóły.
Odbiorca jest zawsze dostępny.
Jednym z niewielu wymagań programowania ekstremalnego (XP) jest stała dostępność do klienta. Nie tylko po to, aby taka osoba mogła pomagać zespołowi wykonawców, ale również po to, aby stała się jego częścią. Wszystkie fazy projektu opartego o metodologię XP wymagają komunikacji z odbiorcą, najlepiej twarzą w twarz, na miejscu. Uważa się, iż najlepiej po prostu przypisać jednego lub kilku przyszłych użytkowników do zespołu. Przy okazji przypisywania, dużą uwagę zwraca się na to, aby osoby te znały się na rzeczy, a nie byli to jacyś praktykanci, których wyznaczono, nie chcąc marnować czasu bardziej wykwalifikowanych pracowników - „potrzebni są eksperci, a nie aktorzy ich grający!”
Podczas spotkań związanych z planowaniem wersji klienci uzgadniają, które z opowiadań mają być włączone do kolejnych wersji. Mogą oni także ustalić termin publikacji. Ponadto klienci podejmują te decyzje w oparciu o własne cele. Spotkania te są używane do określenia mniejszych, inkrementacyjnych publikacji, aby zapewnić jak najwcześniejsze dostarczenie pożądanej funkcjonalności do odbiorcy. Daje to użytkownikom możliwość wcześniejszego wypróbowania systemu i szybszego odzewu do developerów.
Ponieważ szczegóły są pomijane w opowiadaniach, developerzy będą musieli kontaktować się z odbiorcami w celu zebrania odpowiedniej liczby informacji, potrzebnych do opracowania zadań programistycznych - projekty na większą skalę wymagają stałego zaangażowania ze strony klienta.
Użytkownik także jest stale potrzeby do pomocy przy testach funkcjonalności, kiedy trzeba będzie stworzyć dane testowe, a zamierzone wyniki oszacować i zweryfikować. Testy funkcjonalności sprawdzają czy system jest gotowy do publikacji i wdrożania. Może zdarzyć się, że system nie przejdzie wszystkich testów wymaganej funkcjonalności, wtedy klient będzie musiał przejrzeć ich wyniki i zdecydować, czy zgodzi się na jego odbiór czy też wstrzyma wydanie.
Odpowiednie standardy kodowania.
Kod musi być formatowany zgodnie z przyjętymi przez grupę standardami i zasadami. Standardy te utrzymują cały zapis spójnym i łatwym do odszyfrowania oraz przebudowy dla całego zespołu.
Najpierw arkusze testujące.
Tworzenie testów znacznie pomaga programistom uzmysłowić sobie, co tak naprawdę mają wykonać. Bez testów programista może nie być pewny, czy to, co zrobił jest wystarczające. Konsekwencją takiego przypadku mogą być zbędne dodatki i nowe błędy. Jeśli stworzy się najpierw arkusz testujący to dokładnie deweloper wie, kiedy ukończył swoje zadanie -w przypadku, gdy wszystkie testy wykonały się poprawnie. Dodatkowo trzeba tu też nadmienić, że zyskuje także sam projekt systemu w wyniku jego prawidłowego, a nieraz i szybszego implementowania. Zdarza się jednak, że oprogramowanie, które jest tworzone jest na tyle skomplikowane, iż jego testowanie musi być odłożone na później. Takie systemy przeważnie opierają się na wczesnej implementacji i późniejszym testowaniu, często przez inny zespół. Poprzez tworzenie pierwszych testów z góry zostaje wywarty nacisk na sprawdzenia wszystkiego, co zostało stworzone i czego oczekuje klient. Odbija się to na projekcie, który sam staje się łatwiejszym do testowania, a kod, który będzie tworzony również będzie prosty i zwięzły.
Programowanie w parach.
Każdy kod dołączony do kolejnego wydania jest tworzony przez dwie osoby pracujące razem na jednym komputerze. Programowanie takie zwane potocznie „programowaniem w parach” zwiększa jakoś tworzonego oprogramowania nie wpływając przy tym na czas
jego dostarczenia. W wyniku doświadczeń, które odbywały się w wielu projektach wiadome jest, że dwie osoby, które pracują na jednym komputerze dostarczą tyle samo funkcjonalności, co dwie osoby pracujące oddzielnie, tyle, że w pierwszym przypadku kod będzie znacznie bardziej dopracowany.
Najlepszą metodą programowania w parach jest po prostu posadzenie obok siebie przed monitorem dwóch programistów, którzy będą przekazywać sobie myszkę i klawiaturę. Gdy jedna osoba pisze i myśli nad metodą, którą właśnie tworzy, druga w tej chwili myśli strategicznie o tym, jak ta metoda sprawdzi się w tej klasie i odwrotnie.
Sekwencyjna integracja kodu.
Bez kontrolowania integracji kodu źródłowego programiści po lokalnym przetestowaniu swojego kodu mogą umieszczać wyniki swoich prac w tzw. „publicznym repozytorium”. W wyniku takiego działania może zaistnieć wiele konfliktów, które ujawnią się w późniejszym czasie. W niektórych projektach, aby uniknąć tego typu nieprzyjemności, zdarza się, że developerzy opiekują się wydzielonymi klasami. Właściciele tych klas dbają o to, by ich kod był jasny, spójny i właściwie udostępniony. Takie działanie zmniejsza ryzyko, jednakże nie eliminuje całkowicie problemów związanych z powiązaniami pomiędzy klasami, które nadal mogą być niewłaściwe.
Do innych przypadków, jakie są stosowane przez grupy projektowe zalicza się wyznaczenie osoby tzw. „integratora” lub całej grupy osób, które zajmują się tylko i wyłącznie integracją. Takie podejście ma swoje minusy związane z tym, iż w jednym czasie do grupy osób może napłynąć zbyt duża liczba przetestowanych kodów gotowych do integracji, przez co cały proces integracji znacznie się wydłuża powodując zator w prawidłowym i płynnym działaniu całej grupy. Rozwiązaniem tego problemu jest ściśle sekwencyjna (lub jednowątkowa), samodzielna integracja kodu, przez programistów połączona ze zbiorową własnością. Cały kod źródłowy jest publikowany do repozytorium w turach, to jest, tylko jedna para programistów integruje, testuje i wprowadza zmiany w repozytorium w danej chwili. Taka kolejkowana integracja pozwala na jednoznaczne zidentyfikowanie ostatniej wersji systemu. Nie znaczy to, że nie można integrować swoich poprawek z ostatnią wersji, kiedy tylko zechcemy. Po prostu nie możemy publikować swoich zmian do repozytorium dla własnego zespołu, jeśli nie przyszła nasza kolej. Aby zastosować tzw. kolejkowanie w zespole można użyć fizycznego klucza ( -token) przekazywanego między developerami, lub przeznaczyć do tego jeden komputer, na którym dany zespół może pracować. Takie podejście plus częsta integracja i publikacja kodu skraca czas potrzebny na trzymanie blokady, a zatem także czas oczekiwania na otrzymanie pozwolenia na integrację.
Dedykowany komputer publikujący.
Pojedynczy komputer służy do kolejnych publikacji oraz odgrywa rolę fizycznego dowodu kontroli tej publikacji. Dzięki niemu programiści mają możliwość zobaczenia ostatniego słowa w bieżącej konfiguracji.
Komputer umożliwia projektantom przekonanie się, kto i kiedy publikuje, przez co w danej chwili nie mogą wprowadzać dodatkowych zmian.
Częsta integracja.
W miarę ciągła integracja pozwala na wczesne zapobieganie lub wykrywanie problemów z kompatybilnością. Chodzi tu o to, że znacznie łatwiej i bezpieczniej jest wprowadzać częściej drobne poprawki do głównego kodu niż za jednym zamachem, w chwili, gdy przychodzi czas oddania wyników, walczyć za wprowadzeniem opracowywanych w ciągu kilku ostatnich tygodni zmian do tego kodu, który na domiar złego już w tym czasie ewoluował. Dlatego zawsze należy pracować opierając się na aktualnej wersji systemu.
Developerzy powinni integrować i publikować kod do repozytorium, co kilka godzin, kiedy to tylko możliwe. W żadnym razie, nigdy nie powinni przetrzymywać zmienionej wersji dłużej niż jeden dzień. Ciągła integracja często pozwala uniknąć rozbicia prac developerskich oraz pozwala pracować na ostatniej, najnowszej wersji kodu. Wprowadzanie poprawek do i tak już nieaktualnego kodu źródłowego może tylko wprowadzić chaos i narobić problemów w momencie integracji.
Zbiorowa własność kodu.
Zbiorowa własność kodu motywuje wszystkich do zasilania projektu nowymi pomysłami. Dzięki niej każdy programista może zmienić dowolną linijkę kodu dodając nową funkcjonalność, poprawiając błędy lub przebudowując istniejące rozwiązanie.
Kiedy zapewnimy miejsce do działania, każdy będzie mógł wprowadzić zmiany w dowolnej metodzie którejkolwiek z klas i opublikować je do repozytorium kiedy zajdzie taka potrzeba. Gdy połączymy to z częstą integracją developerzy rzadko będą zauważać, iż klasa została rozszerzona czy poprawiona. W praktyce zbiorowa własność kodu lepiej się sprawdza niż umieszczanie pojedynczej osoby, mającej strzec odpowiednich klas. Zwłaszcza, że taka osoba może w każdej chwili opuścić nasz projekt.
Bez nadgodzin.
Praca po godzinach wysysa ducha i motywację zespołu. Projekty, które wymagają nadgodzin, aby zostały ukończone na czas i tak się spóźnią, niezależnie od tego, co zostanie zrobione. Zamiast takiego podejścia należy jak najlepiej wykorzystać spotkania poświęcone planowaniu publikacji do zmian zakresu prac lub ich czasu.
1.4.4 Testowanie - wskazówki i szczegóły.
Arkusze testowe.
Arkusze testów są jednym z kamieni węgielnych programowania ekstremalnego (XP). Jednakże testowanie w XP nieco różni się od zwykłego testowania ze względu na to, iż najpierw tworzy się lub ściąga środowisko, które pozwoli je przeprowadzić w sposób automatyczny, a później testuje się wszystkie klasy w systemie. Proste metody typu get/set w testach są przeważnie pomijane. Arkusze testów są publikowane do repozytorium razem z kodem, który jest testowany. Kod, który nie jest pokryty testami nie może być opublikowany. Jeśli odkryje się, że jakiegoś testu brakuje, natychmiast się go tworzy.
Największą trudnością w prowadzeniu arkuszy testów jest nieubłagalnie zbliżający się „deadline”. Aby przyspieszyć przeprowadzanie testów, a co za tym idzie zaoszczędzić nieco cennego czasu stosuje się automatyczne testy, które potrafią wynajdywać błędy i zapobiegać nim. Im trudniej jest opracować określony test tym bardziej jest on potrzebny, gdyż zaoszczędzi on później grupie wiele czasu. Koszty potrzebne na tworzenie danych testów często zwracają się z nawiązką.
Do popularnych błędów w czasie tworzenie systemu dla klienta jest przekonanie, że testy mogą być pisanie w przeciągu trzech ostatnich miesięcy projektowania. Takie podejście jest dość ryzykowne, ponieważ bez arkuszy testów, prace developerskie przeciągają się, pochłaniając i te trzy miesiące, a nawet i więcej. Kiedy z kolei znajdzie się odrobina dostępnego czasu trzeba się liczyć z tym, iż aby powstały dobrej jakości testy potrzeba jeszcze dodatkowego czasu na to, aby one dojrzały. Odkrywanie potencjalnych problemów, które mogą wystąpić pochłania właśnie ten dodatkowy czas. Żeby testy były dostępne, kiedy będą potrzebne powinno zacząć się je tworzyć od zaraz.
Arkusze testów wspierają zbiorową własność kodu oraz umożliwiają refaktoryzację. Po każdej drobnej zmianie kodu, testy mogą zweryfikować i upewnić się, że zmiana w strukturze rozwiązania nie wpłynie na niepożądaną zmianę funkcjonalności. „Zbudowanie pojedynczego, uniwersalnego zestawu arkuszy testów do walidacji i testowania regresyjnego pozwala na częstą integrację kodu”. Można wtedy szybko zintegrować wszystkie ostatnie zmiany, po czym uruchomić najnowszą wersję zestawu testów. Jeśli kod nie przejdzie testu, oznacza to, iż jest niekompatybilny z poprzednią wersją. Wykorzystując automatyczne testowanie jest możliwe również dołączenie zbioru poprawek do ostatnio wypuszczonej wersji i opublikowanie ich w krótkim czasie. Częste dodawanie takich nowych funkcji wymaga zmiany arkuszy testujących, po to, aby te ogarnęły zmienioną funkcjonalność. Choć jest możliwe wprowadzenie błędu zarówno do kodu jak i do testu, w praktyce zdarza się to rzadko. Arkusze testujące zapewniają bezpieczną sieć testów regresyjnych i zatwierdzających, dzięki czemu można upraszczać i integrować kod bardzo efektywnie. Tworzenie takich arkuszy testów przed kodem ma jeszcze inne dodatkowe zalety, takie jak utrwalanie wymagań, przez co programiści mogą skupić się na konkretnym problemie.
Gdy znajdziemy błąd.
Po ujawnieniu się określonego błędu w kodzie tworzone są odpowiednie testy, które mają za zadanie ostrzegać przed jego ponownym wystąpieniem. Błąd w wykonaniu wymaga testu akceptacyjnego, który będzie sprawdzał system pod jego kątem. Testy akceptacyjne tworzone jako pierwsze, jeszcze przed samym debugowaniem pozwalają użytkownikom na zwięzłe zdefiniowanie problemu i przedstawienie go programistom. Programiści z kolei mając wyszczególniony niespełniony test mogą skoncentrować swoje siły na rozwiązywaniu problemu i wiedzą, kiedy efekt zostanie osiągnięty. W przypadku, kiedy testy akceptacyjne zakończą się niepowodzeniem, developerzy tworzą mniejsze arkusze testujące, aby móc opisać defekt za pomocą większej ilości kodu i ukazać błąd z różnych punktów widzenia, w różnym kontekście. Obserwując interesujące nas arkusze testów można na bieżąco kontrolować, kiedy błędy zostaną poprawione. Gdy wszystkie arkusze przechodzą testy pomyślnie możemy ponownie uruchomić odpowiednie testy akceptacyjne by upewnić się, że problem na pewno został zażegnany.
Testy akceptacyjne.
Testy akceptacyjne tworzone są na bazie opowieści użytkowników. Podczas iteracji opowieści użytkowników (- wcześniej wybrane podczas spotkania planującego iterację) zostaną przetłumaczone na testy akceptacyjne. Kiedy opowieść zostanie prawidłowo zaimplementowana, użytkownik precyzuje scenariusz danego testu. Dana opowieść może mieć jeden lub więcej testów akceptacyjnych - tyle, aby mieć pewność, że funkcjonalność będzie działać prawidłowo. Testy akceptacyjne to „czarne skrzynki testów systemowych”. Każdy z tych testów ma za zadanie podać pewien oczekiwany wynik systemowy. Użytkownicy odpowiedzialni są za sprawdzanie prawidłowego przebiegu testów, a także za przegląd ich wyników. Te informacje pomagają im zdecydować o tym, które z oblanych testów są najważniejsze (najwyższej wagi). Testy akceptacyjne są także używane jako testy regresyjne stosowane jeszcze przed publikacją projektu.
Opowieść użytkownika nie jest uważana za kompletną, zanim nie przejdzie testów akceptacyjnych. Oznacza to, że dla każdej iteracji należy stworzyć nowy test akceptacyjny. W przeciwnym wypadku zespół developerów ogłosi zerowy postęp.
Gwarancja jakości (QA) jest zasadniczą częścią programowania w XP. Przy niektórych projektach QA jest przeprowadzana przez członków specjalnie do tego powołanej grupy, podczas gdy przy innych - grupa ta jest po prostu częścią grupy developerskiej.
Testy akceptacyjne powinny być zautomatyzowane po to, by można je często uruchamiać. Wynik testu akceptacyjnego ogłaszany jest zespołowi, którego zadaniem jest takie zaplanowanie czasu każdej iteracji, by poprawić wszystkie z oblanych testów. Testy akceptacyjne poprzednio nazywane były testami funkcjonalnymi.
1.5 Podsumowanie.
Głównym założeniem Extreme Programmig, podobnie jak Rational Unified Process było takie uproszczenie i pomoc ludziom w projekcie, aby możliwe stało się tworzenie oprogramowania jak najmniejszymi kosztami, a co za tym idzie eliminację jak największej liczby nie potrzebnych błędów. Można powiedzieć, że obie te metodyki stały się swoistymi zbiorami wiedzy, jak należy postępować w danym projekcie - zwłaszcza, że obie metodyki wywodzą się z obserwacji innych projektów, oraz wyciągania z nich odpowiednich lekcji. Jeśli chodzi o metodykę XP jest to właściwie zbiór zasad jak należy postępować. Niema tu wsparcia od strony odpowiednich programów - jak to ma miejsce w RUP-ie. Ponadto przez to, że XP - tak jak metodyki kaskadowe, jest darmowy - ma większą rzeszę ludzi, do których może on trafić, co wiąże się z tym, iż większa ilość ludzi może go używać. RUP przez to, że jest komercyjny i drogi w zakupie traci na swojej popularności, co w konsekwencji przemawia na jego niekorzyść.
W metodyce XP duży nacisk postawiono na komunikację - czego nie można powiedzieć o pozostałych metodologiach. Komunikacja w XP odbywa się nie tylko w obrębie danej grupy projektowej, ale również pomiędzy klientem a grupą. Takie podejście sprawia, że projektanci i programiści dokładnie wiedzą, czego oczekuje klient, co dodatkowo przyczynia się do rzadszych i mniejszych poprawek w systemie. Gdyby nie fakt, iż Extreme Programming lepiej radzi sobie z małymi i średnimi projektami mógłby być jednym z głównych metodologii stosowanych na świecie. Jednakże w wyniku braku odpowiedniego wsparcia narzędziowego dużym problemem staje się zastosowanie tej metodologii do dużych projektów, gdzie najlepsza do zastosowania jest metodyka Rational Unified Prosess.
II Rozdział - Metodologia Rational Unifed Process.
2.1 Wprowadzenie do Rational Unifed Process - krótka historia.
Rational Unifed Process (- w skrócie RUP) jest iteracyjną metodyką tworzenia oprogramowania stworzoną przez Rational Software Corporation, która stała się ważną metodyką w IBM (jest częścią Rational Method Composer [RMC], która pozwala na płynną ingerencje w proces). RUP nie jest sztywną metodyką, nakazującą tworzyć tylko i wyłącznie wytyczonymi ścieżkami, ale pozostawia wiele możliwości wyboru, eliminacji i adaptacji do istniejących warunków, zapotrzebowań. Zawiera uszeregowaną wiedzę, opartą na przykładowych schematach z wyszczególnionymi ścieżkami dla wielu rodzajów działalności.
Historia i podłoże RUP wywodzi się poniekąd ze spiralnego modelu Barrego Boehma, który wspólnie z Kenem Hartmanem stworzyli RUP-a. Pierwsza wersja (1995) nazywała się Rational Objectory Process (ROP) i budowano ją z myślą o obiektowości. W końcu pod kierownictwem Philippe Kruchten w 1998 ukazał się Rational Unified Process. Model był tworzony na podstawie analizy porażek wcześniejszych spokrewnionych modeli, twórcy sięgnęli do źródła by poznać przyczynę klęsk projektów. Czerpali też wiedzę z innych w tamten czas istniejących modeli. Główne przyczyny porażek jakie odkryli to :
Zarząd powoływany ad-hoc (w razie potrzeby)
Wieloznaczna i nieprecyzyjna komunikacja
Architektura procesów, która nie wytrzymywała pracy pod dużym stresem
Przytłaczająca złożoność
Niewykrywalne niespójności w specyfikacji, projekcie i implikacji
Niewydajne testy
Subiektywne zapewnienia o postępie projektu
Źle szacowane ryzyko
Propagacja niekontrolowanych zmian
Niewydajna automatyzacja.
Prześledzenie tych wad i ich analiza były głównym rdzeniem Rational Unified Process. Metodyka narodziła się w ten sam sposób jak inżynierowie tworzyli software - jest oparta na modelowaniu obiektowym i korzysta z UML-a.
2.2 Opis metodyki.
RUP nie jest jak książka - metodą wymyśloną raz i raz opublikowaną.
"Software processes are software, too" napisał Lee Osterwiel, profesor z University of Massachusetts co oznacza iż RUP został zaprojektowany, stworzony i wprowadzany jak każde inne narzędzie software'owe i posiada wiele podobieństw:
Został zaprojektowany i udokumentowany wykorzystując Unified Modeling Language (UML) - takie obiektowe podłoże czyni rdzeń metody bardzo wytrzymałym.
Został rozpowszechniony za pośrednictwem technologii sieciowej, a nie sucha, książkowa teoria.
Ciągle jest ulepszany i rozwijany (poprawki wychodzą średnio dwa razy na rok), zapewniając rzetelną i skuteczną metodę.
Z powodu swojej elektronicznej formy, może zostać zmodyfikowany i zaadoptowany przez konkretne warunki panujące w firmie
Został załączony w wielu narzędziach inżynierii oprogramowania, więc można oczekiwać kontroli i pomocy od strony programu [Rysunek VI - przyklad].
Rys. 7 - Przykładowa aplikacja wspomagająca proces projektowania w RUP.
2.3 Cechy charakterystyczne, architektura i zasada działania RUP-a.
Proces, który został ukazany na poniższym rysunku [Rys. 8] został zaprojektowany przy użyciu technik podobnych jak przy rozwoju software'u. Konkretnie, został oparty o UML. Rysunek ten przedstawia ogólną architekturę RUP-a, która składa się z dwóch struktur (wymiarów):
poziomy wymiar - reprezentujący czas i ukazujący cykl życia oraz rozwój.
pionowy wymiar - ukazujący przepływ (cykl) pracy rdzenia projektu, z uszeregowanymi logicznymi grupami aktywnymi według ich przyjętej natury.
Rys. 8 - Rational Unified Process.
Pierwszy wymiar reprezentujący dynamiczny aspekt procesu wyrażony w cyklach, fazach, iteracjach i kamieniach milowych. W RUP-ie produkt jest sukcesywnie budowany w oparciu o iteracje. To pozwala na testy i walidację zarówno zaprojektowanych pomysłów, jak i analizę ryzyka, która ujawni się we wczesnych fazach. Drugi wymiar reprezentuje zaś statyczny aspekt procesu opisanego w warunkach komponentów procesu: zadania, cykle, artefakty i role.
RUP = doświadczone techniki
RUP bazuje na wypracowanych nowoczesnych praktykach inżynierii programowania takich jak: iteracyjność, zarządzanie wymaganiami, architektura bazująca na komponentach, wizualizacja modelowania, bieżąco kontrolowana jakość, zmiany kontrolne w oprogramowaniu.
2.3.1 Iteracyjność
Większość grup programistycznych ciągle używa modelu kaskadowego w projektowaniu, wykonując w niezmiennej sekwencji fazy analizy wymagań, projektowania, implementacji, integracji i testowania. Ten mało wydajny system "usypia" kluczowych członków na dłuższe okresy i trzyma ich w tym stanie do końca cyklu projektu, kiedy problemy wydają się być ciężkie i nieopłacalne, a opóźnienia zaczynają zagrażać deadline'om. RUP, przeciwnie reprezentuje iteracyjne podejście, które jest lepsze z kilku powodów:
Pozwala wdrożyć osoby do zmieniających się warunków.
Prawdą jest, że wymagania ciągle się zmieniają, łącznie z wykluczaniem tych mało istotnych i to one najczęściej są przyczyną opóźnień, niezadowolonych klientów i sfrustrowanych deweloperów.
Integracja nie jest jednym "wielkim wybuchem" na końcu, zamiast tego elementy są integrowane progresyjne.
Z RUP-em to, co było ciągłą niepewnością i strachem odejmuje ok. 40% wysiłków na końcu - rozlatuje się na 6 do 9 mniejszych części integracji.
Ryzyko jest zazwyczaj odkrywane albo adresowane podczas integracji.
Z iteracyjnym podejściem można zidentyfikować wcześniej ryzyko. Podczas prowadzenia wcześniejszych części integracji, testuje się wszystkie komponenty, doświadczając wiele aspektów projektu, takich jak narzędzia, oprogramowanie poza dziedzinowe, ludzkie umiejętności itd. W takim wypadku ryzyko jest realne, jednakże można je zignorować, a nieplanowane ryzyko przynosi mniejsze straty.
Iteracyjne zarządzanie pozwala zarządowi taktycznie spojrzeć na zmiany projektu, bądź porównać z wcześniejszymi projektami. Daje to możliwość ukończenia projektu wcześniej ze zredukowaną funkcjonalnością - jeśli wymaga tego sytuacja.
Łatwiej jest zidentyfikować bieżące elementy zaprojektowane częściowo albo rozpoznać je podczas planowania. Recenzje projektów we wczesnych fazach pozwalają architektom ukazać potencjalne okazje, które można odłożyć "na potem", a zająć się inną częścią projektu.
Kiedy można poprawiać błędy po kilku iteracjach, architektura staje się bardziej spójna. Kiedy projekt migruje z początku do opracowania sprzeczności są wykrywane wcześniej, niźli później miałby powodować panikę.
Deweloperzy zdobywają doświadczenie, a ich zróżnicowane zdolności są w pełni wykorzystane podczas całego cyklu. Testerzy zaczynają testować wcześnie, technicy zaczynają projektować wcześnie itp. W nie iteracyjnym środowisku, ci sami ludzie czekaliby na swoją kolej, planując, ale nie czyniąc większych postępów. Wcześnie wykrywamy potrzebę dodatkowych szkoleń, bądź zasobów ludzkich.
Sam proces może być ulepszany i zmieniany przez cały czas.
Ostanie fazy w iteracji pozwalają nie tylko spojrzeć na to, co jest zrobione, ale i na to, co ma zostać zmienione w następnej kolejce.
9) Zarząd projektu często opiera się iteracyjności, widząc to jako rodzaj niekończącej się i niekontrolowanej ścieżki. W Rational Unified Process iteracyjność jest w pełni pod kontrolą; liczba, przebiegi i cele są skrzętnie planowane, a zadania i odpowiedzialność dobrze zdefiniowane.
2.3.2 Zarządzanie wymaganiami
Zarządzanie wymaganiami jest systematycznym podejściem aktywacji, organizacji, komunikacji i zarządzania zmianami wymagań. Korzyści są następujące:
Lepsza kontrola nad całością projektu (większe zrozumienie zachowań systemu, jak i zapobieganiu poślizgom wymagań).
Ulepszona jakość oprogramowania i zadowolenia klientów.
Fundamentalną metodą mierzenia jakości jest to czy system robi to, co powinien. Z RUP-em może to być łatwo wymierzone, ponieważ udziałowcy mają pojęcie o tym, co ma być zbudowane i przetestowane.
Zredukowane koszta i opóźnienia.
Naprawianie błędnych wymagań jest bardzo kosztowne, z efektywnym zarządzaniem można zmniejszyć te błędy we wczesnych fazach.
Poprawiona komunikacja zespołu.
Dobrze zarządzana specyfikacja wymagań, zrozumienie i postanowienia pośród udziałowców: użytkowników, klientów, zarządu, projektantów i testerów.
Ciężko jest zwykle spoglądać na tradycyjny obiektowo zorientowany model systemu i powiedzieć jak system robi to, co powinien. Ta trudność wywodzi się z braku konsekwencji i obawy przed podołaniem niektórych elementów. W RUPie use case'y niwelują obawę poprzez zdefiniowanie zachowania wykonywanego systemu.
Use case'y nie są wymagane w systemie obiektowo zorientowanym. Kiedy się jednak pojawiają kształtują ważne połączenie pomiędzy wymaganiami systemu a innymi artefaktami inżynierskimi, jak projektowanie czy testowanie.
RUP jest napędzany przez use-case'y co oznacza, iż odgrywają one główną rolę w przepływie pracy (workflow), zwłaszcza projektowaniu i testowaniu, projektowaniu interface'u użytkownika i zarządzania projektem. Są też niezbędne do modelowania biznesowego.
2.3.3 Architektura bazująca na komponentach.
Use case'y napędzają RUP-a poprzez cały cykl życiowy, lecz projektowanie koncentruje się na architekturze. Głównym celem we wczesnych iteracjach jest produkcja i walidacja architektury systemu. Na początku tworzy się prototyp, który z czasem przeradza się w finalny produkt.
Rational Unified Process dostarcza metodologii, systematyki w projektowaniu, rozwoju i walidacji architektury. Oferuje szablony do opisu architektury bazującej na koncepcji widoku wielorakich architektur. Projektowanie komponentu składa się ze specjalnych czynności, których celem jest identyfikacja restrykcyjności i znaczenia różnorakich elementów architektury, jak i pomocy, co do jej wyborów. Komponentem może być istotny element software'u: moduł, zestaw, albo podsystem, który wykonuje jakąś funkcję, ma jasną budowę i może być zintegrowany do wymaganej architektury. Projektowanie komponentowe może być zrealizowane w kilka sposobów:
W definicji modularnej architektury, identyfikacji, izolacji, projektowaniu, rozwoju i testowaniu jako w pełni ukształtowany element.
Elementy te mogą być oddzielnie testowanie i zintegrowane później z systemem.
Komponenty powinny być projektowane, tak, aby można ich było użyć ponownie. Takie komponenty są zazwyczaj większe niż proste narzędzia, czy biblioteki. Zawierają one pewne metody, często strzeżone, jakie stosuje się wewnątrz organizacji, ukazujące jej jakość i pozycję.
W chwili obecnej można łatwo zauważyć sukces takich większych komponentów jak np. CORBA, ActiveX, JavaBeans; bez których można się obejść, jednakże znacznie ułatwiają nam życie.
Ostatnie punkty ukazują przejście z programowania strukturalnego/obiektowego na komponentowe.
- Iteracyjność pozwala deweloperom na progresywną identyfikację komponentów i decyzje, który rozwijać dalej, którego użyć ponownie, a który zakupić.
- Skupienie się na architekturze pozwala na artykulację struktury. Architektura spaja komponenty i sposób, w jaki są zintegrowane, jak i fundamentalny mechanizm wzorców, z którymi współdziałają.
- Pomysły takie jak zestawy, podsystemy i warstwy są używane podczas analizy i projektowania dla organizacji komponentów i specyfikacji interface'ów.
- Testowanie i organizacja najpierw pośród pojedynczych komponentów, a później z pośród większych zbiorów.
2.3.4 Wizualizacja modelowania.
Modele są uproszczeniem rzeczywistości, pomagają nam zrozumieć kształt problemu jak i rozwiązania. Dzięki nim możemy w łatwy sposób ogarnąć rozumem wielkie systemy. Należy tu wspomnieć, iż dużą częścią RUP'a stanowi właśnie rozwój modeli.
Do pomocy w wizualizacjach modelowania służy w Rup'ie właśnie UML, który jest niczym innym jest graficznym językiem dla wizualizacji, specyfikacji, konstrukcji i dokumentacji artefaktów systemów oprogramowania ( -np. RUP2000 korzysta z UML ver 1.4.). Daje on standardowe zrozumienie planu systemu, pokrywając konceptualne fragmenty jak procesy biznesowe i funkcje systemowe, oraz również klasy zawarte w konkretnym języku programowania, schematy bazodanowe i komponenty do ponownego użytku. RUP opisuje, jakiego modelu potrzebujesz, dlaczego i jak go zrealizować.
2.3.5 Bieżąco kontrolowana jakość.
W metodyce Rational Unified Process nie występuje stanowisko kontrolera jakości ze względu na to, iż jest za nią odpowiedzialny każdy członek zespołu. W inżynierii oprogramowania, skupia się uwagę na dwóch aspektach: jakości produktu i jakości procesu.
2.3.6 Zmiany kontrolne w oprogramowaniu
Właściwie w iteracyjnym projektowaniu produkty często ulegają zmianom. By zapewnić łatwość planowania i wykonywania rozwoju poprzez możliwość rozwoju wymagań, iteracyjność nakłada nacisk na pozostawanie na właściwej ścieżce i dbaniu, aby każdy podlegał synchronizacji. Proces jest przygotowany na systematyczne zmiany, utrzymuje ścieżkę wolną od błędów, nieporozumień, lecz również od postanowień.
2.4 Podsumowanie.
Jak już wspomniałem w podsumowaniu poprzedniego rozdziału, zarówno RUP, jak i XP wywodzą się z obserwacji innych projektów. Co do dalszej genezy tych dwóch metodologii to można powiedzieć, że poszły one w radykalnie różnych kierunkach. W wyniku tego, iż RUP został przejęty przez firmę IBM stał się on produktem typowo komercyjnym, który jest wspierany przez szereg narzędzi - dlatego też jest on najlepszy do zastosowanie przy dużych projektach, niezależnie jak są one zidentyfikowane, czego niemożna powiedzieć o podejściu kaskadowym. Ponadto w wyniku swojej skrupulatności, która objawia się tym, iż sam RUP posiada w sobie 40 ról i dostarcza 80 artefaktów staje się on dość dokładny przy zastosowaniu w projekcie. To, na czym głównie skupia się ta metodyka to na odpowiedniej i dogłębnej standaryzacji, przez co częściej podczas tworzenia danego systemu mogą wyjść wszelkie problemy z integralnością całości, czego niemożna powiedzieć o dwóch pozostałych metodykach, w których takiego podejścia brak. Co do wad metodyki Rational Unified Process to możemy tu zaliczyć zbyt wysoki koszt zakupu tej metodyki, która jest w zasięgu ręki tylko dla większych firm i korporacji oraz brak pełnej komunikacji jaka objawia się w metodologii Extreme Programming i która jest bardzo pomocna podczas procesu produkcyjnego.
III Rozdział - Kaskadowe metody w tworzeniu oprogramowania.
3.1 Co kryje się pod pojęciem „model kaskadowy”.
Model kaskadowy (ang. waterfall approach) zwany inaczej wodospadowym jest jednym z pierwszych podejść, jakie inżynierowie stosowali przy produkcji oprogramowania. Jego nazwa została wprowadzona przez Winstona W. Royce w roku 1970, w czasie, kiedy Inżynieria Oprogramowania dopiero, co się rodziła, w artykule "Managing the Development of Large Software Systems" (zarządzanie tworzeniem dużych systemów informatycznych). Nazwa tego podejścia pochodzi od struktury, która przypomina formą właśnie wodospad lub kaskadę, gdzie tak jak woda spływa w dół kaskadowo tak inżynierowie postępują w projekcie - punkt po punkcie po kolei. Sam model jest dość prosty i łatwy do zastosowania w grupie projektowej. Niestety łatwość i prostota w tym modelu nie idą w parze z brakiem błędów i problemów. Podejście to stosuje się rzadko, głównie jednak w projektach o dobrze zdefiniowanych wymaganiach dla dobrze rozumianych zastosowań. Należy tu również wspomnieć, iż w podejściu tym niema wyznaczonych konkretnych narzędzi do pracy. Stosuje się takie narzędzia, które są odpowiednie dla poszczególnych grup projektowych. W obecnym czasie dość dużą popularnością cieszy się tu język UML, o którym była mowa już wcześniej, w samej metodyce RUP.
3.2 Ogólny opis cech podejścia kaskadowego.
Definiowanie i analiza wymagań.
Usługi, ograniczenia i cele systemu są ustalane w czasie narad z użytkownikami tegoż systemu, następnie są szczegółowo definiowane i służą jako specyfikacje do tworzenia danego produktu.
Projektowanie systemu i oprogramowania.
Proces projektowania systemu prowadzi do podziału wymagań na systemy sprzętu i oprogramowania. Po ustaleniu odpowiednich wymagań i podziale na systemy tworzy się ogólną architekturę tworzonego produktu. Projektowanie oprogramowania obejmuje identyfikowanie i opisywanie zasadniczych abstrakcji danego systemu i związki, jakie występują między nimi.
Implementacja i testowanie jednostek.
W tym kroku projekt oprogramowania jest realizowany w postaci zbioru programów albo jednostek programów. Testowanie jednostek polega na sprawdzeniu, czy każda z nich spełnia swoją specyfikację. Jeśli spełnia możliwe jest przejście do integracji tychże jednostek.
Integracja i testowanie systemu.
Jednostki lub zbiory programów są integrowane i testowane jako kompletne systemy, po to, aby upewnić się czy spełniono wszystkie założenia wymagań. Po zakończeniu integracji i pomyślnym przejściu fazy testowania system jest dostarczany klientowi jako gotowy produkt.
Działanie i pielęgnacja systemu.
Zwykle jest to najdłuższa faza życia produktu. System jest zainstalowany i przekazany do praktycznego użytkowania. Pielęgnacja jego obejmuje poprawianie błędów, których nie wykryto we wcześniejszych fazach życia, poprawianie implementacji jednostek systemu i wzbogacanie usług w miarę odkrywania nowych wymagań.
3.3 Model kaskadowy - rodzaje i zastosowanie.
Obecnie stosuje się dwa modele kaskadowe, które są używane do prac w projektach. Poza ogólnym podobieństwem w strukturze obydwu tych modeli wynikającym z tych samych faz projektu, reszta elementów, a zwłaszcza możliwości postępowania znacznie odbiegają od siebie. Główne różnice i wygląd samych modeli zostaną przedstawione poniżej.
3.3.1 Kaskadowy model bez iteracji.
Rys. 9 - Podejście kaskadowe bez iteracji
Przy stosowaniu tej metody czynności związane z cyklem życia projektu wykonywane są w pojedynczej, liniowej sekwencji dla wszystkich wymogów. Prowadzi to często do odkrywania podczas testów (- kiedy integrowane są poszczególne fragmenty systemu) szeregu problemów związanych z jakością i odpowiednią funkcjonalnością produktu, które pozostawały w ukryciu podczas czynności projektowania i implementacji. Ponieważ problemy te są odkrywane na późnych etapach procesu rozwoju projektu, może być za późno na ich rozwiązanie lub koszty rozwiązania mogą być zbyt wysokie. Dla przykładu - odkrycie, iż dany system zarządzania bazą danych ma za małą wydajność dla korzystających z niego aplikacji, gdy aplikacje te zostały juz opracowane, stanowi kolosalny problem.
W punkcie tym należy również rozważyć projekt obejmujący 10 wymagań, na przykład generowanie 10 różnych typów raportów, z których każdy bierze się z innego wymagania. Przy podejściu kaskadowym wszystkie te wymogi są rejestrowane i analizowane, a cały system jest projektowany, implementowany, testowany i wdrażany w jednej liniowej sekwencji. W takim przypadku, kiedy zastosuje się UML-a można z łatwością posłużyć się nim do przekazywania wymogów i opisów systemu. Ponieważ jednak czynności wykonywane są dla wszystkich wymogów w jednej liniowej sekwencji, modele UML-owe na każdym kolejnym kroku musza być dość kompletne. Taki poziom kompletności często trudno jest zmierzyć, a przed wszystkim osiągnąć, wprawdzie UML jest bardziej precyzyjny od języków naturalnych, lecz zarazem mniej precyzyjny od języków programowania, co wpływa na poziom kompletności opisów systemu. Zamiast wiec koncentrować się na systemie, zespoły projektowe korzystające z UML-a przy podejściu kaskadowym poświęcają swój czas na ustalenie, czy ich modele UML-owe są wystarczająco kompletne, w wyniku, czego cenny czas, który mogliby poświęcić na prace przy samym produkcie, poświęcają na badanie jakości i kompletności swoich opisów, co w konsekwencji przyczynia się na możliwość wydłużenia długości prac nad danym produktem. Oprócz poświęcenia czasu na samo sprawdzanie kompletności opisów, przychodzi jeszcze problem z poświęceniem czasu nad samym ich tworzeniem, gdyż w wyniku takiej a nie innej budowy tegoż podejścia wymagane jest, aby wynikiem każdej fazy był, co najmniej jeden dokument, który musi zostać oczywiście zaakceptowany. Kiedy dana faza zostanie już zaakceptowana prace mogą posunąć się dalej do następnych etapów produkcji systemu. W praktyce etapy te jednak zazębiają się i przekazują sobie nawzajem informacje. Proces ten nie jest prostym modelem liniowym, ale obejmuje ciąg iteracji czynności tworzenia. Koszty opracowania takich dokumentów są wysokie i dlatego iteracje są też kosztowne i wymagają powtórzenia wielu prac. Często po wykonaniu kilku iteracji pozostawia się problem do późniejszego rozwiązania, pomija lub rozwiązuje się go metodami poza modelowymi. Takie podejście powoduje ryzyko powstania złej struktury systemu lub otrzymanie systemu, który nie będzie robił tego, co chce użytkownik.
3.3.2 Kaskadowy model z iteracjami.
Podstawową wadą podejścia bez iteracji jest to, iż zaplanowane fazy pracy mają odbywać się po kolei, a powrót do wcześniejszej fazy traktuje się jako nieprawidłowość, która jest realizowana w sytuacji awaryjnej. W wyniku takiego postępowania i pewnych niedogodności wynikłych z samej budowy pierwszego podejścia, stworzono drugi model, tym razem z iteracjami. W modelu z iteracjami z góry przewiduje się tzw. powroty, dzięki czemu daje to większą elastyczność w projekcie.
Rys. 10 - Model kaskadowy z iteracjami.
Gdy stosujemy metodę iteracyjną, wszystkie podzbiory czynności w cyklu życia projektu są wykonywane kilkakrotnie, aby lepiej zrozumieć wymogi i stopniowo opracować bardziej niezawodny system. Każde przejście cyklu tych działań lub ich podzbioru nosi nazwę iteracji, a seria iteracji w końcu krok po kroku doprowadza do ostatecznego systemu. Pozwala to lepiej zrozumieć wymogi i stopniowo stworzyć bardziej odpowiedni system przez kolejne ulepszenia i przyrostowe zwiększanie szczegółowości w miarę kolejnych iteracji. Dla potwierdzenia tychże stwierdzeń mogę posłużyć się tu znanym przykładem bazy danych z poprzedniego modelu. W tym wypadku, kiedy tworzymy system zarządzania, możemy zbadać wydajność określonego systemu zarządzania bazami danych i odkryć, iż będzie niewystarczająca dla korzystających z niego aplikacji, jeszcze zanim aplikacje te zostaną w pełni skonstruowane. Pozwoli to wprowadzić odpowiednie zmiany w aplikacjach lub zbadać inny system zarządzania bazą danych, zanim będzie na to za późno lub stanie się to zbyt kosztowne.
Tak, więc analizując powyższy przykład, który obejmuje generowanie 10 różnych typów raportów, dochodzimy do konkluzji, iż możliwy jest następujący ciąg iteracji:
1. Identyfikujemy pięć wymogów (nazwanych od W1 do W5) i analizujemy trzy z nich
(np. W1, W3 i W5).
2. Rejestrujemy pięć kolejnych wymogów (nazwanych od W6 do W10), analizujemy dwa nie przeanalizowane w poprzedniej iteracji (W2 i W4) oraz projektujemy, implementujemy i testujemy system, który spełnia trzy wymagania przeanalizowane w poprzedniej iteracji (W1, W3 i W5) oraz dwa przeanalizowane w tej iteracji (W2 i W4), lecz nie wdrażamy systemu, ponieważ w bieżącej iteracji nie przeznaczyliśmy na te czynność wystarczająco dużo czasu.
3. Wdrażamy system spełniający pięć wymogów przetestowanych w poprzedniej iteracji (od W1 do W5) i kontynuujemy prace nad pozostałymi (od W6 do W10).
4. Dalej pracujemy nad systemem, lecz musimy zająć się zmianami w jednym z wdrożonych juz wymogów (np. W3), zmianami w innych wymogach, które nie zostały jeszcze wdrożone (np. W6 i W10) oraz innymi technicznymi zmianami w systemie.
Ten ciąg iteracji może sprawiać wrażenie chaotycznego, jednakże podejście iteracyjne jest tylko ideą, a UML tylko językiem, wiec do zastosowania UML-a w rzeczywistym projekcie niezbędna jest metodologia. Iteracje wykorzystywane przez metodologie nie są chaotyczne, lecz zorganizowane i dość dynamiczne w ramach kontekstu tej metodologii.
Podejście iteracyjne do konstruowania systemu przynosi następujące korzyści:
Możemy lepiej radzić sobie ze złożonością, budując system małymi przyrostowymi porcjami, a nie cały od razu.
Możemy lepiej radzić sobie ze zmianami w wymogach, rozkładając zmiany na cały proces, a nie usiłując zarejestrować i wprowadzić wszystkie zmiany na raz.
Możemy udostępniać użytkownikom fragmentaryczne rozwiązania w trakcie procesu, a nie kazać im czekać na ukończenie procesu, kiedy otrzymaliby kompletny system i być może stwierdzili, ze nie tego oczekiwali.
Możemy zwrócić się do użytkowników z prośbą o uwagi dotyczące opracowanych już części systemu, co pozwoli wprowadzać zmiany i tak kierować postępami w pracach, by stworzyć bardziej solidny system spełniający potrzeby użytkowników.
Proces iteracyjny jest przyrostowy, ponieważ nie przerabiamy jedynie raz za razem tych samych wymogów w kolejnych iteracjach, lecz zajmujemy się w nich coraz większą liczbą wymogów. Oprócz tego w jednej iteracji mogą odbywać się równoległe czynności - jeśli koncentrują się na różnych częściach systemu i nie kolidują ze sobą. Wobec tego, chociaż podejście to określane jest często iteracyjnym i przyrostowym, w rzeczywistości jest iteracyjne, przyrostowe i równoległe. Ponieważ w tej metodzie system tworzony jest przez kolejne udoskonalenia i zwiększaną przyrostowo liczbę szczegółów, łatwiej jest nam ustalić wystarczający poziom kompletności modelu UML niż w samym podejściu kaskadowym.
Na przykład, jeśli mamy pytanie lub problem, którym należy się zając, i jeśli nie jesteśmy w stanie użyć do tego posiadanego modelu UML, to być może musimy rozbudować model, w przeciwnym razie możemy iść dalej bez poświęcania dodatkowych nakładów czasu i pracy na rozwój modeli UML.
3.4 Porównania.
Podejście kaskadowe |
Podejście kaskadowe z iteracjami. |
- zaplanowane fazy pracy muszą być realizowane po kolei, - powroty do wcześniejszych faz traktuje się jako sytuacje niedobrą, niepożądaną, czyli inaczej mówiąc sytuację awaryjną. |
- prace w tym podejściu zależą głównie od grupy projektowej i projektu, jaki jest realizowany, -występują tu powroty, które są przewidziane. Daje to większą elastyczność podczas prac w projekcie.
|
Tab. 2 - Porównanie podejść. (*Opracowanie własne)
WADY
ZALETY
PODSUMOWANIE.
Co? + transformacja;
dlaczego? + widok ogólny;
kiedy? i gdzie? + środowisko;
jak?, kto? + klient; aktor i właściciel.
Podejście kaskadowe |
Podejście kaskadowe z iteracjami. |
- brak elastyczności, - brak weryfikacji, - wysoki koszt błędów popełnianych we wczesnych fazach, - długa przerwa w kontaktach z klientem, co może przenieść się na mniejsze lub wręcz brak zainteresowania produktem przez klienta. W najgorszym wypadku może stać się sytuacja, kiedy produkt nie spełnia wymagań. - formalizm i zbytnie narzucanie ścisłej kolejności wykonywania prac. - nie sprzyja wprowadzaniu modyfikacji. -nie sprzyja tworzeniu systemów wspomagających decyzję. |
- duże nakłady pracy na opracowanie dokumentów zgodnych ze standardem. - przerwy w realizacji niezbędne dla weryfikacji dokumentów przez klienta. |
Tab. 3 - Wady poszczególnych podejść. (*Opracowanie własne)
Podejście kaskadowe |
Podejście kaskadowe z iteracjami. |
- łatwość zarządzanie przedsięwzięciem. - ułatwia planowanie, harmonogramowanie oraz monitorowanie przedsięwzięcia. - zmusza do zdyscyplinowanego podejścia. - wymusza kończenie dokumentacji po każdej fazie.
|
- elastyczność w prowadzeniu prac projektowych. - wczesne wykrycie ewentualnych błędów, co sprzyja zmniejszeniu kosztów wytworzenia systemu. - częstsze kontakty z klientem. -mniejsze ryzyko, iż projekt będzie odbiegał od specyfikacji wymagań. |
Tab. 4 - Zalety poszczególnych podejść. (*Opracowanie własne)
Rys. 11 - Rozbieżność wynikłe z zastosowanie błędnego podejścia.
Podsumowując dotychczasowe rozważania na temat dwóch rodzajów podejść kaskadowych dochodzimy do wniosku, iż pierwszy zapewnia pewną dyscyplinę w projekcie oraz ułatwia zarządzanie przedsięwzięciem, jednakże poprzez słabą kontrole błędów może spowodować, iż w rezultacie możemy otrzymać system, który niespełna wymagań klienta, co w konsekwencji prowadzi do wyraźnego podniesienia kosztów wytworzenia danego produktu. Z kolei prace projektowe przy zastosowaniu drugiego z podejść, gdzie proces produkcji składa się z pewnych faz i iteracji, i gdzie dokonuje się częstych testów czy system jest zgodny ze specyfikacjami wymagań prowadzi do tego, iż niweluje się ryzyko powstanie pod koniec projektu systemu, który będzie niezgodny z wymaganiami określonymi przez klienta.
IV Rozdział - Porównanie trzech podejść produkcji i tworzenia oprogramowania.
4.1 Porównanie.
Wielu inżynierów oprogramowania próbowało stworzyć coś zarówno lekkiego jak, XP, ale także trzymającego się zwięźlejszych reguł (- narodził się RUP), a ponadto chcieli coś pewnego i prostego do wdrożenia w projekcie - powstało podejście kaskadowe. Metodologie te dzielą ze sobą niektóre wspólne charakterystyki, na przykład są iteracyjne lub oparte na rolach. RUP często jest krytykowany (w mniemaniu agile'owym) przez swoją rozległość i obszar działania. Dostarcza on 80 artefaktów, podczas gdy XP skupia się na kodowaniu, zaś podejście kaskadowe jest sztywne, zbyt formalne i dość kosztowne w przypadku wystąpienia potencjalnych błędów. RUP ma 40 ról, podczas gdy XP ma 5, tak samo jak podejście kaskadowe.
Po przeanalizowaniu powyższych kilku informacji nasuwają się pytania - właściwie, która metodologia i w jakich warunkach jest najlepsza do zastosowanie przy tworzeniu oprogramowania? Przy próbie odpowiedzi na powyższe pytanie, musimy najpierw porównać owe metodologie. Aby możliwe było ich porównanie należy zastosować podejście empiryczne oraz case study do przeanalizowania pewnych ich aspektów, ze względu na to, iż nie jesteśmy w stanie zastosować tychże metodologii równolegle, a co za tym idzie nie jesteśmy w stanie zastosować tu podejścia ilościowego. Do poniższego porównania jak już wspomniałem w początkowej części dokumentu będę brał metodologię XP, RUP oraz podejście kaskadowe w wersji klasycznej i z iteracjami.
4.1.1 Szkielet.
Porównanie będzie oparte na dwóch autorytarnych strukturach, Zachmana i Checklanda.
Struktura Zachmana - zawiera sześć kategorii: co?, jak?, gdzie?, kto?, kiedy? i dlaczego?.
Struktura Checklanda - zwana CATWOE (czyt. Katoe) ma również sześć kategorii: klient, aktor, transformacja, widok ogólny( -światopogląd), właściciel i środowisko.
Ta pierwsza skupia się na funkcjach i procesach, a druga na osobach. W celu uzyskania zalet obydwu, można przyjąć prostą kombinację:
W odniesieniu do porównania metodologii pytania prezentują się następująco:
[ I ] Co? (Transformacja)
- Jaka jest zasadnicza natura dla XP, RUP i modelu kaskadowego?
- Dla jakich projektów odpowiedni jest RUP, dla jakich XP, a dla jakich model kaskadowy?
[ II ] Dlaczego ? (Widok ogólny)
- Jakie są techniczne aspekty dla XP, RUP i modelu kaskadowego?
- Jakie są finansowe aspekty dla XP, RUP i modelu kaskadowego?
[ III ] Kiedy i gdzie? (środowisko)
- Jakie są wymiary czasowe dla XP, RUP i modelu kaskadowego?
- Jakie znaczenie ma położenie geograficzne dla XP, RUP i modelu kaskadowego?
[ IV ] Jak ?
- Jaki jest rozmiar i złożoność XP, RUP i modelu kaskadowego?
- Jak są zorganizowane metody rozwoju dla XP, RUP i modelu kaskadowego?
- Jakie narzędzia istnieją dla XP, RUP i modelu kaskadowego?
[ V ] Kto ? (Klient, Aktor, Właściciel)
- Co charakteryzuje indywidualnych deweloperów używających XP, RUP i modelu Kaskadowego?
- Co charakteryzuje organizacje używające XP, RUP i model kaskadowy?
4.1.2 Analiza.
4.1.2.1 Co? (Transformacja)- Tab. 5.
Rational Unified Process:
Korzenie, RUP-a spoczywają w języku UML, wywodzi się on z praktyk dużych organizacji i innych praktycznych zastosowań. Został zaprojektowany dla dużych projektów.
Extreme Programming:
XP ma swoje początki również w praktykach programistycznych z lat 90tch. Jest lekką metodyką dla małych i średnich grup projektowych. XP istnieje, by stanąć naprzeciw zawiłym i ulotnym wymaganiom. Nie ma w nim nic komercyjnego - istnieje zaś zaplecze, które ewoluuje i tworzy narzędzia do wsparcia projektowania w XP.
Model kaskadowy:
Podejście kaskadowe jest jednym z pierwszych podejść w produkcji oprogramowania. Został stworzony do zastosowania w średnich i dużych projektach o dobrze zdefiniowanych wymaganiach. W podejściu tym nie ma zdefiniowanych odpowiednich narzędzi do pracy, a każda z grup projektowych sama przydziela sobie takie narzędzia, jakie są akurat w danej chwili dla niej najlepsze.
Początki RUP i XP są podobne, obydwa są oparte na doświadczeniu w inżynierii oprogramowania, obydwa powstały w tej samej dekadzie ( -idea RUPa powstała troszkę wcześniej). Z kolei powstanie metodologii kaskadowej nie wiąże się z badaniem doświadczeń innych grup projektowych, tak jak miało to miejsce w dwóch poprzednich metodykach. Powstał on w wyniku potrzeby posiadania metodyki prostej i łatwej do wdrożenia w konkretnej grupie projektowej.
Podstawowymi różnicami dla tych poszczególnych metod podejść do procesu produkcji oprogramowania jest to, na czym dana metoda się skupia oraz gdzie się ją głównie stosuje.
Tab.5 - Co? (Transformacja) - Podsumowanie
|
|||
→
→
→
→
→ |
XP |
RUP |
Modele Kaskadowe |
|
Został stworzony do średnich i małych projektów, niezależnie od szczegółowości zdefiniowanych wymagań |
Został stworzony do dużych projektów, niezależnie od szczegółowości zdefiniowanych wymagań
|
Został stworzony do średnich i dużych projektów o dobrze zidentyfikowanych wymaganiach i dobrze rozumianych zastosowaniach. |
|
|
|
|
|
Skupia się na rozwoju samych wymagań.
|
Skupia się na zarządzaniu obszarem działań.
|
Skupia się na kompletności i odpowiednim opisie dokumentów. |
|
Jest darmowy. |
Jest komercyjny. |
Jest darmowy |
|
Posiada 5 ról. |
Posiada aż 40 ról. |
Posiada 5 faz. W modelu kaskadowym z iteracjami, każda faza składa się dodatkowo z iteracji. |
|
Skupia się na kodowaniu.
|
Dostarcza 80 artefaktów.
|
Skupia się na testowaniu. |
(*Opracowanie własne)
4.1.2.2 Dlaczego ? (Widok ogólny) - Tab. 6.
- Aspekty techniczne.
Rational Unified Process:
Od strony technicznej RUP dostarcza organizacjom duży zestaw narzędzi i dokumentów. Jest rozpowszechniany on-line i ciągle ulepszany. Może być "wykrojony" żeby stanąć na przeciw wymaganiom firmy.
Extreme Programming:
XP zaś skłania się naprzeciw prostocie. Nie opiera się na konkretnych narzędziach, ale daje wolną rękę użytkownikom. W półświatku XP istnieje wiele narzędzi i ich wybór zależy od samych twórców.
Model kaskadowy:
Jeśli chodzi o klasyczny model kaskadowy to jest on bardzo formalny. Wszelkie objawy lub symptomy indywidualizmu pracy osoby w grupie są niwelowane. Model ten narzuca ścisły kierunek i model pracy, którego mają się wszyscy w grupie projektowej trzymać.
Inaczej z kolei jest w podejściu kaskadowym z iteracjami. Podejście to jest mniej formalne, jednakże w dalszym ciągu narzuca konkretny kierunek prac. Plusem w tym podejściu jest możliwość cofnięcia się do poprzedniej iteracji -takie podejście w klasycznym modelu kaskadowym jest niepożądane i oznacza sytuację awaryjną. Jeśli zaś chodzi o dokumentację to jest ona odpowiednio ustandaryzowana, w obu przypadkach tworzy się jej dużo w czasie całego procesu tworzenia systemu. Narzędzia stosowane w obu podejściach zależą głównie od samej organizacji i rodzaju tworzonego systemu.
RUP jest większym zbiorem procesów, artefaktów i ról, co sprowadza się do minimalnego rozłożenia wątków na każdego w zespole - XP zaś dąży do prostoty, następuje, więc w nim maksymalizacja wątków w obrębie pojedynczych osób (oczywiście nie w jednym momencie), z kolei w modelu kaskadowym poprzez występowanie ścisłej kolejności pracy rozłożenia na poszczególne osoby lub podgrupy odbywa się głównie w obrębie faz, a w przypadku modelu kaskadowego z iteracjami dodatkowo w obrębie samych iteracji.
- Aspekty finansowe.
Podstawową różnicą pomiędzy metodykami jest samo ich dostarczenie do organizacji. RUP jest komercyjny, XP darmowy tak samo jak metody kaskadowe. Dla wielkich organizacji nie będzie to wielki problem zakupić metodykę RUP, jednakże mniejsi odbiorcy
( -firmy) mogą niemieć tylu funduszy, a co za tym idzie mogą się zniechęcić do jej wykorzystania. Jedynym faktem, który w tej sytuacji przemawia za RUP-em jest to, iż w zamian za odpowiednią cenę oferuje nam pełne wsparcie narzędziowe, oraz częste poprawki i bezpieczeństwo.
Tab. 6 - Dlaczego? (Widok ogólny) - Podsumowanie
|
|||
→
→
→
→
→
|
XP |
RUP |
Modele Kaskadowe |
|
Skłania się naprzeciw prostocie. Nie opiera się na konkretnych narzędziach, ale daje wolną rękę użytkownikom. |
RUP oprócz zestawu narzędzi dostarcza również dokumenty. Jest rozpowszechniany on-line i ciągle ulepszany. Może być "okrojony" żeby stanąć na przeciw wymaganiom firmy.
|
Model klasyczny jest zbyt formalny w przeciwieństwie do modelu z iteracjami. Oby z tych podejść narzucają ścisłą kolejności wykonywania prac. Dodatkowo w podejściu klasyczny występowanie powrotów jest niepożądane, w przeciwieństwie do podejścia z iteracjami, gdzie takie powroty są zaplanowane. W modelu klasycznym wszelkie prace na własną rękę są bardzo niepożądane. |
|
|
|
|
|
Istnieje zaplecze, które ewoluuje i tworzy narzędzia do wsparcia projektowania w XP. |
Posiada już odpowiednie narzędzia do pracy z RUP. |
Poza częstym stosowaniem języka UML w projektowaniu, reszta narzędzi nie jest zdefiniowana -w obu podejściach. |
|
Dąży do prostoty, następuje, więc w nim maksymalizacja wątków w obrębie pojedynczych osób (-oczywiście nie w jednym momencie). |
Jest większym zbiorem procesów, artefaktów i ról, co sprowadza się do minimalnego rozłożenia wątków na każdego w zespole. |
Poprzez występowanie ścisłej kolejności pracy rozłożenia na poszczególne osoby lub zespoły odbywa się głównie w obrębie faz, a w przypadku podejścia z iteracjami, dodatkowo w obrębie danych iteracji. |
|
XP jest darmowy, przez co znacznie ratuje budżet niejednej firmy. Jednakże nie udziela takiego wsparcia i poprawek jak w RUP-ie -pozostawia on samego sobie użytkownika. |
Przez to, iż RUP jest komercyjny należy za niego płacić, co mniejsze firmy stawia w trudnej sytuacji wydania sporych pieniędzy. Jednakże dostają oni pełne wsparcie, bezpieczeństwo i nowe poprawki. |
Modele kaskadowe są darmowe i proste do wdrożenia. Podejście klasyczne w wyniku tego, że jest już dość stare, nie ewoluuje i w dodatku jest zbyt kosztowne przy wystąpieniu błędów, staje się dziś mało używane. |
|
Skupia się tylko na jednostkach, przez co dostajemy lepsze rezultaty niż, w RUP-ie i mniej niedoróbek. |
RUP skupia się na dogłębnej standaryzacji, przez co może wyjść częściej problem z integralnością całości. |
Model klasyczny skupia się na kompletności opisów systemów. W wyniku braku możliwości cofnięcia się do poprzedniej fazy oraz błędnej oceny kompletności opisów częściej niż w pozostałych metodykach dochodzi do błędów, które niebyły wcześniej wykryte, a które w rezultacie prowadzą do większych kosztów produkcji. Z kolei w modelu kaskadowy z iteracjami w miarę postępu tych iteracji zwiększa się przyrostowo szczegółowość samego systemu. |
(*Opracowanie własne)
4.1.2.3 Kiedy i gdzie? (środowisko) -Tab.7.
Rational Unified Process:
Zgodnie z wymiarem czasowym RUP jest zorganizowany na cztery sekwencyjne fazy: 1 -wprowadzenie (początek), 2 -opracowywanie, 3 -konstrukcja i 4 -przeskok (do produkcji). Każda faza zawiera określoną liczbę iteracji, skupiając się na różnych czynnościach.
Extreme Programming:
XP ma swój własny cel - jądro produkcyjne, niezależne od posunięcia w czasie. Projekt ewoluuje razem z software'em i skupia się na teraźniejszych planach.
Model kaskadowy:
Klasyczny - składa się z 5 zhierarchizowanych faz, gdzie powrót do poprzedniej nie jest planowany.
Iteracyjny - oprócz 5 faz składa się również z iteracji, które pozwalają na powrót do wcześniejszej fazy/iteracji, dzięki czemu można ulepszyć system, nad którym się pracuje. W obydwu przypadkach praca nie może posunąć się do przodu o kolejną fazę/iterację, jeśli poprzednia nie zostanie zaakceptowana zarówno przez klienta jak również przez zarząd.
Wszystkie z opisywanych tu metodyk cechuje to, iż są iteracyjne, a także, to, iż stają naprzeciw ograniczeniom czasowym i zasobom.
Położenie geograficzne nie jest nakreślone wprost w żadnej z powyższych metod, jednakże komunikacja RUP-a oparta na artefaktach jest znacznym ułatwieniem. Za to fizjonomia XP objawia się w bezpośredniej, ustnej komunikacji i najbardziej wydajna staje się, gdy każda osoba biorąca udział w projekcie znajduje się w tym samym pomieszczeniu. Z kolei, jeśli chodzi o podejście kaskadowe, zwłaszcza model klasyczny to komunikacja jest słabo rozwinięta, zarówno między członkami zespołów jak również użytkownikiem końcowym i sprowadza się tylko do zatwierdzania odpowiednich faz projektu. Sytuacja nieco się zmieniła, kiedy powstało podejście kaskadowe z iteracjami, gdyż w wyniku wprowadzenia iteracji proces komunikacji z klientem stał się częstszy.
Tab. 7 - Kiedy i gdzie? (środowisko) - Podsumowanie
|
|||
→
→
→
→
→ |
XP |
RUP |
Modele Kaskadowe |
|
Komunikacja w XP opiera się na bezpośrednim przekazie ustnym -najlepiej, aby każda osoba biorąca udział w projekcie znajdowała się w tym samym pomieszczeniu. |
Komunikacja RUP-a oparta na artefaktach jest znacznym ułatwieniem. |
Brak pełnej komunikacji zarówno pomiędzy członkami zespołu, jak również w stosunku do użytkownika końcowego -podejście klasyczne. Częstsze kontakty z klientem -podejście kaskadowe. |
|
XP ma swój własny cel -jądro produkcyjne. |
RUP jest zorganizowany na 4 sekwencyjnych fazach. Każda faza skupia się na różnych czynnościach. |
Model kaskadowy klasyczny zorganizowany jest z 5 faz, natomiast z iteracjami oprócz 5 faz posiada iteracje, które w znaczący sposób poprawiają prace projektowe. W oby wypadkach przejście do kolejnej fazy/iteracji wymaga zatwierdzenia poprzedniej. |
|
Wyłączając z tego grona klasyczne podejście kaskadowe, reszta przedstawionych tu metodyk jest iteracyjna. |
||
|
Wszystkie metodyki stają naprzeciw ograniczonemu czasowi i zasobom. |
||
(*Opracowanie własne)
4.1.2.4 Jak ? - Tab. 8.
- Zasięg.
Rational Unified Process:
RUP bazuje na większym zasobie dokumentów, opisie ról, aktywności itd. Koncentruje się na dopasowaniu do wymogów każdej firmy. Jednakże jest krytykowana za swój duży zasięg.
Extreme Programming:
Zasięg XP jest niewielki, wszystko, co potrzeba by zacząć w nim projektować to mały zbiór książek.
Model kaskadowy:
Model kaskadowy klasyczny i z iteracjami podobnie jak RUP, bazują również na dużym zasobie dokumentów, opisów i specyfikacji, jednakże, aby rozpocząć projektowanie w nich nie potrzebne jest tyle narzędzi, co, w Rational Unified Process, przez co ich zasięg jest niewielki.
- Elastyczność
Metodologie XP, RUP oraz podejście kaskadowe z iteracjami cechuje duża elastycznością, co niemożna niestety powiedzieć o klasyczny modelu kaskadowym, gdzie takiej elastyczności po prostu brak.
Rational Unified Process:
RUP dodatkowo cechuje się dopasowaniem ("okrawaniem") metody do własnych potrzeb.
Extreme Programming:
W XP oznacza to nieustanne zmiany oparte na sprzężeniu zwrotnym. Zapętlone sprzężenia wymagają ciągłych akcji.
Model kaskadowy:
W wyniku wystąpienia iteracji możliwe jest lepsze zrozumienie wymogów stawianych produkowanemu systemowi oraz stopniowe tworzenie bardziej odpowiadającej wersji systemu poprzez kolejne ulepszenia i przyrostowe zwiększanie szczegółowości( -w miarę kolejnych iteracji).
- Silniki metod
Rational Unified Process:
RUP jest napędzany przez use case'y z opisanymi sposobami użycia i bieżącą integracją oraz testowaniem.
Extreme Programming:
XP posiada architekturę napędzaną testami. Test case'y są dostarczone i zaimplementowane przed napisaniem kodu. XP posiada streszczenia, które ukazują, co zostało zaimplementowane. Streszczenia są bardziej dowolną formą aniżeli use case'y w RUPie.
Model kaskadowy:
Klasyczne podejście kaskadowe napędzane jest specyfikacjami wymagań i odpowiednimi opisami, natomiast podejście z iteracjami napędzane są planem testów, które są wykonywane podczas iteracji.
Jeśli chodzi o planowanie to stwierdzenie, iż nie da się zaplanować szczegółów, pasuje do wszystkich z tych metodyk. RUP wprowadza zmiany na bieżąco tak jak modele kaskadowe, a XP jest krótkowzroczny.
- Relacje z klientem
Obie metodologie zalecają pozostawać w bliskim kontakcie z klientem, czego niestety nie można powiedzieć o metodach kaskadowych. Faktem jest, iż podejście kaskadowe z iteracjami zapewnia częstszą komunikację z klientem niż model klasyczny, jednakże nie tak częstą jak zapewniają ją pozostałe dwie metodologie. W XP klient powinien być częścią zespołu by odpowiadać na pytania, rozstrzygać spory, bo przecież to jego priorytety są najważniejsze, z kolei RUP jest bardziej elastyczny w stosunkach, które często ograniczają się do telefonów/internetu. Z kolei kontakt z klientem w podejściu kaskadowym odbywa się głównie podczas końca poszczególnych faz lub iteracji.
- Wydania
Rational Unified Process:
RUP definiuje wydanie, aby było "stabilną, użyteczną, wersją produktu i jego niezbędnych artefaktów".
Extreme Programming:
XP definiuje wydanie jako "zbiór streszczeń kreujących wartość biznesową".
Model kaskadowy:
Obydwa modele definiują wydanie jako „stabilną użytkową wersję produktu wraz z jej niezbędnymi funkcjonalnościami”.
- Narzędzia
Rational Unified Process:
RUP jest prowadzony przez odpowiednie narzędzia i z takowych się składa (np. modelowanie interface'u). Narzędzia te są niezbędnym dodatkiem do metodologii, aby prowadzić użytkownika krok po kroku.
Extreme Programming:
XP nie ma zdeklarowanych żadnych narzędzi. Każdy rodzaj narzędzi case'owych i zarządzających może zostać zastosowany. Jednakże, warto zauważyć tu również, że kartka papieru i długopis też są często wykorzystywane.
Model kaskadowy:
W obydwu podejściach kaskadowych oprócz stosowanie przy opisach samego języka UML, niema zdefiniowanych dodatkowych narzędzi. W tym wypadku może zostać zastosowana większość narzędzi zarządzających, w formie indywidualnej, zależnej od grupy projektowej.
Tab. 8 - Dlaczego? (Widok ogólny) - Podsumowanie
|
|||
→
→
→
→
→
→ →
→ |
XP |
RUP |
Modele Kaskadowe |
|
Zasięg XP jest niewielki, wszystko, co potrzeba by zacząć w nim projektować to mały zbiór książek. |
RUP bazuje na większym zasobie dokumentów, opisie ról, aktywności itd. Koncentruje się na dopasowaniu do wymogów każdej firmy. Posiada duży zasięg. |
Klasyczny model kaskadowy i model z iteracjami bazują na dużym zasobie dokumentów, opisów i specyfikacji, jednakże, aby rozpocząć projektowanie w nich nie potrzebne jest tyle narzędzi, co, w Rational Unified Process, przez co ich zasięg jest niewielki. |
|
Posiada architekturę napędzaną testami, dodatkowo posiada streszczenia, które ukazują co zostało zaimplementowane. |
Jest napędzany przez use case'y z opisanymi sposobami użycia i bieżącą integracją oraz testowaniem, a także streszczeniami. |
Klasyczne podejście kaskadowe napędzane jest specyfikacjami wymagań i odpowiednimi opisami, natomiast podejście z iteracjami napędzane są planem testów, które są wykonywane podczas iteracji.
|
|
W XP klient powinien być częścią zespołu by odpowiadać na pytania, rozstrzygać spory, bo przecież to jego priorytety są najważniejsze.
|
RUP jest bardziej elastyczny w stosunku do klienta, które często ograniczają się do telefonów/ Internetu. |
Podejście kaskadowe z iteracjami zapewnia częstszą komunikację z klientem niż model klasyczny, jednakże nie tak częstą jak zapewniają ją pozostałe dwie metodologie. Kontakt z klientem w tych podejściach odbywa się głównie podczas końca poszczególnych faz lub iteracji. |
|
XP definiuje wydanie jako "zbiór streszczeń kreujących wartość biznesową". |
RUP definiuje wydanie, aby było "stabilną, użyteczną, wersją produktu i jego niezbędnych artefaktów". |
Obydwa modele definiują wydanie jako „stabilną użytkową wersję produktu wraz z jej niezbędnymi funkcjonalnościami”. |
|
XP nie ma zdeklarowanych żadnych narzędzi. Każdy rodzaj narzędzi case'owych i zarządzających może zostać zastosowany. |
RUP jest prowadzony przez odpowiednie narzędzia i z takowych się składa -niezbędnym jest żeby prowadzić użytkownika krok po kroku. |
W obydwu podejściach kaskadowych oprócz stosowanie przy opisach samego języka UML, niema zdefiniowanych dodatkowych narzędzi. W tym wypadku może zostać zastosowana większość narzędzi zarządzających, w formie, zależnej od grupy projektowej. |
|
Z wyjątkiem klasycznego modelu kaskadowego wszystkie pozostałem metody cechują się dużą elastycznością. |
||
|
Mogą się pojawiać wątpliwości, co do odpowiedniej integracji całości i co do ewentualnych niedoróbek. |
||
|
W wszystkich metodach nie da się zaplanować dokładnie szczegółów. |
||
(*Opracowanie własne)
4.1.2.5 Kto ? (Klient, Aktor, Właściciel)- Tab. 9.
Extreme Programming:
XP skupia się na indywidualnych developerach, podnosząc techniczny poziom organizacji. Bazuje na prostej komunikacji i wymaga odwagi, otwartości, szczerości oraz poczucia ważności. To wymaga często doświadczonych pracowników, pracy zespołowej i dobrego samopoczucia.
XP jest metodą bottom-up, opartą na technicznych pracownikach.
Rational Unified Process:
RUP nie skupia się na jednostkach, ale zwiększa ilość ról, które "wyszywają" projekt. To wymaga jednak poświęcenia czasu przez każdego pracownika na dogłębną analizę dokumentacji i przygotowania się.
RUP jest metodą top-down, opartą na zarządzie.
Model kaskadowy:
W modelu kaskadowym z iteracjami developerzy mogą lepiej radzić sobie ze złożonościami systemu, budując system małymi przyrostowymi porcjami, a nie cały od razu. Faktem jest, iż takie podejście plus dodatkowo spora ilość dokumentacji wpływa na długość pracy nad projektem, dlatego potrzebna jest sprawna dogłębna ocena specyfikacji wymagań i odpowiednie wdrożenie się developerów w system, nad którym pracują.
Tab. 9 - Kiedy i gdzie? (środowisko) - Podsumowanie
|
|||
→
→
→
→
|
XP |
RUP |
Modele Kaskadowe |
|
XP skupia się na indywidualnych developerach, podnosząc techniczny poziom organizacji. Bazuje na komunikacji i wymaga odwagi, otwartości, szczerości oraz poczucia ważności. To wymaga często doświadczonych pracowników, pracy zespołowej i dobrego samopoczucia.. |
RUP nie skupia się na jednostkach, ale zwiększa ilość ról, które tworzą projekt. To wymaga jednak poświęcenia czasu przez każdego pracownika na dogłębną analizę dokumentacji i przygotowania się. |
W modelu kaskadowym z iteracjami developerzy mogą lepiej radzić sobie ze złożonościami systemu, budując system małymi przyrostowymi porcjami, a nie cały od razu. Faktem jest, iż takie podejście plus dodatkowo spora ilość dokumentacji wpływa na długość pracy nad projektem, dlatego potrzebna jest sprawna dogłębna ocena specyfikacji wymagań i odpowiednie wdrożenie się developerów w system, nad którym pracują. |
|
Bottom-up, opartą na technicznych pracownikach. |
Top-down, opartą na zarządzie. |
Top-down, opartą na zarządzie |
|
Obie metodologie zalecają pozostanie w bliskim kontakcie z klientem -aż do końca projektu. |
W klasycznej metodzie kaskadowej, często kontakt z klientem jest bardzo ubogi. Sytuacja wygląda ciut lepiej w kaskadowej metodzie z iteracjami. |
|
(*Opracowanie własne)
4.2 Wnioski i zakończenie.
Tab. 10 - Podsumowanie
|
|||
→
→ →
→
→ |
XP |
RUP |
Modele Kaskadowe |
|
Został stworzony do średnich i małych projektów, niezależnie od szczegółowości zdefiniowanych wymagań |
Został stworzony do dużych projektów, niezależnie od szczegółowości zdefiniowanych wymagań
|
Został stworzony do średnich i dużych projektów o dobrze zidentyfikowanych wymaganiach i dobrze rozumianych zastosowaniach. |
|
|
|
|
|
Skupia się na rozwoju samych wymagań.
|
Skupia się na zarządzaniu obszarem działań.
|
Skupia się na kompletności i odpowiednim opisie dokumentów. |
|
Jest darmowy. |
Jest komercyjny. |
Jest darmowy |
|
Posiada 5 ról. |
Posiada aż 40 ról. |
Posiada 5 faz. W modelu kaskadowym z iteracjami, każda faza składa się dodatkowo z iteracji. |
|
Skupia się na kodowaniu. |
Dostarcza 80 artefaktów. |
Skupia się na testowaniu. |
→
→
→
→
→
|
|
|
|
|
Skłania się naprzeciw prostocie. Nie opiera się na konkretnych narzędziach, ale daje wolną rękę użytkownikom. |
RUP oprócz zestawu narzędzi dostarcza również dokumenty. Jest rozpowszechniany on-line i ciągle ulepszany. Może być "okrojony" żeby stanąć na przeciw wymaganiom firmy.
|
Model klasyczny jest zbyt formalny w przeciwieństwie do modelu z iteracjami. Oby z tych podejść narzucają ścisłą kolejności wykonywania prac. Dodatkowo w podejściu klasyczny występowanie powrotów jest niepożądane, w przeciwieństwie do podejścia z iteracjami, gdzie takie powroty są zaplanowane. W modelu klasycznym wszelkie prace na własną rękę są bardzo niepożądane. |
|
|
|
|
|
Istnieje zaplecze, które ewoluuje i tworzy narzędzia do wsparcia projektowania w XP. |
Posiada już odpowiednie narzędzia do pracy z RUP. |
Poza częstym stosowaniem języka UML w projektowaniu, reszta narzędzi nie jest zdefiniowana -w obu podejściach. |
|
Dąży do prostoty, następuje, więc w nim maksymalizacja wątków w obrębie pojedynczych osób (-oczywiście nie w jednym momencie). |
Jest większym zbiorem procesów, artefaktów i ról, co sprowadza się do minimalnego rozłożenia wątków na każdego w zespole. |
Poprzez występowanie ścisłej kolejności pracy rozłożenia na poszczególne osoby lub zespoły odbywa się głównie w obrębie faz, a w przypadku podejścia z iteracjami, dodatkowo w obrębie danych iteracji. |
|
XP jest darmowy, przez co znacznie ratuje budżet niejednej firmy. Jednakże nie udziela takiego wsparcia i poprawek jak w RUP-ie -pozostawia on samego sobie użytkownika. |
Przez to, iż RUP jest komercyjny należy za niego płacić, co mniejsze firmy stawia w trudnej sytuacji wydania sporych pieniędzy. Jednakże dostają oni pełne wsparcie, bezpieczeństwo i nowe poprawki. |
Modele kaskadowe są darmowe i proste do wdrożenia. Podejście klasyczne w wyniku tego, że jest już dość stare, nie ewoluuje i w dodatku jest zbyt kosztowne przy wystąpieniu błędów, staje się dziś mało używane. |
|
Skupia się tylko na jednostkach, przez co dostajemy lepsze rezultaty niż, w RUP-ie i mniej niedoróbek. |
RUP skupia się na dogłębnej standaryzacji, przez co może wyjść częściej problem z integralnością całości. |
Model klasyczny skupia się na kompletności opisów systemów. W wyniku braku możliwości cofnięcia się do poprzedniej fazy oraz błędnej oceny kompletności opisów częściej niż w pozostałych metodykach dochodzi do błędów, które niebyły wcześniej wykryte, a które w rezultacie prowadzą do większych kosztów produkcji. Z kolei w modelu kaskadowy z iteracjami w miarę postępu tych iteracji zwiększa się przyrostowo szczegółowość samego systemu. |
→
→
→
→
→
→
→
→
→ → →
→
→
→
|
Komunikacja w XP opiera się na bezpośrednim przekazie ustnym -najlepiej, aby każda osoba biorąca udział w projekcie znajdowała się w tym samym pomieszczeniu. |
Komunikacja RUP-a oparta na artefaktach jest znacznym ułatwieniem. |
Brak pełnej komunikacji zarówno pomiędzy członkami zespołu, jak również w stosunku do użytkownika końcowego -podejście klasyczne. Częstsze kontakty z klientem -podejście kaskadowe. |
|
XP ma swój własny cel -jądro produkcyjne. |
RUP jest zorganizowany na 4 sekwencyjnych fazach. Każda faza skupia się na różnych czynnościach. |
Model kaskadowy klasyczny zorganizowany jest z 5 faz, natomiast z iteracjami oprócz 5 faz posiada iteracje, które w znaczący sposób poprawiają prace projektowe. W oby wypadkach przejście do kolejnej fazy/iteracji wymaga zatwierdzenia poprzedniej. |
|
Wyłączając z tego grona klasyczne podejście kaskadowe, reszta przedstawionych tu metodyk jest iteracyjna. |
||
|
Wszystkie metodyki stają naprzeciw ograniczonemu czasowi i zasobom. |
||
|
Zasięg XP jest niewielki, wszystko, co potrzeba by zacząć w nim projektować to mały zbiór książek. |
RUP bazuje na większym zasobie dokumentów, opisie ról, aktywności itd. Koncentruje się na dopasowaniu do wymogów każdej firmy. Posiada duży zasięg. |
Klasyczny model kaskadowy i model z iteracjami bazują na dużym zasobie dokumentów, opisów i specyfikacji, jednakże, aby rozpocząć projektowanie w nich nie potrzebne jest tyle narzędzi, co, w Rational Unified Process, przez co ich zasięg jest niewielki. |
|
Posiada architekturę napędzaną testami, dodatkowo posiada streszczenia, które ukazują co zostało zaimplementowane. |
Jest napędzany przez use case'y z opisanymi sposobami użycia i bieżącą integracją oraz testowaniem, a także streszczeniami. |
Klasyczne podejście kaskadowe napędzane jest specyfikacjami wymagań i odpowiednimi opisami, natomiast podejście z iteracjami napędzane są planem testów, które są wykonywane podczas iteracji.
|
|
W XP klient powinien być częścią zespołu by odpowiadać na pytania, rozstrzygać spory, bo przecież to jego priorytety są najważniejsze.
|
RUP jest bardziej elastyczny w stosunku do klienta, które często ograniczają się do telefonów/ Internetu. |
Podejście kaskadowe z iteracjami zapewnia częstszą komunikację z klientem niż model klasyczny, jednakże nie tak częstą jak zapewniają ją pozostałe dwie metodologie. Kontakt z klientem w tych podejściach odbywa się głównie podczas końca poszczególnych faz lub iteracji. |
|
XP definiuje wydanie jako "zbiór streszczeń kreujących wartość biznesową".. |
RUP definiuje wydanie, aby było "stabilną, użyteczną, wersją produktu i jego niezbędnych artefaktów". |
Obydwa modele definiują wydanie jako „stabilną użytkową wersję produktu wraz z jej niezbędnymi funkcjonalnościami”. |
|
XP nie ma zdeklarowanych żadnych narzędzi. Każdy rodzaj narzędzi case'owych i zarządzających może zostać zastosowany. |
RUP jest prowadzony przez odpowiednie narzędzia i z takowych się składa -niezbędnym jest żeby prowadzić użytkownika krok po kroku. |
W obydwu podejściach kaskadowych oprócz stosowanie przy opisach samego języka UML, niema zdefiniowanych dodatkowych narzędzi. W tym wypadku może zostać zastosowana większość narzędzi zarządzających, w formie, zależnej od grupy projektowej. |
|
Z wyjątkiem klasycznego modelu kaskadowego wszystkie pozostałem metody cechują się dużą elastycznością. |
||
|
Mogą się pojawiać wątpliwości, co do odpowiedniej integracji całości i co do ewentualnych niedoróbek. |
||
|
W żadnych z powyższych metoda nie da się zaplanować dokładnie szczegółów. |
||
|
XP skupia się na indywidualnych developerach, podnosząc techniczny poziom organizacji. Bazuje na komunikacji i wymaga odwagi, otwartości, szczerości oraz poczucia ważności. To wymaga często doświadczonych pracowników, pracy zespołowej i dobrego samopoczucia.. |
RUP nie skupia się na jednostkach, ale zwiększa ilość ról, które tworzą projekt. To wymaga jednak poświęcenia czasu przez każdego pracownika na dogłębną analizę dokumentacji i przygotowania się. |
W modelu kaskadowym z iteracjami developerzy mogą lepiej radzić sobie ze złożonościami systemu, budując system małymi przyrostowymi porcjami, a nie cały od razu. Faktem jest, iż takie podejście plus dodatkowo spora ilość dokumentacji wpływa na długość pracy nad projektem, dlatego potrzebna jest sprawna dogłębna ocena specyfikacji wymagań i odpowiednie wdrożenie się developerów w system, nad którym pracują. |
|
Bottom-up, opartą na technicznych pracownikach. |
Top-down, opartą na zarządzie. |
Top-down, opartą na zarządzie |
|
Obie metodologie zalecają pozostanie w bliskim kontakcie z klientem -aż do końca projektu. |
W klasycznej metodzie kaskadowej, często kontakt z klientem jest bardzo ubogi. Sytuacja wygląda ciut lepiej w kaskadowej metodzie z iteracjami. |
|
(*Opracowanie własne)
Opierając się na powyższych wiadomościach można dojść do wniosku, iż najbardziej realnymi i najmniej kosztownymi do zastosowania metodykami spośród wymienionych w tym dokumencie są metodyki: Extreme Programming, Rational Unified Process oraz Kaskadowe Podejście z Iteracjami. Klasyczne Podejście zostało tutaj wyeliminowane ze względu na to, iż jest ono już dość przestarzałe, rzadko używane gdzie koszt wystąpienia ewentualnego błędu jest bardzo wysoki i niemożliwy do zaakceptowania w wielu grupach projektowych. Ze względu na te dość negatywne cechy klasycznego podejścia kaskadowego, nie będzie ono brane pod uwagę w dalszej analizie i podsumowaniu.
W powyższym szkieletowym porównaniu metodologii, RUP, XP i podejścia kaskadowego dochodzimy do konkluzji, iż w kilku obszarach metodologie te są do siebie podobne pomimo tego, że ich historia powstania oraz ogólna budowa jest odmienna. Do wspólnych cech możemy zaliczyć to, iż wszystkie z nich są iteracyjne, dość elastyczne, nie da się w nich zaplanować dokładnie szczegółów, a dodatkowo wszystkie metodyki stają naprzeciw ograniczeniom czasowym i zasobom. Na tych jednak cechach kończy się podobieństwo pomiędzy tymi metodykami. Pozostałe cechy takie jak szczegóły konstrukcji metodyk, obszar zastosowania, metody dostarczenia i sposób kierowania projektem w diametralny sposób odbiegają od siebie w każdym z tych podejść. Dla przykładu możemy tu przytoczyć takie fakty jak chodź by to, iż podejście Kaskadowe z Iteracjami skupia się na kompletności opisów wymagań, jest wspomagane przez system testów i iteracji, jest dość formalne i proste do wdrożenia w projekcie. Z kolei RUP oferuje rozszerzony opis procesu, udział artefaktów, ról, czynności, integracji narzędzi itd. Natomiast XP, skupia się bardziej na wartościach i wymaganiach, niż na perspektywicznych instrukcjach, ceni wolność i niezależność.
Sytuację pomiędzy RUP, XP i Podejściem Kaskadowym z Iteracjami można porównać do sytuacji pomiędzy Windows'em, Linux'em i Mac'iem, gdzie każdy z nich ma swoich stałych zwolenników i przeciwników, i gdzie żadna ze stron nie wyobraża sobie dzisiejszego świata bez któregoś z tych systemów.
Konkludując na temat tych rozważań dochodzimy do naszego pytania, które pojawiło się we wstępie, a które brzmi następująco, „Która z metodyk i w jakich warunkach jest lepsza do zastosowania - RUP, XP czy może Podejście kaskadowe z Iteracjami?” Właściwie na to pytanie odpowiedzi jest tyle ilu jest projektantów na świecie. Jednakże moim zdaniem, jeśli nie jesteśmy dużą organizacją lub korporacją o dużym budżecie, a w dodatku mamy dobrze wykwalifikowaną i doświadczona kadrę pracowników, przygotowujemy średnich rozmiarów projekt i dodatkowo chcemy mieć pewność, iż to, co tworzymy jest zgodne z oczekiwaniami klienta to wybierzmy lekką metodykę Extreme Programming. Z kolei, jeśli faktycznie jesteśmy dużą organizacją o dużym budżecie możemy śmiało skorzystać z metodologii Rational Unified Process, ze względu na to, iż koszt zakupu tej metodyki nie wpłynie w większym stopniu na nasz przyszły budżet, a dodatkowo mamy zagwarantowane, że wszystkie działania naszego obszernego zespołu będą dobrze wspomagane i kontrolowane przy odpowiednim zadbaniu o bezpieczeństwo naszych danych.
Bibliografia:
- A -
1. Andrzej Jaszkiewicz -„Inżynieria Oprogramowania”, Wydawnictwo Helion, 1997.
2. Anna Tołaj -„Planowanie/Zasady i praktyki programowania ekstremalnego” - poratl php.pl
- C -
3. Cynthia Andres, Kent Beck - tłumaczenie Piotr Nowakowski -„Wydajne Programowanie -
Extreme Programming -wydanie II”. Warszawa 2006.
- D -
4. Dariusz Cieślak, artykuł -„Automatyzacja Testowania.” link:
5. Dariusz Cieślak, artykuł -„Extreme Programming w Praktyce.” link:
6. D. E. Avison and A. T. Wood-Harper - „Multiview: An Exploration of Information Systems Development”, Sep 1990.
- G -
7. Giancarlo Succi, Michele Marchesi -“Extreme Programming Examined”, 2001.
- H -
8. Hamlet Dick, Maybee Joe -„Podstawy techniczne inżynierii oprogramowania”, 2003.
- I -
9. IBM, Rational Unified Prosess - www-306.ibm.com/software/andtools/rup/
- K -
10. Kent Beck -“Extreme Programming explained. Embrace change”, 2003.
11. Kent Back, Martin Fowler -“Extreme Programming. Planning”, 2000.
- M -
12. Mariusz Chrapko - “Extreme Programming (XP) i CMMI - Kreatywność czy dyscyplina?”, magazyn 04/2007, Software Developer's Journal.
- O -
13. dr inż.Olgierd Unold, wykład -„Inżynieria Oprogramowania”- Instytut Informatyki,
Automatyki i Robotyki .
- P -
14. Perl Kroll, Philippe Kruchten -“ The Rational Unified Process Made Easy: A Practitioner's Guide to the RUP”, 2003.
15. Philippe Kruchten -“The Rational Unified Process: An Introduction. Third Edition”, 2003.
16. mgr inż. Piotr Greniewski, wykład -„Inżynieria Oprogramowania - Tworzenie oprogramowania”-Wyższa Szkoła Menedżerska SIG -Katedra Informatyki
- R -
17. Rafał Jońca -tłumaczenie „Extreme Programming. Leksykon.”, 2003.
18. Ron Jeffries, Ann Anderson, Chet Hendricksom -“Extreme Programming. Installed”, 2001.
19. Ronald E. Jeffries - www.xprograming.com.
- S -
20. mgr inż. Sławomir Wróblewski, wykład -„Inżynieria Oprogramowania” -Katedra
mikroelektroniki i Technik Informatycznych Politechniki Łódzkiej.
21. Stanisław Wrycza, Bartosz Marcinkowski, Krzysztof Wyrzykowski - „Język UML 2.0 w
modelowaniu systemów informatycznych” , 2006.
22. Siatka Zachmana Link: http://pl.wikipedia.org/wiki/Siatka_Zachmana
23. Stanisław Szejko - „Metody Wytwarzania Oprogramowania”, 2002.
- W -
24.Wydawnictwo Naukowe PWN - Encyklopedia Popularna, Warszawa 2005.
Encyklopedia Popularno-Naukowa Online- Wydawnictwo Naukowe PWN S.A.,
Link: http://encyklopedia.pwn.pl/
„The XP Philosophy” - www.extremeprogramming.org/Kent.html
„Lekką metodykę XP stosuje się w małych i średnich zespołach projektowych, w warunkach dużej dyscypliny i częstych zmian wymagań” -cytat Kent Back „Extreme Programming Explained” str. 15.
„What is Extreme Programming” - www.extremeprogramming.org/what.html
http://www.extremeprogramming.org/map/loops.html
http://www.extremeprogramming.org/map/project.html
http://www.extremeprogramming.org/map/iteration.html
http://www.extremeprogramming.org/map/development.html
http://www.extremeprogramming.org/map/code.html
Cynthia Andres, Kent Beck - tłumaczenie Piotr Nowakowski -„Wydajne Programowanie - Extreme Programming -wydanie II”. Warszawa 2006.
Ang. Portland Pattern Repository (PPR) -to pierwszy na świecie zbiór oraz repozytorium dla wzorców projektowych używanych przy projektowaniu oprogramowania. Repozytorium dotyczy również programowania ekstremalnego. Było przechowywane na serwerze firmy Warda Cunninghama (http://c2.com/ppr/). Mottem repozytorium jest „Ludzie, Projekty i Wzorce”.
Kent Back, Martin Fowler -“Extreme Programming. Planning”, 2000.
14Extreme Programming. Leksykon. Tłumaczenie: Rafał Jońca. 2003
Software Developer's Journal. Mariusz Chrapko - “Extreme Programming (XP) i CMMI - Kreatywność czy dyscyplina?”. 2007
Software Developer's Journal. Mariusz Chrapko - “Extreme Programming (XP) i CMMI - Kreatywność czy dyscyplina?”. 2007, str. 25.
Wydajne Programowanie - Extreme Programming Cynthia Andres, Kent Beck, wydanie II. Tłumaczenie: Piotr Nowakowski. Warszawa 2006.
Wydajne Programowanie - Extreme Programming Cynthia Andres, Kent Beck, wydanie II. Tłumaczenie: Piotr Nowakowski. Warszawa 2006.
Jedna z wielu przykładowych aplikacja. Wersja demonstracyjna IBM możliwa do pobrania ze strony: http://www.ibm.com/developerworks/downloads/r/rup/?S_TACT=105AGX23&S_CMP=DLMAIN&S_CMP=rnav
http://en.wikipedia.org/wiki/IBM_Rational_Unified_Process
Szablon i sposób postępowania, który pozwala w sposób formalny i ściśle strukturalizowany definiować architekturę systemów korporacyjnych. Używa siatki bazując na sześciu podstawowych pytaniach (Co, Jak, Gdzie, Kto, Kiedy, Dlaczego).
Metody Wytwarzania Oprogramowania - Stanisław Szejko. Warszawa 2002.
- 2 -
Wyszukiwarka
Podobne podstrony:
INF II stopien Projektowanie i zarzadzanie projektami informatycznymi
PROJEKT INFORMATYCZNY sciaga, WSB Poznań, Zarządzanie Projektem Informatycznym
2006 05 Antywzorce w zarządzaniu projektami informatycznymi [Inzynieria Oprogramowania]
zarzadzanie projektami informatycznymi, ŚCIĄGI Z RÓŻNYCH DZIEDZIN, zarzadzanie
SSADM-graf, rok III, Zarządzanie Projektami Informatycznymi
Zarządzanie projektem informatycznym
szablon projektu2011 DK v1.03, Inżynierskie, Semestr VI, Zarządzanie projektami informatycznymi
praca inzynierska-ExtremeProgramming, rok III, Zarządzanie Projektami Informatycznymi
tematy 2011 DK v1.03, Inżynieria Oprogramowania - Informatyka, Semestr IV, Zarządzanie Projektami In
zarzadzanie projektami informatycznymi
cz 1d zarzadzanie projektem informatycznym tryb zgodnosci
Frączkowski Zarządzanie projektem informatycznym
Zarzadzanie projektami informatycznymi Eseje
Zarzadzanie projektami informatycznymi dla praktykow 2
więcej podobnych podstron