Zarządzanie projektem systemu informatycznego

1. Zarządzanie projektem systemu informatycznego

2. Cykl życia projektu • Formalnie określony sposób realizacji projektu (plan projektu, metodologia budowy systemu) • Uporządkowanie przebiegu prac • Ułatwienie planowania zadań • Monitorowanie przebiegu realizacji zadań

3. Modele cyklu życia • Realizacja kierowana dokumentami • Prototypowanie • Programowanie odkrywcze • Realizacja przyrostowa • Montaż z gotowych elementów • Model spiralny • Formalne transformacje

4. Weryfikacja przez klienta Prototypowanie Ogólne określenie wymagań Budowa prototypu tak nie Pełne określenie wymagań Realizacja pełnego systemu

5. Programowanie odkrywcze Ogólne określenie wymagań Budowa systemu Przetestuj system System działa poprawnie tak nie Dostarcz system

6. Realizacja przyrostowa Proces realizowany iteracyjnie Określenie wymagań Projekt ogólny Wybór podzbioru funkcji Projekt szczegółowy, implementacja i testy Dostarczenie zrealizowanej części systemu

7. Montaż z gotowych elementów • Źródła: • biblioteki • języki czwartej generacji • pełne aplikacje • Metody pozyskania: • zakup modułów • standaryzacja produktów • Zalety: • wysoka niezawodność, zmniejszenie ryzyka • narzucenie standardów • redukcja kosztów

8. Model spiralny Planowanie Analiza ryzyka Atestowanie Konstrukcja (model kaskadowy)

9. Formalne transformacje Formalna specyfikacja wymagań Postać pośrednia ... Postać pośrednia Kod

10. Model ogólny cyklu życia Określanie wymagań Projektowanie Implementacja Testowanie Konserwacja Faza strategiczna Analiza Instalacja Dokumentacja

11. Rational Unified Process • Rational Unified Process (RUP) to proces iteracyjnego wytwarzania oprogramowania opracowany przez firmę Rational Software Corporation (firma została obecnie przejęta przez IBM) • Proces RUP nie jest pojedynczym, ściśle określonym procesem, ale raczej szablonem procesu

12. Rational Unified Process • Został zaprojektowany w celu przystosowania do charakteru konkretnej organizacji, konkretnego zespołu projektowego lub nawet charakteru konkretnego projektu • Z szablonu RUP można wybrać elementy w zależności od konkretnych potrzeb

13. Rational Unified Process • Rational Unified Process (RUP) to także nazwa oprogramowania, opracowanego przez Rational Software (obecnie dostępnego w IBM) zawierającego hipertekstową bazę wiedzy z przykładowymi artefaktami oraz szczegółowymi opisami wielu typów czynności • Process RUP definiowany jest także w produkcie Rational Method Composer (RMC), który pozwala na tworzenie spersonalizowanych wersji RUP

14. Iteracyjne wytwarzanie oprogramowania • Wytwarzanie oprogramowania w kolejnych iteracjach, pozwala skupić się w pierwszej kolejności na obszarach najbardziej ryzykownych (np. najmniej rozpoznanych) • W idealnym przypadku każda iteracja kończy się stworzeniem wykonywalnego artefaktu - pomaga to zredukować ryzyko w projekcie, otrzymujemy szybciej opinie od odbiorców oprogramowania a programistom pozwalamy skupić się na węższej dziedzinie

15. Architektura bazująca na komponentach • Pozwala na stworzenie systemu, który jest łatwo rozszerzalny, intuicyjnie zrozumiały i wspomaga ponowne użycie (komponent to zbiór powiązanych obiektów) • RUP skupia się na stworzeniu prostej architektury w początkowych iteracjach • Ewoluuje ona w każdej iteracji zbliżając się do architektury finalnej • Poprzez iteracyjne wytwarzanie oprogramowania zyskujemy możliwość stopniowej identyfikacji komponentów, które mogą być w dalszej części: zakupione, zbudowane, lub użyte ponownie

