Wymiarowanie projektu informatycznego

Transkrypt

1 Kiedy możesz zmierzyć coś o czym mówisz, i wyrazić to w liczbach, wtedy wiesz coś o tym, ale kiedy nie możesz tego zmierzyć, nie możesz wyrazić tego w liczbach, wtedy twoja wiedza jest skąpa i niesatysfakcjonująca. Lord Kelvin Wymiarowanie projektu informatycznego Zarządzanie projektem informatycznym, w4 walery.suslow@ie.tu.koszalin.pl

2 Pomiary oprogramowania W projektach informatycznych mierzone są: Procesy każde określone działanie w ramach projektu, dotyczące wytwarzania lub eksploatacji oprogramowania. Produkty każdy dokument powstały w wyniku procesu: specyfikację wymagań, specyfikację systemu, kod źródłowy, plan testów, raport z testowania. Zasoby wszystko, co jest niezbędne do realizacji procesu wytwórczego oprogramowania: zespół projektowy, narzędzia CASE, metody wytwarzania, infrastrukturę sieciową, sprzęt komputerowy.

3 Elementy pomiaru oprogramowania procesy Obiekty Atrybuty bezpośrednio mierzalne Wskaźniki syntetyczne Specyfikacja architektury Projekt szczegółowy Testowanie czas, nakład pracy, liczba zmian wymagań,... czas, nakład pracy, liczba znalezionych usterek specyfikacji,... czas, nakład pracy, liczba znalezionych błędów kodu,... jakość, koszt, stabilność,... koszt, opłacalność,... koszt, opłacalność, stabilność,...

4 Elementy pomiaru oprogramowania produkty Obiekty Atrybuty bezpośrednio mierzalne Wskaźniki syntetyczne Specyfikacje rozmiar, ponowne użycie, modularność, nadmiarowość, funkcjonalność, poprawność składniową,... Projekty rozmiar, ponowne użycie, modularność, spójność, funkcjonalność,... Kod rozmiar, ponowne użycie, modularność, spójność, złożoność, strukturalność,... Dane testowe rozmiar, poziom pokrycia,... zrozumiałość, pielęgnacyjność,... jakość, złożoność, pielęgnacyjność,... niezawodność, używalność, pielęgnacyjność,... jakość,...

5 Elementy pomiaru oprogramowania zasoby Obiekty Atrybuty bezpośrednio mierzalne Wskaźniki syntetyczne Personel wiek, cena,... wydajność, doświadczenie, inteligencja,... Zespoły wielkość, poziom komunikacji, wydajność, jakość, struktura,... cena, wielkość, używalność, niezawodność,... Oprogramo wanie Sprzęt cena, szybkość, wielkość pamięci niezawodność,... Biura wielkość, temperatura, oświetlenie,... wygoda, jakość,...

6 Wydajność Wydajność to ekonomiczna miara efektywności odnosząca wielkość produkcji do wielkości zasobów użytych do jej wytworzenia. Wydajność można oceniać na różnych poziomach analizy i w różnych formach. Formy wydajności określa następujący wzór: wydajność = produkcja / nakłady Ogółem wydajność czynników produkcji jest wskaźnikiem wykorzystania przez organizację wszystkich jej zasobów, takich jak: kapitał, praca, energia i materiały do wytwarzania jej produktów i usług. Czynniki produkcji obliczane są w jednostkach pieniężnych, ponieważ trudno dodawać w sensowny sposób godziny pracy do ilości surowców. Łączna wydajność czynników produkcji nie mówi zbyt wiele jakich zmian trzeba dokonać w celu poprawienia wydajności. Tak też, znaczna część organizacji uznaje, że bardziej przydatne jest obliczenie cząstkowego współczynnika wydajności, który uwzględnia jedną kategorię zasobów, np. wydajność pracy można obliczać na podstawie wzoru: wydajność pracy = produkcja / nakłady pracy bezpośredniej. Metoda ta ma zalety: 1. nie wymaga wyrażania jednostek nakładów w jakichkolwiek innych jednostkach 2. pozwala menedżerom zorientować się, jak zmiany różnych nakładów wpływają na wydajność. walery.suslow@ie.tu.koszalin.pl

