Inżynieria Oprogramowania 5. Prototypowanie

Prezentacja na temat: "Inżynieria Oprogramowania 5. Prototypowanie"— Zapis prezentacji:

1 Inżynieria Oprogramowania 5. Prototypowanie
26/03/2017 Inżynieria Oprogramowania 5. Prototypowanie Leszek J Chmielewski Wydział Zastosowań Informatyki i Matematyki SGGW

2 Prototypowanie oprogramowania
Ian Sommerville: Software prototyping = Rapid software development to validate requirements Prototypowanie oprogramowania = Szybkie tworzenie oprogramowania dla zatwierdzenia wymagań

3 Plan Powtórka o modelach tworzenia oprogramowania
Prototypowanie w procesie tworzenia oprogramowania Prototypowanie błyskawiczne Prototypowanie interfejsu użytkownika

4 Źródła Materiały dra Waldemara Karwowskiego, wykładowcy w poprzednich semestrach Ian Sommerville, Inżynieria Oprogramowania, WNT, Warszawa 2003 Ian Sommerville, Software Engineering, Pearson Education Limited, 2001

5 Modele tworzenia oprogramowania
Model kaskadowy najprostszy Model ewolucyjny badawczy dla niezdecydowanego klienta Model spiralny jw., lepiej uwzględnia ryzyko Model przyrostowy lepszy niż kaskadowy, tańszy niż ewolucyjny Model formalny gdy można wszystko formalnie zapisać systemy krytyczne Model z użyciem wielokrotnym

6 Model kaskadowy Najpopularniejsze podejście Wada:
brak procesu weryfikacji pomiędzy etapami Zastosowanie w czystej postaci: do projektów krótkich gdzie wymagania są bardzo dobrze określone a wątpliwości można wyjaśnić na czas

7 Model kaskadowy

8 Model przyrostowy Pozwala projektować system etapami w przypadku, gdy nie możemy zaprojektować od razu całego systemu nie wiadomo, które funkcje okażą się bardziej istotne

9 Model przyrostowy

10 Model ewolucyjny Ważne:
mieć końcową wizję projektu i konsekwentnie realizować podzielone na kroki działania wdrożeniowe Problemy: wzrost trudności zarządzania nabranie nadmiernego tempa zmian ponad możliwości akceptacji przez wykonawcę system ma złą strukturę – źle dla dużych systemów

11 Model ewolucyjny Wersja początkowa Specyfikacja Ogólny opis Tworzenie
Wersje pośrednie Zatwierdzanie Wersja końcowa

12 Model spiralny System dzieli się na etapy i dla każdego z nich opracowuje się całościowy projekt Długi czas realizacji Stosuje się: gdy najważniejsza jest jakość gdy przewidujemy długi okres eksploatacji

13 Model spiralny

14 Model formalny Wychodzimy od matematycznego, poprawnego zapisu problemu Stosujemy ciąg przekształceń przybliżających zapis do postaci programu Każde przekształcenie formalnie weryfikujemy Dla systemów wysokiej jakości, krytycznych Koszty niekoniecznie wyższe, niż przy innych modelach Przykład: metoda Cleanroom

15 Model z użyciem wielokrotnym
System „składamy z klocków” Analiza komponentów Modyfikacja wymagań jeśli niemożliwa, powrót Projektowanie systemu nowy lub istniejący zrąb Integracja interfejsy ew. dopisane nowych komponentów

16 Plan Powtórka o modelach tworzenia oprogramowania
Prototypowanie w procesie tworzenia oprogramowania Prototypowanie błyskawiczne Prototypowanie interfejsu użytkownika

17 Prototypowanie oprogramowania
Ian Sommerville: Software prototyping = Rapid software development to validate requirements Prototypowanie oprogramowania = Szybkie tworzenie oprogramowania dla zatwierdzenia wymagań

18 Dlaczego? Klienci: trudność z określaniem wymagań
wpływ na codzienną pracę współpraca z innymi systemami które operacje nalezy zautomatzować ... Zamiast starannych przeglądów wymagań wypróbować! Potrzebny prototyp systemu

