Wykład 2. MIS n Inżynieria oprogramowania Marzec Kazimierz Michalik Akademia Górniczo-Hutnicza im. S. Staszica w Krakowie

Transkrypt

1 Wykład 2 MIS n Inżynieria Marzec 2014 Kazimierz Michalik Akademia Górniczo-Hutnicza im. S. Staszica w Krakowie 2.1

2 Agenda

3 Czynności w czasie produkcji. Inżynieria stara się zidentyfikować i opisać podstawowe fazy i funkcjonowania, a także wskazać model optymalnego przebiegu tych faz. Co można robić w czasie? Planowanie. Implementacja. Testowanie. Dokumentowanie. Wdrożenie. Utrzymanie (konserwacja). 2.3

4 Edward V. Berard Walking on water and developing software from a specification are easy if both are frozen. (1993) Essays on object-oriented software engineering. Volume 1. Englewood Cliffs, N.J. : Prentice Hall 2.4

5 Ogólny schemat. 2.5

6 Dwa główne nurty. Istnieje wiele całościowych metodologii, z których dwie obecnie najważniejsze (i istniejace w wielu odmianach) to: - Unified Process RUP Metody zwinne - agile methods Extream programming (XP) Obydwie grupy metodologii zakładaja iteracyjne tworzenie, różniac się głównie stosunkiem do modelowania i planowania w trakcie procesu 2.6

7 Model iteracyjny 2.7

8 Model iteracyjny 2.7

9 Model iteracyjny 2.7

10 Model iteracyjny 2.7

11 Model iteracyjny 2.7

12 Model iteracyjny 2.7

13 Model przyrostowy 2.8

14 Model przyrostowy 2.8

15 Model przyrostowy 2.8

16 Model przyrostowy 2.8

17 Model przyrostowy 2.8

18 Model przyrostowy 2.8

19 Zasady RUP. 1 iteracyjne i przyrostowe tworzenie ; sterowane ryzykiem i priorytetami, ułatwiajace integrację całości kodu i dostosowanie do zmieniajacych się wymagań 2 zarzadzanie wymaganiami; we współpracy z klientem i w oparciu o przypadki użycia 3 stosowanie architektury opartej na komponentach 4 graficzne modelowanie ; różne perspektywy spojrzenia na system, użycie UML 5 kontrola i weryfikacja jakości przez cały czas procesu wytwarzania 6 zarzadzanie zmianami w oprogramowaniu 2.9

20 Fazy projektu RUP. 1 faza poczatkowa (inception) wstępne określenie wymagań, ryzyka, kosztu, harmonogramu, a także architektury systemu 2 faza opracowania (elaboration) ustalenie wymagań (większości przypadków użycia), architektury systemu oraz planu całego procesu wytwarzania systemu 3 faza konstrukcji (construction) tworzenie systemu (kolejnych komponentów), w trakcie nastepuje oddanie pierwszej (i być może dalszych) wersji użytkownikowi 4 faza przekazania (transition) system jest przekazywany użytkownikowi, wdrażany, szkoleni sa pracownicy obsługi systemu, nastepuje walidacja i końcowe sprawdzenie jakości 2.10

21 Dyscypliny - rodzaje wykonywanych zadań modelowanie biznesowe wymagania analiza i projektowanie implementacja testowanie wdrożenie zarzadzanie konfiguracja i zmianami zarzadzanie projektem (zarzadzanie ryzykiem, planowanie iteracji, monitorowanie postępów) organizacja środowiska (m.in. narzędzi) 2.11

22 Schemat RUP. 2.12

23 Agile programming Metody te maja pewne cechy wspólne, które wynikaja z przyjętej ideologii zapisanej w manifeście metod zwinnych (agile manifesto) Agile manifesto Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan Jednostki i interakcje ponad procesy i narzędzia Działajace oprogramowanie ponad wyczerpujac a dokumentację Współpraca z klientem ponad negocjacje kontraktu Reagowanie na zmiany ponad realizowanie planu 2.13

24 Agile programming Co jest charakterystyczne? Metody zwinne nadaja się dla małych zespołów tworzacych małe i średniej wielkości oprogramowanie, najczęściej dla biznesu (ważna szybkość dostarczania i dostosowanie do częstych zmian). Extreme Programming (XP) należy do grupy metodologii wytwarzania nazywanych metodami zwinnymi (agile methods) 2.14

