plik


ÿþMetody szacowania kosztu przedsiwzi informatycznych MateriaB do wykBadu z przedmiotu In|ynieria Oprogramowania Opracowane gBównie na podstawie materiaBu zródBowego B.Boehma i wspóBautorów po przekBadzie T.Tarnawskiego pod kierunkiem G.Blizniuka Ostateczne przygotowanie dla studentów: G.Blizniuk Warszawa, grudzieD 2004r. 1 COCOMO 2, grudzieD 2004 Spis tre[ci 1. Wprowadzenie...........................................................................................................................................................5 2. Uwarunkowania oceny kosztu procesu wytwórczego oprogramowania ...................................................................6 3. PodziaB kosztu procesu wytwórczego na poszczególne etapy cyklu |ycia oprogramowania ....................................9 4. COCOMO 2 ............................................................................................................................................................14 4.1. Cele Cocomo2 ...............................................................................................................................................14 4.2. Modele Cocomo2...........................................................................................................................................14 4.3. Charakterystyka modeli Cocomo2.................................................................................................................15 4.4. Czynniki wpBywajce na koszt: Rozmiar.......................................................................................................18 4.4.1. Komponowanie Aplikacji: Punkty Obiektowe ..............................................................................................18 4.4.1.1. Procedura szacowania kosztu metod Punktów Obiektowych wykorzystana w Cocomo2 ......................19 4.4.2. Rozwój Aplikacji ...........................................................................................................................................21 4.4.2.1. ReguBy zliczania Linii Kodu .....................................................................................................................21 4.4.2.2. ReguBy naliczania Punktów Funkcyjnych .................................................................................................23 4.4.3. Ponowne U|ycie istniejcego kodu i Rein|ynieria........................................................................................25 4.4.3.1. Nieliniowe Koszty Ponownego U|ycia istniejcego kodu........................................................................25 4.4.3.2. Model Dostosowywania istniejcego kodu u|yty w Cocomo2.................................................................26 4.4.3.3. Szacowanie kosztów rein|ynierii i konwersji oprogramowania ...............................................................29 4.4.4. Wystpowanie Usterek ..................................................................................................................................30 4.4.5. Pielgnacja oprogramowania.........................................................................................................................30 4.5. Czynniki wpBywajce na koszt: Skala Programu ...........................................................................................30 4.5.1. Modelowania tzw. ekonomii lub anty-ekonomii skali w pracach informatycznych......................................30 4.5.2. Okre[lenie skali prac w Cocomo i Ada Cocomo ...........................................................................................31 4.5.3. Skalowanie prac w Cocomo2.........................................................................................................................32 4.6. Czynniki wpBywajce na koszt: Dodatkowe czynniki zwikszajce nakBad pracy ........................................33 4.6.1. Czynniki Produktu .........................................................................................................................................34 4.6.1.1. RELY  Wymagana Niezawodno[ Oprogramowania.............................................................................34 4.6.1.2. DATA  Wielko[ Bazy Danych..............................................................................................................35 4.6.1.3. CPLX  ZBo|ono[ (trudno[) Produktu...................................................................................................35 4.6.1.4. RUSE  Wymagane ponowne u|ycie tworzonego oprogramowania........................................................36 4.6.1.5. DOCU  przydatno[ wymaganej dokumentacji przy budowaniu oprogramowania................................36 4.6.1.6. Czynniki Platformy ...................................................................................................................................36 4.6.1.7. TIME  Ograniczenie Czasu DziaBania, STOR  Limit Dostpnej Pamici.............................................38 4.6.1.8. PVOL  Zmienno[ Platformy..................................................................................................................38 4.6.1.9. TURN  Czas Kompilacji (Computer Turnaround Time) ........................................................................38 4.6.2. Czynniki Kadrowe .........................................................................................................................................38 4.6.2.1. ACAP  Umiejtno[ci Analityków, PCAP  Umiejtno[ci Programistów...............................................38 4.6.2.2. AEXP  Do[wiadczenie z aplikacjami, PEXP  Do[wiadczenie z platformami, LTEX  Do[wiadczenie z jzykiem programowania i narzdziami .......................................................................................................................39 4.6.2.3. PCON  Stabilno[ personelu..................................................................................................................40 4.6.3. Czynniki Procesu Produkcji...........................................................................................................................40 4.6.3.1. MODP  Wykorzystanie nowoczesnych metod tworzenia oprogramowania ...........................................40 4.6.3.2. TOOL  Stosowanie narzdzi software owych.........................................................................................40 4.6.3.3. SITE  Rozproszenie tworzenia oprogramowania....................................................................................41 4.6.3.4. SCED  Wymaganie dotyczce harmonogramu prac ...............................................................................41 4.6.3.5. SECU  Oprogramowanie utajnione.........................................................................................................41 4.7. Dodatkowe mo|liwo[ci metody Cocomo2 ....................................................................................................41 4.7.1. Szacunki Punktów Funkcyjnych w modelach Projektu Wstpnego i Póznych Faz Projektowych................41 Czynniki w modelu.......................................................................................................................................................42 Projektu Wstpnego......................................................................................................................................................42 4.7.2. Szacunki harmonogramu prac........................................................................................................................43 4.7.3. PrzedziaBy wyników obliczeD ........................................................................................................................43 5. Podsumowanie ........................................................................................................................................................44 6. Wyja[nienie skrótów u|ytych w tek[cie..................................................................................................................45 2 COCOMO 2, grudzieD 2004 Spis tabel Tabela 1. Procentowy udziaB kosztu w poszczególnych procesach i fazach cyklu |ycia oprogramowania......................10 Tabela 2. Porównanie Cocomo, Ada Cocomo i Cocomo2................................................................................................17 Tabela 3. Typy Funkcji U|ytkowych w FPA....................................................................................................................24 Tabela 4. Warto[ci wskaznika ZrozumiaBo[ci Oprogramowania (SU) w zale|no[ci od jako[ci kodu..............................28 Tabela 5. Skala warto[ci WspóBczynnika AA...................................................................................................................29 Tabela 6. Warto[ci stopnia automatycznego przerabiania kodu .......................................................................................29 Tabela 7. Oceny skBadników wykBadnika skali projektu...................................................................................................33 Tabela 8. Skale szacowania czynników wzrostu kosztów w modelu Post-Architekturowym ..........................................34 Tabela 9. Wyznaczanie trudno[ci dla ró|nych typów moduBów.......................................................................................37 Tabela 10. Czynniki wzrostu kosztów w modelach Projektu Wstpnego i Póznych Faz Projektowych ..........................42 3 COCOMO 2, grudzieD 2004 Spis rysunków Rysunek 1. Przewidywana struktura rynku informatycznego USA w roku 2005...............................................................6 Rysunek 2. Typowe niedokBadno[ci szacowania kosztu przedsiwzicia informatycznego w poszczególnych fazach cyklu wytwórczego. ........................................................................................................................................9 Rysunek 3.UdziaB poszczególnych faz cyklu |ycia oprogramowania w koszcie przedsiwzicia informatycznego........12 Rysunek 4. PodziaB kosztów na procesy cyklu wytwórczego oprogramowania. ..............................................................12 Rysunek 5. UdziaB kosztów skBadowych procesu wytwórczego w poszczególnych fazach cyklu |ycia oprogramowania............................................................................................................................................13 Rysunek 6. Szkielet procedury zliczania punktów obiektowych ......................................................................................20 Rysunek 7. Lista-Definicja do Naliczania LOC ...............................................................................................................22 Rysunek 8. Procedura naliczania punktów funkcyjnych ..................................................................................................25 Rysunek 9. Nieliniowe koszty dostosowywania istniejcego oprogramowania ...............................................................27 Rysunek 10. Liczba testów interfejsów midzy-moduBowych jako funkcja ilo[ci zmian.................................................27 4 COCOMO 2, grudzieD 2004 1. Wprowadzenie Zakres materiaBu obejmuje zaproponowanie albo wskazanie efektywnej metody szacowania kosztu przedsiwzi informatycznych wraz z opisem uwarunkowaD omawianego zagadnienia. Po pierwsze nale|y zauwa|y, |e szacowanie kosztu przedsiwzi informatycznych jest zadaniem niezwykle trudnym i od wielu lat nie wypracowano jednak, ogólnie przyjtej metodzie, dziki której mo|naby jednoznacznie powiedzie, |e koszt wytworzenia jakiego[ konkretnego systemu informatycznego powinien wynosi X, a koszt wytworzenia innego systemu powinien wynosi Y. Zawsze pracuje si tutaj w warunkach wiedzy niepeBnej o potencjalnym koszcie ostatecznym i koszcie rzeczywistym wytworzenia systemu informatycznego. Nie oznacza to jednak, |e wspóBczesny dorobek in|ynierii oprogramowania nie pomaga w tej kwestii. Wa|ne jest jednak, aby mie na wzgldzie to, |e caBy czas poruszamy si tutaj w obszarze szacowania kosztu, a ka|dy szacunek jest jedynie pewnym przybli|eniem rzeczywistej warto[ci, która podlega szacowaniu. W czasie opracowywania tego materiaBu przeanalizowano wBasne do[wiadczenia, dotyczce wytwarzania systemów informatycznych. Z do[wiadczeD tych wynika, |e dominujcymi obecnie metodami szacowania kosztu przedsiwzi informatycznych s dwie metody:  metoda analizy punktów funkcyjnych pochodzca z firmy IBM (ang. Function Point Analisys  FPA), zaproponowana przez A.J.Albrecht a w roku 1979 i potem rozwijana1. Zasadnicz miar kosztu w tej metodzie jest  punkt funkcyjny . Zasadnicz wad tej metody jest jednak to, |e nie do koDca wiadomo, jaka jest miara kosztu punktu funkcyjnego.  metoda Cocomo2 zaproponowana przez SEI2 (ang. Software Engineering Institute) umo|liwiajca efektywne szacowanie kosztu produkcji i wdra|ania oprogramowania. WedBug opinii autora najlepsz obecnie metod jest Cocomo2. Wynika to z tego, |e jej wBa[ciwo[ci daj w naszej opinii wBa[ciwy aparat analityczny dla osób odpowiedzialnych za bud|et poszczególnych przedsiwzi informatycznych, a równocze[nie uwzgldnia ona wBasno[ci metody FPA, równie wa|nej dla oceny kosztu przedsiwzi informatycznych. 1 Metoda FPA jest opisywana na stronie: www.ifpug.org 2 W tej ekspertyzie zostanie wykorzystany materiaB zródBowy opisujcy wersj drug metody Constructive Cost Model, nazywanej w skrócie Cocomo2, przedstawiony przez autorów tej metody, którymi s: Barry Boehm, Bradford Clark, Ellis Horowitz, Chris Westland z USC Center for Software Engineering, Ray Madachy z USC Center for Software Engineering and Litton Data Systems i Richard Shelby zUC Irvine and Amadeus Software Research. 5 COCOMO 2, grudzieD 2004 2. Uwarunkowania oceny kosztu procesu wytwórczego oprogramowania Szacowanie kosztu procesu wytwórczego oprogramowania jest realizowane w warunkach wiedzy niepeBnej i niepewnej. WedBug twórców metody Cocomo2 bardzo istotny i cigBy spadek cen sprztu komputerowego i dominujca tendencja do informatycznego wspomagania zarzdzania przedsibiorstwami wymuszaj intensywne prace nad obni|eniem kosztów tworzenia systemów informatycznych. W takiej sytuacji du|ego znaczenia nabieraj metody analizy zysków i strat, na podstawie których bdzie mo|na dobra wBa[ciwy model cyklu wytwórczego oprogramowania3. Pojawia si te| potrzeba jednoczesnej kontroli jako[ci produktu i procesu produkcji oprogramowania i bie|cej analizy kosztów i jako[ci oprogramowania. Nowa generacja produktów i metod projektowych spowodowaBa istotne zmiany w procesie tworzenia oprogramowania. PrzykBadem mog by tutaj metody zarzdzania ryzykiem, czy wspóBzale|no[ciami w procesie wytwórczym, u|ycie jzyki czwartej generacji (4GL) i czy coraz bardziej powszechne wykorzystanie generatorów aplikacji. Wa|ne w tym miejscu s równie| kwestie ponownego u|ycia wcze[niejszych osigni innych przedsiwzi informatycznych. Kolejn istotn kwesti jest przewidywana struktura rynku informatycznego. Rysunek 1 jest ilustracj przewidywaD rynku informatycznego w najbli|szej przyszBo[ci, na których bazuje metoda Cocomo2. Najwikszy udziaB w prognozowanym rynku maj programi[ci koDcowi, których liczba jest szacowana na okoBo 55 mln programistów (w Stanach Zjednoczonych do roku 2005). Dolny sektor infrastruktury rynku przejmie prawdopodobnie do 0.75 mln osób. Sektor po[redni bdzie mo|na podzieli na trzy równolegBe cz[ci: opracowywanie generatorów aplikacji i narzdzi wspomagajcych tworzenie oprogramowania (ok. 0.6 mln osób), tworzenie systemów przez Bczenie aplikacji (0.7 mln osób) i integrowanie zBo|onych (w tym wbudowanych) systemów informatycznych do zadaD specjalistycznych (0.7 mln osób). Programi[ci i U|ytkownicy KoDcowi (55 mln w Stanach Zjednoczonych) Generatory Aplikacji i Wytwarzanie Aplikacji Wspomaganie Wytwarzania dla warstwy po[redniej Integratorzy Systemów Oprogramowania (0.7 mln) (0.7 mln) (0.6 mln) Infrastruktura informatyczna (0.75 mln) Rysunek 1. Przewidywana struktura rynku informatycznego USA w roku 2005. 3 Zagadnienia doboru cyklu modelu cyklu wytwórczego oprogramowania pozostaj poza zakresem opracowania. 6 COCOMO 2, grudzieD 2004 Bodzcem do szybkiego rozwoju sektora programistów i u|ytkowników koDcowych jest cigBe upowszechnianie wiedzy informatycznej w spoBeczeDstwie, a tak|e fakt, |e jedynie firmy stosujce najlepsze rozwizania informatyczne pozostan konkurencyjne na rynku. W takiej sytuacji coraz wiksza cz[ rynku informatycznego przypadnie na samych u|ytkowników, którzy wBasnorcznie bd tworzy wikszo[ potrzebnych im aplikacji np. przy pomocy generatorów aplikacji. PrzykBadem pomocnych tu generatorów aplikacji s arkusze kalkulacyjne, podrczne bazy danych oraz wyspecjalizowane narzdzia zarzdzania przedsibiorstwami. Przy pomocy stosownych opcji, parametrów i prostych reguB u|ytkownicy s w stanie wykorzysta generatory aplikacji do tworzenia narzdzi informatycznych o po|danych cechach. Praktycznie wszystkie firmy  od najbogatszych firm do sektora MZP4, a tak|e na przykBad instutycje rzdowe bd miaBy swój udziaB w tym sektorze rynku informatycznego. Typowymi przykBadami oprogramowania zaliczanego do infrastruktury informatycznej s systemy operacyjne, systemy baz danych, systemy zarzdzania interfejsem u|ytkownika, czy te| systemy sieciowe. Sektor infrastruktury bdzie coraz bardziej zaanga|owany w tworzenie rozwizaD dla architektury trójwarstwowej do zadaD takich jak przetwarzanie rozproszone i przetwarzanie transakcyjne. Najwikszymi firmami zajmujcymi si infrastruktur informatyczn s teraz midzy innymi: Microsoft, NeXT, Oracle, SyBase, Novell i najwiksze firmy rozprowadzajce sprzt komputerowy. Nale|y pamita o tym, |e programi[ci i u|ytkownicy koDcowi bd doskonale zorientowani w tworzeniu potrzebnego im specjalistycznego oprogramowania, nie bd natomiast mieli szczególnie dobrego pojcia o komputerach czy informatyce jako takiej. Z kolei producenci infrastruktury bd specjalistami z zakresu informatyki i in|ynierii komputerowej, nie bd za[ wiedzie zbyt wiele o programach czysto u|ytkowych. Tworzenie infrastruktury informatycznej bdzie wymagaBo od programistów nad|ania za nowymi technologiami komputerowymi (nowe procesory, pamici, technologie multimedialne i komunikacyjne) i std tylko cz[ moduBów oprogramowania bdzie mogBa by ponownie u|yta. PozostaBa cz[ bdzie musiaBa by stworzona od zera. Sektor generatorów aplikacji bdzie zródBem gotowych pakietów umo|liwiajcych  programowanie koDcowe . Obecnie t cz[ rynku zajmuj firmy takie jak Microsoft, IBM - Lotus, Novell, Borland (ostatnio mniej widoczny na rynku), a tak|e producenci oprogramowania mened|erskiego (np. pakiety IBM-Rational), in|ynierskiego (np. pakiety IBM-Rational, Oracle), 4 MaBe i [rednie przedsibiorstwa 7 COCOMO 2, grudzieD 2004 przemysBowego (np. systemy klasy ERP), systemów klasy workflow (np. polski Rodan Systems, amerykaDski IBM-Lotus Domino) i systemów analizy finansowej (w Europie wiodcy jest niemiecki SAP). W wielu przypadkach oprogramowanie to bdzie tworzone z gotowych (lub nieco zmodyfikowanych) podzespoBów, niemniej zawsze bdzie te| istniaBa konieczno[ budowy pakietów od podstaw. Wspomaganie wytwarzania oprogramowania bdzie rozbudowywane zarówno przez wy|ej wymienione firmy, jak równie| przez inwestycje rozwojowe w sektorze narzdzi wspomagajcych wytwarzanie oprogramowania dla warstwy po[redniej. Sektor ten skupi si na zadaniach na tyle ró|norodnych i specjalistycznych, |e nie sposób bdzie produkowa ich w postaci wielkonakBadowych, gotowych pakietów. Z drugiej za[ strony programy te bd na tyle proste, |e bdzie mo|na bByskawicznie stworzy je z kilku gotowych ju| podzespoBów. Takimi gotowymi komponentami bd zwykle: generatory Graficznego Interfejsu U|ytkownika (GUI) wraz z doskonaBymi generatorami firmy Microsoft czy te| firmy Borland, menad|ery obiektów i baz danych,  middleware do przetwarzania rozproszonego i przetwarzania transakcyjnego, oprogramowanie multimedialne, hurtownie danych oraz oprogramowanie specjalizowane, np.: medyczne, finansowe, kontroli produkcji itp. Integrowanie systemów bdzie zwizane z wielkimi, najcz[ciej wbudowanymi systemami. Po cz[ci programy te bd mogBy powstawa przy wykorzystaniu metod wytwarzania oprogramowania dla warstwy po[redniej, niemniej ich specyfika spowoduje, |e znaczca ilo[ prac przypadnie na projektowanie caBkowicie nowych systemów i tworzenie oprogramowania dostosowanego do indywidualnych potrzeb. PrzykBadami firm obracajcych si w tym sektorze s producenci sprztu lotniczego (np. oprogramowanie sterowania samoloty F22 ma ponad miliard linii kodu), samochodowego, elektronicznego, firmy telekomunikacyjne i finansowe, a tak|e przedsibiorstwa budujce wielkoskalowe systemy informacyjne i kontroli produkcji. Mened|erowie planujcy koszt przedsiwzi informatycznych oprócz znajomo[ci zasad gry rynkowej i prognozy rozwoju tego rynku pracuj w kolejnych, niezwykle restryktywnych uwarunkowaniach. Przede wszystkim pracuj oni w warunkach cigBego stresu wynikajcego z zachodzenia zmian w projektach informatycznych. Na potwierdzenie powy|szej tezy mo|na przytoczy wyniki badania amerykaDskiego rynku informatycznego, w których skoncentrowano si na szacunkach kosztów przedsiwzi informatycznych (patrz: Rysunek 2). Z do[wiadczeD tych wynika jednoznacznie, |e dopiero na etapie eksploatacji systemu informatycznego jeste[my w stanie prawie idealnie oszacowa koszt przedsiwzicia informatycnego. Na etapie definicji systemu mo|emy popeBni nawet 400%-towy 8 COCOMO 2, grudzieD 2004 bBd przeszacowania lub niedoszacowania kosztu. Z tego te| powodu nale|y da mo|liwo[ osobom prowadzcym czynno[ci zwizane z zarzdzaniem bud|etem weryfikacji swoich prognoz, je|eli chodzi o koszt konkretnego przedsiwzicia informatycznego. Pozycja wyj[ciowa do szacowania kosztu przedsiwzi informatycznych jest czsto jeszcze bardziej niekorzystna. Wynika to z faktu, |e bardzo czsto istnieje konieczno[ oszacowania kosztu przedsiwzi informatycznych jeszcze przez faz definicji wymagaD, co wynika z cyklu planowania bud|etu paDstwa. Taka procedura mo|e wprowadza bBd szacowania jeszcze wikszy ni| prognozowane 400%. 4-krotne przeszacowanie 2-krotne przeszacowanie Koszt rzeczywisty 2-krotne niedoszacowanie 4-krotne niedoszacowanie Faza Faza Analizy Faza Definicji Implementacji Faza Faza eksploatacji Projektowania Rysunek 2. Typowe niedokBadno[ci szacowania kosztu przedsiwzicia informatycznego w poszczególnych fazach cyklu wytwórczego. 3. PodziaB kosztu procesu wytwórczego na poszczególne etapy cyklu |ycia oprogramowania 9 COCOMO 2, grudzieD 2004 PodziaB kosztu procesu wytwórczego na poszczególne etapy cyklu |ycia oprogramowania zostanie przedstawiony na podstawie wyników badaD przeprowadzonych przez firm Oracle Corporation. Badania te dotyczyBy okoBo 5 tysicy projektów informatycznych o ró|nej skali i wydaje si, |e s one wiarygodne i adekwatne równie| dla polskiego rynku informatycznego. Tabela 1 stanowi syntez przeprowadzonych i cytowanych w tym miejscu wyników bada firmy Oracle Corp. Proces wytwórczy zostaB tutaj podzielony na 6 zasadniczych faz cyklu |ycia oprogramowania, tj. na: 1. definicj systemu, 2. analiz systemu, 3. projekt systemu, 4. budow (implementacj) systemu, 5. wdra|anie systemu, 6. eksploatacj systemu. W ramach poszczególnych faz cyklu |ycia oprogramowania w ró|nym stopniu realizowane s poszczególne procesy cyklu wytwórczego oprogramowania. Procesami tymi s: 1. definicja wymagaD na system, 2. analiza istniejcych systemów, 3. opracowanie architektury technicznej systemu, 4. projekt i budowa bazy danych, 5. projekt i budowa moduBów systemu, 6. konwersja danych, 7. utworzenie dokumentacji systemu, 8. testowanie systemu, 9. szkolenie u|ytkowników, 10. wdro|enie systemu, 11. asysta po wdro|eniu, 12. zarzdzanie projektem. Tabela 1. Procentowy udziaB kosztu w poszczególnych procesach i fazach cyklu |ycia oprogramowania 10 COCOMO 2, grudzieD 2004 PROCES NAZWA PROCESU % A B C D E F Definicja WymagaD 8,5 % 3,9 % 4,6 % Analiza Istniejcych 2,6 % 1,0 % 1,6 % Systemów Architektura Techniczna 2,1 % 0,3 % 1,5 % 0,3 % Projekt i Budowa Bazy 1,3 % 0,9 % 0,4 % Danych Projekt i Budowa ModuBów 37,3 % 17,5 % 19,8 % Konwersja Danych 7,3 % 0,4 % 1,2 % 1,8 % 3,2 % 0,7 % Dokumentacja 4,2 % 0,1 % 0,1 % 2,2 % 1,8 % Testowanie 16,3 % 0,1 % 1,8 % 13,6 % 0,8 % Szkolenie 1,9 % 0,3 % 0,4 % 0,6 % 0,6 % Wdro|enie 0,9 % 0,1 % 0,1 % 0,2 % 0,5 % Asysta po Wdro|eniu 3,4 % 3,4 % Zarzdzanie Projektem 14,2 % 0,8 % 1,7 % 4,1 % 6,6 % 0,4 % 0,6 % UDZIAA % FAZ 100 % 6,6 % 11,1 % 29,1 % 46,2 % 3 % 4 % DokBadny podziaB procentowy poszczególnych skBadników kosztów zostaB przedstawiony w tabeli wy|ej. Ilustracj procentu udziaBu poszczególnych faz cyklu |ycia oprogramowania przedstawia Rysunek 3, a podziaB kosztu cyklu wytwórczego - Rysunek 4. 11 COCOMO 2, grudzieD 2004 ANALIZA BUDOWA DEFINICJA WDRA { ANIE Udzia B % Procesu EKSPLOATACJA PROJEKTOWANIE Koszt poszczególnych faz cyklu |ycia oprogramowania 50 46,2 45 40 35 29,1 30 25 20 15 11,1 10 6,6 4 3 5 0 nazwa fazy Rysunek 3.UdziaB poszczególnych faz cyklu |ycia oprogramowania w koszcie przedsiwzicia informatycznego PodziaB kosztów w cyklu wytwórczym oprogramowania 40 37,3 35 30 25 20 16,3 14,2 15 8,5 10 7,3 4,2 5 3,4 2,6 2,1 1,9 1,3 0,9 0 Nazwa procesu Rysunek 4. PodziaB kosztów na procesy cyklu wytwórczego oprogramowania. W podsumowaniu analizy udziaBu kosztów, przedstawiono Rysunek 5, na którym przedstawiono zale|no[ci kosztowe pomidzy procesem wytwórczym i cykle |ycia oprogramowania. 12 COCOMO 2, grudzieD 2004 udz % i a B u % udzia B u e a e a a j i j ni za w c i i ac l an n a wa | i do at f o n a t o r e l a bu d ek sp wd oj k r e p a u D w e e e m ch ja i n ch ów ó ni B c ni n z te e u a c e eni ta aga i l | em any d | ek any t n w n o m o D s ro e ko h D r oj y to y r d z c y d s m a e P j S e a M u W s az W k h S T e a W o c er a T B ow ni cj i Do a d a cy ur n a p t i u z  f j d onw st e B ek  y ie dow K t D t i n u rz t k As s a chi B e r i Z t A oj a I r k z P e j o nali A Pr UdziaB procesów cyklu wytw órczego w fazach cyklu |ycia oprogramow ania 100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% fazy cyklu |ycia Definicja WymagaD Analiza Istniejcych Systemów Architektura Techniczna Projekt i Budowa Bazy Danych Projekt i Budowa ModuBów Konwersja Danych Dokumentacja Testowanie Szkolenie Wdro|enie Asysta po Wdro|eniu Zarzdzanie Projektem Rysunek 5. UdziaB kosztów skBadowych procesu wytwórczego w poszczególnych fazach cyklu |ycia oprogramowania 13 COCOMO 2, grudzieD 2004 sk B adowe procesu wytwórczego a a e j ja a ie z i w ic ac ani n o al an i | f at w a e o an l to d bud p dr k e w ks oj e pr 4. COCOMO 2 Metoda COCOMO 2 zostaBa opracowana po to, aby umo|liwi odpowiednie planowanie harmonogramu prac, organizowanie zespoBów ludzkich, szacowanie czasu zakoDczenia projektu, przygotowywanie i przeplanowywanie prac, [ledzenie postpów prac, negocjowania kontraktów, oceny ofert przetargowych, decyzji o zgodzie na warunki kontraktu. 4.1. Cele Cocomo2 Cele metody Cocomo2 s nastpujce: " zapewnienie Batwo[ci zrozumienia metody, " dostosowanie mo|liwo[ci metody do przewidywanej struktury rynku informatycznego, " dostosowanie warto[ci wej[ciowych i wyj[ciowych podmodeli Cocomo2 do przewidywanej rozlegBo[ci i ró|norodno[ci informacji o przedsiwziciu informatycznym, " umo|liwienie uniwersalnego wykorzystania podmodeli Cocomo2 przy ró|nych strategiach projektowo-wdro|eniowych. W Cocomo2 wszystkie algorytmy s w peBni dostpne publicznie. Podobnie wszystkie interfejsy s zaprojektowane tak, aby byBy powszechnie zrozumiaBe, dokBadnie zdefiniowane i sparametryzowane, dziki czemu umo|liwiaj one Batw implementacj pre-szacunków (modele szacowania wielko[ci projektów) i post-szcunków (narzdzia planowania i kontroli procesu produkcji, analizy poziomów ryzyka) wynikajcych z kolejnych algorytmów metody Cocomo2. 4.2. Modele Cocomo2 Model Cocomo2 opisujcy sektor wytwarzania aplikacji dla warstwy po[redniej bazuje na metodzie Analizy Punktów Obiektowych. Punkty Obiektowe s zliczane na podstawie liczby moduBów napisanych w jzykach trzeciej generacji oraz ilo[ci ekranów i raportów stworzonych na potrzeby danej aplikacji. Ka|dy z nicj jest wa|ony wspóBczynnikiem poziomu trudno[ci (Batwy, [redni, trudny) [Banker 1994, Kauffman i Kumar 1993]. Takie podej[cie dobrze odzwierciedla ilo[ informacji na temat komponowanej aplikacji dostpnej zwykle na wstpnym etapie prac. Zapewnia ono dokBadno[ wystarczajc do adekwatnego oszacowania kosztów (projekty w tym 14 COCOMO 2, grudzieD 2004 sektorze tworzone s zwykle przez kilkuosobowe grupy programistów w czasie kilku tygodni, miesicy). Szacowanie zBo|ono[ci generatorów aplikacji, integracji systemów i kosztu infrastruktury opiera si w metodzie Cocomo2 na uniwersalnym poBczeniu modelu dla komponowania aplikacji i dwóch modeli szacunkowych o wzrastajcej dokBadno[ci  opracowanych dla kolejnych etapów cyklu |ycia oprogramowania. 4.3. Charakterystyka modeli Cocomo2 Uzasadnienie dla uniwersalnego zestawu modeli Cocomo2 bazuje si na trzech wymienionych ni|ej przesBankach: Pierwsza: Inaczej ni| w póznych latach siedemdziesitych, kiedy powszechnie preferowano tylko jeden model cyklu |ycia oprogramowania (tzw. model kaskadowy), obecnie stosuje si ró|ne modele procesów produkcyjnych, dostosowane do konkretnych sytuacji. O wyborze wBa[ciwej metody decyduj teraz: mo|liwo[ wykorzystania COTS (gotowych pakietów), u|ycie/dostosowanie istniejcego kodu, poziom znajomo[ci wymagaD i architektury projektowanego systemu, ograniczenia dla harmonogramu prac, wielko[ programu, wymagana niezawodno[. Druga: Mo|liwy bBd oszacowania kosztów (patrz: Rysunek 2) w danej metodzie musi by zgodny z poziomem szczegóBowo[ci informacji dostpnych na ka|dym etapie produkcji. We wczesnych stadiach programu mamy najcz[ciej niewiele wiadomo[ci o wielko[ci programu, docelowej platformie, ilo[ci i jako[ci personelu zaanga|owanego w tworzenie oprogramowania, czy o szczegóBach stosowanego procesu tworzenia oprogramowania. Trzecia: Z powy|szego wynika, |e Cocomo2 umo|liwia wykorzystanie zgrubnych informacji we wczesnych fazach projektowych, a jednocze[nie pozwala na doszlifowanie szacunków wraz z napBywem dokBadniejszych danych z postpujcych prac. Cocomo2 nie daje wic punktowych szacunków kosztów i rozmiarów oprogramowania, a raczej przedziaBy mo|liwych warto[ci  wBa[ciwie dla ilo[ci dostpnych danych. Za podstaw do wyznaczania tych 15 COCOMO 2, grudzieD 2004 przedziaBów szacunkowych przyjto przedziaBy niepewno[ci i niepeBno[ci wiedzy, który ilustracj stanowi Rysunek 2. W dalszych rozwa|aniach przypadki generatorów aplikacji, integracji systemów i infrastruktury informatycznej bd rozwa|ane przy pomocy zestawu trzech modeli procesów. WBa[ciwe poBczenie tych modeli bdzie zale|aBo od czynników rynkowych oraz od stopnia zrozumienia projektu. Poni|ej zamieszczono krótki opis tych trzech modeli. Model komponowania aplikacji umo|liwia opis kosztów prace prototypowych majcych na celu rozpoznanie zagadnieD o potencjalnie zwikszonym ryzyku, takich jak interfejs u|ytkownika, interakcja oprogramowanie-system, wydajno[, dojrzaBo[ technologii. Model wczesnych faz projektu dotyczy rozpoznawania ró|nych alternatyw architektury systemu informatycznego i wypracowywania koncepcji jego dziaBania. W takim stadium na ogóB niewiele jeszcze wiadomo i nie sposób przeprowadza dokBadne szacowania kosztów. Mo|liwo[ci Ccocomo2 w tym zakresie obejmuj zastosowanie punktów funkcyjnych i kilku dodatkowych metod opisu zródeB kosztów (cost drivers). Model póznych faz projektu obejmuje wBa[ciwe prace nad budow i pielgnowaniem oprogramowania. Model ten jest adekwatny do sytuacji, w których architektura systemu jest ju| zaprojektowana i zatwierdzona jako podstawa do dalszych prac produkcyjnych. Ten model w metodzie Cocomo2 obejmuje metryki linii kodu i/lub punkty funkcyjne z uwzgldnieniem wykorzystania kodu ju| istniejcego. Zdefiniowano tutaj zestaw 17-stu wspóBczynników zródeB kosztów oraz 5-ciu czynników wyznaczajcych wykBadnik skali projektu. Podsumowujc, metoda Cocomo2 zawiera nastpujce 3 szczeble umo|liwiajce szacowanie zBo|ono[ci systemów w sektorach generatorów aplikacji, integracji systemów i infrastruktury informatycznej: 1. Pocztkowe stadia spiralnego cyklu tworzenia oprogramowania generalnie nie obejd si bez tworzenia prototypów w wykorzystaniem narzdzi Komponowania Aplikacji. Prace takie, a tak|e dalsze prototypowanie w pózniejszych fazach produkcji s uwzgldnione w Cocomo2 w modelu komponowania aplikacji. 2. W nastpnych stadiach rozwa|ane s zwykle ró|ne alternatywy architektury systemu, a tak|e strategie etapowej budowy produktu. Cocomo2 wspiera te stadia modelem wczesnego szacowania, który stosuje punkty funkcyjne do oceny kosztu projektu i 5-ciu zgrubnych wyznaczników zródeB kosztów (np. 2 wspóBczynniki 16 COCOMO 2, grudzieD 2004 opisujce wykwalifikowanie personelu, jego umiejtno[ci, do[wiadczenie itp.). Jak wspomniano wcze[niej, dokBadno[ szacunków jest tu zale|na od ilo[ci informacji dostpnej na tym etapie. 3. Gdy zakoDcz si prace czysto projektowe, przyszBy produkt ma ju| stabilnie nakre[lon architektur. Dostpne s wtedy znacznie bogatsze dane na temat przyszBych zródeB kosztów i mo|na znacznie dokBadniej szacowa wymogi czasowe, robocze czy finansowe. Ten etap rozwoju jest opisany w C2 przy pomocy modelu punktów funkcyjnych lub zródBowych LOC i 17-tu wspóBczynników zródeB kosztów. Metoda Cocomo2 stanowi kolejn wersj pierwotnej metody Cocomo z lat 70-tych i jej nastpczyni zwanej Ada Cocomo. Tabela 2 stanowi syntetyczne porównanie tych metod5. Tabela 2. Porównanie Cocomo, Ada Cocomo i Cocomo2 Cocomo Ada Cocomo Cocomo2: Cocomo2: Cocomo2: Etap 1 Etap 2 Etap 3 Rozmiar (R) (Dostarczone) DSI lub SLOC Punkty Obiektowe Punkty Funkcyjne FP i Jzyk Instrukcje (FP) i Jzyk Programowania yródBowe (DSI) Programowania lub SLOC lub yródBowe LOC (SLOC) U|ycie kodu Równowa|ne Równowa|ne domy[lne w tym istniejcego SLOC = liniowa SLOC = liniowa modelu funkcja funkcja f(DM,CM,IM) f(DM,CM,IM) BBdne warto[ RVOL warto[ RVOL domy[lne w tym %bBdnych zatrzy- BRAK zatrzymania modelu maD: BRAK Pielgnacja Roczny Poziom ACT Model Ponownego Model Ponownego Model Ponownego Zmian (ACT) = U|ycia Punktów U|ycia U|ycia %dodany + Obiektowych %zmieniony Skalowanie Organiczne: 1.05 Wbudowany: 1.04 1.0 1.01  1.26 (warto[ b) w WpóBodcity: 1.12  1.24 zale|nie od: zale|nie od: MMNOM = a(R)b Wbudowany: 1.20 " poziomu " oryginalno[ci wczesnej " wygody eliminacji ryzyka u|ytkowania " solidno[ci " stabilno[ci architektury wymagaD " stabilno[ci " zgrania zaspoBu wymagaD " dojrzaBo[ci " dojrzaBo[ci procesu procesu produkcji (SEI) produkcji yródBa kosztów RELY, DATA, RELY*, DATA*, brak RCPX*+, RELY, DATA, wynikajce z cech CPLX CPLX*, RUSE RUSE*+ DOCU*+, 5 W tabeli tej u|yto wielu skrótów sklasyfikowanych w wykazie skrótów zamieszczonych w zakoDczeniu ekspertyzy. 17 COCOMO 2, grudzieD 2004 Cocomo Ada Cocomo Cocomo2: Cocomo2: Cocomo2: Etap 1 Etap 2 Etap 3 produktu CPLX+, RUSE*+ yródBa kosztów TIME, STOR, TIME, STOR, brak ZBo|ono[ TIME, STOR, wynikajce z cech VIRT, TURN VMVH, VMVT, platformy: PVOL (=VIRT) platformy TURN PDIF*+ yródBa kosztów ACAP, AEXP, ACAP*, AEXP, brak kwalifikacje ACAP*, AEXP+, wynikajce z cech PCAP, VEXP, PCAP*, VEXP, personelu i PCAP*, PEXP*+, personelu LEXP LEXP* do[wiadczenie: LTEX*+, PERS*+, PREX*+ PCON*+ yródBa kosztów MODP, TOOL, MODP*, TOOL*, brak SCED, FCIL*+ TOOL*+, SCED, wynikajce z SCED SECD, SECU SITE*+ praktyk produkcyjnych * odmienny mno|nik + odmienna skala ocen 4.4. Czynniki wpBywajce na koszt: Rozmiar W tej cz[ci przedstawione bd definicje i uzasadnienia dla trzech wielko[ci w Cocomo2 u|ytych do opisu rozmiaru produktu: punktów obiektowych, nieznormalizowanych punktów funkcyjnych i zródBowych LOC. Nastpnie opisane bd parametry, które w szacunkach rozmiaru uwzgldniaj u|ycie gotowego kodu, przeprojektowywanie istniejcego systemu, dostosowywanie i pielgnacj oprogramowania. 4.4.1. Komponowanie Aplikacji: Punkty Obiektowe Punkty obiektowe s nowo[ci w[ród metryk wielko[ci oprogramowania, niemniej bardzo dobrze nadaj si do opisu sytuacji spotykanych w obszarze Komponowania Aplikacji. Oddaj one koszty prac prototypowych przy bByskawicznym komponowaniu aplikacji przy pomocy narzdzi typu ICASE (Integrated Computer Aided Software Environment), zawierajcych kreatory graficznego interfejsu u|ytkownika, narzdzia tworzenia oprogramowania i pokazne biblioteki gotowych komponentów aplikacji. W tych obszarach punkty obiektowe zostaBy wykorzystane na pokaznym, cho nadal mocno ograniczonym zbiorze aplikacji i okazaBy si metryk nie gorsz od punktów funkcyjnych. Opracowanie porównujce szacunki oparte na punktach funkcyjnych z analogicznymi opartymi na punktach obiektowych [Banker et al. 1994] przeanalizowaBo 19 ró|nych przykBadów oprogramowania inwestycyjno-bankowego, stworzonego przy u|yciu ICASE i o wymaganym nakBadzie pracy od 4.7 do 71.9 roboczo-miesicy. W wyniku badaD okazaBo si, |e wyniki metody 18 COCOMO 2, grudzieD 2004 punktów obiektowych mie[ciBy si w 73% za[ wyniki metody punktów funkcyjnych w 76% w takim samym przedziale ufno[ci przyjtym dla przeprowadzonych badaD. Nastpnie przeprowadzono eksperyment w sposób umo|liwiajcy przeprowadzenie analizy statystycznej [Kaufman i Kumar 1993], w którym czterech do[wiadczonych mened|erów projektu szacowaBo przy pomocy Punktów Funkcyjnych i Punktów Obiektowych koszt prac wymaganych do wykonania dwóch zakoDczonych ju| programów (stworzenie pierwszego zajBo 3.5 roboczo-miesicy, drugiego  6 r-mcy). W wyniku eksperymentu okazaBo si, |e wyniki szacunków Punktami Obiektowymi i Punktami Funkcyjnymi byBy tak samo dokBadne (P.O. uzyskaBy minimalnie wiksz dokBadno[, ale mniejsz ni| wyniósB margines bBdu eksperymentu). Z kolei czas potrzebny na opracowanie szacunków metod Punktów Obiektowych wyniósB okoBo 47% (ponad 2 razy mniej) czasu potrzebnego przy Punktach Funkcyjnych. Wszyscy uczestnicy eksperymentu uznali te|, |e metoda Punktów Obiektowych byBa prostsza w u|yciu. Powy|sze wyniki nie byBy jeszcze potwierdzone w szerszych badaniach, niemniej w zakresie Komponowania Aplikacji wydaj si by dostatecznie obiecujce, aby uzasadni wybór metryki Punktów Obiektowych jako podstawowego modelu szacunkowego Komponowania Aplikacji w metodzie Cocomo2. 4.4.1.1. Procedura szacowania kosztu metod Punktów Obiektowych wykorzystana w Cocomo2 Rysunek 6 przedstawia szkielet procedury szacowania kosztu prac metod Punktów Obiektowych, stosowan dla komponowania aplikacji i prac prototypowych. Jest to syntetyczny skrót metody opisanej w dodatku B3 w [Kaufman i Kumar 1993] i opisów produktywno[ci z grupy 19-stu metryk z [Banker et al. 1994]. Warto[ci produktywno[ci opracowano na podstawie danych z 2 kolejnych lat prac nad ró|nym oprogramowaniem [Banker et al. 1994]. Podczas pierwszego roku narzdzie CASE nie byBo jeszcze w peBni gotowe, a jego u|ytkownicy dopiero uczyli si zasad jego obsBugi. W takiej sytuacji [redni produktywno[ (wynoszc 7 NOP/roboczo-miesic) w 12 cyklach produkcyjnych podczas tego pierwszego roku uznano (na skali ocen  dojrzaBo[ i wydajno[ ICASE i pracowników) za nisk. Z kolei w pracach nad siedmioma innymi programami podczas kolejnego roku wydajno[ tak ICASE jak i personelu byBa zdecydowanie wy|sza. Osignity wtedy poziom 25 NOP/roboczo-miesic uznano (na w/w skali) za wysoki. 19 COCOMO 2, grudzieD 2004 Krok 1: Zliczenie obiektów: oszacowa liczb ekranów, raportów i komponentów w 3GL (ew. 4GL) wchodzcych w skBad aplikacji. ZaBo|y, |e w [rodowisku ICASE bd one zdefiniowane standardowo. Krok 2: Zakwalifikowa ka|dy z tych obiektów jako Batwy, [rednio trudny lub trudny, w zale|no[ci od wielko[ci opisujcych ten obiekt  zgodnie z poni|sz tabel: Dla ekranów Dla raportów ilo[ i zródBa tabel danych ilo[ i zródBa tabel danych Ilo[ Bcznie < 4 Bcznie < 8 Bcznie < 4 Ilo[ Bcznie < 4 Bcznie < 4 Bcznie < 4 Widoków (<2 srvr (2/3 srvr (>3 srvr cz[ci (<2 srvr (<2 srvr (<2 srvr <3 clnt) 3-5 clnt) >5 clnt) <3 clnt) <3 clnt) <3 clnt) <3 Batwy Batwy [redni 0 lub 1 Batwy Batwy [redni 3 do 7 Batwy [redni trudny 2 lub 3 Batwy [redni trudny 8 i wicej [redni trudny trydny 4 i wicej [redni trudny trydny Krok 3: Wyznaczy wag ka|dego obiektu przy pomocy prostego schematu podanego poni|ej. Owa waga opisuje wBa[ciwy nakBad pracy niezbdny do stworzenia takiego obiektu. Rodzaj Obiektu Waga obiektu Aatwy Zredni Trudny Ekran 1 2 3 Raport 2 5 8 Komponent w 3GL (4GL) 10 Krok 4: Wyznaczy ilo[ Punktów Obiektowych: doda wagi wszystkich obiektów w aplikacji. Krok 5: Oszacowa procentow ilo[ kodu ponownie u|ytego, (wspóBczynnik  reuse ). Wyznaczy Nowe Punkty Obiektowe, NOP = (Punkty Obiektowe) (100-%reuse)/100. Krok 6: Wyznaczy produktywno[ PROD (w NOP/roboczo-miesic) na podstawie tabeli: Do[wiadczenie i wydajno[ B. Niska Niska Przecitna Wysoka B. Wysoka programistów dojrzaBo[ i wydajno[ ICASE B. Niska Niska Przecitna Wysoka B. Wysoka PROD 4 7 13 25 50 Krok 7: Obliczy liczb roboczo-miesicy wg. wzoru: r-m = NOP / PROD. Rysunek 6. Szkielet procedury zliczania punktów obiektowych Znaczenie poj u|ytych w rysunku wy|ej: " NOP: Nowe Punkty Obiektowe (liczba P.O. uwzgldniajca zastosowanie gotowego kodu ponownie u|ytego) " srvr: ilo[ tabel danych serverów (mainframe lub równowa|ne) u|ytych w poBczeniu ze SCREEN i REPORT " clnt: ilo[ tabel danych  klientów ( osobiste stacje robocze {personal workstation}) u|ytych w poBczeniu ze SCREEN i REPORT 20 COCOMO 2, grudzieD 2004 " %reuse: procent gotowych ekranów, raportów lub moduBów napisanych w 3GL (4GL) uzyskanych z wcze[niej stworzonych aplikacji, z uwzgldnieniem  wprowadzania ewentualnych modyfikacji (degree of reuse). Odnotujmy tu jeszcze jedn uwag: u|ywane tu pojcia  obiekt i  punkty obiektowe rozumie si w ten sposób, |e obiektami s ekrany, raporty i moduBy w 3GL (4GL). Mo|e, ale nie musi mie to |adnego zwizku z takimi wBasno[ciami  obiektów (w jzykach programowania) jak dziedziczenie, enkapsulacja, przesyBanie komunikatów. Analiz takich obiektów, zdefiniowanych np. w programie napisanym w C++, zajmiemy si w cz[ci nastpnej przy  zródBowych LOC . 4.4.2. Rozwój Aplikacji Jak ju| wspomniano w metrykach projektu wstpnego i póznych faz projektu w metodzie Cocomo2 pomiar wielko[ci programu odbywa si przy pomocy Punktów Funkcyjnych i yródBowych LOC. Nieodzowne jest ujednolicenie reguB zliczania Punktów Funkcyjnych i yródBowych LOC, tak aby mo|liwe byBo porównywanie szacunków dokonywanych w caBej metodzie Cocomo2. Metoda Cocomo2 przejBa reguBy zliczania P.F. i y.LOC do[ powszechnie zaakceptowane w [rodowisku informatycznym. Metryki yródBowych LOC opracowano na podstawie listy-definicji Instytutu In|ynierii Oprogramowania (SEI) [Park 1992]. Metryki Punktów Funkcyjnych zaczerpnito za[ z wytycznych Midzynarodowej Grupy U|ytkowników Punktów Funkcyjnych [IFPUG 1994] [Behrens 1983] [Kunkler 1985]. 4.4.2.1.ReguBy zliczania Linii Kodu W Cocomo2 za standardow lini kodu uwa|a si okre[lone wyra|enie logiczne. Ró|nice w strukturze poleceD i deklaracji w ró|nych jzykach utrudniaj jednoznaczn definicj Linii Kodu (LOC). U|ycie miary LOC ma na celu ocen ilo[ci pracy intelektualnej, potrzebnej do stworzenia danego programu. Trudno jest jednak ustali tak definicj Linii Kodu aby byBa ona jednolita dla wielu ró|nych jzyków programowania. Na przeciw tym trudno[ciom wychodzi opracowana przez SEI lista kryteriów dla zródBowych operacji logicznych  definiujcych LOC. Wicej o owej li[cie, a tak|e o podobnych opracowaniach SEI mo|na znalez w [Park 1992, Goethert et al. 1992]. 21 COCOMO 2, grudzieD 2004 Jednostka miary: Linie Kodu Wyra|enia Logiczne Rodzaj wyra|enia Definicja Tabela Danych WBczy WyBczy ½ Je[li linia kodu lub wyra|enie zawiera wicej ni| jeden typ wyra|enia  klasyfikuj jako ten o najwy|szym priorytecie 1 1. Uruchamialne kolejno[ priorytetowa ’! ½ 2. Nieuruchamialne 2 ½ 3. Deklaracje 3 4. Dyrektywy kompilatora ½ 5. Komentarze 4 ½ 6. Samodzielne w wierszu 5 7. W jednej linii z kodem ½ 6 8. Transparenty i rozdzielacze (banners and spacers) ½ 7 9. Puste komentarze ½ 10. Puste linie 8 ½ 11. Sposób realizacji Definicja Tabela Danych WBczy WyBczy ½ 1. Zaimplementowana rcznie ½ 2. Stworzona przez generator kodu ½ 3. PrzetBumaczona przy pomocy zautomatyzowanego narzdzia ½ 4. Skopiowana i u|yta ponownie bez zmian ½ 5. Zmodyfikowana ½ 6. Usunita ½ 7. yródBo Definicja Tabela Danych WBczy WyBczy ½ 1. Nowy projekt ½ 2. Prowadzono ju| wcze[niejsze prace: projekt bazuje na 3. Poprzedniej wersji ½ 4. Gotowych, nabytych pakietach (z wyjtkiem bibliotek) ½ 5. Oprogramowaniu na zamówienia (z wyjtkiem bibliotek) ½ 6. Innym, wcze[niej wykonanym programie ½ 7. Bibliotece dostarczonej z jzykiem programowania (bez modyfikacji) ½ 8. Elementach nabytego systemu operacyjnego lub programu u|ytkowego (j.w.) ½ 9. Zmodyfikowanych bibliotekach jzyka lub elementach systemu operacyjnego ½ 10. Innych bibliotekach dostpnych na rynku ½ 11. Bibliotekach zaprojektowanych jako oprogramowanie do ponownego u|ytku ½ 12. Innych komponentach, bibliotekach ½ 13. Rysunek 7. Lista-Definicja do Naliczania LOC Rysunek 7 przedstawia cz[ w/w listy-definicji w formie, w jakiej wBcza si j do metody Cocomo2. Ka|dy check-mark w kolumnie WBczy oznacza rodzaj wyra|enia lub jego przymiot, który jest wBczany do zliczanych LOC (i odwrotnie w kolumnie WyBcz). Nie zostaBy pokazane na rysunku wy|ej cz[ci definicji opisujce parametry u|ycia, funkcjonalno[ci, replikacji i statusu rozwojowego. W definicji znajduj si te| dodatkowe wskazówki dla specyficznych 22 COCOMO 2, grudzieD 2004 wyra|eD z ró|nych jzyków programowania (Ada, C, C++, CMS-2, COBOL, FORTRAN, JOVIAL i Pascal). Definicja LOC w Cocomo2 odbiega nieco od tej opisanej w [Park 1992]. GBówn ró|nic jest pominicie tych kategorii oprogramowania, które w ramach prac implementacyjnych nie wymagaj du|ych nakBadów pracy. Z definicji usunito wic gotowe pakiety zakupione na rynku, oprogramowanie wykonane na zamówienie, gotowe biblioteki (dostpne w ramach jzyków programowania, systemów operacyjnych itp.) Kod wygenerowany automatycznie nie jest wliczany do miary LOC, niemniej dla peBniejszej analizy ilo[ciowej pomiary wielko[ci oprogramowania bd si odbywa zarówno z uwzgldnieniem jak i z wyBczeniem kodu wygenerowanego automatycznie.  Linie Kodu wg. Cocomo2 zliczane s automatycznie przy pomocy narzdzia Amadeus umo|liwiajcego obliczanie warto[ci metryk [Amadeus 1994] [Selby et al. 1991]. Narzdzie to zapewnia jednolite i konsekwentne pozyskiwanie danych do pózniejszej analizy w ramach projektu Cocomo2. Autorzy niniejszego artykuBu stworzyli zestaw wzorców dla Amadeus a zgodnych z definicjami zawartymi w Cocomo2. Stosowanie tych pakietów przez wszystkie organizacje rozwijajce Cocomo2 umo|liwi sprawniejsz i bardziej jednolit kolekcj danych liczbowych. Amadeus umo|liwia automatyczne zliczanie nastpujcych metryk: caBkowita ilo[ linii kodu, komentarze, wyra|enia wykonywalne, deklaracje, interfejsy komponentów, zagnie|d|enia i inne. Narzdzie to dostarcza bogaty wachlarz metryk, w tym metryki obiektowe opisane w [Chidamber i Kemerer 1994]. Definicja metryk liczbowych w Cocomo2 bdzie dalej dostosowywana wraz z rozwojem próbki statystycznej pozyskanych warto[ci metryk z grupy LOC. 4.4.2.2.ReguBy naliczania Punktów Funkcyjnych Szacowanie kosztów oprogramowania przy pomocy punktów funkcyjnych opiera si na mierze funkcjonalno[ci (ilo[ci i trudno[ci zadaD jakie program ma wykona) i kilku czynnikach ustalonych dla danego programu [Behrens 1983] [Kunkler 1985] [IFPUG 1994]. Punkty funkcyjne s szczególnie przydatne z tej racji, |e ich kalkulacja opiera si na informacjach dostpnych we wczesnych fazach prac projektowych. Poni|ej przedstawiono krótki opis zastosowania i naliczania punktów funkcyjnych w metodzie Cocomo2. 23 COCOMO 2, grudzieD 2004 Tabela 3. Typy Funkcji U|ytkowych w FPA Wej[cie Zewntrzne (Wej[cia) Policzy wszystkie typy ró|nych danych lub decyzji wprowadzanych przez u|ytkownika, które (i) przekraczaj zewntrzn granic badanego systemu informatycznego i (ii) powoduj zmian w danych w wewntrznych plikach logicznych. Wyj[cie Zewntrzne (Wyj[cia) Policzy wszystkie typy danych, które opuszczaj zewntrzne granice mierzonego oprogramowania. Wewntrzny Plik Logiczny (Pliki) Policzy wszystkie gBówne logiczne grupy informacji na temat danych lub decyzji wprowadzonych przez u|ytkownika. Dotyczy to wszystkich plików logicznych (czyli wszystkich logicznych grup danych) tworzonych, u|ywanych i zachowywanych przez system. Plik Zewntrznego Interfejsu (Interfejsy) Do Plików Zewntrznego Interfejsu zaliczy wszystkie pliki u|ywane wspólnie przez ró|ne systemy informatyczne (lub przekazywane midzy systemami). Zewntrzne Zapytanie (Pytania) Policzy wszystkie kombinacje wej[cie-wyj[cie w których jaka[ dana wej[ciowa powoduje natychmiastowe wygenerowanie danych wyj[ciowych. Punkty funkcyjne opisuj funkcjonalno[ programu poprzez miar przetwarzanych informacji z zewntrznych zródeB danych i przekazywanych na wyj[cie (ekran, pliki). Przy metryce punktów funkcyjnych u|ywa si piciu typów funkcji u|ytkowych  opisanych powy|ej. Dla wszystkich elementów programu z piciu typów funkcji u|ytkowych wyznaczane s ich poziomy trudno[ci (wagi), które nastpnie dodane do siebie daj sum nieznormalizowanych Punktów Funkcyjnych. Zazwyczaj nastpnym krokiem procedury naliczania Punktów Funkcyjnych jest oszacowanie poziomu, w jakim 14-cie ró|nych czynników ma wpByw na tworzony program. Warto[ci ka|dego z tych czynników wahaj si od 0.0 do 0.65 i po dodaniu ich wszystkich (i ewentualnym powikszeniu tej sumy tak, aby byBa nie mniejsza ni| 0.65) daj wspóBczynnik poprawki z przedziaBu od 0.65 do 1.35. Ka|dy z tych 14 czynników uwzgldniajcych funkcje rozproszone, wydajno[, u|ycie gotowego kodu i inne, mógB mie do 5% przyczynku do caBo[ci szacowanego nakBadu prac. Do[wiadczenia metody Cocomo zanegowaBy poprawno[ takiego modelu. W zwizku z tym w Cocomo2 do szacowania wielko[ci u|ywa si wyBcznie nieznormalizowanych Punktów Funkcyjnych, które nastpnie mno|y si przez wspóBczynniki wykorzystania gotowego kodu, wspóBczynniki zródeB kosztów i wykBadnicze mno|niki skali. Rysunek 8 ukazuje procedur naliczania nieznormalizowanych punktów funkcyjnych w metodzie Cocomo2. 24 COCOMO 2, grudzieD 2004 Krok 1: Zliczy punkty funkcyjne wedBug typów funkcji. Opracowane na podstawie danych o wymaganiach i projekcie oprogramowania, przez wiodcego czBonka zespoBu projektowego. Ka|dy z piciu typów funkcji u|ytkowych (Wewntrzny Plik Logiczny* (ILF), Plik Zewntrznego Interfejsu (EIF), Wej[cie Zewntrzne (EI), Wyj[cie Zewntrzne (EO) Zewntrzne Zapytanie (EQ)) musi by znany. Krok 2: Wyznaczy poziomy trudno[ci tych elementów. Poziom trudno[ci mo|e mie warto[ci: Niski, Zredni lub Wysoki, zale|nie od liczby zawartych typów danych i liczby plików ró|nych typów weD u|ytych. Do oceny stosuje si nastpujce kryteria: Dla ILF i EIF Dla EO i EQ Dla EI Elementy Elementy Danych Typy Elementy Danych Typy Elementy Danych rekordu 1-19 20-50 >50 plików 1-5 6-19 >19 plików 1-4 5-15 >15 1 N N Z 0 lub 1 N N Z 0 lub 1 N N Z 2-5 N Z W 2-3 N Z W 2-3 N Z W >5 Z W W >3 Z W W >3 Z W W Krok 3: Wyznaczy wag ka|dego elementu przy pomocy prostego schematu ni|ej: Typy Trudno[ - Waga Funkcji Niska Zrednia Wysoka ILF 7 10 15 EIF 5 7 10 EI 3 4 6 EO 4 5 7 EQ 3 4 6 Krok 4: Wyznaczy ilo[ nieznormalizowanych Punktów Funkcyjnych: doda wagi wszystkich elementów w programie. ____________ * Uwaga: sBowo plik oznacza tu grup powizanych za sob danych, a nie fizyczn implementacj takiej grupy. Rysunek 8. Procedura naliczania punktów funkcyjnych 4.4.3. Ponowne U|ycie istniejcego kodu i Rein|ynieria 4.4.3.1.Nieliniowe Koszty Ponownego U|ycia istniejcego kodu Podej[cie do rein|ynierii i u|ywania kodu istniejcego w metodzie Cocomo2 jest w sposób istotny odmienne od reguB w jej poprzednikach. Nowink w Cocomo2 jest to, |e w tym przypadku stosuje model nieliniowy. W pierwotnej metodzie Cocomo koszt stosowania istniejcego oprogramowania byB praktycznie liniow funkcj ilo[ci zmian, jakie nale|y w nim wprowadzi. WymagaBo to oszacowania rozmiaru dopasowywanego oprogramowania, ASLOC i trzech parametrów wielko[ci zmian: DM (% zmian projektowych), CM (% wymiany kodu) i IM (koszt zBo|enia zmodyfikowanego kodu w caBo[, jako % warto[ci pierwotnych nakBadów integracji systemu). 25 COCOMO 2, grudzieD 2004 Oto formuBa, wedBug której Cocomo obliczaB ekwiwalent ilo[ci nowego kodu w sensie rozmiaru u|ywanego ponownie oprogramowania istniejcego: (0.4 × DM + 0.3× CM + 0.3 × IM ) ESLOC = ASLOC × ( 1 ) 100 Jak wida oprogramowanie u|yte bez zmian spowoduje zerowy wzrost nakBadów (kosztów). W przeciwnym razie wzrost szacowanej wielko[ci programu bdzie liniow funkcj DM, CM i IM. Okazuje si jednak, jak udowadnia analiza kosztów wdra|ania istniejcego oprogramowania w [Selby 1988] opracowana na podstawie do[wiadczeD Laboratorium In|ynierii Oprogramowania NASA z prawie 3000 ponownie u|ytych moduBów oprogramowania, |e koszty ponownego u|ycia oprogramowania odbiegaj od modelu liniowego w dwojaki sposób: " funkcja kosztów nie przebiega przez pocztek ukBadu wspóBrzdnych. Na ogóB mniej-wicej 5cio procentowy koszt przypada na samo przejrzenie, wybranie i zrozumienie przydatnych komponentów. " nieznaczne zmiany pocigaj za sob nieproporcjonalnie du|e koszty. Spowodowane jest to gBównie potrzeb wcze[niejszego dobrego zrozumienia istniejcego oprogramowania oraz wzgldnym kosztem sprawdzenia interfejsów. Model dostosowywania istniejcego oprogramowania u|yty w Cocomo2 uwzgldnia te nieliniowo[ci. 4.4.3.2.Model Dostosowywania istniejcego kodu u|yty w Cocomo2 WedBug [Parikh i Zvegintzov 1983] a| 47% kosztów pielgnacji istniejcego oprogramowania przypada na poznawanie i przyswajanie oprogramowania poddawanego modyfikacjom. W takiej sytuacji przej[cie z u|ywania kodu bez zmian (black-box) na kod dostosowywany do potrzeb istniejcego oprogramowania (white-box) pociga za sob skokowy wzrost kosztów. Ponadto konieczno[ ponownego przetestowania interfejsów midzymoduBowych pociga za sob dodatkowe nakBady pracy. W [Gerlich i Denskat 1994] pokazano, |e zmiany w k z m moduBów wymagaj wykonania N testów, gdzie N = k*(m-k) + k*(k-1)/2. Rysunek 9 pokazuje zale|no[ midzy ilo[ci zmodyfikowanych moduBów k i liczb testów potrzebnych do sprawdzenia poprawnego dziaBania interfejsów. KsztaBt krzywej bdzie te| podobny dla innych warto[ci parametru m (caBkowita liczba moduBów). Wida wic, ze nakBady 26 COCOMO 2, grudzieD 2004 prac podczas projektowania, tworzenia, integrowania i testowania zmodyfikowanego kodu nie s liniow funkcj ilo[ci dokonanych zmian. Rysunek 9. Nieliniowe koszty dostosowywania istniejcego oprogramowania Rysunek 10. Liczba testów interfejsów midzy-moduBowych jako funkcja ilo[ci zmian Koszty przyswajania i testowania oprogramowania mo|na ogranicza poprzez tworzenie kodu o wBa[ciwej strukturze. Pisanie oprogramowania o strukturze modularnej i hierarchicznej mo|e ograniczy ilo[ niezbdnych testów interfejsów [Gerlich i Denskat 1994], a w dodatku taka budowa systemu informatycznego powinna uBatwia jego szybsze przyswajanie. Prawdy te s odzwierciedlone w Cocomo2 w szacunkach nakBadu pracy przy wykorzystywaniu istniejcego 27 COCOMO 2, grudzieD 2004 oprogramowania. Zmodyfikowana formuBa obliczania zale|no[ci liczby linii nowego kodu i rozmiaru ponownie u|ytego oprogramowania jest nastpujca: (AA + SU + 0.4 × DM + 0.3× CM + 0.3× IM ) ESLOC = ASLOC × ( 2 ) 100 Warto[ SU  nakBadu pracy na przyswajanie oprogramowania  otrzymuje si z tabeli 4. Wyznaczane tam warto[ci SU mog si waha od 10% przyrostu pracy dla oprogramowania napisanego w sposób przejrzysty, intuicyjny, o dobrej strukturze i ze stosown liczb komentarzy, do 50% dla kodu trudno przyswajalnego. Drugi za[ nowy wspóBczynnik we wzorze (2), tj. AA (Oceny i wBczania)  symbolizuje prace konieczne do sporzdzenia oceny przydatno[ci istniejcego oprogramowania w tworzeniu nowej aplikacji, oraz do wBczenia dokumentacji tego oprogramowania do caBo[ci dokumentacji programu. Tabela 4. podaje warto[ci parametru AA w zale|no[ci od sytuacji. W ocenie kosztów przeróbek oprogramowania czynnik AA stanowi rozwinicie opisanego w [Boehm 1981, str. 558] tzw. WspóBczynnika Planowania Zmian. Tabela 4. Warto[ci wskaznika ZrozumiaBo[ci Oprogramowania (SU) w zale|no[ci od jako[ci kodu Bardzo niska Niska Przecitna Wysoka B. wysoka Ustruktu- Bardzo sBabe sBabe do[ dobra dobre ModuBowo[, ralnienie pogrupowanie pogrupowanie, struktura, ale z pogrupowanie, informacje kodu, wysoki wysoki kilkoma sBabymi niski  coupling ukryte w  coupling ,  coupling punktami strukturach popltany kod. (sprz|enie) danych Przejrzysto[ Brak powizania SBaba korelacja Zrednia korelacja Dobra korelacja Oczywiste midzy punktem midzy punktem midzy struktur kod-aplikacja powizanie kodu widzenia widzenia kodu a z dziaBaniem programisty i programisty i dziaBaniem aplikacji (od str. u|ytkownika u|ytkownika programu u|ytkownika) ZrozumiaBo[ Kod niejasny. Nieznaczna ilo[ci Zredni poziom Dobra dokumen- ZrozumiaBy kod, kodu Dokumentacja komentarzy i komentarzy, tacja, nagBówki i aktualna wybrakowana, nagBówków. dokumentacji i komentarze, ale z dokumentacja, zagmatwana i Cz[ dokumen- nagBówków. paroma sBabymi uwzgldniajce przestarzaBa tacji u|yteczna. punktami. uzasadnienia warto[ wspB. 50 40 30 20 10 SU 28 COCOMO 2, grudzieD 2004 Tabela 5. Skala warto[ci WspóBczynnika AA. Warto[ wspóBczynnika AA Prace nad ocena i wBczeniem oprogramowania 0 Brak 2 Proste wyszukiwanie moduBów i dokumentacji 4 Nieznaczna ilo[ testów/ocen moduBów; dokumentacja 6 Znaczca ilo[ testów/ocen moduBów; dokumentacja 8 SzczegóBowe testowanie i ocena moduBów, dokumentacja 4.4.3.3.Szacowanie kosztów rein|ynierii i konwersji oprogramowania Model stosowania istniejcego oprogramowania wymaga dalszych u[ci[leD uwzgldniajcych rein|ynieri i konwersj oprogramowania. Wydajno[ wspóBczesnych zautomatyzowanych narzdzi do przerabiania/konwersji oprogramowania jest tak wysoka, i| nawet bardzo znaczce zmiany w oprogramowaniu (tzn. o wysokiej warto[ci parametru CM  procentu wymiany kodu) wykonywane s stosunkowo maBym nakBadem pracy. PrzykBadowo, w jednej z prac w NIST 80% kodu (13 131 wyra|eD w COCOLu) byBo zmienione przy pomocy zautomatyzowanego narzdzia i wymagaBo nakBadu pracy wynoszcego 35 roboczo-miesicy. Estymacja wykonana metod Cocomo oszacowaBa ten nakBad pracy na 152 roboczo-miesice (ponad 4 razy wicej) [Ruhl i Gunn 1991]. Wobec powy|szego Cocomo2 wprowadza nastpny parametr AT, oznaczajcy procent kodu przetwarzanego przez automatyczne translatory. Na podstawie danych do[wiadczalnych wyznaczono pracochBonno[ automatycznej translacji i wynosi ona 2400 wyra|eD kodu zródBowego / roboczo-miesic. Opisany wcze[niej model wykorzystania istniejcego oprogramowania stosuje si dla pozostaBego kodu, nie translowanego automatycznie. Tabela 6. Warto[ci stopnia automatycznego przerabiania kodu proces rein|ynierii AT (% automatycznego przerabiania) plikami wsadowymi 96% plikami wsadowymi + SORT 90% plikami wsadowymi + DBMS 88% pliki wsadowe, SORT i DBMS 82% Interaktywne 50% Szacunkowe warto[ci parametru AT wyznaczono w du|ej mierze na podstawie danych z prac NIST i pokazano je w tabeli wy|ej. WspóBczynnik AT okazuje si by pewnym rodzajem funkcji granicznej (np.: wykorzystania pakietów COTS, przej[cia z operacji wykonywanych 29 COCOMO 2, grudzieD 2004 plikami wsadowymi na interaktywne) umo|liwiajcej ocen w granicy kosztu oprogramowania wytworzonego niezmienionym i przetranslowanym kodem. 4.4.4. Wystpowanie Usterek W Cocomo2 zastpiono wystpujce w Cocomo i Ada Cocomo wspóBczynnik zmienno[ci wymagaD poprzez procentowy wskaznik wystpowania usterek: BRAK. Powoduje on w podobny sposób regulowanie efektywnej wielko[ci programu. PrzykBadowo zaBó|my, |e gotowy produkt mo|e zawiera 100 000 wyra|eD. Miara ta nie uwzgldnia dodatkowych 20 000 wyra|eD które musiaBy by zmienione w celu poprawienia programu. Warto[ wskaznika BRAK w takim programie wynosiBaby 20, a efektywny rozmiar programu w szacunkach Cocomo2 wyniósBby Bcznie 120 000 wyra|eD. W modelu Komponowania Aplikacji nie stosuje si czynnika BRAK, gdy| jest on tam domy[lny. 4.4.5. Pielgnacja oprogramowania GBówn miar nakBadów pracy na pielgnacj oprogramowania u|ywan w pierwotnej metodzie Cocomo byB Roczny PrzepByw Zmian (ACT), czyli procent oprogramowania które byBo poprawione/dodane w cigu roku. Miara ta nie zdaBa egzaminu, albowiem byBa ograniczona do rocznych przedziaBów czasu, a tak|e kBóciBa si z wynikami zastosowania modelu ponownego u|ycia istniejcego oprogramowania. By unikn podobnych problemów w metodzie Cocomo2, u|yto modelu dostosowania istniejcego kodu tak|e do zagadnieD pielgnacji oprogramowania. 4.5. Czynniki wpBywajce na koszt: Skala Programu 4.5.1. Modelowania tzw. ekonomii lub anty-ekonomii skali w pracach informatycznych Ekonomi skali nazywa si zjawisko zmniejszenia kosztów jednostkowych wytwarzania spowodowane wyBcznie poprzez wzrost wielko[ci produkcji. Anty-ekonomi skali bdzie natomiast wzrost kosztów przy wzro[cie wielko[ci. Zjawiska te w procesie produkcji oprogramowania modelowanie s w Cocomo2 przy pomocy wykBadniczej funkcji wielko[ci programu. Czynnik ekonomii bdz anty-ekonomii skali oznaczony jest jako B w poni|szym wzorze: Naklady = A × (Wielkosc)B ( 3 ) 30 COCOMO 2, grudzieD 2004 W przypadku gdy B < 1.0, mamy do czynienia z ekonomi skali. Dwukrotne powikszenie rozmiaru programu powoduje wzrost kosztów o czynnik mniejszy ni| 2. Wydajno[ produkcji wzrasta wic ze wzrostem wielko[ci samego programu. Ekonomi skali mo|na czasem uzyska poprzez stosowanie w procesie wytwórczym stosownych narzdzi (symulacji, platform do testowania), na ogóB jednak ekonomia skali jest rzadko[ci. W przypadku maBych produkcji staBe koszty pocztkowe (rozpoczcie produkcji, zakupienie i przygotowanie narzdzi, prace administracyjne) s zródBem ekonomii skali. Je[li B = 1.0 to zjawiska ekonomii i anty-ekonomii skali równowa| si wzajemnie. Przy szacowaniu kosztów niewielkich projektów czsto posBuguje si takim modelem liniowym. W metodzie Cocomo2 model taki stosuje si dla Komponowaniu Aplikacji. Przypadek B > 1.0 oznacza anty-ekonomi skali. Dzieje si tak zwykle z dwu gBównych przyczyn: wikszej ilo[ci czasu potrzebnego na przekazywanie informacji w zespoBach ludzkich i dodatkowych prac wymaganych do integracji systemu. Wiksza liczba ludzi zaanga|owanych w tworzenie pokaznego programu w oczywisty sposób oznacza wiksz ilo[ kontaktów midzyludzkich (przekazywanie informacji, dopracowywanie zBo|onych pomysBów itp.) które konsumuj czas pracy. Ponadto wBczanie mniejszej cz[ci oprogramowania do wikszej caBo[ci wymaga nie tylko stworzenia samego moduBu, ale tak|e zaprojektowania, dogldania, integrowania i testowania interfejsów midzy t cz[ci a reszt produktu. Wstpna warto[ parametru A zostaBa w Cocomo2 ustalona na 3.0. Pierwsze przymiarki tego modelu do danych liczbowych z Cocomo [Boehm 1981, str. 496-97] wskazuj, |e jest to caBkiem rozsdny punkt wyj[ciowy. 4.5.2. Okre[lenie skali prac w Cocomo i Ada Cocomo Analiza danych liczbowych przy pracach nad metod Cocomo wykazaBa, |e wikszo[ programów cechowaBa anty-ekonomia skali. Systemy informatyczne podzielono w tej metodzie na trzy gBówne grupy (Organiczna, WpóB-OdBczona i Wbudowana), dla których warto[ci parametru B wynosiBy odpowiednio 1.05, 1.12 i 1.20. Przyczyny tych ró|nic le|aBy gBównie w szczegóBach realizacji produktu: systemy wbudowane s generalnie najbardziej bezprecedensowe, wymagaj wikszego przepBywu informacji midzy zespoBami programistów i sprawiaj wicej trudno[ci podczas integracji caBego systemu. Jednocze[nie wymagania sprztowe i czasowe s bardziej 31 COCOMO 2, grudzieD 2004 restryktywne  wszelkie problemy projektowe trzeba rozwiza w ograniczonym czasie i bud|ecie, przy restryktywnych wymaganiach sprztowych i nie dopuszczajcym zmian opisie interfejsów. Zmiany wprowadzone w metodzie Ada Cocomo miaBy na celu uwzgldnienie faktu, i| zmiana parametrów procesu produkcji mo|e ograniczy efekt anty-ekonomii skali. Wymagany przepByw informacji i nakBady na integracj systemu obni|ony bdzie przez m.in.: wczesn redukcj ryzyka i bBdów; stosowanie dokBadnych i sprawdzonych specyfikacji architektury; u[ci[lenie wymagaD; itp. W Ada Cocomo warto[ parametru B zale|aBa od stosowania tych praktyk w realizacji programu [Boehm i Royce 1989, Royce 1990]. Taki model zastosowano w Ada Cocomo tylko w odniesieniu do oprogramowania systemów wbudowanych, gdzie w miejsce pojedynczej warto[ci wspóBczynnika B (= 1.20) umo|liwiono wahania tej warto[ci midzy 1.04 a 1.24. Zale|y to od stopnia stabilno[ci wymagaD i architektury, redukcji ryzyka dojrzaBo[ci procesu produkcji oraz innych czynników redukujcych anty-ekonomi skali. 4.5.3. Skalowanie prac w Cocomo2 Cocomo2 Bczy w sobie modele obu swoich poprzedników. Do metody Ada Cocomo jest podobna w tym, |e stosuje zestaw skBadników, których suma daje warto[ B. Cz[ z tych skBadników pozostaBa bez zmian, cho wspóBczynniki architektury i ryzyka poBczono w jedn warto[, a wyznacznik dojrzaBo[ci procesu stosowany w Ada Cocomo zastpiono podobn wielko[ci zdefiniowan przez Instytut In|ynierii Oprogramowania (SEI). (SzczegóBy tej definicji s obecnie dopracowywane przez SEI.) Z kolei w spadku po pierwotnej metodzie Cocomo, w wersji 2.0 znalazBy si skBadniki opisujce  bezprecedensowo[ (precedentness) i elastyczno[ wymagaD programu które zastpiBy wcze[niejszy podziaB oprogramowania na 3 grupy (organiczna, wspóBzale|na i wbudowana z Cocomo). Nowo[ci w Cocomo2 jest ocena zgrania personelu, która uwzgldnia wpByw sBabej koordynacji prac na nasilenie anty-ekonomii skali. Usunito natomiast czynnik zmienno[ci wymagaD (z Ada Cocomo)  zwikszenie kosztu produktu koDcowego jest teraz zamknite we wspóBczynniku  wystpowania usterek (Breakage). W tabeli 7 podano warto[ci skBadników do wykBadnika skali programu. Oceny z ka|dej kategorii, Wi, s do siebie dodane i daj warto[ wspóBczynnika B wg. wzoru (4). 32 COCOMO 2, grudzieD 2004 B = 1.01 + 0.01 ( 4 ) "Wi Tabela 7. Oceny skBadników wykBadnika skali projektu. (Wi) Elementy B. Niska Niska Normalna Wysoka B. Wysoka Wybitnie wspóBczynnika skali (5) (4) (3) (2) (1) Wysoka (0) bezprecedensowo[ CaBkowicie wikszo[ bez cz[ciowo generalnie wikszo[ CaBkowicie problemu / zadania bez preced. precedensu. bez preced. nieobcy nieobca znany elastyczno[ Rygorystycz mo|liwe maBe mo|liwe [rednia du|a znane tylko wymagaD -ne odstpstwa odstpstwa elastyczno[ elastyczno[ ogólne cele Architektura / maBe (20%) [rednie (40%) ponad póB wikszo[ prawie peBne PeBne usunicie ryzyka * (60%) (75%) (90%) (100%) zgranie zespoBu Bardzo utrudnione [rednio do[ dobre bardzo dobre Idealny utrudnione kontakty dobre kontakty kontakty przepByw kontakty kontakty informacji DojrzaBo[ procesu + Zrednia wa|ona odpowiedzi twierdzcych na kwestionariusz CMM * % zakoDczenia specyfikacji interfejsów midzy gBównymi moduBami; % wykonania prac eliminacji ryzyka; + kwestionariusz Modelu DojrzaBo[ci Produkcyjnej (CMM od Capability Maturity Model) jest opracowywany z udziaBem SEI. DojrzaBo[ procesu produkcji bdzie [redni wa|on odpowiedzi na pytania dotyczce 18 kluczowych aspektów procesu produkcji w CMM [Paulk et al. 1993]. Wagi poszczególnych odpowiedzi nie s jeszcze ustalone PrzykBadowo, program o wielko[ci 100K yródBowych LOC, który otrzymaB wyjtkowo wysokie (=0) noty we wszystkich elementach skali programu, bdzie miaB wykBadnik skali B = 1.01 (bo sumaW=0) i wyskalowany nakBad pracy wzro[nie do 105 roboczo-miesicy. Z kolej otrzymanie samych bardzo niskich (=5) ocen da w wyniku warto[ B = 1.26 (sumaW=25) i wzrost nakBadu pracy do 331 roboczo-miesicy. Jest to bardzo du|y skok, cho trzeba zauwa|y, |e maBa zmiana (o 1) jednego tylko parametru spowoduje tylko 4.7 procentow zmian szacowanych kosztów. W ten sposób Cocomo2 zapobiega a| 40% zmianom szacowanego nakBadu prac spowodowanym odmienn interpretacj charakteru prac w modelu skalowania metody Cocomo. 4.6. Czynniki wpBywajce na koszt: Dodatkowe czynniki zwikszajce nakBad pracy Podobnie jak w Cocomo i Ada Cocomo w metodzie Cocomo2 u|ywa si zestawu wspóBczynników regulujcych koDcow warto[ szacunków w roboczo-miesicach. Warto[ci otrzymane po uwzgldnieniu wykBadniczej skali projektu, mno|one s nastpnie przez dodatkowe czynniki zwikszajce nakBad pracy: PM = PM × ( EM ) ( 5 ) poprawione no min a ln e " i i GBównymi kryteriami doboru wspóBczynników EM byBy w Cocomo2: 33 COCOMO 2, grudzieD 2004 " cigBo[: z wyjtkiem uzasadnionych przypadków, sposób naliczania nakBadu prac pozostawiono taki sam, jak w poprzednikach  Cocomo i Ada Cocomo. " oszczdno[: wspóBczynniki przyrostu kosztów zostaBy umieszczone w Cocomo2 wyBcznie w przypadkach, gdy samodzielnie i adekwatnie opisuj znaczcy czynnik wpBywajce na zmian nakBadu pracy. 4.6.1. Czynniki Produktu 4.6.1.1.RELY  Wymagana Niezawodno[ Oprogramowania Skala ocen i waga wspóBczynnika RELY zostaBy w Cocomo2 zachowane po pierwotnej Cocomo. Z kolei w metodzie Ada Cocomo zaw|ono zbiór mo|liwych warto[ci tego wspóBczynnika dla wy|szych poziomów wymaganej niezawodno[ci, uwa|ano bowiem, |e rygorystyczne przestrzeganie typów zmiennych, wbudowana wielozadaniowo[, wyjtki i inne atrybuty jzyka programowania Ada uBatwi tworzenie niezawodnego oprogramowania. Analiza danych liczbowych tez tych nie potwierdziBa, wobec czego W Cocomo2 powrócono do opisu RELY z pierwotnej Cocomo. Tabela 8. Skale szacowania czynników wzrostu kosztów w modelu Post-Architekturowym B. Niski Niski Normalny Wysoki B. Wysoki Wyj. Wysoki RELY minimalna Niska, Batwo [rednio-Batwo duze straty ryzyko dla niewygoda naprawialne naprawialne finansowe |ycia ludzi DATA DB bytes/Pgm 10d" D/B <100 100 d" D/B < D/P e" 1000 SLOC < 10 1000 CPLX patrz Tabela 8. RUSE Brak w danym w caBym w caBej linii wielu liniach podzespole programie produkcyjnej produkcyjnych DOCU Wiele potrzeb Cz[ potrzeb Stosowna do zbyt obszerna zdecydowanie niezaspokoj. niezaspokoj. potrzeb zbyt obszerna TIME 70% 85% 95% d" 50% dostp. czasu pracy STOR 85% 95% d" 50% dostp- 70% nej pamici PVOL du|e zmiany du|e: 6 m-cy; du|e: 2 m-ce; du|e: 2 tyg.; co 12 m-cy; maBe: 2 tyg. maBe: tydzieD maBe: 2 dni maBe co 1 m-c ACAP kwantyl 15 rz. kwantyl 30 rz. kwantyl 55 rz. kwantyl 75 rz. kwantyl 90 rz. PCAP kwantyl 15 rz. kwantyl 30 rz. kwantyl 55 rz. kwantyl 75 rz. kwantyl 90 rz. PCON 48% / rok 24% / rok 12% / rok 6% / rok 3% / rok AEXP 6 miesicy 1 rok 3 lata 6 lat d" 2 miesice PEXP 6 miesicy 1 rok 3 lata 6 lat d" 2 miesice LTEX 6 miesicy 1 rok 3 lata 6 lat d" 2 miesice TOOL edycja, debug proste, poczt- podstawowe dobry, dobre, dojrzaBe kowe i koDco- narzdzia dojrzaBy zes- i postpowe 34 COCOMO 2, grudzieD 2004 B. Niski Niski Normalny Wysoki B. Wysoki Wyj. Wysoki we CASE, cyklu prod., taw narzdzi, narzdzia nieznaczna [rednio [rednio zintegrowane integracja zintegrowane zintegrowane z metodami produkcji i wielokrotnym u|yciem kodu SITE: midzynaro- Ró|ne miasta i ró|ne miasta obszar miasta budynek lub w jednym Blisko[ dowe ró|ne firmy albo firmy (metropolii) kompleks miejscu SITE: poczta, kilka FAX, ka|dy zwykBy e-mail pojemne Bcza pojemne Bcza interaktywne, Tele- telefonów ma telefon elektroniczne elektroniczne multimedialne komunikacja + okazyjne telekonferenc. SCED 75% 85% 100% 130% 160% nominalnego 4.6.1.2.DATA  Wielko[ Bazy Danych Podobnie jak w przypadku RELY, analiza danych liczbowych nie wykazaBa potrzeby zmian ocen i warto[ci wspóBczynników. Zachowujc kryterium cigBo[ci wspóBczynnik DATA w Cocomo2 pozostaB bez zmian. 4.6.1.3.CPLX  ZBo|ono[ (trudno[) Produktu Tabela 8 przedstawia now skal not dla CPLX w Cocomo2. Zmiany, które miaBy miejsce, odzwierciedlaj postp w technologii komputerowej i tworzeniu oprogramowania. PolegaBy one na dodaniu skali dla Operacji Zarzdzania Interfejsem U|ytkownika, uwzgldnieniu wpBywu przetwarzania rozproszonego i równolegBego, oraz uwzgldnieniu postpu w technologii warstwy po[redniej i obiektów baz danych. Zbiór warto[ci wspóBczynnika CPLX w Ada Cocomo byB zmniejszony dla bardziej zBo|onych programów. Uwa|ano, |e mechanizmy w jzyku Ada (wielozadaniowo[, wyjtki, enkapsulacja i inne) uBatwi rozwizywanie dotychczas trudnych problemów. W Tabeli 8 widzimy jednak dodatkowy, Wyjtkowo Wysoki poziom trudno[ci oprogramowania dla dziedzin takich, jak przetwarzanie równolegBe, rozproszone sterowanie w warunkach silnego uwarunkowania czasem rzeczywistym (hard real time) i wirtualna rzeczywisto[, które akurat w Ada (czy innych nowych jzykach programowania) nie s szczególnie uBatwione. Zdaje si, |e wzrost wymagaD na oprogramowanie rozwizujce zBo|one problemy bez trudu nad|a za postpem w techikach 35 COCOMO 2, grudzieD 2004 rozwizywania tych problemów. W takiej sytuacji zachowanie skali dla CPLX z pierwotnej metody Cocomo wydaje si by jak najbardziej na miejscu. 4.6.1.4.RUSE  Wymagane ponowne u|ycie tworzonego oprogramowania Ten wspóBczynnik wzrostu kosztów dodano w metodzie Ada Cocomo, aby uwzgldni wzrost nakBadów pracy na stworzenie kodu dostosowanego do pózniejszego wielokrotnego u|ycia w ró|nych programach. WspóBczynnik miaB cztery kategorie ocen i przybieraB warto[ci midzy 1.0 a 1.5. Pózniejsze do[wiadczenia wykazaBy, |e konieczne byBo rozszerzenie ilo[ci kategorii i zakresu warto[ci. PrzykBadowo do[wiadczenia AT&T (American Telephone & Telegraph), w których tworzenie kodu do pózniejszego wielokrotnego u|ytku spowodowaBo 2.25-krotny wzrost kosztów. Co prawda wymagania odno[nie wielokrotnego u|ycia korespondowaBy te| ze zwikszon niezawodno[ci oprogramowania, zatem wBa[ciwy wspóBczynnik wzrostu kosztów wyniósBby w Ada Cocomo (1.5)(1.4) = 2.10, a nie 1.5. Zmiana wprowadzone w Cocomo2 rozszerza zakres warto[ci RUSE do 1.75, co w efekcie poBczenia RUSE*RELY mo|e da warto[ci do (1.75)(1.5) = 2.45. 4.6.1.5.DOCU  przydatno[ wymaganej dokumentacji przy budowaniu oprogramowania Cz[ modeli szacowania kosztów oprogramowania zawiera odpowiednik warto[ci DOCU zale|ny od rozmiarów wymaganej dokumentacji. W Cocomo2 natomiast skala ocen tego wspóBczynnika opisana jest przydatno[ci wymaganej dokumentacji do potrzeb cyklu produkcji. Noty zaczynaj si na poziomie Bardzo Niskim (potrzeby produkcyjne niezaspokojone) a koDcz na Bardzo Wysokim (nadmiar dokumentacji z punktu widzenia potrzeb producentów). Zakresu (iloraz warto[ci najwikszej przez najmniejsz) wspóBczynnika DOCU wynosi 1.35. 4.6.1.6.Czynniki Platformy Okre[lenie  platforma odnosi si do docelowego zastawu sprztu i oprogramowania, z którymi dany program ma pracowa (dawniej:  maszyna wirtualna ). Czynniki platformy zostaBy cz[ciowo zmodyfikowane w porównaniu z poprzednimi wersjami metody  szczegóBy tych zmian s opisane poni|ej. Niektóre z rozwa|anych czynników usunito (np.: rozproszenie, stopieD 36 COCOMO 2, grudzieD 2004 wbudowania, wymagania czasu rzeczywistego) gdy| zagadnienia te s ju| uwzgldnione w ZBo|ono[ci Produktu (CPLX). Tabela 9. Wyznaczanie trudno[ci dla ró|nych typów moduBów B. Niski Niski Normalny Wysoki B. Wysoki Wyb. Wysoki Operacje Szereg prostych, Proste zagnie|- Przewa|nie proste Wysoce Rekurencja i Koordynacja sterujce nie zagnie|d|o- d|enie struktur zagnie|d|anie. zagnie|d|one wielokrotne zasobów o nych operacji: programu. Przypadki stero- operacje o wielu uruchamianie. zmiennych DO, CASE, Przewaga wania midzy- zBo|onych ObsBuga przerwaD priorytetach. IFTHENELSE. prostych moduBowego.  predykatach . o bez zmian ich Sterowanie na Prosta kompozyc-  predykatów . Tabele decyzyjne, Nadzorowanie priorytetów. poziomie mikro- ja moduBowa z proste  callbacks kolejek i stert. Synchronizacja kodu. Praca wywoBaniami lub przekazywa- Jednolite przetwa- procesów, zBo|one ukBadu wielo- procedur i nie wiadomo[ci. rzanie rozproszo- callbacks, procesorowego w  skryptami . Przetwarzanie ne. Pojedynczy Przetwarzanie warunkach rozproszone przy procesor pracuje rozproszone.  twardego czasu udziale warstwy w warunkach Pojedynczy rzeczywistego. po[redniej.  mikkiego proce-sor czasu realizujcy rzeczywistego. zadania  twardego czasu rzeczywistego Operacje Obliczanie pros- Obliczanie [red- Wykorzystanie Podstawy analizy: ZBo|ona analiza ZBo|ona i  nie- obliczenio- tych wyra|eD, n.p. nio trudnych standardowych interpolacja numeryczna: strukturalna ana- we A=B+C*(D-E) wyra|eD, n.p: operacji matema-  wielu zmiennych równania z macie- liza numeryczna: D=Sqrt(B**2- tycznych i statys- zwykBe równania rzami niemal- dy|a dokBadno[ 4*A*C) tycznych. Podsta- ró|niczkowe. jednostkowymi, brzy danych wowe operacje na Podwy|szona czstkowe równa- stochastycznych z macierzach i waga zaokrglania nia ró|niczkowe. szumem. ZBo|ona wektorach. Prosta paraleliza- paralelizacja cja obliczeD. obliczeD Operacje Proste komendy Zbdna wiedza na Przetwarzanie I/O Operacje na fizy- Operacje obsBugi, DziaBanie zsyn- specyficzne odczytu i zapisu. temat danego zawiera wybór cznym poziomie diagnozowania i chronizowane z dla urzdze- Wyra|enia o procesora czy urzdzenia, I/O (przeliczanie ukrywania przer- prac urzdzenia, nia przejrzystym urzdzenia I/O. sprawdzenie adresów fizycz- waD. ObsBuga cz[ programu w formacie. Wej[cie/wyj[cie statusu i obsBug nych; szukanie, linii komunikacyj- mikro-kodzie. na poziomie bBdów. czytanie danych) nych. Systemy Systemy operacji GET i Zoptymalizowane wbudowane o wbudowane o PUT. operacje I/O. du|ej szybko[ci wy[rubowanych dziaBania. osigach. Operacje Proste tablice w Pojedynczy plik z Dane wej[ciowe z Proste  odpalacze Koordynacja Wysoce sprz|o- zarzdzania pamici. Proste pojedynczym ty- wielu plików, (triggers) rozproszonej bazy ne, dynamiczne danymi zapytania i pem danych, bez wyj[ciowe do uruchamiane danych. ZBo|one struktury zmiany w bazie zmian w pliku, jednego. Niewiel- przez zawarto[c  odpalacze . obiektów i relacji. danych COTS bez po[rednich kie zmiany ich strumienia danych Optymizacja Zarzdzanie plików. Zrednio struktury. ZBo|one manipu- przeszukiwania danymi w zaawansowane ZBo|one operacje lacje na struktu- danych. jzykach operacje w bazie w bazie danych rach danych. naturalnych (a. danych COTS. COTS. ludzkich) Operacje Proste formy do Proste kreatory ZwykBe zastoso- Rozwinicie zes- Zrednio zBo|one Skomplikowane interfejsu danych wej[cio- graficznego inter- wanie zestawu tawu widgetów, 2D/3D, dynamicz- multimedia, u|ytkow- wych, generatory fejsu u|ytkownika widgetów (?) proste I/O multi- na grafika, multi- wirtualna nika raportów (GUI) medialne (gBos) media rzeczywisto[ 37 COCOMO 2, grudzieD 2004 4.6.1.7.TIME  Ograniczenie Czasu DziaBania, STOR  Limit Dostpnej Pamici W [wietle zadziwiajcego wrcz postpu technicznego w dziedzinie szybko[ci procesorów i wielko[ci pamici (operacyjnej, dyskowej) mo|na by si zastanawia, czy ograniczenia czasu wykonywania programu lub ilo[ci dostpnej pamici maj nadal znaczenie. Okazuje si jednak, |e coraz to nowe aplikacje w peBni wykorzystuj zasoby szybko[ci i pamici sprztu komputerowego, a ograniczenia TIME/STOR s wi|ce. Zgodnie z kryterium cigBo[ci i w [wietle wyników analiz danych liczbowych, skale i warto[ci tych czynników pozostaBy bez zmian w Cocomo2. 4.6.1.8.PVOL  Zmienno[ Platformy W Cocomo warto[ ta nosiBa nazw Zmienno[ci Maszyny Wirtualnej (VIRT  Virtual Machine Volatility), natomiast w Ada Cocomo byBa rozdzielona na Zmienno[ Hosta i Zmienno[ Maszyny Docelowej  odzwierciedlajc dominujcy wówczas trend  tworzenie oprogramowania host-maszyna docelowa w Ada (Ada host-target software development approach). Obecnie pod|a si raczej w kierunku rozproszonego tworzenia oprogramowania, a podziaB midzy hostem a maszyn docelow jest bardziej rozmyty. W takiej sytuacji Cocomo2 powraca do pojedynczego czynnika Zmienno[ci Platformy, zgodnie z kryterium oszczdno[ci. Skala i warto[ci wspóBczynnika tak|e zostaBy zachowane z opisu czynnika VIRT w Cocomo.  Platform definiuje si tu identycznie do dawnej  Maszyny wirtualnej : poBczenie sprzt-oprogramowanie (OS, DBMS) wykorzystywane przez dany program do wykonania swoich zadaD. 4.6.1.9.TURN  Czas Kompilacji (Computer Turnaround Time) Czynnik ten miaB zdecydowanie wiksze znaczenie w okresie wprowadzania pierwotnej metody Cocomo (lata 70-te), kiedy to programi[ci pracowali zwykle na sprzcie wykonujcym zadania wsadowe. Obecnie wikszo[ oprogramowania tworzy si w [rodowiskach interaktywnych i tendencja ta tylko si umacnia. W rezultacie czynnik TURN utraciB niemal caBkowicie swoje znaczenie i zostaB usunity z Cocomo2. 4.6.2. Czynniki Kadrowe 4.6.2.1.ACAP  Umiejtno[ci Analityków, PCAP  Umiejtno[ci Programistów Zarówno w Cocomo jak i Ada COCOCMO Bczny zakres warto[ci (iloraz warto[ci najwikszej do najmniejszej) tych dwóch wspóBczynników wynosiB nieco ponad 4, odzwierciedlajc 38 COCOMO 2, grudzieD 2004 w ten sposób du|y wpByw, jaki umiejtno[ci personelu maj na wydajno[ tworzenia oprogramowania. Pierwotnie, w Cocomo, zaBo|ono mniej-wicej równe warto[ci obu czynników: ACAP=2.06 i PCAP=2.03. Z kolei w Ada Cocomo zaBo|ono sytuacj, w której zwarty sztab wysoce wykwalifikowanych analityków kreowaB dokBadne specyfikacje oprogramowania  do wcielenia w |ycie przez mo|e mniej zdolnych programistów. Zakresy warto[ci zmieniBy si zatem na ACAP=2.57 i PCAP=1.62. Dzisiaj tak|e podkre[la si wag umiejtno[ci analityków, ale wzrasta te| znaczenie kwalifikacji samych programistów. Spowodowane jest to w du|ej mierze zwikszonym wykorzystaniem zBo|onych pakietów COTS, z którymi tylko dobrze wyszkoleni programi[ci bd w stanie sprawnie sobie radzi. Dla powy|szych przyczyn wspóBczynniki ACAP i PCAP Bcznie zachowuj podobny zakres warto[ci (4), natomiast rozwa|ane oddzielnie znajduj si w punkcie po[rednim midzy Cocomo i Ada Cocomo. W rezultacie zakresy wspóBczynników w Cocomo2 wynosz: 2.24 dla ACAP i 1.85 dla PCAP. 4.6.2.2.AEXP  Do[wiadczenie z aplikacjami, PEXP  Do[wiadczenie z platformami, LTEX  Do[wiadczenie z jzykiem programowania i narzdziami W metodzie Cocomo2 dokonano trzech zasadniczych zmian w powy|szych czynnikach wzrostu kosztów: " przeniesiono je na jedn wspóln skal dla uniknicia wcze[niejszych nieporozumieD; " powikszono zakres warto[ci PEXP, poniewa| dogBbne zrozumienie mo|liwo[ci wykorzystania najnowszego sprztu nabraBo ostatnio na znaczeniu (np.: sprztowe wspomaganie dla graficznego interfejsu u|ytkownika, baz danych, sieci komputerowych, wykorzystanie mo|liwo[ci middleware); " rozszerzono do[wiadczenie w jzyku programowania o umiejtno[ci u|ywania narzdzi i metod projektowych. Powy|sze wspóBczynniki w Cocomo2, w porównaniu do Cocomo i Ada Cocomo, maj nastpujce zakresy warto[ci: " AEXP : 1.54 w Cocomo2; 1.57 w Cocomo i Ada Cocomo; " PEXP : 1.58 w Cocomo2; 1.34 w Cocomo i Ada Cocomo (VEXP); 39 COCOMO 2, grudzieD 2004 " LTEX : 1.51 w Cocomo2; 1.20 w Cocomo i Ada Cocomo (LEXP); 4.6.2.3.PCON  Stabilno[ personelu Przy kolekcji i analizie danych liczbowych pierwotnej metody Cocomo rozwa|ano zastosowanie wspóBczynnika PCON. Wyniki analizy nie byBy jednak jednoznaczne i ostatecznie nie umieszczono tej warto[ci w[ród czynników zwikszajcych nakBad pracy [Boehm 1981, str. 486-487]. W Cocomo2 skal szacowania warto[ci PCON opisuje procentowa warto[ wymiany personelu w cigu roku: od 3 do 48 procent. Zakres warto[ci wynosi 1.52. 4.6.3. Czynniki Procesu Produkcji 4.6.3.1.MODP  Wykorzystanie nowoczesnych metod tworzenia oprogramowania Pojcie  nowoczesne metody tworzenia oprogramowania ewoluuje w stron jeszcze szerszego okre[lenia:  dojrzaBe metody in|ynierii oprogramowania u|ytego w CMM (Capability maturity Model  wspomniany wy|ej) Instytutu In|ynierii Oprogramowania (SEI) [Paulk et al. 1993] i innych podobnych modelach (ISO 9000-3, SPICE). WpByw zastosowania takich metod w tworzeniu oprogramowania opisany jest w Cocomo2 jako skBadnik DojrzaBo[ci Procesu Produkcji w[ród wykBadniczych wspóBczynników skali. WspóBczynnik zródeB kosztów MODP nie jest zatem potrzebny w Cocomo2. 4.6.3.2.TOOL  Stosowanie narzdzi software owych Od czasu kalibracji pierwotnej metody Cocomo, czyli lat 70-tych, narzdzia informatyczne byBy znaczco usprawniane. W Ada Cocomo dodano wic dwa nowe poziomy ocen wychodzce naprzeciw oczekiwanemu rozwojowi mo|liwo[ci tych narzdzi w póznych latach 80-tych i pocztku 90-tych. Od tego czasu programy otrzymujce noty  B. Niska i  Niska na skali TOOL zaczBy by rzadko[ci. Wobec tego w Cocomo2 przesunito caB skal TOOL eliminujc najni|sze (B. Niska i Niska) warto[ci i zmieniajc nieco pozostaBe pi poziomów ocen z Ada Cocomo. Usunicie dwóch ocen ze skali zmniejszyBo zakres warto[ci wspóBczynnika TOOL z 2.00 do 1.61. 40 COCOMO 2, grudzieD 2004 4.6.3.3.SITE  Rozproszenie tworzenia oprogramowania Dwie przesBanki  upowszechnienie rozproszonego tworzenia oprogramowania oraz gBosy producentów oprogramowania stwierdzajce, |e taki tryb pracy ma znaczcy wpByw na nakBad pracy  spowodowaBy dodanie czynnika SITE do metody Cocomo2. Jego szacowana warto[ci jest [redni dwu czynników: fizycznej blisko[ci (od pracy w jednym miejscu po rozmieszczenie w ró|nych krajach) i mo|liwo[ci infrastruktury telekomunikacyjnej (od zwykBej poczty i poBczeD telefonicznych po interaktywny kontakt multimedialny). Zakres warto[ci wynosi 1.57. 4.6.3.4.SCED  Wymaganie dotyczce harmonogramu prac Analiza danych liczbowych nie wykazaBa, aby zmiana dotychczasowych warto[ci wspóBczynnika SCED byBa potrzebna. Wobec tego pozostaj one bez zmian w Cocomo2, zgodnie z kryterium cigBo[ci. 4.6.3.5.SECU  Oprogramowanie utajnione W Ada Cocomo wspóBczynnik SECU zwikszaB szacunkowy nakBad prac o 1.10 w przypadku produktów poufnych/utajnionych. Znakomita wikszo[ oprogramowania nie jest klasyfikowana na |adnym poziomie tajno[ci, w zwizku z czym zgodnie z postulatem oszczdno[ci, wspóBczynnik SECU usunito z metody Cocomo2 4.7.Dodatkowe mo|liwo[ci metody Cocomo2 W tej cz[ci uszczegóBowione bd zagadnienia zwizane z zastosowaniem wspomnianych wcze[niej narzdzi w Cocomo2: modele szacunkowe Projektu Wstpnego i Póznych Faz Projektowych u|ywajce Punktów Funkcyjnych, estymacja harmonogramu prac, przedziaBy dokBadno[ci szacunków. W nastpnych artykuBach opisane bd dalsze mo|liwo[ci metody Cocomo2, w tym ocena wpBywu wykorzystania gotowego kodu i zastosowania komponowania aplikacji na koszt i harmonogram prac. 4.7.1. Szacunki Punktów Funkcyjnych w modelach Projektu Wstpnego i Póznych Faz Projektowych Po wyznaczeniu liczby Punktów Funkcyjnych programu, zgodnie z opisem przedstawionym wcze[niej, nale|y uwzgldni poziom jzyka programowania (asembler, jzyki 41 COCOMO 2, grudzieD 2004 wysokiego poziomu, jzyki czwartej generacji), w którym program ma by napisany. Na tej podstawie okre[li si proporcj punktów funkcyjnych do faktycznych yródBowych LOC. Przeliczanie punktów funkcyjnych na SLOC kodu odbywa si w Cocomo2 przy pomocy odpowiednich tabel (m.in. tabel stworzonych przez Badania Wydajno[ci Informatycznej (Software Productivity Research - SPR) [SPR 1993]); zarówno dla modelu Projektu Wstpnego jak i Póznych Faz Projektu. Dalsze obliczenia w modelu Póznych Faz Projektu przebiegaj identycznie do obliczeD bazowanych na SLOC. Co wicej, metoda Cocomo2 umo|liwia zastosowanie punktów funkcyjnych do niektórych moduBów program i SLOC do pozostaBych (np. w sytuacji, gdy punkty funkcyjne nie s miar adekwatn, jak przy systemach czasu rzeczywistego czy obliczeniach naukowych). W przypadku modelu Projektu Wstpnego szacowanie przy pomocy punktów funkcyjnych, przeliczanie ich na SLOC i skalowanie opisane w rozdziale 5 odbywaj si tak samo jak w modelu Póznych Faz Projektowych. Jedyn ró|nic jest u|ycie mniejszej ilo[ci czynników przyrostu nakBadu pracy. WspóBczynniki te otrzymuje si poprzez Bczenie ich odpowiedników z modelu Póznych Faz Projektu; zgodnie z opisem w tabeli 10. Po poBczeniu tym otrzymujemy siedem gBównych czynników kosztów. Ich warto[ci mo|na oszacowa ju| we wczesnych stadiach prac nad programem, znacznie Batwiej ni| warto[ci odpowiadajcych im 17 wspóBczynników z modelu Póznych Faz Projektowych. Z racji pokaznych zakresów warto[ci tych czynników (do 5.45 w przypadku PERS i 5.21 przy RCPX) zwikszyB si zakres mo|liwych warto[ci koDcowych. W takiej sytuacji wikszy jest tak|e mo|liwy bBd oszacowania i w zwizku z tym wynikowi w modelu Projektu Wstpnego przypisuje si odpowiednio wiksz warto[ odchylenia standardowego (ni| w Póznych Faz Projektowych). Tabela 10. Czynniki wzrostu kosztów w modelach Projektu Wstpnego i Póznych Faz Projektowych Czynniki w modelu Odpowiedniki w modelu Projektu Wstpnego Póznych Faz Projektowych RCPX RELY, DATA, CPLX, DOCU RUSE RUSE PDIF TIME, STOR, PVOL PERS ACAP, PCAP, PCON PREX AEXP, PEXP, LTEX FCIL TOOL, SITE SCED SCED 42 COCOMO 2, grudzieD 2004 4.7.2. Szacunki harmonogramu prac Pierwsza wersja metody Cocomo2 zawiera prosty model szacunkowy dla harmonogramu prac projektowych i produkcyjnych, podobny do analogicznych modeli w Cocomo i Ada Cocomo. Równanie stosowane we wszystkich trzech podmodelach Cocomo2 jest nastpujce: %SCED TDEV = [3.0 × (PM )(0.33+0.2×(b-1.01) ]× ( 6 ) 100 gdzie TDEV oznacza czas w miesicach midzy dostarczeniem pierwotnych wymagaD do momentu zatwierdzenia produktu, jako speBniajcego wymagania programowe. PM jest ilo[ci roboczo- miesicy wymagan do zakoDczenia prac wyznaczon z uwzgldnieniem wszystkich wskazników z wyjtkiem SCED. Wystpujce w równanie %SCED jest natomiast procentow warto[ci wspóBczynnika skomasowania/rozluznienia harmonogramu prac opisanego w Tab. 7. 4.7.3. PrzedziaBy wyników obliczeD Niektórzy u|ytkownicy metody Cocomo wyrazili opini, i| bardziej celowe byBoby otrzymanie wyników w postaci przedziaBów, a nie pojedynczych warto[ci. W metodzie Cocomo2 jest to mo|liwe przy pomocy opisu dokBadno[ci szacunków (Rysunek 2). Po wyznaczeniu najbardziej prawdopodobnej warto[ci nakBadu pracy E (w ka|dym z trzech modeli: Komponowania Aplikacji, Projektu Wstpnego i Póznych Faz Projektowych) mo|na znalez warto[ci dla optymistycznej i pesymistycznej wersji szacunku  odlegB o okoBo jedno odchylenie standardowe od E. Oblicza si je w nastpujcy sposób: Model Wersja Optymistyczna Wersja Pesymistyczna Komponowanie Aplikacji 0.50 E 2.0 E Projekt Wstpny 0.67 E 1.5 E Pózne Fazy Projektowe 0.80 E 1.25 E Tak obliczone warto[ci mo|na te| u|y do wyznaczenia przedziaBu czasu potrzebnego na stworzenie programu (we wzorze 6.) 43 COCOMO 2, grudzieD 2004 5. Podsumowanie Z przedstawionego powy|ej materiaBu wida wyraznie, |e jakkolwiek szacowanie kosztu produkcji oprogramowania  szczególnie w pocztkowych fazach jego cyklu |ycia  jest mo|liwe, ale równocze[nie jest bardzo trudne. BBd szacunku mo|e wynie[ nawet 400%, co w przypadku bud|etów projektów rzdowych mo|e oznacza ogromne kwoty. Dlatego te| wydaje si, |e ka|dy mened|er projektu musi przewidzie odpowiednie sBu|by, które bd odpowiedzialne wyBcznie za zarzdzanie kosztem przedsiwzi i za szacowanie pracochBonno[ci procesu wytwórczego oprogramowania. Nale|y tutaj równie| rozwa|y mo|liwo[ odpowiedniego oprzyrzdowania koniecznego dla komputerowego wspomagania zespoBu szacujcego koszty przedsiwzi informatycznych. Nale|y równie| pamita o tym, |e Cocomo2 podaje koszt produkcji oprogramowania w osobogodzinach. Na tej podstawie bdzie mo|liwe przeliczanie szacunku Cocomo2 na warto[ci pieni|ne, o ile znamy stawk godzinow w firmie, dla której wykonywane s szacunki kosztu wytwarzania oprogramowania. 44 COCOMO 2, grudzieD 2004 6. Wyja[nienie skrótów u|ytych w tek[cie 3GL Jzyk Programowania 3ciej Generacji AA %nakBadu prac przy ponownym u|yciu kodu pochBonita na przejrzenie i ocen kodu ACAP Umiejtno[ci Analityków ACT Roczny PrzepByw Zmian ASLOC Dostosowane yródBowe Linie Kodu AEXP Do[wiadczenie z Aplikacjami AT Zautomatyzowane TBumaczenie BRAK Wystpowanie Usterek CASE In|ynieria Programowania Wspomagana Komputerowo CM % Kodu zmodyfikowanego dla potrzeb ponownego jego u|ycia CMM Model DojrzaBo[ci Produkcyjnej Cocomo Model Kosztów Konstrukcji Oprogramowania COTS pakiety informatyczne zakupione jako caBo[  do u|ycia we wBasnym programie CPLX ZBo|ono[ Produktu CSTB Naczelna Rada Informatyki i Telekomunikacji DATA Rozmiar Bazy Danych DBMS System Zarzdzania Bazami Danych DI Poziom WpBywu DM % projektu zmodyfikowanego dla potrzeb ponownego jego u|ycia DOCU przydatno[ wymaganej dokumentacji do potrzeb produkcji EDS Elektroniczne Systemy Danych ESLOC Równowa|ne yródBowe Linie Kodu FCIL Zaplecze FP Punkty Funkcyjne GFS Oprogramowanie na Zamówienie (Rzdowe) GUI Graficzny Interfejs U|ytkownika ICASE Komputerowo Wspomagane Zintegrowane Zrodowiska Programowania IM %prac integracyjnych powtórzonych przy ponownym u|yciu kodu KSLOC Tysic yródBowych Linii Kodu LEXP Do[wiadczenie z Jzykiem Programowania LTEX Do[wiadczenie z Jzykiem i Narzdziami Programowania MODP WspóBczesne Metody Tworzenia Oprogramowania 45 COCOMO 2, grudzieD 2004 NIST Krajowy Instytut Norm i Technologii NOP Nowe Punkty Obiektowe OS Systemy Operacyjne PCAP Umiejtno[ci Programistów PCON CigBo[ Personelu PDIF ZBo|ono[ Sprztu PERS Umiejtno[ci ZaBogi PEXP Do[wiadczenie z Platform PL Linia Produkcyjna PM Roboczo-miesic PREX Do[wiadczenie ZaBogi PROD WspóBczynnik Wydajno[ci Produkcji PVOL Zmienno[ Platformy RCPX Niezawodno[ i ZBo|ono[ Produktu RELY Wymagana Niezawodno[ Oprogramowania RUSE Wymaganie tworzenia kodu do ponownego wykorzystania RVOL Zmienno[ wymagaD SCED Wymagany harmonogram prac SECU Tajne Aplikacje SEI Instytut In|ynierii Oprogramowania SITE równolegBa praca w wielu ró|nych miejscach SLOC yródBowe Linie Kodu STOR Ograniczenie Dostpnej Pamici T&E Testy i Ocena DziaBania SU %nakBadu prac przy ponownym u|yciu kodu pochBonita na przyswajanie kodu TIME Ograniczenie Czasu DziaBania TOOL Wykorzystanie Narzdzi Informatycznych TURN Czas Kompilacji USAF/ESD OddziaB Systemów Elektronicznych SiB Powietrznych Stanów Zjednoczonych VEXP Do[wiadczenie z  Maszyn Wirtualn VIRT Zmienno[ Maszyny Wirtualnej VMVH Zmienno[ Maszyny Wirtualnej: Hosta VMVT Zmienno[ Maszyny Wirtualnej: Wyniku 46 COCOMO 2, grudzieD 2004

Wyszukiwarka

Podobne podstrony:
Koszty w przedsiebiorstwie
informacja z realizacji dla koordynatora przedszkolnego programu
Potrzeby informacyjne i doradcze przedsiębiorców wchodzących na rynek e usług
ekonomika przedsiębiorczości 1 Koszty transakcyjne
05 Przychody i koszty dzialalnosci przedsiebiorstwa wyklad
wykład Koszty, nakłady, a wielkość produkcji
Praca kontrolna z Informatyki semestr I Grafika komputarowa przedstaw jeden z program, krótko go op
Informator dla rodziców osób z autyzmem województwo wielkopolskie 2009(1)
Zrodla finansowania przedsiebiorstwa i koszty ich pozyskania

więcej podobnych podstron