Konstruktywny model

Praktyka projektowa pokazuje, że nawet kwalifikowane oszacowanie złożoności tworzonego oprogramowania nie gwarantuje wyznaczenia czasowych ram realizacji przedsięwzięcia. Warto zatem sięgnąć po sprawdzone narzędzia inżynierii oprogramowania, wspomagające procesy estymacyjne.

Praktyka projektowa pokazuje, że nawet kwalifikowane oszacowanie złożoności tworzonego oprogramowania nie gwarantuje wyznaczenia czasowych ram realizacji przedsięwzięcia. Warto zatem sięgnąć po sprawdzone narzędzia inżynierii oprogramowania, wspomagające procesy estymacyjne.

Jednym z takich narzędzi jest konstruktywny model kosztowy COCOMO (Constructive Cost Model), którego podstawą są praktyczne doświadczenia branżowej legendy, jaką jest Barry Boehma. Były one zbierane w trakcie dziesiątków projektów IT w takich firmach, jak RAND, Thomson czy General Dynamics.

Doświadczenia te pozwoliły na sformułowanie kilku wniosków:

(1) przebieg rzeczywisty czasowej krzywej projektu jest niemalejący w relacji do planowanej; (2) krzywa rośnie szybko, gdy planowany czas znajduje się poniżej optimum; (3) krzywa rośnie powoli, gdy planowany czas znajduje się powyżej optimum; zaś (4) optimum czasowe należy wyznaczyć formułą postaci

T<sub>R</sub> = C (T<sub>P</sub>)<sup>D</sup>

gdzie T<sub>R</sub> - kalendarzowy czas optymalny (rzeczywisty), T<sub>P</sub> - nakłady czasowe w osobomiesiącach (OM), pierwotnie szacowane innymi metodami (poprzez analogie do innych projektów), C, D - stałe projektowe, przy czym D jest ułamkowym wykładnikiem dla uzyskania efektu nieliniowości formuły.

Co zatem oznacza w praktyce powyższe równanie? W gruncie rzeczy można je sprowadzić do złośliwego prawa Murphy'ego - "rzeczywisty czas realizacji dowolnego przedsięwzięcia jest dwa razy dłuższy niż planowany". Oczywiście istotne jest tutaj pytanie, jak faktycznie wyglądają związki między złożonością oprogramowania, wysokością nakładów czasowych w osobomiesiącach i wreszcie kalendarzowym czasem realizacji projektu. Przejdźmy więc do praktycznych przykładów, pokazujących jak przejść od rozmiaru oprogramowania liczonego w tysiącach linii kodowych KSLOC (Kilo Source Lines Of Code) do wartości czasowych, względnie optymalnej wielkości grupy projektowej.

Kara za wiedzę

Pierwsza formuła, którą należy zastosować, ma podobną postać do poprzedniej i służy do wyznaczenia nominalnej ilości niezbędnych osobomiesięcy (OM<sub>N</sub>) w zależności od rozmiaru przedsięwzięcia:

OM<sub>N</sub> = A (KSLOC)<sup>B</sup>

Dodajmy, że wartość KSLOC dogodnie jest wyliczyć metodą punktów funkcyjnych FP (Function Points), stosując odpowiednie przeliczniki punktów funkcyjnych na linie kodowe w zależności od narzędzia programowania. Zanim przejdziemy do podania możliwych wartości dla współczynników formuły, przeprowadźmy krótką prezentację jej znaczenia. Również i w tym przypadku oprócz mechanicznej umiejętności posłużenia się wzorem, ważna jest jego interpretacja - bezkrytyczne, automatyczne stosowanie różnych formuł estymacyjnych rodzi bowiem niebezpieczeństwo nakładania się na siebie błędów szacowania.

Tak więc stała A w prosty sposób odzwierciedla efekty mnożnikowe, zwiększania się nakładów niezbędnych do realizacji projektu w zależności od jego wielkości. Z kolei wykładniczy współczynnik B odpowiada za nieliniowość ekonomiczności skali projektu. W trywialnym przypadku B = 1, mamy do czynienia z modelem liniowym, co oznacza ekonomiczne zbalansowanie projektu i może być stosowane dla szacowania nakładów mniejszych przedsięwzięć.