16. Wizualne modelowanie oprogramowania • Abstrakcja projektowania od kodu i przedstawienie koncepcji za pomocą bloków graficznych może być efektywnym sposobem aby pokazać perspektywę rozwiązania • Reprezentacja graficzna jest produktem pośrednim pomiędzy analizą procesu biznesowego, a implementacją • Model w tym kontekście jest formą wizualizacji oraz uproszczeniem bardziej skomplikowanego projektu • RUP specyfikuje wymagane modele i opisuje dlaczego są wymagane

17. Kontrola i weryfikacja jakości oprogramowania • Ocena jakości jest najczęstszym słabym punktem projektów programistycznych ponieważ jest często planowana po fakcie budowy systemu i czasami obsługiwana przez inny zespół • RUP pomaga w planowaniu kontroli jakości i jej ocenie poprzez wbudowanie jej w cały proces i zaangażowanie w nią wszystkich członków zespołu • Proces koncentruje się na spełnieniu wymaganego poziomu jakości i zapewnia mechanizmy do pomiaru tego poziomu

18. Zarządzanie zmianami w oprogramowaniu • RUP definiuje metody śledzenia, ewidencji i kontroli zmian • Zdefiniowane są także tzw. secure workspaces (bezpieczne przestrzenie robocze), które pozwalają na zagwarantowanie, że zmiany w innych systemach nie wpłyną na system tworzony • Koncepcja ta jest ściśle powiązana z tworzeniem architektury zorientowanej komponentowo

21. Struktura organizacyjna • RUP proponuje strukturę zespołów w dwóch obszarach • biznesowym (business unit) • projektowym • Zadaniem zespołu biznesowego jest koordynowanie funkcji i zasobów wykorzystywanych w wielu projektach z zastosowaniem wspólnej technologii i zasad

22. Struktura organizacyjna • Zespół biznesowy odpowiada za • definicję i doskonalenie procesów • przestrzeganie założeń umów (kontraktów) • dostarczenie narzędzi programistycznych • wsparcie logistyczne personelu (trening, biblioteki, organizacja badań i rozwoju itp.)

23. Struktura organizacyjna • Organizacja projektowa składa się z następujących zespołów: • zarządzania oprogramowaniem (Software Management Team) • inżynierii systemowej (Systems Engineering Team) • administracyjny (Administration Team) • architektury oprogramowania (Software Architecture Team) • rozwoju oprogramowania (Software Development Team) • oceny oprogramowania (Software Assessment Team)

24. Struktura organizacyjna • W ramach oceny realizowane są następujące zadania: • Zarządzanie konfiguracją • identyfikacja konfiguracji, kontrola zmian, raportowanie statusów, audyty • Zapewnienie jakości • Testowanie • Zarządzanie narzędziami

25. Zalety RUP • RUP jest procesem iteracyjnym zakładającym budowanie systemu w kolejnych przebiegach • Po zakończeniu iteracji produkowany jest fragment systemu spełniający wymagania klienta, jest on następnie udostępniany • W ten sposób zespół analityczno-projektowy otrzymuje szybko sygnał zwrotny od klienta, który umożliwia bieżącą ocenę ryzyka niepowodzenia projektu jak również pozwala stwierdzić czy zespół analityczno-projektowy dobrze zrozumiał wymagania klienta wobec systemu

26. Zalety RUP • W razie wystąpienia problemów zostaną one szybko wykryte i zespół analityczno-projektowy będzie mógł wdrożyć odpowiednie postępowanie zaradcze • Podejście iteracyjne powoduje gwałtowną redukcję ryzyka niepowodzenia projektu już po zakończeniu pierwszej iteracji

27. Wady RUP • Rup to metodyka ciężka i kosztowna • Wymaga obszernego dokumentowania procesu • Ogranicza inicjatywę i samodzielność • Wysokie koszty administracyjne • Sztywne procedury (np. audytu)

