Modele tworzenia systemu informatycznego

Prezentacja na temat: "Modele tworzenia systemu informatycznego"— Zapis prezentacji:

1 Modele tworzenia systemu informatycznego
Dariusz Badura Instytut Informatyki Zakład Modelowania i Grafiki Komputerowej

2 Procesy tworzenia oprogramowania
Cztery fundamentalne działania wspólne dla wszystkich procesów: Specyfikowanie oprogramowania zebranie wymagań, definiowanie funkcjonalności i ograniczeń dotyczących tworzonego software’u. Tworzenie oprogramowania produkcja oprogramowania zgodnego ze specyfikacją. Walidacja oprogramowania Sprawdzenie czy gotowy program jest tym, czego oczekuje klient. Ewolucja oprogramowania Modyfikowanie oprogramowania tak, by ciągle zaspokajało zmieniające się potrzeby użytkownika.

3 Cykl tworzenia systemu
... obejmuje cały okres istnienia systemu; Obejmuje: studium zastosowalności analizę, specyfikację, projektowanie i tworzenie działanie, pielęgnację i aspekty usprawnienia

4 Przedsięwzięcie ... środowisko zarządzania zorganizowane w celu zapewnienia dostawy określonego produktu biznesowego i sprostania danej sytuacji biznesowej Z punktu widzenia tworzenia systemów należy to traktować jako dostarczenie określonego systemu informatycznego (SI) w ramach ograniczeń nałożonych przez czas, koszty, zasoby i jakość; Może jednak nie obejmować wszystkich etapów cyklu tworzenia systemu.

5 Proces tworzenia oprogramowania
Podczas realizacji oprogramowania dochodzi do największej liczby konfliktów i spięć, najczęściej wynikających z niezrozumienia potrzeb klienta, niedotrzymania terminów, itp. Tradycyjne procesy wytwarzania oprogramowania są nazywane procesami ciężkimi (ang. heavyweight processes)

6 Modele tworzenia Model kaskadowy Model spiralny
Wszystkie inne stosowane modele są zwykle wariantami lub uszczegółowieniem powyższych modeli.

7 Model kaskadowy Tworzenie systemu podzielone na wyizolowane etapy; każdy z nich musi być zakończony, zanim rozpoczną się prace w następnym etapie; Wyjścia z jednego etapu są wykorzystywane jako wejścia do etapu następnego; Każdy etap podzielony jest na dwie części: części twórczej oraz weryfikacji i/lub zatwierdzenia; Ponowna praca, jeśli jest konieczna, jest wykonywana w kolejnych etapach bez powrotu na pierwotny etap, na którym dany produkt został utworzony, np. gdy pojawi się nowe wymaganie;

8 Model kaskadowy Zastosowalność systemu Zatwierdzenie Kodowanie
Testowanie jednostek Model kaskadowy Plany i wymagania oprogramowania Zatwierdzenie Scalanie Weryfikacja produktu Projektowanie produktu Weryfikacja Wdrożenie produktu Testowanie systemu Projektowanie szczegółowe Weryfikacja Eksploatacja i pielęgnacja Ponowne zatwierdzenie

9 Modele pochodne do modelu kaskadowego
Realizacja kierowania dokumentami, (koncentracja na dokumentacji prac) – Każdy etap realizacji projektu zakończony szczegółowym opisem wyników realizacja danej fazy projektu – Każdy etap akceptowany przez zlecającego – wymóg wprowadzenia punktów kontrolnych; Weryfikacja opracowanych dokumentów spowalnia działania projektowe – ale włącza użytkownika w proces realizacji projektu. Metodyka HIPO, (Hierarchy-Input-Process-Output – precyzyjne dokumentowanie prac wykonywanych w całym procesie projektowania i realizacja kierowana dokumentami (document-driven)) – stosowanie dwóch wykresów: hierarchii i „wejście-proces-wyjście”;

10 Model „b” Model kaskadowy nie ujmuje we właściwy sposób etapu pielęgnacji; Eksploatacja i pielęgnacja mają inną naturę; stanowi etap, który właściwie nigdy się nie kończy (chyba, że następuje „śmierć” systemu); Większość nakładów na system w ciągu całego jego istnienia ma miejsce podczas pielęgnacji i może to stanowić ponad 70% ogólnych kosztów cyklu tworzenia systemu;

11 Model „b” Analiza Projektowanie Produkcja Produkcja Akceptacja
Rozpoczęcie Model „b” Analiza Projektowanie Produkcja Produkcja Akceptacja Projektowanie Działanie Analiza Ocena Rozpoczęcie

12 Model „V” Lewa, schodząca w dół część V ilustruje przejście od analizy do projektowania, następnie do programowania oraz zwiększający się podział składowych systemu; Prawa, biegnąca ku górze część V ilustruje narastające składanie i testowanie, kończące się na dostarczonym produkcie; Ważną cechą modelu – odzwierciedlenie powiązań między różnymi etapami przedsięwzięcia; Dla kierownika przedsięwzięcia, gdy uczestniczą w nim firmy zewnętrzne, model umożliwia dokładne zdefiniowanie etapów nabywania i dostawy oraz zatwierdzania produktów wynikowych każdego etapu;

