Podstawy Inżynierii Oprogramowania WYKŁAD 3 Modele cyklu życia oprogramowania MODEL KASKADOWY Faza strategiczna (c.d.) i Faza określania wymagań Dr hab. inż. Barbara Dębska, prof. PWSZ Dr hab. inż. Barbara Dębska, prof. PWSZ

Przykładowy harmonogram przedsięwzięcia przedstawiony na wykresie Gantta: Nazwa zadania V VI VII IX X XI XII I II III IV 1 Wstępne zbieranie wymagań 2 Budowa prototypu 3 Ocena prototypu 4 Opracowanie wymagań 5 Analiza 6 Projekt dziedziny problemu 7 Projekt interfejsu użytkownika 8 Projekt bazy danych 9 Realizacja bazy danych 10 Implementacja 11 Testy 12 Wdrożenie Dr hab. inż. Barbara Dębska, prof. PWSZ

Przykładowe kryteria, które stosuje firma do oceny rozwiązań: koszt, czas realizacji, niezawodność, stopień możliwości ponownego wykorzystania fragmentów systemu, przenośność na inne platformy, oraz wydajność. Do oceny rozwiązania wykorzystuje się zapis tabelaryczny. Dr hab. inż. Barbara Dębska, prof. PWSZ

Tabela przedstawia zapis rozważanych rozwiązań Kryterium A B C Koszt tys. [zł] 60 40 90 Czas [miesiące] 35 30 Niezawodność [liczba błędnych wykonań/tydzień] 4 8 12 Ponowne wykorzystanie [%] 50 Przenośność [%] 80 55 25 Wydajność [transakcji/s] 0.4 0.65 0.9 Analiza tabeli: 1. usuwanie rozwiązań zdominowanych. Rozwiązanie jest zdominowane jeśli istnieje inne rozwiązanie nie gorsze z punktu widzenia żadnego kryterium i lepsze w co najmniej jednym kryterium. (np. gdyby wydajność rozwiązania C wynosiła nie więcej niż 0.65 [transakcji/s] to było by to rozwiązanie zdominowane). Dr hab. inż. Barbara Dębska, prof. PWSZ

Niezawodność [liczba błędnych wykonań/tydzień] Analiza tabeli (c.d.): 2. znaczenie poszczególnych kryteriów jest różne, można im zatem nadać wagi, które pozwolą obliczyć sumę ważoną rozwiązań. Aby to było możliwe należy znormalizować dane w tabeli do zakresów [0, 1]. Kryterium A B C Waga Koszt tys. [zł] 0.60 1 3 Czas [miesiące] 0.50 2 Niezawodność [liczba błędnych wykonań/tydzień] Ponowne wykorzystanie [%] Przenośność [%] 0.55 Wydajność [transakcji/s] Łączna ocena 7.80 8.55 2.00 W tym wypadku rozwiązanie B można uznać za najlepsze. Sposobem oceny opcji w obecności wielu kryteriów zajmuje się dział statystyki znany pod nazwą ”wielokryterialne wspomaganie decyzji”. Dr hab. inż. Barbara Dębska, prof. PWSZ

Ocena przedsięwzięcia na podstawie spodziewanych kosztów rozwiązania: Niepewność w ocenie kosztów A B Pesymistyczny koszt [tys. zł] 100 80 Optymistyczny koszt [tys. zł] 40 60 Prawdopodobieństwo subiektywne Prawdopodobieństwo pesymistycznego rozwiązania 0.5 0.2 Prawdopodobieństwo optymistycznego rozwiązania 0.8 Spodziewany koszt rozwiązania [tys. zł] 70 64 Spodziewany koszt jest wyższy dla rozwiązania A, należy więc wybrać B. Dr hab. inż. Barbara Dębska, prof. PWSZ

Wierzchołki – sytuacje w których mogą zajść różne zdarzenia, DRZEWO RYZYKA: Ocena kosztów przedsięwzięcia w przypadku, gdy o wyborze rozwiązania decyduje wiele czynników. Opis drzewa ryzyka: Wierzchołki – sytuacje w których mogą zajść różne zdarzenia, Krawędzie – alternatywne zdarzenia, prawdopodobieństwo zajścia zdarzenia zależy od sytuacji odpowiadającej wierzchołkowi z którego wychodzi dana krawędź, Liście – możliwe scenariusze zajścia zdarzenia, prawdopodobieństwo zajścia scenariusza jest iloczynem prawdopodobieństw wszystkich krawędzi łączących liść z korzeniem. Dr hab. inż. Barbara Dębska, prof. PWSZ

