Szacowanie oprogramowania

Estymacja jest oceną ilościową nieznanych parametrów projektu na podstawie zdefiniowanego zakresu prac oraz wiedzy ogólnej o warunkach realizacji projektu. Szacujemy te wielkości, których nie możemy policzyć czy zmierzyć, lub też takie, których pomiar jest bardzo kosztowny lub skomplikowany. Zanim jednak przejdziemy do estymacji pracochłonności warto zastanowić się do czego można wykorzystać otrzymane szacowania.

Wyniki estymacji zwykle wykorzystywane są dwóch podejściach związanych z wytwarzaniem oprogramowania. Pierwszym z nich jest podejście do szacowania całego projektu związane z przygotowaniem kosztorysu i czasem realizacji całego przedsięwzięcia w kontekście przygotowania oferty przetargowej. Klient zwykle przygotowuje wymagania wobec przyszłego systemu informatycznego natomiast dostawcy oprogramowania na podstawie zdefiniowanych wymagań szacują koszty związane ze swoimi ofertami.

Drugie podejście jest związane ze zwinnym (ang. Agile) wytwarzaniem oprogramowania w podejściu iteracyjnym. Tu w kontekście planowania najbliższej iteracji należy wskazać, które wymagania będą przedmiotem prac w najbliższym cyklu wytwórczym. Rola dostawcy oprogramowania skupia się wtedy na zbadaniu w jakim czasie i jakim nakładem pracy daną funkcjonalność przyszłego systemu będzie mógł zrealizować.

Jak się okazuje istnieje wiele metod związanych z estymacją pracochłonności i kosztów związanych z wytwarzaniem systemów informatycznych, są to między innymi:

  • COCOMO II (skrót od ang. COnstructive COst Model)
  • Metoda delficka
  • Metoda linii kodu
  • Metoda punktów funkcyjnych (ang. Function Points Method)
  • Metoda punktów przypadków użycia

W zestawie artykułów opiszę wraz z Markiem Pilskim metodę punktów przypadków użycia (ang. Use Case Points), którą stosuję najczęściej w swoich projektach.

Metoda punktów przypadków użycia (ang. Use Case Points, w skrócie UCP) opracowana w 1993 roku przez Gustava Karnera jest metodą estymacji nakładu pracy oraz kosztów wyprodukowania systemu informatycznego już na etapie zbierania wymagań. Wykorzystuje ona podstawowe elementy techniki obiektowej modelowania systemów informatycznych takie jak aktor i przypadek użycia oraz charakterystykę przyszłego produktu jak i cechy zespołu pracującego nad rozwiązaniem problemu.

Poniższe teksty przedstawiają aspekty teoretyczne i praktyczne tej metody.

Podobne wpisy
Zintegrowane środowisko wytwarzania aplikacji web’owych na platformie .NET

W artykule przedstawiono opis pakietu narzędziowego VS.NET (Microsoft) z Rational XDE (IBM) do wytwarzania aplikacji webowych pracujących w środowisku urządzeń więcej

Rational Software Architect Pierwszy Krok

Technorati Tagi: Rational Software Architect,inżynieria oprogramowania W artykule zaprezentowano jak rozpocząć pracę z i opis elementów tego narzędzia CASE. Środowisko więcej

Wstęp do projektowania aplikacji w Rational Software Architect

Rational Software Architect jest kolejną po Rational Rose i Rational XDE generacją narzędzi wspierających twórców oprogramowania w czasie projektowania. RSA więcej

Rational Unified Process – Wstęp

Rational Unified Process jest zunifikowanym procesem wytwórczym oprogramowania dostarczającym praktycznych wskazówek, wzorców dokumentów i narzędzi, szablonów dokumentów oraz przykładów postępowania więcej

Reklama
MODESTO - licencje Enterprise Architect

Zostaw komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Przewiń do góry