13 Kodowanie i testowanie
Model „V” Wstępna koncepcja Ocena ofert i zawieranie umów może mieć miejsce w każdym punkcie objętym tym nawiasem Ewolucja Faza wynikowa produktu Rozpoczęcie przedsięwzięcia Specyfikacja wymagań Sprawdzony system Testowanie akceptacyjne produktów wynikowych Szczegółowa specyfikacja wymagań Przetestowany system łącznie z akceptacją i przekazaniem Specyfikacja Projektowanie architektury oprogramowania Scalanie i testowanie systemu Projekt Scalone oprogramowanie Przetestowane oprogramowanie Szczegółowe projektowanie oprogramowania Scalanie i testowanie oprogramowania KJ KJ Przetestowane moduły oprogramowania Projekt Projekt Projekt modułu Uruchomione moduły Kodowanie i testowanie jednostek Zarządzanie przedsięwzięciem

14 Model przyrostowy etapowe dochodzenie do ostatecznej postaci- przyrostowo realizuje kolejne etapy projektu – duży projekt obejmujący duży obszar działalności instytucji. funkcjonalność systemu ma być dostarczana stopniowo w pewnym przedziale czasu – tzw. „dostawa fazowa”; lepsze możliwości dostawy i testowania mogą wystąpić trudności z dokonaniem podziału na fazy; ostatnia faza może okazać się kosztowna.

15 Prosty model przyrostowy

16 Model przyrostowy Studium zastoso- walności Sprzężenie zwrotne
Definiowanie wymagań i planowanie procesu tworzenia Projekto- wanie wysokiego poziomu Projekto- wanie szczegóło- we Kodowanie i testowanie jednostek Scalanie systemu instalacja i testowanie systemu Działanie Sprzężenie zwrotne zatwierdzenie/ weryfikacja Projekto- wanie szczegóło- we Kodowanie i testowanie jednostek Scalanie systemu instalacja i testowanie systemu Działanie Projekto- wanie szczegóło- we Kodowanie i testowanie jednostek Scalanie systemu instalacja i testowanie systemu Działanie Model przyrostowy

17 Model spiralny Model spiralny, (cykliczne powtarzanie pewnej sekwencji działań – idea krokowego dochodzenia do rozwiązania docelowego poprzez cykliczne wykonywanie tych samych faz projektu). Model zakłada cykliczne przechodzenie przez kolejne fazy realizacji projektu, istnieje on jednak w nieco innym wymiarze - nie wyróżnia bowiem aktywności takich jak projektowanie, programowanie itp. ale cztery cyklicznie powtarzane etapy: określanie wymagań i planowanie – ustalanie celów produkcji kolejnej wersji systemu, analiza ryzyka i ewentualna budowa prototypu, wytworzenie systemu – najczęściej w tej fazie stosuje się model kaskadowy, ocena systemu przez użytkownika; jeśli ocena nie jest w pełni pozytywna, następuje kolejny cykl.

18 Model spiralny Zalety:
skupienie się na wczesnym eliminowaniu błędów i nie satysfakcjonujących rozwiązań, model można stosować podczas tworzenia oprogramowania i jego ulepszania, łączenie zalet innych modeli procesów tworzenia oprogramowania i jednocześnie, poprzez analizę ryzyka, uniknięcie związanych z nimi utrudnień, położenie nacisku na ponowne użycie istniejącego oprogramowania.

19 Model spiralny Koszt skumulowany Przejście kolejnych kroków
Ocena alternatyw określenie rozwiązanie ryzyka Określenie celów alternatyw, ograniczeń Analiza ryzyka Analiza ryzyka Analiza ryzyka Prototyp operacyjny Analiza ryzyka Prototyp 3 Prototyp 1 Prototyp 2 Zatwierdzenie podział Przegląd Plan wymagań Symulacje, modele, punky odniesienia Plan cyklu życiowego Koncepcja działania Wymagania dotyczące oprogramowania Projekt produktu programo- wego Plan oprogramowania Projekt szczegółowy Zatwierdzenie wymagań Plan scalania i testowania Kod Test jednostek Zatwierdzenie i sprawdzanie projektu Testy akceptacji Scalanie i testowanie Planowanie następnych etapów Wdrażanie Opracowanie , sprawdzanie produktu następnego poziomu

20 Tradycyjne podejście do tworzenia systemu
„tradycyjne” oznacza w tym przypadku niestrukturalne; tworzenie projektu wysokiego poziomu oznacza stosowanie się do dokumentu wymagań, na podstawie którego, ustalając projekt bazy danych, specyfikację wejść i wyjść, strukturę menu oraz ogólny projekt programów i podziału; brak zaangażowania użytkowników, zastosowanie tekstowej a nie graficznej (diagramowej) dokumentacji, nacisk na sposób osiągnięcia wyników, a nie na same wyniki.

21 Tradycyjne podejście do tworzenia systemu
Użytkownicy Warunki, informacje Analiza wymagań Dostarczenie warunków odniesienia i informacji Analiza notatek itp. Tworzenie projektu wysokiego poziomu Określenie wymagań Specyfikacja projektu wysokiego poziomu Przegląd szkicu specyfikacji wymagań Szkic Specyfikacji wymagań Specyfikacja Tradycyjne podejście do tworzenia systemu Poprawa specyfikacji wymagań Uwagi z przeglądu Do specyfikacji programu, kodowania itd. Specyfikacja wymagań

22 SSADM – Structured systems analysis and design method
Model SSDAM obejmuje tylko analizę i projektowanie (.. z cyklu życia SI) Należą do niego następujące elementy: zastosowalność, analiza wymagań, specyfikacja wymagań logiczna specyfikacja systemu, projekt fizyczny