Drzewo ryzyka: Zatrudniony zewnętrzny ekspert 0,8 Nie znaleziono eksperta 0,2 Porażka 0,1 Sukces 0,5 Porażka 0,5 Sukces 0,9 0,8*0,9=0,72 0,8*0,1=0,08 0,2*0,5=0,1 0,2*0,5=0,1 Koszt [tys. zł] 45 105 40 100 Prawdopodobieństwo zajścia scenariusza jest iloczynem prawdopodobieństw wszystkich krawędzi łączących liść z korzeniem. Spodziewany koszt: 450.72 + 1050.08 + 400.1 + 1000.1 = 54.80 [tys. zł] Dr hab. inż. Barbara Dębska, prof. PWSZ

SZACOWANIE KOSZTÓW OPROGRAMOWANIA Czynniki wpływające na koszt oprogramowania: koszt sprzętu będącego częścią tworzonego systemu, koszt wyjazdów i szkoleń, koszt zakupu narzędzi, nakład pracy. Techniki wykorzystywane dla oszacowania kosztów oprogramowania: - modele algorytmiczne, Przedsięwzięcie opisuje się za pomocą atrybutów, Odpowiedni algorytm daje w wyniku nakład pracy. - ocena przez ekspertów, Eksperci, wykorzystując własne doświadczenie, z dużą dokładnością potrafią oszacować koszt przedsięwzięcia. Dr hab. inż. Barbara Dębska, prof. PWSZ

Techniki wykorzystywane dla oszacowania kosztów oprogramowania: (c.d.) - ocena przez analogię, Wymaga dostępu do danych o podobnych przedsięwzięciach. Stosuje się tutaj systemy automatycznie uczące się stawiania prognoz (CA – cluster analysis, DT - decision trees, RKB - rule knowledgebase, ANN - artificial neural network). - prawo Parkinsona, Prawo, które stwierdza, że przedsięwzięcia prawie zawsze wykonywane są przy założonych nakładach. - wycena dla wygranej, Koszt szacowany jest na podstawie oceny możliwości klienta. Technika często stosowana przez firmy w przetargach na opracowanie oprogramowania. - szacowanie wstępujące. Przedsięwzięcie dzieli się na mniejsze zadania, szacuje się ich koszty, a następnie sumuje. Dr hab. inż. Barbara Dębska, prof. PWSZ

Nakład [osobomiesiące] = A(KDSI) b ALGORYTMICZNE MODELE SZACOWANIA KOSZTÓW OPROGRAMOWANIA, model COCOMO Model COCOMO wymaga oszacowania liczby instrukcji, z których będzie składał się system. Nakład pracy wylicza się z wzoru: Nakład [osobomiesiące] = A(KDSI) b KDSI – tysiąc instrukcji kodu źródłowego (thousand of delivered source code instruction) Dr hab. inż. Barbara Dębska, prof. PWSZ

Rozważane przedsięwzięcie można zaliczyć do jednej z klas: - przedsięwzięcie organiczne, To przedsięwzięcie wykonywane przez stosunkowo małe zespoły, złożone z osób o podobnym, wysokim poziomie umiejętności technicznych. Dziedzina problemu jest dobrze znana. Przedsięwzięcie jest wykonywane za pomocą dobrze znanych metod i narzędzi. - przedsięwzięcie półoderwane, Członkowie zespołu różnią się stopniem zaawansowania. Pewne aspekty dziedziny problemu, część metod i narzędzi nie jest im dobrze znana. - przedsięwzięcie osadzone, Klasa ta obejmuje przedsięwzięcia polegające na realizacji systemów o bardzo złożonych wymaganiach (np. wymagających ścisłej współpracy za sprzętem). Dziedzina problemu, stosowane metody i narzędzia są w dużej mierze nieznane. Większość członków zespołu nie ma doświadczenia w realizacji podobnych zadań. Dr hab. inż. Barbara Dębska, prof. PWSZ