19 Prototyp pomaga: w określaniu wymagań w zatwierdzaniu wymagań
eksperymentowanie, nowe pomysły, silne i słabe strony sugestie nowych wymagań w zatwierdzaniu wymagań ujawnienie błędów, pominięć w wymaganiach w analizie i eliminacji zagrożeń jw., w późnych fazach tworzenia – koszty w rozpoznawaniu nieporozumień twórca – zamawiający – użytkownik w wykazaniu kierownictwu wykonalności w wyspecyfikowaniu systemu o jakości przemysłowej

20 Do czego jeszcze można go użyć?
Do szkoleń użytkowników Do testowania systemu „ramię w ramię” systemu wraz z prototypem różnica w wynikach oznacza obecność błędu

21 Przykład Gordon, Bieman (1995), 39 przedsięwzięć:
Zwiększona użyteczność Lepsze dopasowanie do potrzeb użytkowników Zwiększona jakość projektu Większa zdatność do pielęgnacji Zmniejszony wysiłek twórczy Niekoniecznie większy koszt większy na początku, mniejszy później klienci żądają mniej zmian Wada: możliwa mniejsza efektywność jeśli wykorzystuje się nieefektywny rdzeń z prototypu

22 Jasno określ cele Możliwe cele (nie wszystkie razem!)
zatwierdzenie wymagań funkcjonalnych pierwsza wersja systemu dowód wykonalności opracowanie interfejsu użytkownika Niezrozumienie celu  brak pożytku

23 Prototyp  system Pominięte funkcje
Osłabione wymagania niefunkcjonalne Minimum obsługi błędów (nie w interfejsie!) Nieuwzględnione standardy jakości, niezawodności, normy, ...

24 Najważniejszy krok prototypowania
Ocena prototypu sposób oceniania zależy od przyjętego celu

25 Prototyp w modelach tworzenia oprogr.
Model przyrostowy, ewolucyjny i spiralny Prototypowanie ewolucyjne: cel: dostarczenie działającego systemu stosowane wymagania: przede wszystkim najlepiej znane, o najwyższym priorytecie Prototypowanie z porzuceniem: cel: ustalenie/zatwierdzenie wymagań stosowane wymagania: przede wszystkim najmniej znane, o których chcemy więcej wiedzieć

26 Dalsze różnice W zarządzaniu jakością: Prototypowanie ewolucyjne:
budowane z zachowaniem standardów jakości właściwa architektura, dobra do pielęgnacji Prototypowanie z porzuceniem: ważna możliwość szybkich zmian dopuszczalna mała efektywność i niezawodność pielęgnacja nieistotna

27 Prototypowanie ewolucyjne
Idea: wstępna implementacja wystawiona na krytykę użytkowników udoskonalanie jeszcze raz...

28 Cechy Zalety: Przyspieszone dostarczenie systemu
gdy szybkość ważniejsza od jakości Włączenie użytkowników w proces budowy będą chcieli, aby system dobrze działał Wady: Brak specyfikacji zatwierdzamy względem celów: odpowiedniość ocena subiektywna Eskalacja zmian ...

29 Kłopoty... Z zarządzaniem Z pielęgnacją Z umową
brak lub za mało dokumentacji szybkość  nowe, mało znane technologie trudno o personel Z pielęgnacją liczne zmiany  uszkodzenia struktury system łatwo rozumieją tylko twórcy specjalistyczne technologie tworzenia szybko się starzeją Z umową nie można się oprzeć na specyfikacji stawka godzinowa niekorzystna dla klienta stała kwota niekorzystna dla wykonawcy

30 Zatem: Raczej dla systemów małych i średnich
Nie pielęgnujemy, ale wymieniamy całość Systemy duże – dalej... Trzeba łączyć modele wytwarzania np. z modelem przyrostowym opracowujemy i zamrażamy zrąb ewolucyjnie prototypujemy komponent N po dostarczeniu komponentu zamrażamy go wraz z jego interfejsami jeśli trzeba, wracamy do 2.

31 Prototypowanie z porzuceniem
Dla dużych systemów Aby zmniejszyć koszt całego (długiego) cyklu życia, rozszerzamy fazę analizy wymagań Prototypu używamy do dogłębnego wyjaśnienia wymagań dostarczenie informacji o ryzyku A następnie porzucamy

