Widziałem w moim miejscu pracy (na uniwersytecie), że większość studentów dokonuje oszacowania oprogramowania kosztu pracy dyplomowej przy użyciu COCOMO . Domyślam się, że ten sposób szacowania kosztów jest nieco stary (daty COCOMO z 1981 r.), Stąd moje pytanie:

How do you estimate costs in your software?

Widziałem takie rzeczy jak:

Koszt = (HoursOfWork + EstimatedIddle) * HourlyRate

Nie tego chcę, szukam właściwie (naukowo) zdefiniowanego modelu kosztów

EDYCJA Znalazłem kilka powiązanych pytań na temat SO:

• Jakie są metody i modele szacowania kosztów oprogramowania?
• Jak szacujesz koszt opracowania wymagań oprogramowania?

Jeśli utkniesz w trybie wodospadu, jedyną dość dokładną metodą, którą zastosowałem, jest:

1. Utwórz strukturę podziału pracy
2. Upewnij się, że jest wystarczająco szczegółowy, abyś mógł powiązać wielkość każdego zadania z czymś, co wcześniej (lub ktoś, z kim możesz porozmawiać).
3. Dla każdego zadania wymyśl najlepsze, najbardziej prawdopodobne i najgorsze liczby na podstawie doświadczenia. Najlepszy przypadek to taki, że wszystko poszło idealnie, najgorszy przypadek to konieczność powtórzenia go (może dwa razy) i prawdopodobnie gdzieś tam jest.
4. Użyj formuły ważenia, takiej jak (1 * najlepsza + 4 * prawdopodobna + 1 * najgorsza) / 6, aby uzyskać oszacowanie dla każdego zadania uwzględniającego zakres.
5. Widziałem także warianty, w których możesz dodać element „ryzyka” do każdego zadania. Trzy poziomy ryzyka to 0, 1 i 2. Ryzyko 0 oznacza, że ​​zrobiłeś to wcześniej (lub coś bardzo bliskiego), 1 oznacza, że ​​nie zrobiłeś tego wcześniej, ale dzieje się to regularnie w twojej branży, 2 oznacza, że ​​prawdopodobnie nigdy wcześniej tego nie robiono w branży. Bierzesz liczbę ryzyka i pomnażasz ją przez przybliżenie „odchylenia standardowego” swojego oszacowania. Dodaj to do swoich ważonych szacunków. Zatem ryzyko 0 nie przenosi go, ale ryzyko 2 przesuwa go dość blisko najgorszego numeru sprawy.
6. Dodaj wszystkie zadania.
7. Dodaj nieprzewidziane okoliczności (niektóre%) dla „nieznanych niewiadomych”.

Skończysz z bardzo dokładną liczbą. Nie twierdzę, że to jest dokładne, ale będzie dokładne.

Dokładność zależy wyłącznie od tego, czy uda się wymyślić numer dla każdego zadania na podstawie przeszłych doświadczeń lub znaleźć kogoś, kto to zrobił wcześniej. Im więcej masz doświadczenia, tym lepsze prognozy.

Kiedy wykonasz projekt, śledź swój czas na każde zadanie i zapisz te, które przegapiłeś, abyś mógł je porównać. Z czasem sprawi to, że poczujesz się lepiej.

Ocena oprogramowania jest niezwykle trudna. Jednym z zastosowanych przeze mnie podejść jest jak najdokładniejsze rozbicie wymagań i oszacowanie każdego elementu osobno. Następnie dodaj „współczynnik krówki”, który może być albo mnożnikiem (podwoić go), albo stałą kwotą (x godzin nieprzewidzianej pracy). Jeśli nie masz dobrego oszacowania wymagań, jest to niemożliwe ze względów praktycznych.

Przemysł wiele się nauczył w ciągu 30 lat od '81. Takie oszacowanie nigdy nie zadziałało. Ponieważ szaleństwo Agile w zasadzie przepisało krajobraz, używamy „punktów fabularnych” reprezentujących mgliste „trudności porównawcze”. Następnie uzyskujemy „prędkość”, dzięki czemu zarozumiałe gnójki mogą dokonywać oszacowań $$ z pewną ilością danych empirycznych.

Nauczyłem się kilku „rygorystycznych” podejść, takich jak szacunki punktów funkcyjnych i niektóre ich odmiany, które zostały zaprojektowane do nowoczesnych zastosowań. Myślę, że część tych podejść, która jest cenna, polega na tym, że wymusza bardziej szczegółową analizę znanych wymagań, niż mogłabym je podać.

Uzyskanie dobrego zestawu danych do pracy jest bardzo trudne, nawet jeśli masz dobry model. Pomiar wydajności jest trudny. Ludzie grają prawie każdą metryką.

Przestałem go używać, ponieważ moja organizacja jest zbyt dysfunkcjonalna, aby korzystać z oszacowań oprogramowania, ale mam pewien szacunek dla grupy Cost Xpert i jej narzędzia; ale jest to bardzo drogie i prawdopodobnie nie warte kosztów i krzywej uczenia się w zdecydowanej większości organizacji.

Bardzo trudno jest oszacować wysiłki i koszty, ale jeśli chcesz czegoś bardziej precyzyjnego, to:

• podzielić HoursOfWork na 3 części:

  1. najlepsze oszacowanie,
  2. najprawdopodobniej szacunek,
  3. gorsze oszacowanie.

• usuń EstimatedIddle.

Zwróć uwagę, że wszystko, co trwa dłużej niż 8 godzin, spowoduje ogromny błąd.

Zwykle dzielimy pełny zakres pracy na główne moduły / elementy, które można by uznać za podprojekt. Innymi słowy, są to części robocze, które klient uważa za oddzielne części projektu i które klient chce uzyskać osobno.

Po zakończeniu dzielimy każdy moduł na zadania, podzadania, a nawet mniejsze podzadania, aby każdy z nich można było dość łatwo oszacować, a oszacowanie zajmie od jednej do dziesięciu roboczogodzin. W ten sposób otrzymujemy szczegółowy podział zakresu prac dla projektu.

Ostatnim krokiem jest rozdzielenie zadań między kamienie milowe. Robimy to w taki sposób, aby po każdym kamienia milowym klient uzyskał widoczne wyniki. Pomaga to przejść jeden kamień milowy i przejść do następnego. W końcu otrzymujemy coś takiego:

Moduł 1

    <ol>
        <li>
            Primary task 1 - 5 hrs
            <ol>
                <li>Subtask 1.1 – 3 hrs</li>
                <li>Subtask 1.2 – 2 hrs</li>
            </ol>
        </li>
        <li>
            Primary task 2 - 9 hrs
            <ol>
                <li>Subtask 2.1 – 1 hrs</li>
                <li>Subtask 2.2 – 2 hrs</li>
                 <li>Subtask 2.2 – 5 hrs</li>
            </ol>

Początkowo zrobiliśmy to za pomocą arkusza programu Excel. Ale ponad dwa lata temu zaczęliśmy do tego używać oprogramowania. Istnieje kilka podobnych produktów, które pomagają w tym www.evenflow.com , www.swproposal.com i kilka innych. Nie pamiętam wszystkich list. Przeprowadziliśmy badania dawno temu. Mam nadzieję, że to może pomóc.

Dobre pytanie brzmi: jak dokładnie oszacować. Według nas nie ma 100% poprawnych szacunków. Jedynym sposobem jest podzielenie pełnego zakresu pracy na możliwie najmniejsze zadania. Im mniejsze zadania, tym bardziej szczegółowy przegląd i analiza wykonywanego projektu. Tak więc i tak zwiększa dokładność.