23 Prototypowanie szczególny nacisk na minimalizację ryzyka związanego z błędnym określaniem wymagań) - metody generowania oprogramowania, programy szkieletowe, języki 4GL, narzędzia programowania obiektowego. Prototypem oprogramowania nazywa się częściową implementację produktu przekazywaną potencjalnym użytkownikom, którzy oceniają rozwiązanie i przekazują swoje uwagi i ocenę zespołowi projektowemu. Prototypowanie pozwala na uściślenie wymagań i odpowiednią ich interpretację.

24 Prototypowanie Prototypowanie zwykle obejmuje następujące kroki:
zebranie i analiza wymagań, szybkie projektowanie, budowa prototypu, ocena prototypu przez klienta, poprawa projektu i prototypu, aż do uzyskania zadowolenia klienta, jeśli klient jest zadowolony z prototypu, budowa pełnego systemu.

25 Schemat procesu budowy oprogramowania oparty o prototypowanie

26 Metodyka RAD ... charakteryzuje się:
gwarantowaną wysoką jakością rozwiązania, ewolucyjnością procesu wytwarzania systemu, stosowaniem inżynierskich technik wytwarzania w całym cyklu realizacji, zleceniem wytwarzania profesjonalnym zespołom, wydzielonym do określonych zadań, wykorzystaniem profesjonalnych metod zarządzania zespołem, stosowaniem wydajnych narzędzi wspomagających wytwarzanie oprogramowania, gwarantowaną produktywnością wytwarzanego oprogramowania.

27 Model Rational Unified Process
... (RUP) definiuje metody postępowania dla całego cyklu tworzenia systemu informatycznego od momentu jego rozpoczęcia do odbioru przez klienta. Oparty jest o język UML jako standard wizualnego modelowania. U podstaw RUP leżą następujące praktyki prowadzenia projektu informatycznego: tworzenie iteracyjne, zarządzanie wymaganiami, oparcie architektury systemu na komponentach, wizualne modelowanie, ciągłe weryfikowanie jakości, kontrola nad zmianami systemu.

28 Lekkie procesy tworzenia oprogramowania
... zwane też zwinnymi (agile methods) – praktyczne podejście do produkcji software’u;   Nie wymagają tworzenia dużej ilości dokumentacji; Nie definiują rygorystycznych procedur; Kładą nacisk na działanie dające najlepszy efekt, zgodne z przesłankami wynikającymi z doświadczenia; Pozwala zespołom tworzącym oprogramowania na szybką pracę i szybkie reagowania na zmiany wymagań użytkownika

29 „Agile Alliance” ... grupa ekspertów wydaje
Manifest lekkich metod tworzenia oprogramowania The Manifest of the Agile Alliance Podstawowe zasady:

30 Zasada pierwsza Pojedyncze osoby i interakcje pomiędzy ludźmi są ważniejsze niż procesy i narzędzia Indywidualności w zespole nie gwarantuje efektywności oprogramowania Dobry proces nie uchroni projektu przed klęską, gdy w zespole brak mocnych graczy – zły proces może zniwelować wszelkie zalety ich posiadania. Mocny gracz – nie koniecznie bardzo dobry programista, ale sprawnie współpracujący z resztą zespołu. Nadmiar narzędzi oraz wykorzystywanie ich za wszelką cenę jest zwykle błędem.

31 Zasada druga Działające oprogramowanie jest istotniejsze niż obszerna dokumentacja Projekt bez żadnej dokumentacji, tzn, taki, w którym istnieje jedynie kod programu, nie jest idealnym rozwiązaniem; Dwa podstawowe elementy pozwalające nowym programistom na zapoznanie się z istniejącym oprogramowaniem: Kod programu: pisany w sposób przejrzysty i czytelny: konieczność przyjęcia i przestrzegania pewnych standardów: formatowanie kodu i dokumentowanie; język Java i narzędzie Javadoc lub język Python (tzw. Agile Language); Zespół, który dane oprogramowanie stworzył. Metody lekkie skupiają się na ludziach i ich wzajemnych interakcjach.

32 Zasada trzecia Współpraca z klientem powinna być przedkładana nad negocjowanie kontraktów Oprogramowanie nie jest zwyczajnym towarem. Nie jest możliwe opisanie tego, co program powinien robić i znalezienie wykonawcy, który go napisze w ściśle określonym czasie i za określoną cenę Najlepszymi kontraktami są takie, które dają możliwość współpracy zespołowi wytwarzającemu oprogramowanie i klientowi Częsty kontakt z klientem jest istotnym elementem sukcesu

33 Zasada czwarta Reakcja na zmianę jest ważniejsza niż realizowanie planu Harmonogramy powinny być elastyczne Wymagania co do aplikacji zmieniają się, klient będzie miał jakieś uwagi, będzie nanosił poprawki, proponował dodanie lub usunięcie jakichś funkcjonalności Lepsze jest tworzenie dokładniejszych harmonogramów na krótkie, mierzone w tygodniach okresy i ogólniejszego planu na dłuższe przedziały czasowe.

34 Dwanaście reguł odróżniających procesy lekkie od ciężkich

