JEDNOSTKI PROGRAMOWE A JEDNOSTKI UMOWNE Beata CZARNACKA-CHROBOT

Streszczenie: Koszty projektów informatycznych, czas ich realizacji, jak również produktywność działań projektowych, rozumiana jako stosunek wielkości budowanego systemu informatycznego do nakładów pracy przeznaczonych na jego stworzenie, zależą w sposób bezpośredni i zasadniczy od rozmiaru tworzonego systemu. W ielkość systemu informatycznego można wyrazić za pom ocą dwóch rodzajów jednostek. Pierw szą grupę stanow ią jednostki programowe, do których zalicza się liczbę linii kodu źródłowego oraz liczbę poleceń. Drugi rodzaj zaś to jednostki umowne w postaci punktów funkcyjnych, punktów charakterystycznych, punktów obiektowych oraz pełnych punktów funkcyjnych. W związku z tym do pomiaru i szacowania projektów informatycznych wykorzystuje się zasadniczo dwie grupy metod, k tó re . opierają się na zupełnie odmiennych zasadach i uw zględniają zupełnie inne elementy projektu. Niniejszy artykuł zawiera krótką charakterystykę każdej z tych grup, przy czym nieco dokładniej przedstawiono metodę punktów funkcyjnych stanowiącą klasyczny przykład sposobu analizy i estymacji opartego na jednostkach umownych. Nie pom inięto również jej wariantów służących do pomiaru i szacowania rozmiaru funkcjonalnego, które albo bazują na innych jednostkach tej klasy, albo m odyfikują zasady owego klasycznego podejścia. W dalszej części zestawiono podstawowe cechy metod opartych na jednostkach programowych z metodami bazującymi na jednostkach umownych w kontekście ich przydatności w procesie pom iaru i szacowania produktywności projektu. Końcowa część publikacji zawiera om ówienie sposobu powiązania obydwu rodzajów jednostek poprzez wykorzystanie punktów funkcyjnych do oceny efektywności języków programowania

1 M etody oparte na jednostkach programowych

Z całości prac nad realizacją projektu systemu informatycznego (SI) często wyodrębnia się prace programowe, co wynika z możliwości zastosowania do ich oceny prostych kryteriów ilościowych. Stąd też niektóre metody pomiaru i szacowania opierają się na czynnikach wymiernych stosowanych jedynie do oceny prac wchodzących w skład stadium budowy oprogramowania. Do takich metod należą metody oparte na liczbie linii kodu źródłowego (LKZ) oraz na liczbie poleceń1. Najpowszechniejsze to:

1 Różnice między tymi jednostkami są jedynie formalne i bez znaczenie dla strategii pomiaru produktywności. Np. w języku C czy Pascalu pojedyncza linia programu zawiera

27

□ m eto d a S L IM (ang. Software Lifecycle M anagement)2 oparta na licznie LKZ;

