Szacowanie pracochłonności tworzenia oprogramowania

W rozwoju oprogramowania szacowanie nakładu pracy to proces przewidywania najbardziej realistycznego nakładu pracy (wyrażonego w osobogodzinach lub pieniądzach) wymaganego do opracowania lub utrzymania oprogramowania na podstawie niekompletnych, niepewnych i zaszumionych danych wejściowych. Szacunkowe nakłady pracy mogą być wykorzystywane jako dane wejściowe do planów projektów, planów iteracji, budżetów, analiz inwestycyjnych, procesów cenowych i rund przetargowych.

Stan praktyki

Opublikowane badania dotyczące praktyki szacowania sugerują, że szacowanie przez ekspertów jest dominującą strategią przy szacowaniu pracochłonności tworzenia oprogramowania.

Zazwyczaj szacunki nakładów pracy są zbyt optymistyczne i panuje nadmierna pewność co do ich dokładności. Wydaje się, że przekroczenie średniego nakładu pracy wynosi około 30% i nie zmniejsza się w czasie. Aby zapoznać się z przeglądem badań błędów oszacowania nakładu pracy, zob. Jednak pomiar błędu oszacowania jest problematyczny, patrz Ocena dokładności oszacowań . Silną nadmierną pewność co do dokładności oszacowań nakładów pracy ilustruje stwierdzenie, że jeśli specjalista ds. rzeczywisty wysiłek to tylko 60-70%.

Obecnie termin „oszacowanie nakładu pracy” jest używany do określenia różnych pojęć, takich jak najbardziej prawdopodobne wykorzystanie wysiłku (wartość modalna), wysiłek, który odpowiada 50% prawdopodobieństwu nieprzekroczenia (mediana), planowany wysiłek, budżetowy wysiłek lub wysiłek włożony w zaproponowanie oferty lub ceny klientowi. Uważa się, że jest to niefortunne, ponieważ mogą wystąpić problemy z komunikacją, a koncepcje służą różnym celom.

Historia

Badacze i praktycy oprogramowania zajmowali się problemami szacowania pracochłonności w projektach tworzenia oprogramowania co najmniej od lat 60. XX wieku; patrz np. praca Farra i Nelsona.

Większość badań koncentrowała się na budowie formalnych modeli szacowania pracochłonności oprogramowania. Wczesne modele były zazwyczaj oparte na analizie regresji lub wyprowadzone matematycznie z teorii z innych dziedzin. Od tego czasu oceniono wiele podejść do budowania modeli, takich jak podejścia oparte na rozumowaniu opartym na przypadkach , drzewach klasyfikacji i regresji , symulacji , sieciach neuronowych , statystyce bayesowskiej , analizie leksykalnej specyfikacji wymagań, programowaniu genetycznym , programowanie liniowe , ekonomiczne modele produkcji , obliczenia miękkie , modelowanie w logice rozmytej , statystyczne ładowanie początkowe i kombinacje dwóch lub więcej tych modeli. Być może obecnie najbardziej powszechnymi metodami szacowania są parametryczne modele szacowania COCOMO , SEER-SEM i SZCZUPŁA. Opierają się na badaniach estymacyjnych przeprowadzonych w latach 70. i 80. XX wieku i od tego czasu są aktualizowane o nowe dane kalibracyjne, przy czym ostatnią dużą wersją było COCOMO II w roku 2000. Podejścia do szacowania oparte na miarach wielkości opartych na funkcjonalności, np. funkcja points , jest również oparty na badaniach przeprowadzonych w latach 70. i 80. XX wieku, ale został ponownie skalibrowany za pomocą zmodyfikowanych miar wielkości i różnych podejść do liczenia, takich jak punkty przypadków użycia lub punkty obiektów w latach 90.

Podejścia szacunkowe

Istnieje wiele sposobów kategoryzacji podejść do szacowania, patrz na przykład. Kategorie najwyższego poziomu to:

  • Oszacowanie eksperckie: Etap kwantyfikacji, tj. etap, w którym oszacowanie jest tworzone na podstawie procesów oceny.
  • Formalny model estymacji: Etap kwantyfikacji opiera się na procesach mechanicznych, np. użyciu formuły wyprowadzonej z danych historycznych.
  • Szacowanie oparte na kombinacjach: etap kwantyfikacji opiera się na osądzającym i mechanicznym połączeniu szacunków z różnych źródeł.