32 Cechy Do systemów sprzętowych Tworzony szybko Można pominąć
droga implementacja wymaga sprawdzenia Tworzony szybko aby dać czas użytkownikom na opinie przed tworzeniem specyfikacji Można pominąć dobrze znane funkcjonalności kryteria efektywnościowe normy jakości Inny, niż końcowa implementacja inna technologia, inny język ale można wykorzystać wybrane komponenty

33 Zamiast specyfikacji? Można by było użyć prototypu zamiast specyfikacji: „Zamawiamy system taki, jak ten.” Ale może pominięto ważne cechy implementacja nie ma umocowania prawnego pominiętych cech nie można przetestować

34 Kłopoty Kłopoty z testowaniem
testerzy-entuzjaści nie są typowymi użytkownikami zbyt powolny prototyp jest inaczej użytkowany, niż byłby gotowy system

35 Plan Powtórka o modelach tworzenia oprogramowania
Prototypowanie w procesie tworzenia oprogramowania Prototypowanie błyskawiczne Prototypowanie interfejsu użytkownika

36 Prototypowanie błyskawiczne
Skrócenie czasu dostarczenia, a nie dobre właściwości 3 sposoby: dynamiczne języki wysokiego poziomu programowanie bazy danych scalanie komponentów i programów

37 Języki wysokiego poziomu
Smalltalk obiektowy systemy interakcyjne Java Prolog logika przetwarzanie symboliczne Lisp listy Bardzo duże wymagania sprzętowe działanie wyraźnie wolniejsze (z czasem mniej ważne)

38 Programowanie bazy danych
Małe i średnie programy gospodarcze korzystają z baz danych Systemy zarządzania bazami mają wbudowane operacje Języki programowania 4. generacji: 4GL język zapytań do bazy generator interfejsów – formularze arkusz kalkulacyjny generator raportów Często interfejs www (dość powolny) Całościowo, szybkość i pamięć niekorzystne Języki słabo standaryzowane, starzeją się

39 Scalanie komponentów i programów
Trzeba: ustalić zrąb struktury napisać kod sterujący i integrujący Języki (skryptowe): Visual Basic, TCL/TK, Python, Perl Zręby integracji komponentów: CORBA, DCOM, JavaBeans Mechanizm łączenia i zagnieżdżania obiektów MS OLE

40 Scalanie... Zazwyczaj wspomagane graficznie Ma sens Ale
jeśli użytkownicy znają komponenty Ale komponenty wnoszą olbrzymie zbiory funkcjonalności całkiem niepotrzebnych zaś szczegółowe wymagania mogą być poza możliwościami komponentów

41 Plan Powtórka o modelach tworzenia oprogramowania
Prototypowanie w procesie tworzenia oprogramowania Prototypowanie błyskawiczne Prototypowanie interfejsu użytkownika

42 Prototypowanie interfejsu użytkownika
Zasadniczy udział użytkowników, projektanci nie powinni narzucać swojej wizji projektowanie koncentrujące się na użytkowniku – user centred approach bez użytkownika nie ma sensu Opisy i diagramy nie wystarczają, stąd prototypowanie jest podstawą Graficzne generatory interfejsów – implementacja automatyczna Często bywają to interfejsy www Niekonieczny program – może papier? metoda „Czarnoksiężnika z krainy Oz”

43 Plan Powtórka o modelach tworzenia oprogramowania
Prototypowanie w procesie tworzenia oprogramowania Prototypowanie błyskawiczne Prototypowanie interfejsu użytkownika Podsumowanie

44 Podsumowanie 1/2 Prototyp: aby ustalić wymagania
Ewolucja prototypu – małe i średnie systemy przyspiesza dostarczenie najpierw najlepiej rozumiane części Prototypowanie z porzuceniem – duże systemy tylko do b. dobrego ustalenia wymagań najpierw najsłabiej rozumiane części Tworzenie błyskawiczne pominięta część funkcjonalności lub wymagań niefunkcjonalnych

45 Podsumowanie 2/2 Metody Zawsze prototypujemy interfejsy użytkownika
języki wysokiego poziomu bazy danych komponenty wielokrotnego użycia Zawsze prototypujemy interfejsy użytkownika bo niemożliwa jest ich specyfikacja statyczna bo (tylko) użytkownicy mają wpływ na strukturę

46 Dziękuję