35 12 reguł (1) 1. Najwyższym priorytetem jest zadowolenie klienta: wczesne i ciągłe dostawy oprogramowania 2. Wszelkie zmiany wymagań, nawet w końcowych stadiach projektu, nie są niczym złym. Zmiana wymagań jest czymś pozytywnym; Należy tak tworzyć oprogramowanie, aby produkt miał elastyczną strukturę i aby każda pojawiająca się zmiana miała minimalny wpływ na całość systemu. 3. Oprogramowanie dostarczane jest często, w okresach czasowych wynoszących od kilku tygodni do kilku miesięcy, z naciskiem na krótkie terminy

36 12 reguł (2) 4. Osoby tworzące oprogramowanie muszą codziennie pracować razem z klientem w całym okresie trwania projektu. 5. Projekty powinny być budowane wokół wyróżniających się w zespole indywidualistów. Ludzie są uznawani za najistotniejszy czynnik sukcesu. 6. Najbardziej wydajnym i efektywnym sposobem przekazywania informacji pomiędzy członkami zespołu jest rozmowa. Procesy lekkie – niewielka ilością tworzonej dokumentacji. Domyślnym sposobem przekazywania sobie większości informacji jest rozmowa. Różnego rodzaju specyfikacje mogą powstawać, jeśli tylko są potrzebne, ale nie jest to wymóg.

37 12 reguł (3) 7. Działające oprogramowanie jest podstawą miarą postępu prac projektowych. Postęp projektu jest mierzony liczbą funkcjonalności, które spełniają potrzeby klienta. 8. Lekkie procesy promują tworzenie oprogramowania ze stałą prędkością, bez nadmiernego forsowania tempa. 9. Ciągła dbałość o techniczną doskonałość i dobry projekt zwiększa zwinność. Wysoka jakość jest kluczem do szybkości.

38 12 reguł (4) 10. Prostota, rozumiana jako sztuka maksymalizowania pracy, która nie została zrobiona jest podstawą. Programiści w lekkich projektach próbują osiągnąć założony cel przy wykorzystaniu najprostszych środków. Zmiany, które będą musiały zostać kiedyś dokonane, będą łatwe do przeprowadzenia dzięki prostocie już istniejącego kodu. 11. Najlepsze architektury, wymagania i projekty mają swój początek w samoorganizujących się zespołach. Zespół „agile team” jest zespołem samoorganizującym się; 12. W regularnych odstępach czasu zespół określa, jak być bardziej efektywnym, a potem dostosowuje się do zdefiniowanych w ten sposób zasad. Grupa ciągle „dostraja” swoją organizację, zasady, kontrowersje i wzajemne relacje. Jej członkowie są świadomi, iż zmienia się otoczenie zatem muszą zmieniać swoje zachowanie.

39 Kiedy możemy „dojść” do klęski?
Pomimo dobrych intencji zespołu, jego uwikłanie się w wymagający i skomplikowany proces tworzenia oprogramowania jest często przynajmniej jedną z przyczyn porażki. A zatem: ... Skupienie się na prostych technikach umożliwiających skuteczną realizację postawionych przed zespołem zadań.

40 Najpopularniejsze metody lekkie
Scrum LSD (Lean Software Development) FDD (Feature Driven Development) ADP (Adaptive Software Development) XP (Extreme Programming)

41 Scrum Ken Shwaber „Sprawne zarządzanie projektami metodą SCRUM”
Tytuł oryginału: „Agile Project Management with SCRUM”

42 Trochę historii …początek lat 90-tych
Twórcy: Ken Schwaber i Jeff Southerland Cel: pomoc organizacjom zmagającym się ze skomplikowanymi projektami programistycznymi ... ukierunkowuje organizację na tworzenie produktów, które mają szansę odnieść sukces na rynku. Bez poważnych zmian, często w przeciągu trzydziestu dni, zespoły są w stanie stworzyć użyteczny i gotów do zademonstrowania fragment produktu. SCRUM może zostać zaimplementowany na początku projektu lub nawet już w trakcie jego realizacji.

43 SCRUM „Najbardziej wprowadzający w zakłopotanie i paradoksalny proces do zarządzania skomplikowanymi projektami” Ken Shwaber

44 SCRUM jest ... ... zbiorem wzajemnie powiązanych praktyk i zasad, które optymalizują środowisko produkcyjne, redukują nadmierną biurokrację w organizacji i synchronizują wymagania rynku z iteracyjnymi prototypami. Bazując na nowoczesnych teoriach związanych z kontrolą procesów, SCRUM sprawia, że oprogramowanie może zostać skonstruowane w oparciu o dostępne zasoby, mieć akceptowalną jakość, a projekt nie przekroczy terminu dostawy. Co trzydzieści dni, nawet jeśli wykorzystywana jest nie do końca opanowana technologia, klientowi jest dostarczana jakaś funkcjonalność, która jest dla niego użyteczna[1]. [1] What is SCRUM:

45 Kiedy stosować ? Skomplikowane projekty – kiedy nie można przewidzieć wszystkiego co może się przydarzyć lub nawet nie można ich szczegółowo opisać w momencie powstawania Klienci nie do końca wiedzą czego potrzebują Często zmieniające się wymagania

46 Co oferuje ? Oferuje szkielet oraz zestaw zachowań, które utrzymują wszystko na widoku Wszystko odbywa się na zdrowym rozsądku – brak nakazów typu: „teraz zrób to” Oparty na iteracyjnej, przyrostowej strukturze procesu -> wybierana jest część, która stanowi przyrost funkcjonalności Prowadzenie i monitorowanie projektów w taki sposób aby dostarczyć najlepsze rezultaty