Stałe A i b zależą od klasy przedsięwzięcia: Przedsięwzięcia organiczne: Nakład = 2,4(KDSI) 1,05 Przedsięwzięcia półoderwane: Nakład = 3,0(KDSI) 1,12 Przedsięwzięcia osadzone: Nakład = 3,6(KDSI) 1,20 Czas trwania przedsięwzięcia wylicza się z wzoru: Przedsięwzięcia organiczne: Czas [miesiące] = 2,5(Nakład) 0,32 Przedsięwzięcia półoderwane: Czas [miesiące] = 2,5(Nakład) 0,35 Przedsięwzięcia osadzone: : Czas [miesiące] = 2,5(Nakład) 0,38 Dr hab. inż. Barbara Dębska, prof. PWSZ

wymagania wobec niezawodności systemu, Otrzymane oszacowania powinny zostać skorygowane za pomocą, tzw. czynników modyfikujących, uwzględniających dodatkowe atrybuty opisujące przedsięwzięcie, np.: wymagania wobec niezawodności systemu, rozmiar bazy danych w stosunku do rozmiaru kodu, złożoność systemu, tj. złożoność struktur danych, złożoność algorytmów, komunikację pomiędzy innymi systemami, stosowanie obliczeń równoległych, wymagania co do wydajności systemu, ograniczenia pamięci, oraz zmienność sprzętu i oprogramowania systemowego tworzących środowisko pracy systemu. Dr hab. inż. Barbara Dębska, prof. PWSZ

Minikomputerowy wielodostępowy system rozliczania odbiorców HANDEL Przykład. Temat przedsięwzięcia: Minikomputerowy wielodostępowy system rozliczania odbiorców HANDEL FAZA STRATEGICZNA Opis systemu: HANDEL - minikomputerowy wielodostępowy system rozliczania odbiorców energii elektrycznej i gazu. Opracowywany system powinien zawierać komplet programów do bieżącego rozliczania odbiorców (zakładanie odbiorców, wymiana liczników, wprowadzanie odczytów, rozliczanie, drukowanie rachunków i faktur, załatwianie reklamacji, rejestrację wpłat, statystykę i gospodarkę licznikową). Dr hab. inż. Barbara Dębska, prof. PWSZ

Cele systemu - wymagania: Rozliczanie odbiorców energii elektrycznej i gazu w dowolnym cyklu obliczeniowym (rocznym, półrocznym, dwumiesięcznym, miesięcznym). Emisja raportów, rachunków i faktur. Prowadzenie ewidencji książek, odbiorców, liczników. Wprowadzanie danych rozliczeniowych z odczytów liczników. Wprowadzanie kompletu dokumentów finansowych. Załatwianie bieżących reklamacji odbiorców w trybie konwersacyjnym. Prowadzenie rozliczań bieżących sald odbiorców i płatników. Analiza zadłużeń, drukowanie not wraz z naliczonymi odsetkami. Sporządzanie sprawozdań ze sprzedaży energii. Tworzenie planu legalizacji liczników. Emisja zleceń OT. Zbiorcza inwentaryzacja liczników. Ewidencjonowanie obowiązujących taryf. Tworzenie i przeglądanie wieloletniego archiwum danych. Dr hab. inż. Barbara Dębska, prof. PWSZ

System zewnętrzny tworzą: - Pracownicy dokonujący bieżących odczytów. - Pracownicy dokonujący okresowych rozliczeń i aktualizacji danych. - Pracownicy dokonujący podsumowań i raportów. - Pracownicy odpowiedzialni za bieżącą eksploatację systemu (administratorzy) Środowiska implementacji: - Język bazy danych INFORMIX-4GL - Pakiet INFORMIX ONLINE - Standardowy język zapytań SQL - Eksploatacja na komputerach pracujących w sieci pod nadzorem systemu operacyjnego UNIX wyposażonych w końcówki terminalowe, systemową drukarkę i drukarki lokalne oraz terminale z piórem świetlnym do odczytów barakodów - Minikomputery PSION Dr hab. inż. Barbara Dębska, prof. PWSZ

Harmonogram przedsięwzięcia: II III IV V VI VII VIII IX 1 Ustalanie strategii 2 Opracowanie wymagań 3 Analiza i budowa modelu 4 Projekt dziedziny problemu 5 Projekt interfejsu użytkownika 6 Projekt bazy danych 7 Realizacja baz danych 8 Implementacja 9 Testowanie 10 Instalacja i szkolenie użytkowników Dr hab. inż. Barbara Dębska, prof. PWSZ