Poniżej przedstawiono przykłady podejść do szacowania w ramach każdej kategorii.

Podejście szacunkowe Kategoria Przykłady wsparcia wdrażania podejścia szacunkowego
Szacowanie oparte na analogii Formalny model estymacji ANIOŁ, Ważone Punkty Mikrofunkcyjne
oparte na WBS (oddolne). Szacunek eksperta Oprogramowanie do zarządzania projektami , szablony działań specyficznych dla firmy
Modele parametryczne Formalny model estymacji COCOMO , SLIM , SEER-SEM , TruePlanning dla oprogramowania
Modele szacowania oparte na wielkości Formalny model estymacji Analiza punktów funkcyjnych , Analiza przypadków użycia , Punkty przypadków użycia , SSU (Jednostka rozmiaru oprogramowania), Szacowanie na podstawie punktów historii w zwinnym tworzeniu oprogramowania , Punkty obiektowe
Szacowanie grupowe Szacunek eksperta Planowanie pokera , szerokopasmowy delphi
Kombinacja mechaniczna Szacowanie oparte na kombinacjach oszacowania nakładu pracy opartego na analogii i opartego na strukturze podziału pracy
Sądowa kombinacja Szacowanie oparte na kombinacjach Ocena ekspercka oparta na szacunkach z modelu parametrycznego i estymacji grupowej

Wybór podejść estymacyjnych

Dowody na różnice w dokładności szacowania różnych podejść i modeli szacowania sugerują, że nie ma „najlepszego podejścia” i że względna dokładność jednego podejścia lub modelu w porównaniu z innym zależy silnie od kontekstu. Oznacza to, że różne organizacje odnoszą korzyści z różnych metod szacowania. Ustalenia, które mogą wspierać wybór podejścia do szacowania w oparciu o oczekiwaną dokładność podejścia obejmują:

  • Szacowanie ekspertów jest średnio co najmniej tak dokładne, jak szacowanie nakładu pracy oparte na modelu. W szczególności sytuacje o niestabilnych relacjach oraz informacje o dużym znaczeniu nieuwzględnione w modelu mogą sugerować zastosowanie szacunków eksperckich. Zakłada to oczywiście dostępność ekspertów z odpowiednim doświadczeniem.
  • Formalne modele szacowania niedostosowane do kontekstu danej organizacji mogą być bardzo niedokładne. Wykorzystanie własnych danych historycznych jest zatem kluczowe, jeśli nie można mieć pewności, że podstawowe relacje modelu estymacji (np. parametry formuły) są oparte na podobnych kontekstach projektowych.
  • Formalne modele estymacji mogą być szczególnie przydatne w sytuacjach, gdy model jest dostosowany do kontekstu organizacji (albo poprzez wykorzystanie własnych danych historycznych, albo model wywodzi się z podobnych projektów i kontekstów) i prawdopodobne jest, że oszacowania ekspertów będą podlega silnemu myśleniu życzeniowemu.

Najbardziej solidnym odkryciem w wielu dziedzinach prognozowania jest to, że połączenie szacunków z niezależnych źródeł, najlepiej przy zastosowaniu różnych podejść, średnio poprawi dokładność oszacowania.

Ważne jest, aby zdawać sobie sprawę z ograniczeń każdego tradycyjnego podejścia do pomiaru produktywności tworzenia oprogramowania.

Ponadto w procesie selekcji należy wziąć pod uwagę inne czynniki, takie jak łatwość zrozumienia i przekazania wyników podejścia, łatwość stosowania podejścia oraz koszt wprowadzenia podejścia.

Ocena dokładności szacunków

Najpowszechniejszą miarą średniej dokładności estymacji jest MMRE (średnia wielkość błędu względnego), gdzie MRE każdego estymatora definiuje się jako:

MRE = | (rzeczywisty wysiłek) - (szacowany wysiłek) | / (rzeczywisty wysiłek)

Miara ta była krytykowana i istnieje kilka miar alternatywnych, takich jak miary bardziej symetryczne, średnia ważona kwartyli błędów względnych (WMQ) i średnia zmienność od oszacowania (MVFE).