47 Udogodnienia dla klienta
Nabywca (klient) dostaje po kawałku (zamkniętą funkcjonalność) swój produkt – wczesne wdrażanie poszczególnych kawałków Nabywca może powiedzieć co chce aby było zrobione w pierwszej kolejności

48 Role ScrumMaster Właściciel produktu Zespół Pozostałe osoby

49 SPRAWIA ŻEBY SCRUM DZIAŁAŁO
ScrumMaster ScrumMaster – jest liderem, a nie kierownikiem Odpowiedzialny za: Przywództwo Prowadzenie Dostarczanie wskazówek Uczy zespół metodyki SCRUM Pomoc właścicielowi produktu w wyborze najbardziej wartościowych zaległości produktowych SPRAWIA ŻEBY SCRUM DZIAŁAŁO

50 ScrumMaster cd. Usuwanie barier pomiędzy projektantami, a właścicielem produktu tak aby właściciel produktu bezpośrednio kierował rozwojem projektu Uczenie właściciela produktu maksymalizacji zwrotów kosztów i spełniania swoich celów przy pomocy SCRUM Poprawa życia zespołu projektującego poprzez ułatwienie mu pracy twórczej Poprawa wydajności zespołu projektowego na wszelkie możliwe sposoby Poprawa praktyk inżynierskich oraz narzędzi tak, by każdy przyrost funkcjonalności był możliwy do wydania Udostępnianie zaktualizowanych informacji o postępach zespołu wszystkim stronom

51 Właściciel produktu Reprezentuje interesy każdej z zainteresowanych stron Odpowiedzialny za: Zebranie początkowych (ogólnych) wymagań Przypisywanie priorytetów zadaniom funkcjonalnym i niefunkcjonalnym Wybór najbardziej wartościowej funkcjonalności (na początku), a następnie nadbudowywanie jej

52 BRAK INTEGRACJI Z ZEWNĄTRZ
Zespół Sam organizuje swoją pracę Zbiorowa odpowiedzialność Może wybierać zadania do zrealizowania Może się podzielić na mniejsze zespoły Najbardziej optymalny to 7 osób BRAK INTEGRACJI Z ZEWNĄTRZ

53 Zaległości produktowe
Lista wymagań projektowych o ustalonych priorytetach wraz szacowanym czasem zamiany każdego jej elementu na ukończoną funkcjonalność produktu. Szacunki wyraża się w dniach i są tym precyzyjniejsze, im wyżej na liście priorytetów znajduje się dany element zaległości produktowych. Lista ta ewoluuje w kierunku zmian warunków biznesowych i technologii.

54 Zaległości produktowe
Na liście znajdują się: Wymagania funkcjonalne Wymagania niefunkcjonalne …wraz z określeniem priorytetów (ustalane według ważności dla klienta oraz zależności)

55 Zaległości produktowe
Opis | Początkowe szacunki | Współczynnik dostosowania | Dostosowane szacunki | Ilość pozostałej pracy

56 Sprinty, spotkania Rodzaje:
Spotkanie planujące sprint -> początek sprintu Sprint Codzienny SCRUM Przegląd sprintu Retrospektywne spotkanie sprintu

57 Spotkanie planujące sprint (max. 8 godzin)
W spotkaniu uczestniczą: ScrumMaster Właściciel produktu Zespół Dwa etapy: PIERWSZY (max. 4 godziny) Wybór co zostanie zrealizowane podczas sprintu DRUGI (max. 4 godziny) Rozplanowanie szczegółów zadania

58 Sprint (30 dni) Początek: spotkanie planujące sprint
Codzienny SCRUM (max. 15 minut) Cel: synchronizacja prac zespołu W spotkaniu uczestniczą: - ScrumMaster - Zespół Odpowiedzi na pytania: Co zrobiłeś w projekcie od ostatniego spotkania ? Co planujesz zrobić w projekcie między obecną chwilą, a kolejnym spotkaniem ? Jakie przeszkody stoją na drodze realizacji założeń danego sprintu oraz tego projektu ? Koniec: przegląd sprintu

59 Zaległości sprintu Opis zadania | Pomysłodawca | Osoba odpowiedzialna | Status | Pozostałe godziny pracy

60 Zaległości sprintu Zaległości sprintu zmienia zespół
Zadania – przydzielony czas wykonania od 4 do 16 godzin Zadania, które wykraczają poza ten czas traktowane są jako nieodpowiednio zdefiniowane.

61 Przegląd sprintu (max. 4 godziny)
W spotkaniu uczestniczą: Zespół ScrumMaster Właściciel produktu Ewentualnie udziałowcy Prezentowanie wykonanych zadań oraz zastanowienie się co powinno być następnie zrealizowane.

62 Retrospekcja sprintu (max. 3 godziny)
W spotkaniu uczestniczą: ScrumMaster Zespół Skorygowanie prac zespołu tak by kolejny sprint był bardziej efektywny i przyjemny

63 Przebieg sprintu Sprint może przerwać ScrumMaster,
np. zmiana prawa, wymagań funkcjonalnych

64 Przebieg SCRUM

65 Przebieg SCRUM

66 Kilka zespołów: Projekt skalowalny.
Pierwszy zespół robi fundament – przygotowuje infrastrukturę do pracy etapowej

67 Kilka zespołów Przed przystąpieniem do prac nowych zespołów muszą być ustalone m.in. Zaległości funkcjonalne i niefunkcjonalne Zasady komunikacji Zasady przechowywania kodu itd.

