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

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

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

Ź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

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

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

Model kaskadowy

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

Model przyrostowy

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

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

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

Model spiralny

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

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

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

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

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

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

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

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

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

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

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

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ć

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

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

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

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

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.

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

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

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ć

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

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

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

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)

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ę

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

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

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

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”

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

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

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ę

Dziękuję