Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

Wymagania jakości w Agile Programming Jarosław Kuchta Dokumentacja i Jakość Oprogramowania.

Podobne prezentacje


Prezentacja na temat: "Wymagania jakości w Agile Programming Jarosław Kuchta Dokumentacja i Jakość Oprogramowania."— Zapis prezentacji:

1 Wymagania jakości w Agile Programming Jarosław Kuchta Dokumentacja i Jakość Oprogramowania

2 2Agile Programming Wady klasycznych metod zapewnienia jakości Duży narzut na dokumentowanie Duży narzut na dokumentowanie Późne uzyskiwanie konkretnych rezultatów Późne uzyskiwanie konkretnych rezultatów Trudność w odpowiednio wczesnym definiowaniu wymagań Trudność w odpowiednio wczesnym definiowaniu wymagań Utrata łączności z klientem (użytkownikiem) w fazie implementacji Utrata łączności z klientem (użytkownikiem) w fazie implementacji Brak pewności co do uzyskanej jakości Brak pewności co do uzyskanej jakości

3 Dokumentacja i Jakość Oprogramowania 3Agile Programming Założenia Agile Programming (1/2) Najwyższym priorytetem jest zadowolenie klienta, które można zapewnić przez szybkie i ciągłe dostarczanie działającego oprogramowania. Najwyższym priorytetem jest zadowolenie klienta, które można zapewnić przez szybkie i ciągłe dostarczanie działającego oprogramowania. Dopuszczalne są zmiany wymagań nawet w późnym stadium projektu. Projekt musi być dopasowywany do zmieniających się wymagań i warunków na korzyść klienta. Dopuszczalne są zmiany wymagań nawet w późnym stadium projektu. Projekt musi być dopasowywany do zmieniających się wymagań i warunków na korzyść klienta. Działające oprogramowanie jest dostarczane często, co kilka tygodni lub co kilka miesięcy. Im częściej tym lepiej. Działające oprogramowanie jest dostarczane często, co kilka tygodni lub co kilka miesięcy. Im częściej tym lepiej. Potrzebna jest bliska, codzienna współpraca między przedstawicielami klienta i zespołem projektowym. Potrzebna jest bliska, codzienna współpraca między przedstawicielami klienta i zespołem projektowym. Projekty są oparte o odpowiednio zmotywowanych deweloperów, którym trzeba zapewnić środowisko pracy i zaufać, że wykonają swoją pracę. Projekty są oparte o odpowiednio zmotywowanych deweloperów, którym trzeba zapewnić środowisko pracy i zaufać, że wykonają swoją pracę. Najbardziej odpowiednią i efektywną metodą zbierania informacji przez zespół projektowy jest bezpośrednia rozmowa. Najbardziej odpowiednią i efektywną metodą zbierania informacji przez zespół projektowy jest bezpośrednia rozmowa.

4 Dokumentacja i Jakość Oprogramowania 4Agile Programming Założenia Agile Programming (2/2) Działające oprogramowanie jest podstawową miarą postępu prac. Działające oprogramowanie jest podstawową miarą postępu prac. Proces opracowywania oprogramowania powinien być stale podtrzymywany przez sponsorów, deweloperów i użytkowników. Proces opracowywania oprogramowania powinien być stale podtrzymywany przez sponsorów, deweloperów i użytkowników. Potrzebne jest stałe zwracanie uwagi na techniczną doskonałość i dobre projektowanie Potrzebne jest stałe zwracanie uwagi na techniczną doskonałość i dobre projektowanie Upraszczanie ma znaczenie zasadnicze Upraszczanie ma znaczenie zasadnicze Najlepsze wymagania, projekty i struktury pochodzą od samoorganizujących się zespołów. Najlepsze wymagania, projekty i struktury pochodzą od samoorganizujących się zespołów. W regularnych odstępach zespół projektowy zastanawia się nad tym, jak zwiększyć swoją efektywność, następnie odpowiednio zmienia i dopasowuje swoje sposoby postępowania. W regularnych odstępach zespół projektowy zastanawia się nad tym, jak zwiększyć swoją efektywność, następnie odpowiednio zmienia i dopasowuje swoje sposoby postępowania.

5 Dokumentacja i Jakość Oprogramowania 5Agile Programming Model cyklu pracy Prototyp Opowieści użytkownika Planowanie wydań Prototyp metafora systemu wymagania oszacowanie niepewne oszacowanie potwierdzone Iteracje plan wydania nowa opowieść użytkownika szybkość projektu Testy akceptacyjne ostatnia wersja błędy scenariusze testowe następna iteracja Małe wydania akceptacja klienta