68 Zespoły w projekcie skalowalnym.
Pojedyncze osoby z pierwszego zespołu dołączane są do zespołów jako eksperci

69 Projekty skalowalne – Scrum Scrumów
Dodatkowe spotkanie W spotkaniu uczestniczą: ScrumMaster Pojedyncze osoby z zespołów Przebieg taki sam jak przy codziennym SCRUM

70 Dokumenty w SCRUM Zaległości produktowe Zaległości sprintu
POZIOMO: Pozostałe dni PIONOWO: - Ile pozostało do wykonania Zaległości produktowe Zaległości sprintu Wykres wypalania Używany przy: Zaległości sprintu Zaległości produktowe

71 Problemy przy wdrażaniu
Mało informacji np. dla zarządu na temat przebiegu aktualnego SCRUM – Co gdy zarząd wymusza dodatkowe raporty Przykład dodatkowego raportu

72 LSD (Lean Software Development)
Lean Software Development (LSD) stanowi przeniesienie tak zwanego Lean Thinking do dziedziny projektowania oprogramowania, programowania, zarządzania projektem i kontraktami. Lean oznacza szczupłość, a Lean Thinking to koncepcja mająca na celu wyeliminowanie wszystkiego co nadmiarowe i niepotrzebne.[1] Lean Software Development stawia głównie na wyeliminowanie wszelkich nadmiarowych elementów z procesu tworzenia oprogramowania. [1] Martin Fowler: The New Methodology, kwiecień 2004

73 Jako typowe źródła marnotrawstwa wskazuje:
nieukończoną pracę Nieukończone oprogramowanie szybko się dezaktualizuje i z każdym dniem maleje prawdopodobieństwo, że kiedykolwiek wejdzie ono do przemysłowej eksploatacji. Do czasu gdy takie oprogramowanie zostanie zintegrowane z resztą systemu, pochłania ono zasoby i stwarza ryzyko finansowe. Minimalizowanie ilości niedokończonego oprogramowania, które z jakichś względów nie zostało uruchomione jest zarówno ograniczaniem ryzyka jak i redukcją marnotrawstwa.

74 ... źródła marnotrawstwa:
dodatkowe procesy Typowym procesem, który nie stanowi wartości dla projektu jest tworzenie dokumentacji. Zasadnicze pytania w tym przypadku brzmią – czy klient naprawdę uważa dokumentację za przydatną i wartościową? Czy jest ona nam do czegoś potrzebna? A jeśli odpowiedź na któreś z nich jest twierdząca należy pamiętać o tym aby generowane dokumenty były krótkie i możliwie ogólne. Dokumentację na pewno warto tworzyć gdy jest ktoś kto na nią czeka, na przykład programiści, którzy oczekują od analityka zdefiniowania przypadków użycia. Ale nawet wtedy trzeba szukać innych efektywniejszych dróg przekazywania informacji – na przykład tworzyć testy akceptacyjne zamiast spisywać wymagania. Należy również pamiętać o tym aby dokumentować szczegóły danej cechy dopiero gdy rozpoczyna się iteracja, w której ma być ona implementowana.

75 ... źródła marnotrawstwa:
dodatkowe cechy Bardzo często wydaje się, że dodanie kilku nowych cech do systemu będzie z jakichś względów korzystne. Programiści mają tendencje do poszerzania systemu o nowe funkcje choćby po to by sprawdzić jak działają. Niestety takie działanie musi być uznane za marnotrawstwo. Każdy fragment kodu w programie musi przecież zostać napisany, zintegrowany, przetestowany, a potem musi być utrzymywany. Każdy kawałek kodu podnosi złożoność systemu i stanowi potencjalne miejsce wystąpienia błędu. Z tego punktu widzenia jeśli kod nie jest potrzebny na teraz to jego tworzenie jest trwonieniem zasobów.

76 ... źródła marnotrawstwa:
przełączanie zadań Obciążanie ludzi pracą nad kilkoma projektami jednocześnie jest marnotrawstwem. Za każdym razem gdy programista przełącza się między zadaniami w różnych projektach traci pewną ilość czasu na przemyślenie sobie tego to co ma do zrobienia i na wejście w rytm pracy nad nowym zadaniem. Najszybszą drogą do ukończenia dwóch projektów jest zrealizowanie najpierw jednego projektu, a potem drugiego. Równoległa praca skutkuje częstym przełączaniem się między zadaniami, a tym samym powoduje zmarnowanie dużej liczby czasu.

77 ... źródła marnotrawstwa:
oczekiwanie Jednym z głównych źródeł marnotrawienia czasu jest oczekiwanie na to aż coś się wydarzy. Przykładem są tu opóźnienia w rozpoczęciu projektu, w tworzeniu wymagań czy też w testowaniu. Opóźnienia zmniejszają wartość systemu dla klienta, a do tego redukują szybkość z jaką można zareagować na jego potrzeby.

78 ... źródła marnotrawstwa:
przemieszczanie Pierwszym problemem jest przemieszczanie się ludzi. Chodzi tu o sytuację, w której programista poszukuje odpowiedzi na pytanie lub potrzebuje pomocy przy jakimś technicznym problemie. Jeśli nie jest w stanie uzyskać jej na miejscu wówczas zmuszony jest do tracenia czasu na przemieszczanie się w poszukiwaniu osób które będą w stanie mu pomóc – na przykład przedstawicieli klienta. Do tego programista traci koncentrację i wybija się z rytmu pracy. Jest to poważne źródło marnotrawstwa. Drugi problem to przemieszczanie rozmaitych artefaktów – na przykład dokumentacji. Każde jej przekazanie od analityka do projektanta, od projektanta do programisty i od programisty do testera jest potencjalnym źródłem strat - dokumentacja z reguły nie zawiera pełnej wiedzy osoby, która ją przekazuje.

