1 / 114

Zarządzanie projektem systemu informatycznego

Zarządzanie projektem systemu informatycznego. 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ń. Modele cyklu życia.

umika
Download Presentation

Zarządzanie projektem systemu informatycznego

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

  19. 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

  20. 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.)

  21. 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)

  22. 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

  23. 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

  24. 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

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

  26. 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”

  27. 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

  28. 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

  29. 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

  30. 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

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

  32. 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

  33. 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

  34. 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

  35. 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

  36. 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

  37. XP Reguły i praktyki

  38. 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

  39. 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

  40. 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)

  41. Hydrodynamiczny model projektu

  42. Hydrodynamiczny model projektu

  43. Cykl życia

  44. Cykl życia

  45. 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

  46. 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ą

  47. 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ć

More Related