Szacowanie kosztów oprogramowania: Dodatkowe wymagania: - System musi uwzględniać możliwość zmiany cen w trakcie okresu rozliczeniowego. - W przyszłości zapewniać interfejs z systemami zewnętrznymi - Możliwość dostosowywania do zmieniających się możliwości sprzętowych - Zmianę parametrów uwzględniających zmiany w prawie Szacowanie kosztów oprogramowania: Czynniki wpływające na koszt oprogramowania: koszt delegacji służbowych (1000 PLN) - koszt zakupu oprogramowania do wytworzenia aplikacji (2200 PLN) - nakład pracy 28 osobo/miesięcy pracy (100 000 PLN) Dr hab. inż. Barbara Dębska, prof. PWSZ

FAZA OKREŚLANIA WYMAGAŃ Określenie wymagań Określenie wymagań Projektowanie Implementacja Testowanie Konserwacja Analiza Faza strategiczna Instalacja Dokumentacja Faza określania wymagań - to faza wstępna w której: określane są wymagania klienta wobec tworzonego systemu, a więc następuje zamiana wymagań klienta na konkretne zadania zapewniające osiągnięcie zdefiniowanych celów przedsięwzięcia. W tej fazie klient i analitycy (reprezentujący producenta oprogramowania) wspólnie konstruują zbiór wymagań wobec systemu zgodny z postawionymi celami. Dr hab. inż. Barbara Dębska, prof. PWSZ

Kontakt klient – analitycy: - Klient wyznacza osobę (osoby) do współpracy z analitykami. (Dla dużych przedsięwzięć wyznacza się wiele osób, wśród których wyłania się kierownika przedsięwzięcia.) - Analitycy przeprowadzają wywiady z przedstawicielami klienta. - Gdy oprogramowanie produkowane jest na rynek, analitycy prowadzą wywiady z potencjalnymi klientami i ekspertami z danej dziedziny. Przyczyny występowania trudności na linii analityk – klient: - Klient z reguły nie wie jak osiągnąć założone cele. - Cele klienta można osiągnąć na wiele sposobów. - Z dużych systemów korzystają różni klienci; ich cele mogą być sprzeczne. - Różni użytkownicy systemu mogą posługiwać się różną terminologią mówiąc o tych samych problemach. - Użytkownicy i zleceniodawcy to często inne osoby. Głos zleceniodawców może być decydujący, chociaż nie zawsze są oni w stanie przewidzieć potrzeby rzeczywistych użytkowników. Dr hab. inż. Barbara Dębska, prof. PWSZ

Klienci banku, którzy korzystają z systemu. Przykład. Przedstawiciele różnych grup użytkowników, którzy powinni wziąć udział przy ustalaniu wymagań dla systemu bankomatowego, którego opracowanie zleca się: Klienci banku, którzy korzystają z systemu. Przedstawiciele innych banków, którzy podpisują umowy o wzajemnym udostępnieniu bankomatów klientom banku. Dyrektorzy oddziałów banków, którzy odbierają informacje o zarządzaniu systemem. Pracownicy obsługi klientów w oddziałach, którzy biorą udział w codziennym działaniu systemu, przyjmują reklamacje klientów, itd. Administratorzy baz danych, którzy odpowiadają za integrację systemu z bazami danych klientów banku. Osoby odpowiedzialne za bezpieczeństwo w banku, którzy mają obowiązek zapewnić, aby bezpieczeństwo systemu nie było zagrożone. Dział marketingu banku, który prawdopodobnie będzie chciał wykorzystać system do celów marketingowych. Inżynierowie pielęgnacji sprzętu i oprogramowania, odpowiadający za unowocześnianie. Dr hab. inż. Barbara Dębska, prof. PWSZ

Proces określania i analizowania wymagań: Specyfikacja wymagań Sprawdzanie wymagań Początek procesu Rozpoznanie dziedziny Dokumentacja wymagań Nadawanie priorytetów Zbieranie wymagań Usuwanie sprzeczności Klasyfikacja Dr hab. inż. Barbara Dębska, prof. PWSZ