7 Modele i miary wydajności ludzi Czynniki wpływające na ogólną wydajność Wartość Wydajność Koszt Jakość Ilość Personel Zasoby Złożoność Niezawodność Wielkość Czas Sprzęt Ograniczenia środowiskowe Defekty Funkcjonalność Pieniądze Oprogramowanie Trudność problemu Niebezpieczne jest zastępowanie wielu miar jedną miarą, np. długością wyprodukowanego kodu.

8 Ocena złożoności w planowaniu projektu CELE i OGRANICZENIA Rezultaty, czas, koszty, zasoby DEFINIOWANIE ZADAŃ Co? W jakiej kolejności? SZEREGOWANIE ZADAŃ Jak długo? OCENA CZASU REALIZACJI ZADAŃ Kto i czym? OCENA ZASOBÓW (LUDZIE, KOSZTY, SPRZĘT, MATERIAŁY...) OPRACOWANIE HARMONOGRAMU Za ile? Co i kiedy? SCALANIE PLANU

9 Efekt skali ZużycieZasobu = ZużycieStałe + K * WielkośćProjektu Zużycie zasobu 1 Systemy informatyczne 1 Przemysł/ budownictwo Wielkość projektu

10 Czynniki wpływające na efekt skali Czynniki spłaszczenia krzywej: Specjalizacja Uczenie się, doświadczenie Narzędzia CASE Wspomaganie dokumentowania Biblioteki gotowych elementów Stałe koszty projektu Czynniki wzrostu krzywej: Koszty zarządzania (czas produkcyjny/nie) Lawinowy wzrost ilości powiązań Komunikacja wewnątrz zespołu Wzrost złożoności testowania

11 Definicja Analiza Projektowanie Budowa Przejście Eksploatacja ZPI 2008 W.Suslow Etapy i koszty wytwarzania oprogramowania Empiryczne koszty poszczególnych faz wytwarzania oprogramowania systemów informatycznych 50% 45% 40% 35% 30% 25% 20% 15% 10% 5% 0% Źródło: Oracle Corp. Badaniom podlegały realizacje systemów przetwarzania danych, realizowane metodą CDM, prze użyciu narzędzi CASE firmy Oracle.

12 IBM LOC

13 Metoda linii kodu (IBM) Pracochłonność w osobomiesiącach: P =(N/170)*K K = 1 + a + b + c + d + e Liczebność zespołu: L=SQRT(P) Czas realizacji (w miesiącach): T=P/L N - liczba linii kodu; K - współczynnik korygujący; a = (0-0,5) niedoświadczenie zespołu; b = (0-0,7) zmienność wymagań; c = (0-0,3) ograniczenia sprzętowe; d = (0-0,2) kompletność wymagań; e = (0-0,4) czynniki zewnętrzne. Jak rozumieć linię kodu? Czy linią kodu są deklaracja oraz komentarz? Czy można porównywać systemy pisane w różnych językach? Punktem wyjścia jest znajomość liczby linii kodu, ją trzeba ustalić PRZED rozpoczęciem projektu techniką analogii lub techniką inżynierską.

14 Metoda szacowania kosztów COCOMO CONSTRUCTIVE COST MODEL

15 Wymiarowanie a klasyfikacja projektów Standardowe: znana technologia i dziedzina problemowa, doświadczony zespół, rutyna łatwość wymiarowania. Dobrze określone: znana technologia, wąska lub dobrze opisana dziedzina problemowa, wysoka adaptowalność zespołu. Nowatorskie: nowe technologie informatyczne, nieznajoma dziedzina problemowa, brak wzorców, brak doświadczeń lub nieprzydatne doświadczenia.