28. Metodyki zwinne (agile) • Irytacja podejściami nastawionymi na kontrolowanie procedur i dyscyplinę • W jaki sposób można „odchudzić” procesy wytwarzania oprogramowania, przy zachowaniu wysokiej jakości (lub czasem wręcz jej poprawieniu)? • Powstały „lekkie” metodyki rozwoju oprogramowania, których dobrym przykładem jest Programowanie Ekstremalne, po angielsku zwane również „XP”

29. Metodyki zwinne (agile) • Programowanie Ekstremalne (XP) wymyślone przez Kenta Becka w latach 1996-1999, kiedy to pracował w firmie Chrysler nad oprogramowaniem przetwarzającym listy płac dla 87000 pracowników • XP i inne lekkie podejścia, wyrosły na pragmatycznym gruncie sukcesu tzw. "dobrych praktyk" programistycznych

30. Metodyki zwinne (agile) • Praktyki te obejmują m. in.: • aktywny udział klienta w pracach rozwojowych • szybkie sprzężenie zwrotne pomiędzy formułowaniem wymagań biznesowych a ich realizacją • nieustanną pielęgnację jakości wytwarzanego oprogramowania poprzez intensywne testowanie • refaktoryzację* oraz konstrukcję efektywnego zespołu *Termin refaktoryzacja definiuje się jako mechanizm zmiany struktury kodu bez zmiany jego zachowania

31. Manifest zwinności (Agile Manifesto) • Kent Beck - twórca metody kart CRC stosowanej podczas analizy obiektowej, autor narzędzi xUnit - wspomagających testowanie jednostkowe oraz twórca XP • Alistair Cockburn - autor rodziny zwinnych metodyk Crystal, oraz książek poświęconych inżynierii wymagań (głównie przypadkom użycia) • Martin Fowler - twórca pomysłu refaktoryzacji, autor świetnej książki „UML Distilled” (UML w kropelce) • Jim Highsmith - autor metodyki Adaptive Software Development

32. Manifest zwinności • Jednostki i interakcje są ważniejsze niż procesy i narzędzia • Działające oprogramowanie jest ważniejsze niż obszerna dokumentacja • Współpraca z klientem jest ważniejsza niż negocjacja kontraktu • Nadążanie ze zmianami jest ważniejsze niż trzymanie się planu

33. Wartości XP • Komunikacja • Prostota • Sprzężenie zwrotne • Odwaga • Szacunek

34. Komunikacja • Budowanie systemów informatycznych wymaga przekazania wymagań od klienta do programistów • W tradycyjnych metodykach wykorzystuje się w tym celu dokumenty (specyfikację wymagań) • XP posługuje się komunikacją werbalną, dzięki czemu wiedza o systemie bardzo szybko rozprzestrzenia się w zespole • Dzięki komunikacji wszyscy członkowie zespołu mają takie samo wyobrażenie przyszłego systemu i wiedzą w jakim kierunku projekt dąży

35. Prostota • XP zachęca do rozpoczęcia najprostszym możliwym rozwiązaniem problemu (minimalnym, spełniającym pewne początkowe wymagania) • Dopiero kiedy się upewnimy że idziemy w prawidłowym kierunku, na tej podstawie dobudowujemy resztę • Dzięki refaktoryzacji jakość produktu jest stale na najwyższym poziomie • Dzięki prostocie programiści skupiają się na projektowaniu i kodowaniu na potrzeby bieżącego dnia, a nie robią nic na wyrost

36. Sprzężenie zwrotne • System - ważna jest odpowiedź systemu, otrzymywana w procesie testowania jednostkowego • Klient - przygotowuje testy akceptacyjne wraz z testerem; dzięki takim testom można sprawdzić w jakim stanie znajduje się aktualnie budowany system • Zespół - w momencie kiedy klient proponuje nowe wymagania podczas gry planistycznej, zespół podaje szacunki ile czasu zajmie ich zaimplementowanie

