F a za strategiczna w projektach informatycznych (cd..)

mgr inż. Michał Kolano Faza strategiczna w projektachinformatycznych (cd..) mgr inż. Michał Kolano Instytut Informatyki Zakład Oprogramowania

Etap formułowania wymagań Etap formułowania wymagań to proces zamiany celów klienta na formalnąspecyfikację wymagań. Celem fazy jest dokładne określenie wymagań klienta wobec tworzonego systemu, czyli udzielenie odpowiedzi na pytanie co i przy jakich założeniach system ma robić. Proces określania wymagań należy rozumieć nie jako proste zbierania informacji o wymaganiach, lecz jako proces, w którym klient samodzielnie (albo wspólnie z przedstawicielami producenta – analitykami) tworzy zbiór wymagań zgodny z postawionymi celami. formułowanie wymagań mgr inż. Michał Kolano Instytut Informatyki Zakład Oprogramowania

Trudności fazy formułowania wymagań • klient nie potrafi rozgraniczyć potrzeb od wymagań; te pierwsze często formułuje mało konkretnie i ogólnikowo; tych drugich nie potrafi wyartykułować (trzeba je rozpoznać) • klient z reguły spodziewa się poprawy stanu aktualnego organizacji, często nie przewidując jakie zmiany w organizacji przedsiębiorstwa spowoduje ulepszony system; najchętniej też nie ponosiłby za zmiany te odpowiedzialności • klient z reguły nie wie w jaki sposób osiągnąć założone cele; z drugiej strony cele klienta można osiągnąć na wiele sposobów • duże system wykorzystywane są przez wielu użytkowników; ich cele często są sprzeczne; różni użytkownicy mogą posługiwać się inną terminologią mówiąc o tych samych problemach • zleceniodawcy i użytkownicy do często inne osoby; głos zleceniodawcy, choć decydujący, nie zawsze właściwie potrafi przewidzieć potrzeby rzeczywistych użytkowników mgr inż. Michał Kolano Instytut Informatyki Zakład Oprogramowania

Poziomy abstrakcji opisu wymagań Definicja wymagań: to ogólny opis usług jakie system będzie wykonywał dla użytkownika. Opis formułuje się w języku naturalnym, tak aby ten był zrozumiały dla kierownictwa firmy (ale także dla wykonawcy, finansujących i użytkowników). Specyfikacja wymagań: to częściowo ustrukturalizowany zapis wykorzystujący zarówno język naturalny jak i proste, przynajmniej częściowo sformalizowane notacje; podstawowym celem dokumentu jest stworzenie pomostu komunikacyjnego pomiędzy zleceniodawcą a twórcą oprogramowanie; specyfikacja powinna być zrozumiała dla służb technicznych obu stron. Specyfikacja oprogramowania: w pełni formalny opis wymagań; baza dla projektu i implementacji; ma ścisły związek ze specyfikacją wymagań, lecz przemawia głownie do wykonawcy mgr inż. Michał Kolano Instytut Informatyki Zakład Oprogramowania

Problemy i potrzeb systemu Badanie wykonalności Modelowanie systemu Definiowanie wymagań Raport o potrzebach Specyfikacja wymagań Model systemu Specyfikacja systemu Studium wykonalności Definicja wymagań Dokument wymagań Specyfikacja wymagań Specyfikacja projektowa Etap formułowania wymagań mgr inż. Michał Kolano Instytut Informatyki Zakład Oprogramowania

Rodzaje wymagań wymagania wymaganie funkcjonalne wymagania niefunkcjonalne mgr inż. Michał Kolano Instytut Informatyki Zakład Oprogramowania

Klasyfikcja wymagań niefunkcjonalnych Wymagania niefunkcjonalne Wymagania Wymagania Wymagania dotyczące dotyczące zewnętrzne procesu produktu Wymagania Wymagania Wymagania Wymagania Wymagania Wymagania Wymagania Wymagania Wymagania Ograniczenie dotyczące dotyczące dotyczące dotyczące dotyczące dotyczące legislacyjne dotyczące dotyczące kosztów dostawcy implementacji standardów używalności efektywności niezawodności interoperacyj- przenośności ności Wymagania dotyczące szybkości działalnia Wymagania dotyczące rozmiarów /objętości mgr inż. Michał Kolano Instytut Informatyki Zakład Oprogramowania

Metryka Liczba transakcji przetwarzanych na sekundę, czas reakcji na sygnał użytkownika / sygnał zewnętrzny KB/MB/GB Cecha Szybkość Czas treningu użytkownika, liczba stron systemu pomocy Rozmiar Średni czas międzyawaryjny, prawdopodobieństwo niedostępności, częstotliwość występowania awarii Łatwość użycia Niezawodność Czas restartu po awarii, procent zdarzeń powodujących awarie Odporność na błędy Procent instrukcji zależnych od systemu, liczna systemów docelowych Przenośność Metryki wymagań niefunkcjonalnych mgr inż. Michał Kolano Instytut Informatyki Zakład Oprogramowania