25 Programowanie ekstremalne - XP Motywacja: klasyczne metodologie wytwarzania zbyt wolno reaguja na zmiany rynku i wymagań klientów zbyt dużo planowania, analizy i modeli oraz dokumentacji opóźnia wytworzenie i dostarczenie tego co naprawdę się liczy kodu klasyczne podejścia powoduja, że zmiany (spowodowane np. wykryciem błędu) w późnych fazach kodu sa bardzo kosztowne w procesach opartych na drobiazgowej analizie i planowaniu zbyt mało ufa się i daje swobody, tym którzy tak naprawdę tworza kod programistom 2.15

26 Programowanie ekstremalne - XP Podstawowe zasady: oprogramowanie jest rozwijane w krótkich cyklach i w ciagłej interakcji z klientem, po każdym cyklu może nastapić zmiana założeń co do dalszej pracy, co więcej może nastapić rewizja już napisanego kodu (refactoring) każdy przyrost dostarcza konkretna funkcjonalność określana na podstawie scenariuszy (opowieści użytkownika, user stories) już pierwsze wydanie zawiera system o pewnej całościowej strukturze realizujacy istotne dla klienta funkcje kolejne wydania (releases) kodu następuja co kilka miesięcy (maximum), iteracje maja po kilka tygodni, obowiazuje planowanie zadań kilka dni do przodu, przy założeniu, że kolejność działań jest określana przez priorytety ważności 2.16

27 Programowanie ekstremalne - XP Podstawowe zasady: przed przystapieniem do kodowania opracowywane sa szczegółowe testy majace za zadanie sprawdzenie wszelkich aspektów poprawności wprowadzanych zmian każda zmiana jest od razu integrowana z całościa kodu oraz testowana nowe oraz opracowane wcześniej testy (zautomatyzowane) sa powtarzane codziennie (lub nawet kilka razy dziennie), żeby sprawdzić czy nie zostały wprowadzone błędy w ciagu całego procesu gromadzona jest informacja zwrotna służaca usprawnieniu procesu i ostatecznego kodu ważna jest specyficzna organizacja miejsca pracy kodowanie realizowane jest zgodnie z przyjętymi przez cały zespół regułami (coding standards) 2.17

28 Programowanie ekstremalne - XP Podstawowe zasady: programowanie odbywa się parami (zgodnie ze szczegółowo ustalonymi zasadami), częste sa także dyskusje pomiędzy członkami całego zespołu tworzacego kod dokumentacja składa się z komentarzy w kodzie, opisu testów i niewiele więcej 2.18

29 Programowanie ekstremalne - XP 2.19

30 Programowanie ekstremalne - XP Troska o programistów: 40sto godzinny tydzień pracy - mamy za dużo pracy zamiast mamy za mało czasu odpowiednie środowisko pracy - otwarta przestrzeń z małymi prywatnymi pomieszczeniami na obrzeżach i stanowiskami w środku dla programowania parami wspólne posiadanie kodu nacisk na nieustanna komunikację (zwiazane m.in. z programowaniem parami) stworzenie ideologii zespołu walczacego o zwycięstwo (i nagradzajacego się za wszystkie osiagnięcia) dużo jedzenia i picia w zasięgu ręki zasada work with human nature, not against it 2.20

31 Scrum. 2.21

32 Model spiralny - zarzadzanie ryzykiem. 2.22

33 V(ee)-model. 2.23

34 Dual V(ee)-model. 2.24

35 Cleanroom model. 2.25

36 Rapid Application Development. 2.26

37 Continuous Integration (Continuous Delivery) 2.27

38 Istotne czynniki podczas wyboru modelu Tematyka Wielkość (obszerność) Czas trwania Złożoność Ryzyko (poziom i rodzaj) Zrozumienie wymagań użytkownika Zrozumienie obszaru zastosowań Zaangażowanie klienta Doświadczenie zespołu Wielkość zespołu Interakcje człowiek-komputer Dostępność narzędzi i technologii Wymagany poziom niezawodności 2.28