6 Dokumentacja i Jakość Oprogramowania 6Agile Programming Częste tworzenie małych wydań Częste tworzenie wydań umożliwia lepsze dostosowanie się do wymagań użytkowników (uzyskanie oceny) Częste tworzenie wydań umożliwia lepsze dostosowanie się do wymagań użytkowników (uzyskanie oceny)

7 Dokumentacja i Jakość Oprogramowania 7Agile Programming Podział projektu na iteracje Harmonogram opracowania jest dzielony na 1-3 tygodniowe iteracje. Harmonogram opracowania jest dzielony na 1-3 tygodniowe iteracje. Utrzymuje się stałą długość iteracji. Utrzymuje się stałą długość iteracji. Nie planuje się zadań na przyszłość. Nie planuje się zadań na przyszłość. Jeśli długość iteracji jest zagrożona, to trzeba usunąć z niej część zadań. Jeśli długość iteracji jest zagrożona, to trzeba usunąć z niej część zadań.

8 Dokumentacja i Jakość Oprogramowania 8Agile Programming Planowanie iteracji Każda iteracja trwa od 1 do 3 tygodni. Każda iteracja trwa od 1 do 3 tygodni. Na początku każdej iteracji wybiera się opowieści do implementacji. Na początku każdej iteracji wybiera się opowieści do implementacji. Dla każdej opowieści określa się zadania programistyczne. Dla każdej opowieści określa się zadania programistyczne. Wybiera się też testy akceptacyjne, które się nie powiodły w poprzedniej iteracji. Wybiera się też testy akceptacyjne, które się nie powiodły w poprzedniej iteracji.

9 Dokumentacja i Jakość Oprogramowania 9Agile Programming Prostota Prosty projekt zajmuje o wiele mniej czasu Prosty projekt zajmuje o wiele mniej czasu Jeśli coś jest skomplikowane, to trzeba to zastąpić czymś prostszym Jeśli coś jest skomplikowane, to trzeba to zastąpić czymś prostszym Unikaj dodawania funkcjonalności przed uwzględnieniem tego w harmonogramie. Unikaj dodawania funkcjonalności przed uwzględnieniem tego w harmonogramie.

10 Dokumentacja i Jakość Oprogramowania 10Agile Programming Unikanie wczesnego dodawania funkcjonalności Należy unikać dodawania funkcjonalności, które mogą być użyte później. Jedynie 10% z nich jest rzeczywiście później wykorzystanych. Należy unikać dodawania funkcjonalności, które mogą być użyte później. Jedynie 10% z nich jest rzeczywiście później wykorzystanych.

11 Dokumentacja i Jakość Oprogramowania 11Agile Programming Stosowanie refaktoringu Programiści stosują dawno już napisany kod, który niekoniecznie pasuje do rozwiązania, ale działa. Programiści stosują dawno już napisany kod, który niekoniecznie pasuje do rozwiązania, ale działa. To rozwiązanie jest nieefektywne. To rozwiązanie jest nieefektywne. Należy usuwać nadmiarowości, niewykorzystane funkcjonalności, przestarzałe projekty. Należy usuwać nadmiarowości, niewykorzystane funkcjonalności, przestarzałe projekty.

12 Dokumentacja i Jakość Oprogramowania 12Agile Programming Klient jest zawsze dostępny Klient ma nie tylko pomagać zespołowi projektowemu, ale ma być jego częścią. Klient ma nie tylko pomagać zespołowi projektowemu, ale ma być jego częścią. Klient pisze opowieści użytkownika. Klient pisze opowieści użytkownika. W czasie planowania wydania klient negocjuje wybór opowieści, które mają być włączone do wydania. W czasie planowania wydania klient negocjuje wybór opowieści, które mają być włączone do wydania. Klient określa szczegółowe wymagania dla programistów. Klient określa szczegółowe wymagania dla programistów. Klient uczestniczy w testach funkcjonalnych. Klient uczestniczy w testach funkcjonalnych.

13 Dokumentacja i Jakość Oprogramowania 13Agile Programming Stosowanie standardów Kod musi być pisany zgodnie ze standardami. Kod musi być pisany zgodnie ze standardami. Łatwość czytania dla całego zespołu. Łatwość czytania dla całego zespołu. Łatwość refaktoringu. Łatwość refaktoringu.

14 Dokumentacja i Jakość Oprogramowania 14Agile Programming Moduły testowe Moduły testowe są kodowane w pierwszej kolejności. Moduły testowe są kodowane w pierwszej kolejności. Umożliwia to skupienie się na zrobieniu tego, co jest rzeczywiście wymagane. Umożliwia to skupienie się na zrobieniu tego, co jest rzeczywiście wymagane.

