Faza strategiczna w projektach informatycznych (cd..)

Prezentacja na temat: "Faza strategiczna w projektach informatycznych (cd..)"— Zapis prezentacji:

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

2 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

3 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

4 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

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

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

7 Klasyfikcja wymagań niefunkcjonalnych
Wymagania niefunkcjonalne Wymagania Wymagania Wymagania dotyczące dotyczące zewnętrzne procesu produktu Wymagania Wymagania Wymagania Wymagania Wymagania Wymagania Wymagania Wymagania Ograniczenie Wymagania dotyczące dotyczące dotyczące dotyczące dotyczące dotyczące dotyczące legislacyjne kosztów dotyczące dostawcy implementacji standardów używalności efektywności niezawodności przenośności interoperacyj- 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

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

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

10 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

11 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

12 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 PMnorm = A x (KDSI)B mgr inż. Michał Kolano Instytut Informatyki Zakład Oprogramowania

13 COCOMO mgr inż. Michał Kolano Instytut Informatyki
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 mgr inż. Michał Kolano Instytut Informatyki Zakład Oprogramowania

14 COCOMO II PMnorm = A x (KDSI)B A =2,45; B=1,01+0,001 * wi
Współczynniki wi Bardzo niski Niski Nomi nalny Wysoki Bardzo wysoki Ekstra wysoki PREC 4,05 3,24 2,43 1,62 0,81 0,00 FLEX 6,07 4,86 3,64 1,21 RESL 4,22 3,38 2,53 1,69 0,84 TEAM 4,94 3,95 2,97 1,98 0,99 PMAT 4,54 2,73 1,82 0,91 mgr inż. Michał Kolano Instytut Informatyki Zakład Oprogramowania

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

16 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 systemach koszt ich poprawy jest różny na różnych etapach szybko rośnie: Faza projektowania Przed rozpoczęciem testowania W trakcie testowania Po przekazaniu do eksploatacji Koszt 1 6,5 15 67 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

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

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

19 Zakład Oprogramowania
Model propagacji błędów przykład L.B. Jednostka kosztu Łącznie Przed testowaniem 22 6,5 143 Podczas testów 85 15 1230 Po przekazaniu 12 67 804 razem 2177 bez przeglądów L.B. Jednostka kosztu Łącznie Projekt 22 1,5 33 Przed testowaniem 6,5 234 Podczas testów 85 15 315 Po przekazaniu 12 67 201 Razem 783 z przeglądami mgr inż. Michał Kolano Instytut Informatyki Zakład Oprogramowania

20 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

21 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

22 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

23 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 procesu aż do osiągnięcia poziomu procesów elementarnych zbiornik danych aktor przepływ mgr inż. Michał Kolano Instytut Informatyki Zakład Oprogramowania

24 Dekompozycja procesów
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

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

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

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

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

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