□ m eto d a COCOMO (ang. C onstructive COst M O d elft oparta na liczbie poleceń.

Podstaw ą wyżej wymienionych metod są następujące założenia:

> wielkość kosztów projektowania jest równoznaczna wielkości kosztów budowy oprogramowania;

> wielkość kosztów oprogramowania zależy od wielkości oprogramowania, którą mierzy się liczbą LKZ lub liczbą poleceń, a zatem rozmiar produktu uzależniony będzie przede wszystkim od rodzaju użytego języka programowania, który w ten sposób wpływa na koszty budowy oprogramowania;

> nakłady pracy ludzkiej, które mierzy się w osobo-jednostkach, stanow ią zasadniczy czynnik determinujący poziom kosztów oprogramowania;

> środki materialne wykorzystywane przy tworzeniu oprogramowania, główne sprzęt komputerowy, który wyznacza jednocześnie warunki technologiczne realizacji oprogramowania, determ inują zaangażowanie pracy ludzkiej.

Jednostki programowe stanow ią miarę naturalną i łatw ą w zastosowaniu.

Zasadnicze znaczenie m ają jednak ich wady. Podstawowe to:

•Z Zupełna dowolność w definiowaniu tych jednostek: różnice między dwoma ekstremalnymi metodami obliczania liczby LKZ, tzn. między definicją linii kodu a określeniem linii kodu, jako tylko tych linii, które są wykonywane, są ja k 2:1.

■Z Zależność od wykorzystywanego języka programowania: nie dają zatem możliwości porównania aplikacji napisanych w różnych językach.

Z Preferowanie aplikacji o nadmiarowych rozmiarach w zestawieniu z aplikacjami zwięzłymi oraz ignorowanie różnic między językam i programowania: różnice między językam i wyższego rzędu a językam i symbolicznymi są oczywiste - jednostki programowe preferują programistów piszących w językach symbolicznych. Pomija się również różnice między językam i tego samego poziomu. Na przykład COBOL w porównaniu z PL/1 jest językiem bardziej opisowym z rozbudow aną składnią i daje więcej linii kodu źródłowego.

■S Zbyt późno dostarczają informacji o wielkości SI: wprawdzie niektóre z metod opartych na jednostkach programowych można stosować ju ż na etapie wczesnych prac projektowych, ale błąd szacunku wówczas występujący jest zwykle przyczyną dyskwalifikacji tych metod i nie może stanowić podstawy do podjęcia decyzji inwestycyjnej.

się między dwoma kolejnymi naciśnięciami klawisza [ENTER], na-nią może składać się kilka poleceń oddzielonych od siebie średnikiem.

2 Por. [PUTN92],

3 Por. np. [KNÓL91]. Obecnie metoda COCOMO funkcjonuje w wersji II, uwzględniającej oprócz jednostek programowych również jednostki umowne (punkty obiektowe i funkcyjne).

S O graniczają się jedynie do prac programistycznych: trudno przy ich wykorzystaniu określić wielkość nakładów potrzebnych na cały cykl projektowy, a przecież o kosztach i cenie projektu decydują nakłady całkowite.

^ Ignorują udział użytkownika w procesie projektowania: sytuacja taka zmniejsza prawdopodobieństwo akceptacji systemu przez przyszłych użytkowników oraz sprzyja niewłaściwym decyzjom inwestycyjnym polegającym na zaangażowaniu środków w przedsięwzięcia, które są niezgodne z wymaganiami użytkownika.

•S Stanowią jedynie lokalną miarę, m ającą znaczenie tylko wewnątrz jednostek zajmujących się projektowaniem systemów: miar tych nie można odnieść do jednostek użytkownika, jako że ustalanie wymagań użytkownika co do systemu

w odniesieniu do wielkości programu nie ma sensu.

■S Subiektywność szacunków: różnią się one w zależności od osoby przeprowadzającej analizę i jej doświadczenia w wykorzystaniu określonego języka programowania.

S W reszcie: brak zgodności z ekonomiczną definicją produktywności4.

Jednostki programowe są zatem krytykowane zarówno jeśli chodzi o planowanie, jak i kontrolę działań projektowych. S ą one jednak ciągle wykorzystywane i nierzadko traktowane jako miara podstawowa, m odyfikowana w zależności od innych czynników.

M etody oparte na liczbie linii kodu źródłowego bądź liczbie poleceń zwykle nie odzwierciedlają prawdziwych możliwości systemu informatycznego.

Często bowiem program o znacznie większej liczbie jednostek programowych ma znacznie m niejszą funkcjonalność w zestawieniu z aplikacją o mniejszej liczbie LKZ lub poleceń. Dlatego lepszym podejściem jest ocena operacji, których realizację zapew niają poszczególne programy. Form alną m etodą um ożliw iającą tego typu obliczenia jest metoda punktów funkcyjnych, stanowiących ilościowe wskaźniki możliwości aplikacji komputerowej, oraz oparte na niej warianty.

2 M etody oparte na jedostkach umownych

Do metod opartych na jednostkach umownych zalicza się przede wszystkim:

LU m etodę punktów funkcyjnych (ang. Function Points Method),

LU

Przy czym dwie ostatnie stanow ią najpopularniejsze warianty metody opartej na punktach funkcyjnych.

Jednostki umowne um ożliw iają pomiar i estymację rozmiaru SI z punktu widzenia nie wielkości oprogramowania, a jego użytkowej funkcjonalności.

Stanow ią zatem jednostkę obowiązującą dla wszystkich języków program owania i istotną dla użytkownika systemu. Twórca metody punktów funkcyjnych, Allan

4 Problem ten jest dokładniej przedstawiony w dalszej części artykułu.

29

Albrecht, zdefiniował owe punkty jako “liczbą bezw ym iarow ą którą znajdujemy ja ko efektywną relatywną miarą wartości fu nkcji dostarczanych naszemu

klientowi." (por. [ALBR79]).

Cele metod opartych na jednostkach umownych są następujące:

> Pomiar i estymacja funkcjonalności SI wymaganej przez użytkownika systemu i dostarczonej użytkownikowi;

> Pom iar i estymacja parametrów projektowania i użytkowania SI (wielkość SI, nakładów pracy, produktywności, czasu trwania działań projektowych, itp.) niezależnie od technologii;

> Dostarczenie miary znormalizowanej w ramach projektów i organizacji projektujących, w tym:

S Ocena zrealizowanych projektów pod kątem nakładów pracy, tak aby oceny te można było wykorzystać do szacunków dla przyszłych projektów;

■S Rozpoznanie i przedstawienie trendów produktywności prac projektowych;

■S Kontrolowanie efektywności bieżącej pracy projektantów i sygnalizowanie sytuacji niezgodnych z planem.

2.1 M etoda punktów funkcyjnych - krótka charakterystyka

M etoda punktów funkcyjnych (PF) została stworzona pod koniec lat 70.

przez Allan'a Albrecht'a, pracownika firmy IBM, w celu pomiaru wielkości i wartości systemów informatycznych, jako metoda alternatywna do rozwiązań opartych na jednostkach programowych. Ze względu na swoje założenia oraz uwzględniane czynniki umożliwia ona nie tylko kontrolę, ale i planowanie projektów, zmniejszając tym samym problemy wynikające z zarządzania działaniami projektowymi. M etoda ta charakteryzuje się bowiem stosunkowo dużą niezawodnością, czego dowodzi praktyka, dzięki niej projekty SI m ogą być opisywane w kategoriach ilościowych, a zarządzający m ogą wykorzystywać odpowiednie narzędzia do wzrostu produktywności i jakości pracy zespołów projektowych. M iara ta pomaga bowiem wykrywać nieprawidłow e działania i je eliminować.

GRANICE ____

ł FUNKCJE UŻYTKOWNIKA

TYPY