79 ... źródła marnotrawstwa:
defekty Ilość strat powodowanych przez defekty jest złożeniem wpływu defektu na system i czasu przez jaki defekt pozostawał nie wykryty. Sposobem na redukcję strat powodowanych przez defekty jest jak najszybsze ich wykrywanie. Rozwiązaniem są tu praktyki takie jak testowanie utworzonego kodu, częste integrowanie i wczesne przekazywanie kolejnych wydań systemu do eksploatacji.

80 Lean Software Development definiuje dobre praktyki zarządzania procesem tworzenia oprogramowania, jednak nie przedstawia samego procesu.

81 FDD (Feature Driven Development)
... został utworzony pomiędzy rokiem 1997 a 1999 w United Overseas Bank w Singapurze przez zespół, któremu przewodził Jeff De Luca. Zespół ten w swojej pracy bazował na materiałach Petera Coad’a, również członka zespołu, który wprowadził idee Feature definition i Feature list[1]. [1] David J. Anderson, Eli Schragenheim: Agile Management for Software Engineering

82 FDD ... ... opiera się na następujących założeniach:
system służący budowaniu innych systemów powinien być skalowalny, proste procesy są najlepsze, dobre procesy pozwalają zespołowi na skupienie się na wynikach, krótkie, ukierunkowane na cechy produktu i iteracyjne cykle są najlepsze.

83 Feature Driven Development
... definiuje pięć procesów wysokiego poziomu[1]: opracowanie ogólnego modelu (modelowanie kształtu), zbudowanie listy cech, plan projektu na podstawie cech, projektowanie, wytworzenie. [1] Stephen Palmer: Feature Driven Development and Extreme Programming

84 Opracowanie ogólnego modelu
Krok ten dotyczy zdefiniowania wstępnego kształtu projektu. Członkowie zespołu tworzącego oprogramowanie i udziałowcy systemu definiują wspólnie wstępny, prowizoryczny model tego, co powinno zostać wytworzone. Końcowym efektem tego etapu powinien być model klas zdefiniowany w języku UML

85 Zbudowanie listy cech Wykorzystując wiedzę zebraną w poprzednim etapie, członkowie zespołu i udziałowcy opracowują możliwie szczegółową listę pożądanych cech systemu. W procesie tym mogą zostać wykorzystane już istniejące dokumenty, na przykład specyfikacje przypadków użycia.

86 Plan projektu na podstawie cech
Trzecią czynnością jest uszeregowanie zdefiniowanych wcześniej cech tak, by tworzyły one pewien ogólny plan projektu, który następnie może zostać przypisany szefowi zespołu programistów.

87 Projektowanie i wytwarzanie
Szef programistów wybiera małą grupę cech, które powinny zostać wytworzone w przeciągu następnych dwóch, trzech tygodni, a następnie identyfikuje klasy związane z tymi cechami oraz osoby, które będą nad tymi klasami pracowały. Zespół, przydzielony do zrealizowania wybranych cech, określa szczegółowe diagramy sekwencji dla każdej cechy. Następnie osoby odpowiedzialne za dane klasy tworzą je i opisują ich metody. Zanim nastąpi ostatni etap – wytwarzanie, zespół dokonuje inspekcji projektu. W fazie wytwarzania osoba odpowiedzialna za klasę tworzy jej kod, opracowuje testy pakietów i integruje klasę z pozostałymi elementami systemu. Kierownik zespołu podejmuje decyzję, czy można dane cechy dodać do głównej wersji aplikacji.

88 FDD jest uważany za dobrą mieszankę zasad i elastyczności, która stanowi prosty w wykorzystaniu szkielet dla projektu.

89 ASD (Adaptive Software Development)

90 Adaptive software development
... bazuje na teorii złożonych systemów adaptujących się (complex adaptive systems – CAS), która została wykorzystana przez Briana Arthura i jego kolegów w instytucie Santa Fe Institute w celu zrewolucjonizowania sposobu rozumienia fizyki, biologii, ewolucji i ekonomii. ASD został utworzony przez Jima Highsmitha, który zauważył że, pomimo iż proces wytwarzania oprogramowania nie jest liniowy, a więc nie ma bezpośredniego powiązania pomiędzy przyczyną a efektem, to jednak są skomplikowane projekty informatyczne, które odnoszą sukces. Highsmith stwierdził, że proces tworzenia oprogramowania można potraktować zgodnie z teorią CAS, a wspomniane powiązanie przyczyna-efekt można z powodzeniem zastąpić pojęciem „wyłaniania się” (ang. emergence).

91 Adaptive software development
Nie powinno się planować procesu wytwarzania oprogramowania, ale powinien on się „wyłaniać” na podstawie podejmowanych w ostatniej chwili decyzji mówiących, co robić dalej. Podejście to jest zgodne z zasadami zawartymi w Agile Manifesto, które mówią, że najlepsze architektury, wymagania i projekty powstają (wyłaniają się) w samoorganizujących się zespołach. Samoorganizacja pociąga za sobą właśnie wspomniane „wyłanianie się”. Adaptive life-cycle, czyli adaptujący się cykl życia, wiąże się ze zmianami w stylu zarządzania, na przykład, kiedy zachodzą jakieś przemiany w środowisku danego projektu, osoba używająca tradycyjnego, deterministycznego procesu będzie szukała nowego zbioru zasad pozwalających na zdefiniowanie zależności pomiędzy przyczyną a efektem. W przypadku ASD osoba taka będzie wiedziała, że zasad takich nie ma.