Oczywiście najbardziej pożądany jest przypadek, gdy B < 1, co oznacza ekonomiczną skalowalność projektu, np. dla trzy razy większego przedsięwzięcia nakłady rosną w mniejszym stopniu niż trzykrotnie. W takiej sytuacji produktywność rośnie wraz z wielkością projektu, ale w praktyce może to być trudne do osiągnięcia. Główną przyczyną tego stanu rzeczy jest - z definicji - systemowość projektów informatycznych. System jest czymś więcej niż tylko prostą sumą jego składowych elementów. W obszarze IT dodatkowo mamy tu do czynienia z problemem integracji trzech rodzajów interfejsów: osobowego (interpersonal communication), aplikacyjnego i sprzętowego.

W pierwszym przypadku liczba połączeń komunikacyjnych między N członkami zespołu rośnie wykładniczo zgodnie z formułą N(N-1)/2, prowadząc do szybkiego wzrostu ilości czasu przeznaczonego na koordynację działań w grupie. Natomiast w zakresie aplikacyjnym już niewielkie zmiany projektowe prowadzą do istotnego wzrostu kosztów, co wiąże się z koniecznością kontroli (modyfikacji) interfejsów oraz tzw. karą za zrozumienie (understanding penalty) jak naprawdę działa oprogramowanie - to przejście od modelu "czarnej skrzynki" (black box) do "białej skrzynki" (white box).

Przyjmuje się, że modyfikacja K modułów, spośród ich ogólnej liczby M, powoduje konieczność zweryfikowania I = K(M-K) + K(K-1)/2 interfejsów, tj. nie tylko wszelkich połączeń między weryfikowanymi modułami (drugi człon równania), ale także interfejsów między "nowymi" a "starymi" modułami. Bez szczegółowego badania przebiegu zmienności tej funkcji powiedzmy jedynie, że dość ostro pnie się ona w górę w miarę wzrostu wartości zmiennej K, niezależnie od poziomu parametru M. Przykładowo: modyfikacja 4 zamiast 2 modułów z 8 oznacza niemal dwukrotny wzrost ilości interfejsów do weryfikacji (z 13 do 22), podobnie jak w przypadku całkowitej liczby modułów równej 12 (z 21 do 38).

Prawo Amdahla

Pozostaje jeszcze trzeci z wymienionych rodzajów interfejsów: integracja na poziomie sprzętowym. "Wąskie gardła" obserwowane podczas zarządzania zespołami ludzkimi uwidaczniają się także w systemach wieloprocesorowych. Tutaj również istnieją granice złożoności, poza którymi opłacalność zwiększania liczby procesorów w konfiguracji szybko zaczyna maleć. Zjawisko to znane jest jako prawo Amdahla. Przyjmijmy, że jeden procesor może wykonać określone zadanie w ustalonym, jednostkowym czasie. Gdyby problem dało się w 100% "zrównoleglić", to oczywiście czas potrzebny N procesorom byłby N razy mniejszy i wynosił 1/N. Niestety, w praktyce nie wszystkie fragmenty programu można sparalelizować. Przyjmijmy, że 30% kodu trzeba wykonać sekwencyjnie i opiszmy ten czas współczynnikiem S = 0,3.

Zysk na czasie uzyskamy jedynie dla pozostałej części algorytmu:

1-S, proporcjonalnie do ilości użytych procesorów. Tak więc cały czas obliczeń T wyrazi się wzorem T = (1 - S)/N + S.

Podstawmy zatem do wzoru przyjętą wartość 0,3. W przypadku, gdy decydujemy się na dodatkowy procesor (N = 2), otrzymamy wówczas T = 0,65. Uzyskaliśmy spodziewane skrócenie czasu, ale zbadajmy teraz jak wygląda przyrost wydajności, którą można opisać odwrotnością czasu: 1/T = 1,538. Wniosek: drugi procesor przyniósł poprawę wydajności jedynie o 54%! Łatwo zauważyć hamujący wpływ współczynnika nierównoległości na przyrosty wydajności: im jest mniejszy, tym owe przyrosty są większe; dla 0,2 użycie drugiego procesora przynosi wzrost wydajności o 67%. Zwróćmy z kolei uwagę, że nawet nieskończona liczba procesorów nie podniesie nam relatywnej wydajności powyżej granicy jaką jest 1/S. Dla 0,3 będziemy się zatem asymptotycznie zbliżać do poziomu 3,33 w stosunku do wydajności podstawowej. W takiej sytuacji użycie jednego, cztery razy szybszego procesora da lepszy efekt niż 1000 wolniejszych procesorów równoległych. Jasne jest też, że największe przyrosty wydajności uzyskuje się przy pierwszych, dodatkowych procesorach.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200