15 Dokumentacja i Jakość Oprogramowania 15Agile Programming Optymalizacja Optymalizację zostawia się na koniec. Optymalizację zostawia się na koniec. Nie próbuje się zgadnąć, co będzie wąskim gardłem. To trzeba zmierzyć. Nie próbuje się zgadnąć, co będzie wąskim gardłem. To trzeba zmierzyć.

16 Dokumentacja i Jakość Oprogramowania 16Agile Programming Testowanie przed rozpowszechnieniem Kod nie może być rozpowszechniony, jeśli nie przejdzie testów. Kod nie może być rozpowszechniony, jeśli nie przejdzie testów. To umożliwia stosowanie kolektywnej własności kodu. To umożliwia stosowanie kolektywnej własności kodu.

17 Dokumentacja i Jakość Oprogramowania 17Agile Programming Testy akceptacyjne Testy akceptacyjne są tworzone na podstawie opowieści użytkownika. Testy akceptacyjne są tworzone na podstawie opowieści użytkownika. Klient formułuje scenariusze testowe. Klient formułuje scenariusze testowe. Jedna opowieść może mieć wiele testów akceptacyjnych. Jedna opowieść może mieć wiele testów akceptacyjnych. Implementacja opowieści nie jest zakończona dopóki nie przejdzie wszystkich testów akceptacyjnych. Implementacja opowieści nie jest zakończona dopóki nie przejdzie wszystkich testów akceptacyjnych.

18 Dokumentacja i Jakość Oprogramowania 18Agile Programming Wnioski Agile Programming zapewnia większą wydajność tworzenia aplikacji w stosunku do tradycyjnych, ciężkich metod (np. RUP). Agile Programming zapewnia większą wydajność tworzenia aplikacji w stosunku do tradycyjnych, ciężkich metod (np. RUP). Agile Programming może zapewnić odpowiednią jakość produktu pod warunkiem spełnienia kluczowych założeń. Agile Programming może zapewnić odpowiednią jakość produktu pod warunkiem spełnienia kluczowych założeń.

19 Dokumentacja i Jakość Oprogramowania 19Agile Programming Warunki zapewnienia jakości Dobra współpraca (komunikacja) z klientami (użytkownikami końcowymi) w całym procesie wytwarzania. Dobra współpraca (komunikacja) z klientami (użytkownikami końcowymi) w całym procesie wytwarzania. Formułowanie celów wydań na podstawie rzeczywistych wymagań klientów. Formułowanie celów wydań na podstawie rzeczywistych wymagań klientów. Utrzymanie harmonogramu częstych wydań - ciągła praca nad produktem (!). Utrzymanie harmonogramu częstych wydań - ciągła praca nad produktem (!). Pisanie testów przed pisaniem kodu i przeprowadzanie testów przed opublikowaniem każdego wydania. Pisanie testów przed pisaniem kodu i przeprowadzanie testów przed opublikowaniem każdego wydania. Poddawanie wydań testom akceptacyjnym użytkowników. Poddawanie wydań testom akceptacyjnym użytkowników.

20 Dokumentacja i Jakość Oprogramowania 20Agile Programming Wady - zagrożenia Uzależnienie procesu od ludzi – zmienność składu zespołu. Uzależnienie procesu od ludzi – zmienność składu zespołu. Brak możliwości powrotu do projektu po dłuższej przerwie – brak dokumentacji. Brak możliwości powrotu do projektu po dłuższej przerwie – brak dokumentacji. Możliwość przeoczenia poważnych błędów projektowych – sytuacje wyjątkowe i awaryjne. Możliwość przeoczenia poważnych błędów projektowych – sytuacje wyjątkowe i awaryjne. Wysokie koszty wsparcia (pielęgnacji) Wysokie koszty wsparcia (pielęgnacji)

21 Dokumentacja i Jakość Oprogramowania 21Agile Programming Zastosowanie Proste aplikacje Proste aplikacje Projekty o niskim poziomie ryzyka Projekty o niskim poziomie ryzyka Możliwość nieustannej pielęgnacji produktu Możliwość nieustannej pielęgnacji produktu

22 Dokumentacja i Jakość Oprogramowania 22Agile Programming Źródła Kent Beck: Extreme Programming Explained: Embrace Change, Addison-Wesley, 1999 Kent Beck: Extreme Programming Explained: Embrace Change, Addison-Wesley,


Pobierz ppt "Wymagania jakości w Agile Programming Jarosław Kuchta Dokumentacja i Jakość Oprogramowania."

Podobne prezentacje


Reklamy Google