Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

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

Podobne prezentacje


Prezentacja na temat: "Mgr inż. Michał Kolano Instytut Informatyki Zakład Oprogramowania Faza strategiczna w projektach informatycznych (cd..) mgr inż. Michał Kolano."— Zapis prezentacji:

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

2 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łowaniewymagań

3 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

4 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

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

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

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

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

9 mgr inż. Michał Kolano Instytut Informatyki Zakład Oprogramowania Wymagania funkcjonalne 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 Nazwa funkcji Opis Dane wejściowe Źródło danych wejściowych Wynik Warunek wstępny Warunek końcowy Efekty uboczne Powód Funkcja obsługuje standardową transakcję materiałową

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

11 mgr inż. Michał Kolano Instytut Informatyki Zakład Oprogramowania Techniki szacowania kosztów 1.Modele algorytmiczne 1.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 2.Ocena przez eksperta 2.Ocena przez eksperta – wycena projektu przez doświadczonego specjalistę 3.Ocena przez analogię 3.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 4.Prawo Parkinsona 4.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 5.Wycena dla wygranej 5.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 6.Szacowanie wstępujące 6.Szacowanie wstępujące – podział projektu na mniejsze składowe, a następnie próba wyceny każdej z nich

12 mgr inż. Michał Kolano Instytut Informatyki Zakład Oprogramowania Model COCOMO 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 COCOMO II - nowy model zaktualizowany i dopasowany dla potrzeb projektów obiektowych. Szczegóły dostępne na witrynie PM norm = A x (KDSI) B

13 mgr inż. Michał Kolano Instytut Informatyki Zakład Oprogramowania COCOMO KlasaUczestnicyMetody 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 ZnaneZnana 2,4 * (KDSI) ,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

14 mgr inż. Michał Kolano Instytut Informatyki Zakład Oprogramowania COCOMO II PM norm = A x (KDSI) B A =2,45; B=1,01+0,001 * w i Współczynniki wi Bardzo niski NiskiNomi nalny WysokiBardzo wysoki Ekstra wysoki PREC 4,053,242,431,620,810,00 FLEX 6,074,863,642,431,210,00 RESL 4,223,382,531,690,840,00 TEAM 4,943,952,971,980,990,00 PMAT 4,543,642,731,820,910,00

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

16 mgr inż. Michał Kolano Instytut Informatyki Zakład Oprogramowania 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 Koszt16, 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. Jest tak bo:

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

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

19 mgr inż. Michał Kolano Instytut Informatyki Zakład Oprogramowania z przeglądami bez przeglądów Model propagacji błędów przykład L.B.Jednostka kosztu Łącznie Przed testowaniem226,5143 Podczas testów Po przekazaniu razem2177 L.B.Jednostka kosztu Łącznie Projekt221,533 Przed testowaniem226,5234 Podczas testów Po przekazaniu Razem783

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

21 Instytut Informatyki Zakład Oprogramowania Faza analizy logiczny model logicznego modelufazy modelowania 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.

22 mgr inż. Michał Kolano Instytut Informatyki Zakład Oprogramowania Analiza strukturalna i obiekowa metod strukturalnych 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 Metody obiektowe integrują w sobie składowanie danych i procesy. Modele pojawiły się w latach osiemdziesiątych i są nadal rozwijane.1

23 mgr inż. Michał Kolano Instytut Informatyki Zakład Oprogramowania Tworzenie diagramu DFD proces zbiornik danych aktor przepływ 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

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

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

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

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

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

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


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

Podobne prezentacje


Reklamy Google