92 Fazy w cyklu życia projektu
Adaptive Software Devleopment wyróżnia następujące fazy w cyklu życia projektu: Speculate (spekulacja) Collaborate (współpraca) Learn (nauka)

93 Speculate (przemyślenie, spekulacja)
Planowanie w złożonym środowisku to paradoks. Rezultaty są w takiej sytuacji nieprzewidywalne. Spekulowanie, podobnie jak planowanie, dotyczy definiowania celów, wizji i nakreślenia wymagań dla produktu. W procesie spekulowania otwarcie przyznajemy, że możemy się mylić przy określaniu nawet istotnych fragmentów projektu. Kiedy dojdzie do niezrozumienia potrzeb użytkownika, gdy zmieni się technologia lub konkurencja nas wyprzedzi, prawdopodobieństwo popełnienia błędu jest bardzo duże. ASD postuluje nakreślenie tylko ogólnej wizji tego, do czego powinien zmierzać projekt i umożliwienie wykorzystywanym mechanizmom dostosowywania się w trakcie trwania projektu do zachodzących zmian.

94 Collaborate (współpraca)
ASD nie przewiduje tworzenia planu – nie ma możliwości kontrolowania projektu w tradycyjny sposób. Znaczący zbiór obecnie stosowanych praktyk zarządczych staje się bezużyteczny lub – jest użyteczny tylko dla tych fragmentów procesu wytwarzania oprogramowania, które są przewidywalne. Pojęcie współpracy oznacza utrzymanie równowagi pomiędzy zarządzaniem pracą a tworzeniem oraz utrzymywaniem środowiska pozwalającego na współpracę, które jest konieczne dla „wyłaniania się”. Im bardziej skomplikowany staje się projekt, tym bardziej szala przechyla się w stronę tego drugiego elementu. Dla osoby zarządzającej projektem, która utrzymuje wspomnianą równowagę, istotne są dwie rzeczy. konieczne jest zdecydowanie, które części projektu są przewidywalne, zapewnienie dla nieprzewidywalnych elementów odpowiedniego środowiska, które umożliwi „wyłanianie się idei”.

95 Learn (nauka) Nauka, to zgodnie z definicją słownikową osiąganie doskonałości poprzez doświadczenie. W środowisku adaptującym się nauka dotyczy zarówno zespołu tworzącego produkt, jak i klientów. Po zakończeniu każdego cyklu powinni oni zweryfikować pierwotne założenia projektowe i wykorzystać to, co zostało w tym cyklu wytworzone do wyznaczenia kierunku, w jakim należy dążyć podczas cyklu następnego. Cykle powinny być krótkie, tak by zespoły mogły uczyć się raczej na małych, niż na dużych błędach, a ponadto powinny również być podwójnie zapętlone, aby umożliwić naukę zarówno o zmianach samego produktu, jak i o zmianach założeń

96 eXtreme Programming Jest to bardzo kontrowersyjny, zorientowany obiektowo model procesu tworzenia oprogramowania. „Lekki”, interaktywny i przyrostowy proces oparty jest na czterech podstawach: komunikacji, prostocie, sprzężeniu zwrotnym i odwadze.

97 Extreme Programming ... popiera następujące zwyczaje:
zespół projektowy określa czas, ryzyko i porządek realizacji prac; zamawiający określa zakres, datę uruchomienia i priorytety, projektowanie jest minimalne, gwarantujące przejście testów, programowanie w parach – cały kod jest pisany przez pary programistów pracujących na jednej stacji roboczej, testowanie modułów i testy akceptacyjne – testy są pisane przed kodowaniem,

98 Zwyczaje Extreme Programming
współdzielenie kodu, ciągła integracja, zamawiający jest członkiem zespołu, odpowiedzialnym za dostarczenie wiedzy z dziedziny obejmowanej przez oprogramowanie i testy akceptacyjne, 40-godzinny tydzień pracy, który gwarantuje, że zespół jest zawsze czujny i sprawny, niewielkie poprawki, zawierające użyteczną funkcjonalność, standardy kodowania, opracowane i stosowane przez zespół.

99 Podstawowe zasady Współpraca z klientami
User stories (historie użytkowników). Krótkie cykle. Plan iteracji Plan dostawy Testy akceptacyjne. Programowanie w parach. Programowanie oparte na testach - TDD (Test Driven Development). Wspólna własność (kolektywne kontrolowanie kodu).

100 Podstawowe zasady c.d. Ciągła integracja.
Czterdziestogodzinny tydzień pracy (stała prędkość). Otwarta przestrzeń robocza. Plan gry. Prosty projekt. Refaktoryzacja Metafora

101 Podsumowanie Z punktu widzenia kosztów najważniejsze elementy XP to –
test driven development, programowanie w parach i szybkie wdrażanie fragmentów działającego kodu. Główne zalety XP mówią, że: Para programistów pracuje z większą szybkością niż pojedynczy programista. Ciągłe sprawdzanie kodu zwiększa jego jakość Kod wytworzony przez parę programistów ma zmniejszoną ilość błędów.