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
Metodyka wytwarzania oprogramowania

O tym, że systemy się rozrastają a ich stopień złożoności wzrasta logarytmicznie nie trzeba chyba nikomu tłumaczyć. By budować i więcej

Architektura systemów

Obserwując zmiany na rynku zauważyłem, że rola architektury systemów (architektury oprogramowania) rośnie. Dziś w wielu organizacjach myśli nie tylko a więcej

NATO Architecture Framework

Technik i obszarów, które możemy modelować jest bardzo wiele. Ponadto powstało wiele szablonów, ram, frameworków, które mówią co i jak więcej

MVP, czyli o zwinnym podejściu do zakresu przedsięwzięcia

O MVP słyszy się często wśród analityków. MVP to Minimum Viable Product, czyli minimalnie wykonywalny produkt. Tłumaczenie nie jest doskonałe, więcej

Reklama
MODESTO - licencje Enterprise Architect

Zostaw komentarz

Twój adres email nie zostanie opublikowany. Wymagane pola są oznaczone *

Przewiń do góry