37. Odwaga • Odwaga jest potrzebna, aby przestrzegać zasady projektowania i kodowania wg aktualnych potrzeb, bez zastanawiania się co będzie potrzebne w przyszłości • Odwaga, aby nie angażować się za bardzo w projektowanie i od razu przejść do kodowania • Odwaga jest potrzebna, aby zrefaktoryzować kod, wtedy kiedy to jest potrzebne, aby nie bać się refaktoryzacji • Jeżeli okaże się, że pewien fragment kodu jest już nieprzydatny, lub musi zostać zmieniony, do podjęcia decyzji o wyrzuceniu takiego kodu potrzeba dużo odwagi

38. Szacunek • Nie można wysyłać do repozytorium zmian, które nie dają się skompilować lub powodują błędy w testach jednostkowych, gdyż przez to praca innych osób będzie utrudniona, lub niemożliwa i stracą one dużo czasu • Dzięki dążeniu do najwyższej jakości i szukanie najlepszych rozwiązań projektowych (dzięki refaktoryzacji) innym osobom będzie dużo łatwiej wykorzystać kod napisany przez nas

39. XP Reguły i praktyki

40. Struktura zespołu • XP nie pokazuje wprost struktury zespołu • Dwie główne role w zespole pełnią: • programiści • klient • Klient uważany jest za członka zespołu, więc musi przez cały czas pracować razem z informatykami (w jednym pomieszczeniu); czasem nie występuje w tej roli osobiście, lecz za pośrednictwem przedstawiciela klienta

41. Struktura zespołu • Role pomocnicze pełnią: • tester, którego zadaniem jest napisanie skryptów testowych na podstawie rozmów z klientem • coach, to osoba, która pomaga rozwiązywać napotkane problemy • tracker natomiast zbiera statystyki dotyczące wykonanych zadań, czasu pracy i tworzy podsumowania postępów projektu

43. Opowieści użytkowników • Przedstawiciel klienta jest ciągłym źródłem wymagań • Wymagania są dyskutowane z nim na bieżąco, natomiast ślad z tych dyskusji jest przechowywany w formie opowieści użytkowników • Każda opowieść jest zapisana w kilku zdaniach na małej kartce papieru • Może być oznaczona dodatkowymi atrybutami (np. data utworzenia, typ, numer, rozmiar)

44. Hydrodynamiczny model projektu

45. Hydrodynamiczny model projektu

46. Cykl życia

47. Cykl życia

48. Wydania i przyrosty • Każde wydanie ma wartość użytkową i trafia do użytkowników końcowych, dzięki czemu programiści dostają sprzężenie zwrotne • Należy stosować częste i krótkie wydania • Przyrosty mają charakter wewnętrzny • Pośrednie przyrosty niekoniecznie stanowią produkt, z którego klient byłby w stanie skorzystać • Każdy przyrost powinien trwać 2-3 tygodnie, oraz zawierać kilka opowieści użytkownika

49. Gra planistyczna • Na początku gry planistycznej podczas rozmów dotyczących wymagań systemu klient spisuje opowieści użytkownika • Informatycy szacują rozmiar opowieści, podając liczbę osobo-dni potrzebnych do jej zrealizowania • Jeżeli opowieść jest za duża (np. wykracza poza jeden przyrost), wówczas dzieli się ją na mniejsze • Jeżeli opowieść jest też zbyt mała wtedy łączy się ją z inną opowieścią

50. Gra planistyczna • W momencie kiedy spisane są wstępne opowieści i oszacowane przez informatyków, klient wybiera zakres kolejnych przyrostów • Klient zna koszt każdej opowieści i może zadecydować czy będzie ona realizowana czy też nie, oraz kiedy będzie realizowana, czyli do którego dwutygodniowego przyrostu należy ją przypisać