16 Klasyfikacja przedsięwzięć IT według COCOMO Łatwe (organic) wykonywane są przez małe zespoły specjalistów o wysokich kwalifikacjach, przy pomocy dobrze znanych metod i narzędzi, dziedzina projektu jest dobrze znana. Niełatwe (semi-detached) członkowie zespołu różnią się stopniem zaawansowania, pewne aspekty dziedziny problemu nie są dobrze znane. Trudne (embedded) obejmują przedsięwzięcia realizujące systemy o bardzo złożonych wymaganiach, dziedzina problemu, stosowane narzędzia i metody są w dużej mierze nieznane, większość członków zespołu nie ma doświadczenia w realizacji podobnych zadań.

17 Oszacowanie nakładu pracy na podstawie rozmiaru kodu źródłowego Metoda COCOMO wymaga estymacji liczby instrukcji, z których będzie składał się system. Kilo of Delivered Source code Instructions (KDSI) oznacza rozmiar kodu źródłowego mierzony w tysiącach linii. KDSI obejmuje tylko kod, który został wykorzystany w finalnej wersji systemu. Nakład[osobomiesiące] = A * KDSI b Przedsięwzięcia łatwe: b=1.05; Niełatwe: b=1.12; Trudne: b=1.20. walery.suslow@ie.tu.koszalin.pl

18 Oszacowanie czasu wytwarzania oprogramowania na podstawie nakładu pracy Metoda COCOMO zakłada, że znając nakład można oszacować czas realizacji przedsięwzięcia. Czas[miesiące] = 2.5 * Nakład k Przedsięwzięcia łatwe: k=0.32; Niełatwe: k=0.35; Trudne: k=0.38. Z oszacowanego czasu wynika przybliżona optymalna wielkość zespołu wykonawców: Zespół = Nakład / Czas. Zwiększenie liczby wykonawców nie skraca istotnie czasu realizacji projektu. walery.suslow@ie.tu.koszalin.pl

19 Korygowanie oszacowania z uwzględnieniem specyfiki przedsięwzięcia Czynniki modyfikujące biorą pod uwagę następujące atrybuty przedsięwzięcia: wymagania wobec niezawodności systemu; rozmiar bazy danych w stosunku do rozmiaru kodu; złożoność systemu (złożoność struktur danych, złożoność algorytmów, komunikację z innymi systemami, stosowanie obliczeń równoległych); wymagania co do wydajności systemu; ograniczenia pamięci; zmienność sprzętu i oprogramowania systemowego tworzącego środowisko pracy systemu.

20 Wady metody COCOMO Liczba linii kodu jest znana dokładnie dopiero wtedy, gdy system jest napisany. Szacunki są zwykle obarczone bardzo poważnym błędem (niekiedy ponad 100%). Określenie linii kodu źródłowego inaczej wygląda dla każdego języka programowania. Jedna linia w Smalltalk u jest równoważna 10- ciu linii w C. Dla języków 4GL i języków zapytań ten stosunek może być nawet 1000 : 1. Koncepcja oparta na liniach kodu źródłowego jest całkowicie nieadekwatna dla nowoczesnych środków programistycznych, np. opartych o programowanie wizyjne. Zły wybór czynników modyfikujących może prowadzić do znacznych rozbieżności pomiędzy oczekiwanym i rzeczywistym kosztem przedsięwzięcia.

21 ANALIZA PUNKTÓW FUNKCYJNYCH

22

23

24 Metoda analizy punktów funkcyjnych (FPA) Opracowana przez Albrechta w latach bada pewien zestaw wartości. Łączy ona własności metody, badającej rozmiar projektu programu z możliwościami metody badającej produkt programowy. Liczbę nie skorygowanych punktów funkcyjnych wylicza się na podstawie formuły korzystając z następujących danych: Wejścia użytkownika: obiekty wejściowe wpływających na dane w systemie Wyjścia użytkownika: obiekty wyjściowe związane z danymi w systemie Zbiory danych wewnętrzne: liczba wewnętrznych plików roboczych. Zbiory danych zewnętrzne: liczba plików zewnętrznych zapełnianych przez produkt programowy Zapytania zewnętrzne: interfejsy z otoczeniem programu