Przyjęcie materiału (PZ) Przyjęcie na magazyn materiałów od kontrahenta zewnętrznego z wystawieniem dokumentu PZ i przesłaniem odpowiedniego dekretu do księgowości Nazwa funkcji Opis Numer kontrahenta, Kwota netto dokumentu, Ilośćmateriału na dokumencie, Indeks materiałowy, Stan magazynowy danego materiału Dane wejściowe Źródło danych wejściowych Faktura, Dokument ważenia Wynik Zwiększenie stanu na indeksie materiałowym Wysłanie dekretu (WN)311-(MA)301 do FK Warunek wstępny Warunek końcowy Numer kontrahenta jest w bazie kontrahentów Istnieje odpowiedni indeks materiałowy Efekty uboczne Powód Zwiększony stan indeksu materiałowego Aktualizacja salda dostaw kontrahenta Funkcja obsługuje standardową transakcję materiałową Wymagania funkcjonalne mgr inż. Michał Kolano Instytut Informatyki Zakład Oprogramowania

Szacowanie kosztów oprogramowania Koszt przedsięwzięcia informatycznego należy kalkulować w oparciu o klasyczny rachunek kosztów. Ze względu na fakt, że największą wartość kosztów w ogólnej wartości projektu tworzy praca (robocizna) największe znaczenie ma zaplanowanie kosztów utrzymania grup projektowych.Nakłady pracy najczęściej szacuje się w osobomiesiącach . mgr inż. Michał Kolano Instytut Informatyki Zakład Oprogramowania

Techniki szacowania kosztów • Modele algorytmiczne – wymagają opisu danego przedsięwzięcia za pomocą szeregu atrybutów liczbowych i opisowych (np. liczba użytkowników, liczba transakcji, wymagany czas reakcji systemu, ilość przetwarzanych dokumentów). Odpowiedni algorytm daje w wyniku szacowany nakład pracy • Ocena przez eksperta – wycena projektu przez doświadczonego specjalistę • Ocena przez analogię – metoda dla firm posiadających doświadczenia z prowadzących projektów, polega na gromadzeniu informacji o wykonanych projektach i wykorzystywaniu jej do szacowania nakładów potrzebnych na zakończenie nowego projektu • Prawo Parkinsona – przyjęcie założenia, że projekt zawsze może być wykonany przy założonych nakładach -> tzn. że system dopasuje się do planowanego poziomu kosztów • Wycena dla wygranej – przyjęcie założenia, że koszty projektu nie mogą przekroczyć możliwości klienta (odbiorcy), a jednocześnie przewidywanych działań konkurentów • Szacowanie wstępujące – podział projektu na mniejsze składowe, a następnie próba wyceny każdej z nich mgr inż. Michał Kolano Instytut Informatyki Zakład Oprogramowania

Model COCOMO COCOMO – model kontruowania kosztów (Constructive Cost Model opublikowany w książce Software Engineering Economics, Prentice-Hall 1981 ). Barry Boehm (autor) twierdzi, że samo programowanie pochłania około połowy wysiłku wkładanego w tworzenie oprogramowania COCOMO II - nowy model zaktualizowany i dopasowany dla potrzeb projektów obiektowych. Szczegóły dostępne na witrynie http://sunset.usc.edu/cocomoII PMnorm = A x (KDSI)B mgr inż. Michał Kolano Instytut Informatyki Zakład Oprogramowania

Klasa Uczestnicy Metody i narzędzia Dziedzina problemu Nakład (osobomiesiące) Czas (miesiące) Przedsięwzięcia organiczne (organic project) Małe zespoły, złożone z osób o wysokim poziomie umiejętności technicznych Znane Znana 2,4 * (KDSI) 1.05 2,5 (Nakład) 0,32 Przedsięwzięcia półoderwane (semi-detached projects) Członkowie różnią się stopniem zaawansowania Część metod i narzędzi nieznana Częściowo znana 3 * (KDSI) 1,12 2,5 (Nakład) 0,35 Przedsięwzięcia osadzone (embeded projects) Członkowie zespołu nie mają doświadczeń z podobnych zadań, wymagania bardzo wysokie Większość metod i narzędzi nie znana W dużej mierze nieznana 3,6 (KDSI) 1,2 2,5 (Nakład) 0,38 COCOMO mgr inż. Michał Kolano Instytut Informatyki Zakład Oprogramowania

COCOMO II PMnorm = A x (KDSI)BA =2,45; B=1,01+0,001 * wi mgr inż. Michał Kolano Instytut Informatyki Zakład Oprogramowania

Wycena projektu metodą COCOMO– przykład mgr inż. Michał Kolano Instytut Informatyki Zakład Oprogramowania