Klasyfikacja. Podzielenie bezładnego zbioru wymagań na spójne grupy. Charakterystyka czynności procesu określania i analizowania wymagań jest procesem iteracyjnym, którego jeden cykl obejmuje: Rozpoznanie dziedziny. Analitycy musza zrozumieć dziedzinę zastosowania. Zbieranie wymagań. Proces integracji z uczestnikami systemu, którego celem jest wyjawienie ich wymagań. Klasyfikacja. Podzielenie bezładnego zbioru wymagań na spójne grupy. Usuwanie sprzeczności. Wymagania podane przez wielu użytkowników będą nieuchronnie zawierać sprzeczności. Ta czynność polega na ich wyeliminowaniu. Nadawanie priorytetów. W każdym zbiorze wymagań można wskazać takie które są mniej lub bardziej ważne. Ta czynność powinna wskazać najważniejsze wymagania. Sprawdzanie wymagań. Sprawdza się wymagania, aby stwierdzić, czy lista jest pełna, spójna i zgodna z tym, jakie oczekiwania, tak naprawdę mają użytkownicy wobec systemu. Dr hab. inż. Barbara Dębska, prof. PWSZ

Poziomy ogólności (abstrakcji) wymagań klienta: 1. Definicja (opis) wymagań, ogólny opis w języku naturalnym. 2. Specyfikacja wymagań, częściowo ustrukturalizowany zapis wykorzystujący zarówno język naturalny, jak i proste, sformalizowane notacje, 3. Specyfikacja oprogramowania, w pełni formalny opis wymagań. Właściwości dobrego opisu wymagań: kompletny i niesprzeczny, opisuje zewnętrzne zachowanie się systemu, a nie sposób jego realizacji, obejmuje ograniczenia przy jakich musi pracować system, jest łatwy w modyfikacji, bierze pod uwagę przyszłe możliwe zmiany wymagań wobec systemu, oraz opisuje zachowanie systemu w niepożądanych sytuacjach. Dr hab. inż. Barbara Dębska, prof. PWSZ

Spis treści dla dokumentu zawierającego opis wymagań: – dokument w którym są zebrane wymagania wobec systemu, to formalny, szczegółowy kontrakt pomiędzy klientem a producentem, który powinien pozwalać na weryfikację czy stworzony system rzeczywiście spełnia postawione wymagania. Opis wymagań Spis treści dla dokumentu zawierającego opis wymagań: 1. Wprowadzenie – cele, zakres i kontekst systemu, 2. Opis ewolucji systemu – opis przewidywanych zmian wobec wymagań systemu. 3. Opis wymagań funkcjonalnych – opis funkcji, czynności i operacji wykonywanych przez system, 4. Opis wymagań niefunkcjonalnych – opis ograniczeń, przy zachowaniu których system powinien realizować swoje funkcje. 5. Model systemu. 6. Słownik – słownik powinien wyjaśniać terminy niezrozumiałe dla obu stron: terminy informatyczne niezrozumiałe dla klienta i terminy dotyczące dziedziny zastosowania systemu niezrozumiałe dla producenta, a także precyzować terminy niejednoznaczne. Dr hab. inż. Barbara Dębska, prof. PWSZ

Fragment opisu wymagań dla przedsięwzięcia Pity 2003 - zleconego przez biuro rozrachunkowe. Przykład. Nazwa funkcji Część I: edycja dochodów podatnika Opis Pozwala edytować łączne dochody podatnika uzyskane w roku 2003. Cel Przyspiesza obsługę klienta oraz zmniejsza ryzyko popełnienia błędu w zeznaniu podatkowym. DWE – Dane wejściowe Informacje o dochodach podatnika uzyskanych z różnych źródeł: kwoty przychodów, koszty uzyskania przychodów, kwoty wpłaconych zaliczek na poczet podatku dochodowego. Informacje mogą pochodzić z różnych źródeł. Źródło DWE Dokumenty oraz informacje dostarczone przez podatnika. Algorytm obliczania Kwota dochodu = kwota przychodu – kwota kosztów Wzór dotyczy zarówno konkretnych dochodów, jak i łącznych dochodów podatnika uzyskanych z różnych źródeł. Łączne kwoty przychodów, kosztów uzyskania, dochodów oraz zapłaconych zaliczek liczy się jako sumy tych kwot pochodzące z poszczególnych źródeł. DWY Obliczenie kwoty od której będzie liczony podatek. Dr hab. inż. Barbara Dębska, prof. PWSZ

Dziękuję za uwagę Dr hab. inż. Barbara Dębska, prof. PWSZ