25 Wartości wag Lp Poziom złożoności (j) Element (i) Prosty Średni Złożony 1 Wejście Wyjście Zb.wewn Zb.zewn Zapytania Wartości wag mogą być dopasowywane do lokalnych możliwości i doświadczeń wykonawcy.

26 UFP - nieskorygowane punkty 5 UFP w n 3 i 1 j 1 ij ij UFP- nieskorygowane punkty funkcyjne gdzie: w ij - wagi, n ij - ilość elementów i = 1 i = 2 i = 3 i = 4 i = 5 Czynnik złożoności Wejścia użytkownika Wyjścia użytkownika Zbiory danych wewnętrzne Zbiory danych zewnętrzne Zapytania zewnętrzne Wagi przypisywane projektom: Projekt prosty Projekt średni Projekt złożony j = 1 j = 2 j = 3 6

27 Stopnie złożoności Nawet na początkowym etapie prac projektowych oszacowanie w/w elementów jest prostsze, pewniejsze i dokładniejsze, niż oszacowanie linii kodu. Dla każdej kategorii wprowadza się 3 stopnie złożoności: prosty, średni, złożony. Niestety, ocena złożoności z konieczności jest subiektywna.

28 Korekcja Punktów Funkcyjnych Występowanie urządzeń komunikacyjnych Rozproszenie przetwarzania Długość czasu oczekiwania na odpowiedź systemu Stopień obciążenia sprzętu istniejącego Częstotliwość wykonywania dużych transakcji Wprowadzanie danych w trybie bezpośrednim Wydajność użytkownika końcowego Aktualizacja danych w trybie bezpośrednim Złożoność przetwarzania danych Możliwość ponownego użycia programów w innych zastosowaniach Łatwość instalacji Łatwość obsługi systemu Rozproszenie terytorialne Łatwość wprowadzania zmian - pielęgnowania systemu

29 Skorygowane Punkty Funkcyjne Bez wpływu Bardzo silny wpływ Wpływ czynnika Punkty funkcyjne (FPs): Kompleksowy współczynnik korygujący: VAF 14 k 1 k k FP ( 0, 65 0, 01 VAF) UFP FP ( 0, , 35) UFP

30 Kolejność obliczeń Punktów Funkcyjnych a. Identyfikacja systemu b. Obliczenie współczynnika korygującego c. Wyznaczenie ilości zbiorów danych i ich złożoności d. Wyznaczenie ilości i złożoności elementów funkcjonalnych (we, wy, zapytania) e. Realizacja obliczeń f. Weryfikacja g. Raport, zebranie recenzujące

31 Przykład obliczania punktów funkcyjnych Elementy Proste Waga Średnie Waga Złożone Waga Razem Wejścia Wyjścia Zbiory wew Zbiory zew Zapytania Łącznie 383

32 Aplikacje a Punkty Funkcyjne 1 FP 125 instrukcji w C 10 FPs - typowy mały program tworzony samodzielnie przez klienta (1 m-c) 100 FPs - większość popularnych aplikacji; wartość typowa dla aplikacji tworzonych przez klienta samodzielnie (6 m-cy) 1,000 FPs - komercyjne aplikacje w MS Windows, małe aplikacje klient-serwer (10 osób, ponad 12 m-cy) 10,000 FPs - systemy (100 osób, ponad 18 m-cy) 100,000 FPs - MS Windows 95, MVS, systemy militarne

33 Punkty Funkcyjne a pracochłonność Pracochłonność, osobo-miesiące Punkty funkcyjne - FPs

34 Wykorzystanie punktów funkcyjnych Ocena złożoności realizacji systemów Audyt projektów Wybór systemów informatycznych funkcjonujących w przedsiębiorstwie do reinżynierii (wg. koszt utrzymania/fps) Szacowanie liczby testów Ocena jakości pracy i wydajności zespołów ludzkich Ocena stopnia zmian, wprowadzanych przez użytkownika na poszczególnych etapach budowy systemu informatycznego Prognozowanie kosztów pielęgnacji i rozwoju systemów Porównanie i ocena różnych ofert dostawców oprogramowania pod kątem merytorycznym i kosztowym