MRE nie jest wiarygodne, jeśli poszczególne elementy są przekrzywione. PRED(25) jest preferowaną miarą dokładności estymacji. PRED(25) mierzy procent przewidywanych wartości, które mieszczą się w granicach 25 procent wartości rzeczywistej.

Wysoki błąd oszacowania nie może być automatycznie interpretowany jako wskaźnik niskiej zdolności oszacowania. Alternatywne, konkurencyjne lub uzupełniające się przyczyny to niska kontrola kosztów projektu, duża złożoność prac rozwojowych i większa dostarczona funkcjonalność niż pierwotnie szacowano. Ramy dla lepszego wykorzystania i interpretacji pomiaru błędu oszacowania są zawarte w.

Kwestie psychologiczne

Istnieje wiele czynników psychologicznych potencjalnie wyjaśniających silną tendencję do zbyt optymistycznych szacunków nakładu pracy, z którymi należy się uporać, aby zwiększyć dokładność szacunków nakładu pracy. Czynniki te są istotne nawet w przypadku korzystania z formalnych modeli estymacji, ponieważ większość danych wejściowych do tych modeli opiera się na osądach. Czynniki, które okazały się ważne, to: myślenie życzeniowe , zakotwiczenie , błąd planowania i dysonans poznawczy . Omówienie tych i innych czynników można znaleźć w pracy Jørgensena i Grimstada.

  • Łatwo oszacować, co wiadomo.
  • Trudno oszacować to, co wiadomo, że jest nieznane. (znane niewiadome)
  • Bardzo trudno jest oszacować to, co nie jest znane jako nieznane. (nieznane niewiadome)

Humor

Chroniczne niedocenianie wysiłków rozwojowych doprowadziło do powstania i popularności wielu humorystycznych porzekadeł, takich jak ironiczne odnoszenie się do zadania jako „małej kwestii programowania ” (kiedy prawdopodobnie wymaga to dużego wysiłku) oraz cytowanie praw dotyczących niedoszacowania:

Pierwsze 90 procent kodu stanowi pierwsze 90 procent czasu programowania. Pozostałe 10 procent kodu stanowi pozostałe 90 procent czasu programowania.

— Tom Cargill, Bell Labs

Prawo Hofstadtera: To zawsze trwa dłużej, niż się spodziewasz, nawet jeśli weźmiesz pod uwagę prawo Hofstadtera.

— Douglas Hofstadter , Gödel, Escher, Bach: Wieczny złoty warkocz

To, co jeden programista może zrobić w miesiąc, dwóch programistów może zrobić w dwa miesiące.

— Freda Brooksa

Porównanie oprogramowania do szacowania rozwoju

Oprogramowanie Zaplanuj kosztorys Oszacowanie kosztów Modele kosztów Wejście Format wyjściowy raportu Obsługiwane języki programowania Platformy Koszt Licencja
REWIC AFCAA Tak Tak REWIC KLOC , czynniki skali, czynniki kosztowe własnościowy, Tekst Każdy DOS Bezpłatny
Własność / Darmowy do publicznej dystrybucji
Widzący oprogramowanie Tak Tak SEER-SEM SLOC , punkty funkcyjne , przypadki użycia, oddolne, obiekt, cechy własne, Excel, Microsoft Project, IBM Rational, Oracle Crystal Ball Każdy Windows, dowolny ( internetowy ) Handlowy Prawnie zastrzeżony
SZCZUPŁY Tak Tak SZCZUPŁY Rozmiar ( SLOC , punkty funkcyjne , przypadki użycia itp.), ograniczenia (rozmiar, czas trwania, wysiłek, personel), czynniki skali, projekty historyczne, trendy historyczne własnościowe, Excel, Microsoft Project, Microsoft PowerPoint, IBM Rational, tekst, HTML Każdy Windows, dowolny ( internetowy ) Handlowy Prawnie zastrzeżony
Prawdziwe planowanie Tak Tak CENA Komponenty, Struktury, Działania, Czynniki kosztowe, Procesy, Funkcjonalny rozmiar oprogramowania (Linie źródłowe kodu (SLOC), Punkty funkcyjne, Punkty konwersji przypadków użycia (UCCP), Predictive Object Points (POP) itp.) Excel, CAD Każdy Okna Handlowy Prawnie zastrzeżony

Zobacz też

Pobrano z „ https://en.wikipedia.org/w/index.php?title=Software_development_effort_estimation&oldid=1136129247 ”