Faza projektowania Przed rozpoczęciem testowania W trakcie testowania Po przekazaniu doeksploatacji Koszt 1 6,5 15 67 Dlaczego warto dokonywać przeglądów kończących poszczególne fazy Badania Pressmana: na etapie projektowania powstaje 50%-65% wszystkich błędów z fazy rozwoju; w dużych systemachkoszt ich poprawy jest różny na różnych etapach szybko rośnie: Jest tak bo: • - w przypadku prac wykonywanych jednoosobowo jest kwestią czasu zapomnienie trudnych do udokumentowania szczegółów, decyzji i motywacji • - w ogólnym przypadku błędny efekt końcowy efekt końcowy powstał na bazie błędnego projektu – na bazie projektu rozwiązywano bowiem szereg zagadnień bardziej szczegółowych • - szybko rosnący koszt błędu jest także efektem konieczności powtórzenia części procesów projektowych i kontrolnych. mgr inż. Michał Kolano Instytut Informatyki Zakład Oprogramowania

Model propagacji błędów mgr inż. Michał Kolano Instytut Informatyki Zakład Oprogramowania

Model propagacji błędówprzykład mgr inż. Michał Kolano Instytut Informatyki Zakład Oprogramowania

Model propagacji błędówprzykład bez przeglądów z przeglądami mgr inż. Michał Kolano Instytut Informatyki Zakład Oprogramowania

mgr inż. Michał Kolano Faza analizy [1]– modelowanie systemu przy pomocy diagramów przepływu danych mgr inż. Michał Kolano Instytut Informatyki Zakład Oprogramowania

Faza analizy Podstawowym celem fazy jest udzielenie odpowiedzi na pytanie jak system ma działać. Wynikiem fazy jest logiczny model opisujący sposób realizacji przez system postawionych wymagań, lecz abstrahujący od szczegółów implementacyjnych. Ponieważ celem jest budowa logicznego modelu systemu faza nosi też nazwę fazy modelowania. Logiczny model pozwala lepiej zrozumieć postawiony problem i dzięki temu lepiej określić wymagania wobec systemu. Często w opisach cyklu życia oprogramowania wymienia nie wymienia się fazy formułowania wymagać: wówczas faza analizy określa formułowanie wymagań i budowę modelu. mgr inż. Michał Kolano Instytut Informatyki Zakład Oprogramowania

Analiza strukturalna i obiekowa Tradycyjne metody, rozwijane od lat sześćdziesiątych noszą nawę metod strukturalnych (structured methods). Metody te opierają się na rozłącznym analizowaniu dwóch składowych problemu: składowych pasywnych, odzwierciedlających fakt przechowywania w systemie pewnych danych (modele danych) oraz aktywnych odzwierciedlających wykonywanie w systemie pewnych operacji (modele procesów). Analiza strukturalna rozpoczyna się od budowy dwóch różnych modeli systemu. Pierwszy to model danych (model związków encji - ERD), drugi model procesów (PM dataflow diagam). Te dwa modele są następnie integrowane w model przepływów danych – DFD). Metody te wykorzystuje się głównie wtedy gdy jedna ze składowych problemów wyraźnie dominuje nad drugą; modele te ukierunkowane są na współpracę z relacyjnymi bazami danych. Metody obiektowe integrują w sobie składowanie danych i procesy. Modele pojawiły się w latach osiemdziesiątych i są nadal rozwijane. 1 mgr inż. Michał Kolano Instytut Informatyki Zakład Oprogramowania

Tworzenie diagramu DFD proces • Algorym budowy DFD • Skonstruuj diagram kontekstowy, obejmujący systemy zewnętrzne, pojedynczy proces opisujący cały system orze przepływy danych pomiędzy systemami zewnętrznymi oraz systemem • Zdekomponuj proces znajdujący się na powyższym diagramie, aż do opisującego go diagramu przepływu danych • Powtarzaj dekompozycję dla każdego procesuaż do osiągnięcia poziomu procesów elementarnych zbiornik danych aktor przepływ mgr inż. Michał Kolano Instytut Informatyki Zakład Oprogramowania

Dekompozycja procesów A B F F f2 x z v f6 p k A f1 f1 f4 f5 B f7 s y f3 w z f4 f41 a f41 f41 k b w f41 c mgr inż. Michał Kolano Instytut Informatyki Zakład Oprogramowania

Modelowanie – system LBMS Dataflow Diagram (DFD) Proces Hierarchy Diagram (PHD) mgr inż. Michał Kolano Instytut Informatyki Zakład Oprogramowania

Przykład: Biuro adwokackie mgr inż. Michał Kolano Instytut Informatyki Zakład Oprogramowania

Dziękuję za uwagę mgr inż. Michał Kolano Instytut Informatyki Zakład Oprogramowania

F a za strategiczna w projektach informatycznych (cd..)