35 Linie kodu na punkt funkcyjny Język programowania LOC/FP Delphi 29 Informix 40 Progress 36 Sybase 40 C 125 PL/1 75 Ada 70 C++ 53 Java 53

36 Punkty Funkcyjne a języki baz danych Typ języka lub konkretny język Access ANSI SQL CLARION CA Clipper dbase III dbase IV DELPHI FOXPRO 2.5 INFORMIX MAGIC ORACLE Oracle Developer 2000 PROGRESS v.4 SYBASE Poziom języka wg. SPR Efektywność LOC/FP wg. Software Productivity Research

37 Punkty Funkcyjne a wydajność zespołu Poziom języka wg. SPR >55 Średnia produktywność FPs/osobomiesiąc wg. Software Productivity Research

38 Podsumowanie Metryki są tworzone i stosowane na bazie doświadczenia i zdrowego rozsądku. Metryki powinny być wykorzystywane jako metody wspomagania ekspertów. Najlepiej jest stosować zestawy metryk, co pozwala zmniejszyć błędy pomiarowe. Pomimo pochodzenia empirycznego, metryki skutecznie pomagają w szybkiej i mniej subiektywnej ocenie oprogramowania. Specjalizacja metryk w kierunku konkretnej klasy oprogramowania powinna dawać lepsze i bardziej adekwatne oceny niż metryki uniwersalne. Wskazane jest wspomaganie metod opartych na metrykach narzędziami programistycznymi.

39 Dodatek 1: Metoda Punktów Przypadków Użycia Use Case Points (UCP) Bazuje na diagramach Use Case Wymaga: Starannego modelowania aktorów Ostrożności w oznaczaniu powiązań między poszczególnymi przypadkami użycia Odpowiedniego poziomu szczegółowości modelu

40 Metoda Punktów Przypadków Użycia Klasyfikacja aktorów Aktor prosty - zewnętrzny wobec analizowanego, komunikujący się przez jeden z interfejsów programistycznych (Waga 1) Aktor średnio-złożony - system zewnętrzny, dostępny przez protokół z rodziny TCP/IP, HTTP lub podobny; również zbiory danych (Waga 2) Aktor złożony - zazwyczaj użytkownik końcowy, komunikujący się z systemem poprzez interfejs graficzny lub stronę WWW (Waga 3) Suma nieskorygowanych wag aktorów (UAW) Suma wszystkich aktorów, pomnożona przez współczynniki ich wag

41 Metoda Punktów Przypadków Użycia Klasyfikacja przypadków użycia Prosty przypadek użycia do trzech transakcji (Waga 5) Średnio-złożony przypadek użycia od czterech do siedmiu transakcji (Waga 10) Złożony przypadek użycia więcej niż siedem transakcji (Waga 15) Możliwa również poprzez zliczenie klas potrzebnych do obsługi przypadku Prosty przypadek użycia - nie więcej niż pięć klas (Waga 5) Średnio-złożony przypadek użycia - od pięciu do dziesięciu klas (Waga 10) Złożony przypadek użycia - powyżej dziesięciu klas (Waga 15) Suma nieskorygowanych wag przypadków użycia (UUCW) Suma wszystkich przypadków, pomnożona przez współczynniki ich wag

42 Metoda Punktów Przypadków Użycia Modyfikacja przez czynniki techniczne Technical Complexity Factor(TCF) = 0,6 + (0,01 * Wagowa suma powyższych)

43 Metoda Punktów Przypadków Użycia Modyfikacja przez czynniki środowiskowe Environmental Factor(EF) = 1,4 + (-0,33 * Wagowa suma powyższych)

44 Metoda Punktów Przypadków Użycia Ostatecznie poszukiwany rezultat UCP = UUCP * TCF * EF Przyjmuje się, że 1 UCP = 20 osobogodzin pracy programisty