Inżynieria oprogramowania wykład III Faza strategiczna prowadzący: dr hab. inż. Krzysztof Bartecki, prof. PO
Faza strategiczna Wymagania Projektowanie Implementacja Testowanie Konserwacja Strategiczna Analiza Instalacja Dokumentacja Głównymi celami fazy strategicznej są: ustalenie możliwości realizacji przedsięwzięcia programistycznego (czyli wykonanie tzw. studium wykonalności), oszacowanie jego kosztów, prowadzenie rozmów/negocjacji z przedstawicielami klienta. K. Bartecki, Inżynieria oprogramowania, III/2
Studium wykonalności (ang. feasibility study) ma na celu, w kontekście projektowanego systemu informatycznego, umożliwienie odpowiedzi na następujące pytania: czy system przyczyni się do realizacji ogólnych celów przedsiębiorstwa oraz/lub poprawy jego funkcjonowania? czy system może być zaimplementowany z użyciem dostępnych technologii, w ramach ustalonego budżetu i ograniczeń czasowych? czy system może być zintegrowany z istniejącymi systemami, które już funkcjonują? Studium wykonalności jest narzędziem, na podstawie analizy którego można dojść do jednoznacznych wniosków: czy projekt warto wcielać w życie, czy też nie. K. Bartecki, Inżynieria oprogramowania, III/3
Dwa typowe przypadki System tworzony na konkretne zamówienie (ang. bespoke software): - ścisła współpraca z klientem, - negocjacje, - firma bierze udział w przetargu. Firma produkująca oprogramowanie sprzedawane rynkowo (ang. offthe-shelf software): - uwagi użytkowników poprzednich wersji systemu, - uwagi potencjalnych klientów, - badania marketingowe (również w fazie określania wymagań). K. Bartecki, Inżynieria oprogramowania, III/4
Czynności wykonywane w fazie strategicznej rozmowy (wywiady) z klientem lub jego przedstawicielami, określenie celów przedsięwzięcia z punktu widzenia klienta, określenie zakresu i kontekstu przedsięwzięcia, ogólne określenie wymagań wykonanie wstępnej analizy i projektu systemu, propozycja kilku możliwych sposobów realizacji systemu oraz wybór tej optymalnej, oszacowanie kosztów budowy systemu, analiza rozwiązań, prezentacja wyników analizy klientowi oraz korekta wyników, budowa wstępnego harmonogramu przedsięwzięcia. K. Bartecki, Inżynieria oprogramowania, III/5
Wywiad (ang. interview) Cel: uzyskanie informacji potrzebnych do oceny wykonalności przedsięwzięcia oraz pozyskanie celów strategicznych klienta w zakresie wymagań funkcjonalnych oraz ograniczeń. Rozmówca: średni i wyższy szczebel zarządzania firmy merytorycznie przygotowany, posiadający wystarczające kompetencje w zakresie wyrażania wymagań klienta. Metoda realizacji: bezpośrednie rozmowy. K. Bartecki, Inżynieria oprogramowania, III/6
Uwaga Znaczna część wiedzy jest posiadana przez ludzi nieświadomie, albo uważana za powszechnie znaną tzn., ten, kto ją posiada uznaje, że jest to tak oczywiste, że nie warto o tym mówić, lub że dana informacja nie ma znaczenia, w celu pozyskania wiedzy, dobry analityk musi zrobić więcej, niż tylko wysłuchać rozmówcę tzn. nie ograniczać się tylko do pytań Co?, ale również: Dlaczego?, Załóżmy, że, A co, jeżeli, na przykład opisując pożądane funkcje systemu, pracownik fabryczny prawdopodobnie nie wspomni o tym, że poziom hałasu na hali, na której system ma pracować, jest bardzo wysoki (uniemożliwiając np. usłyszenie sygnałów dźwiękowych wydawanych przez system). K. Bartecki, Inżynieria oprogramowania, III/7
Przykład Firma meblarska PanKos zajmuje się produkcją boazerii panelowych, listew wykończeniowych, komponentów do mebli, takich jak np. fronty meblowe, a także gotowych produktów, jak np. drzwi. Do tej pory dane o zamówieniach i stanach magazynowych zapisywane były w plikach programu Excel oraz w zeszytach, co sprawiało spore kłopoty pracownikom i było przyczyną trudności z obsługą wielu zamówień. Ze względu na rozwój firmy, rosnącą liczbę oferowanych produktów oraz stale wzrastającą liczbę klientów, firma zdecydowała się na zamówienie dedykowanego specjalnie dla niej systemu informatycznego. K. Bartecki, Inżynieria oprogramowania, III/8
Przykład definicji celu przedsięwzięcia (dla systemu informatycznego firmy PanKos): usprawnienie ewidencji stanów magazynowych półproduktów oraz produkowanych komponentów, zmniejszenie ryzyka popełnienia błędu przy realizacji zamówień na surowce i produkty, usprawnienie ewidencji kontrahentów, czyli dostawców półproduktów oraz odbiorców produktów, umożliwienie ewidencji pracowników obsługujących system. K. Bartecki, Inżynieria oprogramowania, III/9
Zakres przedsięwzięcia (zakres odpowiedzialności systemu) to zakres procesów zachodzących w firmie, które zostaną objęte planowanym przedsięwzięciem programistycznym. Z reguły obejmuje on jedynie pewien zakres (wycinek) działalności firmy. Dziedzina problemu (zakres działalności firmy) Zakres odpowiedzialności systemu K. Bartecki, Inżynieria oprogramowania, III/10
Przykład zakresu przedsięwzięcia (dla systemu informatycznego firmy PanKos): Zakres przedsięwzięcia obejmuje głównie tę część działalności firmy PanKos, która dotyczy obsługi jej magazynu półproduktów i produktów, w tym operacje ich dodawania, usuwania oraz zmiany parametrów (np. ceny). Ponadto system będzie wspomagał pracę działu obsługi zamówień. Dotyczyć to będzie zarówno zamówień składanych przez firmę PanKos u współpracujących z nią dostawców półproduktów (np. płyt MDF), jak również zamówień składanych przez odbiorców na produkty wytwarzane przez firmę PanKos (np. drzwi). K. Bartecki, Inżynieria oprogramowania, III/11
Ilustracja zakresu przedsięwzięcia informatycznego (dla systemu informatycznego firmy PanKos) Dział Kadr Dział Zamówień Dział Produkcji Dział Magazynowy K. Bartecki, Inżynieria oprogramowania, III/12
Kontekst przedsięwzięcia (tzw. terminatory) to użytkownicy, systemy, organizacje, z którymi tworzony system informatyczny będzie współpracował. Przykład (dla systemu informatycznego firmy PanKos): W systemie wyróżnić można następujące typy jego bezpośrednich użytkowników, będących pracownikami firmy PanKos: Administrator systemu, Pracownik. Ponadto, dla potrzeb ewidencji pracowników uprawnionych do korzystania z systemu, będzie on współpracował z: bazą danych pracowników firmy, zarządzaną przez Dział Kadr. Ponadto, w celu umożliwienia przeglądania magazynu produktów oraz składania zamówień, dostęp do systemu będzie miał: Kontrahent, nie będący pracownikiem firmy PanKos. K. Bartecki, Inżynieria oprogramowania, III/13
Kontekst systemu informatycznego firmy PanKos Pracownik Dział Kadr (baza pracowników) Firma PanKos Kontrahent System informatyczny firmy PanKos Administrator K. Bartecki, Inżynieria oprogramowania, III/14
Ogólne określenie wymagań stanowi bardziej szczegółowe rozwinięcie celu i zakresu przedsięwzięcia. Przykład (dla systemu informatycznego firmy PanKos): System powinien posiadać następujące funkcje: przyjmowanie półproduktów i gotowych towarów na stan magazynu, wyświetlanie stanów magazynowych, usuwanie półproduktów i towarów ze stanu magazynu, umożliwienie ewidencji pracowników obsługujących system, dodawanie zamówień na półprodukty, dodawanie zamówień na towary, anulowanie zamówień, przeprowadzanie inwentaryzacji, itp. K. Bartecki, Inżynieria oprogramowania, III/15
Decyzje strategiczne dotyczące sposobu dalszej realizacji przedsięwzięcia informatycznego: wybór modelu, zgodnie z którym będzie realizowane przedsięwzięcie, wybór technik stosowanych w kolejnych fazach: analizy i projektowania (metodologie, notacje), wybór narzędzia (narzędzi) CASE, wybór środowiska (środowisk) implementacji, określenie stopnia wykorzystania gotowych komponentów, podjęcie decyzji o współpracy (lub nie) z innymi producentami oprogramowania lub zatrudnieniu ekspertów. Ograniczenia, jakie należy uwzględnić: maksymalne nakłady finansowe, jakie można ponieść, dostępny personel, dostępne narzędzia, ograniczenia czasowe. K. Bartecki, Inżynieria oprogramowania, III/16
Ocena rozwiązań W fazie strategicznej często rozważa się kilka możliwych rozwiązań realizacji systemu informatycznego, z których następnie wybiera się jedno najlepsze. Przykładowe kryteria oceny jakości rozwiązań: koszt, czas realizacji, niezawodność, możliwość ponownego użycia, przenośność na inne platformy (systemowe, sprzętowe), wydajność (szybkość). K. Bartecki, Inżynieria oprogramowania, III/17
Tabelaryczny zapis rozważanych rozwiązań przykład Rozwiązanie A B C Koszt (tys. zł) 120 80 175 Czas (miesiące) Niezawodność (błędy/tydzień) Ponowne użycie (%) Przenośność (%) 33 5 40 90 30 36 9 13 40 30 75 30 Wydajność (transakcje/s) 0.35 0.75 0.75 Oszacowanie wartości podanych w tabeli może być trudnym zadaniem. K. Bartecki, Inżynieria oprogramowania, III/18
Wybór rozwiązania etapy usunięcie rozwiązań zdominowanych, tj. gorszych według wszystkich (lub prawie wszystkich) kryteriów w podanym przypadku rozwiązaniem zdominowanym jest C, normalizacja wartości dla poszczególnych kryteriów, czyli sprowadzenie ich do przedziału [0,1], przypisanie wag do poszczególnych kryteriów, w zależności od priorytetów (może być trudne), wybór rozwiązania o największej wartości. K. Bartecki, Inżynieria oprogramowania, III/19
Ocena rozwiązań za pomocą sumy ważonej Rozwiązanie A B waga Koszt 0,58 1 3 Czas Niezawodność Ponowne użycie Przenośność 0,5 1 1 1 1 2 0,5 3 1 1 0,75 1,5 Wydajność 0 0,62 0,75 Łączna ocena 7,74 9,17 K. Bartecki, Inżynieria oprogramowania, III/20
Szacowanie kosztów oprogramowania Na koszt tworzonego oprogramowania składają się następujące czynniki: koszt sprzętu będącego częścią tworzonego systemu, koszt wyjazdów i szkoleń, koszt zakupu narzędzi, nakład pracy. Trzy pierwsze czynniki są stosunkowo łatwe do oszacowania, natomiast ocena nakładów pracy niezbędnych dla zrealizowania systemu jest bardzo trudna. Z tego względu szacowanie kosztów oprogramowania jest praktycznie tożsame z szacowaniem nakładów pracy. K. Bartecki, Inżynieria oprogramowania, III/21
Metody szacowania kosztów oprogramowania modele algorytmiczne np. model COCOMO oraz COCOMO II, ocena przez eksperta doświadczone osoby często z dużą precyzją potrafią oszacować koszt realizacji nowego systemu, ocena przez analogię wycena na podstawie wcześniej realizowanych przedsięwzięć, prawo Parkinsona przedsięwzięcia, w tym programistyczne, praktycznie zawsze wykonywane są przy założonych nakładach, wycena dla wygranej koszt oprogramowania szacowany jest na podstawie oceny możliwości klienta oraz przewidywanych działań konkurentów zgodnie z Prawem Parkinsona projekt i tak się zmieści w założonych ramach, szacowanie wstępujące realizację przedsięwzięcia dzieli się na mniejsze zadania, których koszt jest łatwiej ocenić. K. Bartecki, Inżynieria oprogramowania, III/22
Model COCOMO / COCOMO II Model COCOMO (ang. Cost Construction Model) jest algorytmicznym modelem szacowania kosztów oprogramowania, opartym o szacowaną liczbę instrukcji kodu, z których będzie składał się system. Powstał on w oparciu o informacje dotyczące wielu projektów informatycznych o różnej złożoności, napisanych w różnych językach programowania. Obecnie rozwijany jest model COCOMO II, zorientowany na nowoczesne modele wytwarzania oprogramowania, oparty o zaktualizowaną bazę danych projektów informatycznych. K. Bartecki, Inżynieria oprogramowania, III/23
Uwaga I Krytycy modelu COCOMO zwracają uwagę, że w celu dokonania prognozy nakładu pracy trzeba przewidzieć wielkość systemu, liczoną w liniach kodu czyli aby rozwiązać jeden trudny problem prognostyczny, zastępujemy go innym, równie trudnym. Uwaga II Nigdy nie jesteśmy w stanie podać dokładnej prognozy. Literatura mówi o widełkach różnej szerokości w zależności od etapu projektu: na etapie wstępnych wymagań możemy się pomylić 4 razy (koszt może wyjść 4 razy większy, jak również 4 razy mniejszy), na etapie dokładnej specyfikacji wymagań statystycznie można się pomylić 1,5 raza, dopiero tuż przed końcem projektu jesteśmy w stanie powiedzieć, ile projekt naprawdę kosztował (lecz wtedy taki szacunek nie jest nikomu potrzebny:) K. Bartecki, Inżynieria oprogramowania, III/24
Wyrażenia pozwalające wyznaczyć nakład pracy zgodnie z modelem COCOMO mają następującą postać: E D P a KDSI c E d E / D b gdzie: KDSI (ang. Thousands of Delivered Source Instruction) liczba tysięcy instrukcji kodu źródłowego, E nakład pracy (w osobomiesiącach), D czas potrzebny do wykonania projektu (w miesiącach), P liczba osób, przy której projekt będzie najefektywniej zrealizowany, a, b, c, d współczynniki zależne od rodzaju (złożoności) projektu. K. Bartecki, Inżynieria oprogramowania, III/25
Typy projektów w modelu COCOMO łatwy (ang. "organic") mały zespół posługuje się znanymi narzędziami pracy. Zna on sprzęt i oprogramowanie, przy użyciu których będzie tworzony projekt. Presja czasu jest mała. Łatwe projekty są wielkości do 50 KDSI. pośredni (ang. "semi-detached"), to projekt, w którym jeden z czynników z projektu prostego nie jest znany, np. zespół nie zna sprzętu, który przyjdzie mu programować, itp. Takie projekty są zwykle wielkości do 300 KDSI. trudny (ang. "embedded"), to bardzo złożony projekt, wiele czynników jest nieznanych lub należy uwzględnić szczególne procedury, np. w branży bankowej. K. Bartecki, Inżynieria oprogramowania, III/26
Wartości stałych modelu COCOMO dla różnych typów projektów projekt a b c d łatwy 2.4 1.05 2.5 0.38 pośredni 3.0 1.12 2.5 0.35 trudny 3.6 1.2 2.5 0.32 Na przykład dla projektu łatwego otrzymujemy: E 2.4 KDSI 0.38 D 2.5 E 1.05 K. Bartecki, Inżynieria oprogramowania, III/27
a) b) Oszacowania nakładu pracy (a) oraz czasu trwania projektu (b) w modelu COCOMO K. Bartecki, Inżynieria oprogramowania, III/28
Inne metody Metody szacowania rozmiaru systemu w oparciu o rozmiar linii kodu źródłowego są niedokładne, zawodne, sprzyjające patologiom, np. sztucznemu pomnażaniu ilości linii, ignorowaniu komentarzy, itp. Przykład: ten sam kod można zapisać na różne sposoby, np.: 1: if(i>10) 2: { 3: do_sth_1(); 4: } 1: if (i>10) { do_sth_1(); } 5: else 2: else { do_sth_2(); } 6: { 7: do_sth_2(); 8: } Dlatego obecnie stosuje się wiele miar o lepszych charakterystykach, np. metodę punktów funkcyjnych. K. Bartecki, Inżynieria oprogramowania, III/29
Metoda punktów funkcyjnych (ang. Function Point Method) Jej twórcą jest Alan Albrecht (1927 2010), który opracował ją w 1977 roku, kiedy był pracownikiem firmy IBM. Metoda punktów funkcyjnych pozwala mierzyć ilość funkcjonalności, którą dostaje użytkownik systemu, czyli umożliwia ocenę rozmiaru systemu z punktu widzenia użytkownika. Liczba punktów funkcyjnych jest zatem niezależna (w przeciwieństwie do metody COCOMO) od technologii implementacji (języka programowania). Istnieją przeliczniki punktów funkcyjnych na liczbę linii kodu dla różnych języków programowania, pozwalające w dalszej kolejności na oszacowanie nakładu pracy zgodnie z metodą COCOMO. K. Bartecki, Inżynieria oprogramowania, III/30
Metoda punktów funkcyjnych szczegóły Wyodrębnia się podstawowe funkcje, jakie są istotne dla użytkownika: - zewnętrzne wejścia (ang. External Inputs, EI), - zewnętrzne wyjścia (ang. External Outputs, EO), - zewnętrzne zapytania (ang. External Inquires, EQ), - wewnętrzne pliki danych (ang. Internal Logical Files, ILF), - zewnętrzne typy interfejsów plików (ang. External Interface Files, EIF). Te dane są następnie mnożone przez zadane z góry wagi i sumowane. Rezultatem jest liczba tzw. punktów funkcyjnych. K. Bartecki, Inżynieria oprogramowania, III/31
Metoda punktów funkcyjnych c.d. Liczba punktów funkcyjnych ocenia ilość funkcjonalności którą otrzymuje użytkownik systemu. Dzięki temu można stwierdzić, że pewien system ma 324 punkty funkcyjne, a inny np. 543. Istnieje kilka narzędzi programistycznych wspierających obliczanie punktów funkcyjnych, np.: - Function Point Workbench firmy Charismatek Software Metrics, - SPR KnowledgePLAN firmy Software Productivity Research. K. Bartecki, Inżynieria oprogramowania, III/32
Budowa harmonogramu przedsięwzięcia informatycznego Popularnym graficznym sposobem planowania i kontroli projektów (w tym również systemów informatycznych) jest tzw. diagram Gantta. Projekt dzielony jest na odrębne zadania. Dla każdego zadania oszacowuje się czas realizacji i określa termin jego wykonania, niezbędny do zakończenia w ustalonym czasie całego projektu. Informacja o zadaniu przedstawiana jest na wykresie Gantta w postaci klamry, której początek wyznacza datę rozpoczęcia, a koniec datę zakończenia każdego zadania. Układ zdarzeń na wykresie przedstawiany jest najczęściej w wersji planowanej przed rozpoczęciem działania oraz rzeczywistej, nanoszonej na wykres wraz z upływem czasu. K. Bartecki, Inżynieria oprogramowania, III/33
Przykładowy wstępny diagram Gantta dla przedsięwzięcia informatycznego K. Bartecki, Inżynieria oprogramowania, III/34
Diagram Gantta inny przykład K. Bartecki, Inżynieria oprogramowania, III/35
Przykładowa (darmowa) aplikacja do tworzenia diagramów Gantta: GanttProject: http://www.ganttproject.biz K. Bartecki, Inżynieria oprogramowania, III/36
Rezultaty fazy strategicznej Przeznaczony dla klienta raport obejmujący: definicję celów przedsięwzięcia, opis zakresu przedsięwzięcia, opis kontekstu (systemów zewnętrznych), ogólny opis wymagań, wstępny model systemu, opis proponowanego rozwiązania, oszacowanie kosztów, wstępny harmonogram prac. Raport oceny rozwiązań, zawierający informacje o rozważanych rozwiązaniach oraz przyczynach wyboru jednego z nich. Opis wymaganych zasobów pracownicy, oprogramowanie, sprzęt. Harmonogram fazy analizy. K. Bartecki, Inżynieria oprogramowania, III/37