Techniki szacowania - szybki przewodnik

Estimation to proces znajdowania oszacowania lub przybliżenia, czyli wartości, której można użyć do jakiegoś celu, nawet jeśli dane wejściowe mogą być niekompletne, niepewne lub niestabilne.

Oszacowanie określa, ile pieniędzy, wysiłku, zasobów i czasu zajmie zbudowanie określonego systemu lub produktu. Szacunek opiera się na -

  • Wcześniejsze dane / wcześniejsze doświadczenia
  • Dostępne dokumenty / wiedza
  • Assumptions
  • Zidentyfikowane ryzyka

Cztery podstawowe kroki szacowania projektu oprogramowania to:

  • Oszacuj rozmiar produktu deweloperskiego.
  • Oszacuj wysiłek w osobo-miesiącach lub osobogodzinach.
  • Oszacuj harmonogram w miesiącach kalendarzowych.
  • Oszacuj koszt projektu w uzgodnionej walucie.

Uwagi dotyczące szacowania

  • Szacowanie nie musi być jednorazowym zadaniem w projekcie. Może to mieć miejsce podczas -

    • Zdobycie projektu.
    • Planowanie projektu.
    • Realizacja Projektu w miarę potrzeb.

  • Zakres projektu należy zrozumieć przed rozpoczęciem procesu szacowania. Pomocne będzie posiadanie historycznych danych projektu.

  • Metryki projektu mogą zapewnić perspektywę historyczną i cenny wkład do generowania szacunków ilościowych.

  • Planowanie wymaga od kierowników technicznych i zespołu ds. Oprogramowania podjęcia początkowego zobowiązania, ponieważ prowadzi to do odpowiedzialności i rozliczalności.

  • Przeszłe doświadczenia mogą bardzo pomóc.

  • Użyj co najmniej dwóch technik szacowania, aby uzyskać szacunki i uzgodnić otrzymane wartości. Zapoznaj się z Technikami dekompozycji w następnej sekcji, aby dowiedzieć się więcej o uzgadnianiu szacunków.

  • Plany powinny być iteracyjne i umożliwiać dostosowywanie w miarę upływu czasu i poznawania większej liczby szczegółów.

Ogólne podejście do szacowania projektu

Powszechnie stosowaną metodą szacowania projektu jest Decomposition Technique. Techniki dekompozycji przyjmują podejście dziel i zwyciężaj. Szacowanie rozmiaru, nakładu pracy i kosztów jest wykonywane w sposób stopniowy, poprzez rozbicie projektu na główne funkcje lub powiązane działania inżynierii oprogramowania.

Step 1 - Zrozum zakres oprogramowania, które ma zostać zbudowane.

Step 2 - Wygeneruj oszacowanie rozmiaru oprogramowania.

  • Zacznij od określenia zakresu.

  • Podziel oprogramowanie na funkcje, które można oszacować indywidualnie.

  • Oblicz rozmiar każdej funkcji.

  • Uzyskaj oszacowanie nakładu pracy i kosztów, stosując wartości rozmiaru do podstawowych wskaźników wydajności.

  • Połącz oszacowania funkcji, aby uzyskać ogólne oszacowanie dla całego projektu.

Step 3- Wygeneruj oszacowanie nakładu pracy i kosztów. Możesz oszacować nakłady pracy i koszty, dzieląc projekt na powiązane działania związane z inżynierią oprogramowania.

  • Zidentyfikuj sekwencję czynności, które należy wykonać, aby projekt został ukończony.

  • Podziel czynności na zadania, które można zmierzyć.

  • Oszacuj wysiłek (w osobogodzinach / dniach) wymagany do wykonania każdego zadania.

  • Połącz oszacowania nakładu pracy związane z zadaniami czynności, aby uzyskać oszacowanie czynności.

  • Uzyskaj jednostki kosztów (tj. Koszt / nakład pracy) dla każdego działania z bazy danych.

  • Oblicz całkowity wysiłek i koszt dla każdego działania.

  • Połącz nakłady pracy i szacunki kosztów dla każdego działania, aby uzyskać ogólny nakład pracy i oszacowanie kosztów dla całego projektu.

Step 4- Uzgodnij oszacowania: porównaj wartości otrzymane z kroku 3 z wartościami uzyskanymi w kroku 2. Jeśli oba zestawy oszacowań są zgodne, twoje liczby są wysoce wiarygodne. W przeciwnym razie, jeśli wystąpią bardzo rozbieżne szacunki, należy przeprowadzić dalsze badanie, czy -

  • Zakres projektu nie został odpowiednio zrozumiany lub został źle zinterpretowany.

  • Podział funkcji i / lub działalności nie jest dokładny.

  • Dane historyczne użyte w technikach szacowania są nieodpowiednie dla aplikacji, przestarzałe lub zostały nieprawidłowo zastosowane.

Step 5 - Określić przyczynę rozbieżności, a następnie uzgodnić szacunki.

Dokładność szacowania

Dokładność wskazuje, jak blisko jest coś do rzeczywistości. Za każdym razem, gdy generujesz szacunki, każdy chce wiedzieć, jak bliskie są rzeczywistości. Będziesz chciał, aby każde oszacowanie było jak najbardziej dokładne, biorąc pod uwagę dane, które posiadasz w momencie ich generowania. I oczywiście nie chcesz przedstawiać szacunków w sposób, który wzbudza fałszywe poczucie zaufania do liczb.

Ważnymi czynnikami wpływającymi na dokładność szacunków są:

  • Dokładność wszystkich danych wejściowych oszacowania.

  • Dokładność wszelkich obliczeń szacunkowych.

  • Jak bardzo dane historyczne lub dane branżowe użyte do kalibracji modelu są zgodne z szacowanym projektem.

  • Przewidywalność procesu tworzenia oprogramowania w Twojej organizacji.

  • Stabilność zarówno wymagań produktu, jak i środowiska wspierającego wysiłki inżynieryjne oprogramowania.

  • Czy rzeczywisty projekt był dokładnie zaplanowany, monitorowany i kontrolowany oraz czy nie wystąpiły żadne większe niespodzianki, które spowodowały nieoczekiwane opóźnienia.

Oto kilka wskazówek, jak uzyskać wiarygodne szacunki -

  • Szacunki bazowe na podobnych projektach, które zostały już zakończone.
  • Użyj stosunkowo prostych technik dekompozycji, aby wygenerować szacunkowe koszty projektu i nakład pracy.
  • Użyj jednego lub więcej empirycznych modeli szacowania do oszacowania kosztów oprogramowania i nakładu pracy.

Zapoznaj się z częścią dotyczącą Wytycznych szacowania w tym rozdziale.

Aby zapewnić dokładność, zawsze zaleca się oszacowanie przy użyciu co najmniej dwóch technik i porównanie wyników.

Problemy z szacowaniem

Często kierownicy projektów uciekają się do szacowania harmonogramów, pomijając szacowanie wielkości. Może to być spowodowane harmonogramami określonymi przez najwyższe kierownictwo lub zespół marketingowy. Jednak bez względu na przyczynę, jeśli zostanie to zrobione, na późniejszym etapie trudno byłoby oszacować harmonogramy, aby uwzględnić zmiany zakresu.

Przy szacowaniu można przyjąć pewne założenia. Ważne jest, aby zanotować wszystkie te założenia w arkuszu kosztorysów, ponieważ niektóre nadal nie dokumentują założeń w arkuszach szacunków.

Nawet dobre szacunki mają nieodłączne założenia, ryzyko i niepewność, a mimo to często są traktowane tak, jakby były dokładne.

Najlepszym sposobem wyrażenia szacunków jest szereg możliwych wyników, mówiąc na przykład, że projekt zajmie od 5 do 7 miesięcy, zamiast stwierdzać, że zostanie ukończony w określonym terminie lub zakończy się w ustalonym nr. miesięcy. Uważaj na zobowiązanie się do zakresu, który jest zbyt wąski, ponieważ jest to równoważne zobowiązaniu się do określonej daty.

  • Możesz również uwzględnić niepewność jako towarzyszącą wartość prawdopodobieństwa. Na przykład istnieje 90% prawdopodobieństwo, że projekt zakończy się w określonym terminie lub wcześniej.

  • Organizacje nie gromadzą dokładnych danych dotyczących projektów. Ponieważ dokładność szacunków zależy od danych historycznych, byłoby to problemem.

  • Dla każdego projektu istnieje najkrótszy możliwy harmonogram, który pozwoli Ci uwzględnić wymaganą funkcjonalność i uzyskać wysokiej jakości wydruki. Jeśli kierownictwo i / lub klient mają ograniczenia dotyczące harmonogramu, można negocjować zakres i funkcjonalność, która ma być dostarczona.

  • Uzgodnij z klientem sposób postępowania ze zmianami zakresu, aby uniknąć przekroczenia harmonogramu.

  • Brak uwzględnienia nieprzewidzianych okoliczności w ostatecznym oszacowaniu powoduje problemy. Na przykład spotkania, imprezy organizacyjne.

  • Wykorzystanie zasobów należy uznać za mniej niż 80%. Dzieje się tak, ponieważ zasoby byłyby produktywne tylko przez 80% ich czasu. Jeśli przydzielisz zasoby z wykorzystaniem ponad 80%, z pewnością wystąpią odchylenia.

Wytyczne dotyczące szacowania

Przy wycenie projektu należy mieć na uwadze następujące wskazówki -

  • Podczas szacowania zapytaj o doświadczenia innych ludzi. Wykorzystaj też swoje własne doświadczenia.

  • Załóżmy, że zasoby będą produktywne tylko przez 80 procent swojego czasu. Dlatego podczas szacowania należy przyjąć wykorzystanie zasobów na mniej niż 80%.

  • Zasoby pracujące nad wieloma projektami zajmują więcej czasu na wykonanie zadań ze względu na stracony czas na przełączanie się między nimi.

  • Uwzględnij czas zarządzania w każdym oszacowaniu.

  • Zawsze buduj zdolności do rozwiązywania problemów, spotkań i innych nieoczekiwanych wydarzeń.

  • Daj wystarczająco dużo czasu na oszacowanie projektu. Przyspieszone szacunki są niedokładne i wiążą się z wysokim ryzykiem. W przypadku dużych projektów deweloperskich etap szacowania należy naprawdę traktować jako mini projekt.

  • Tam, gdzie to możliwe, korzystaj z udokumentowanych danych z podobnych poprzednich projektów organizacji. Daje to najdokładniejsze oszacowanie. Jeśli Twoja organizacja nie przechowuje danych historycznych, teraz jest dobry moment, aby zacząć je gromadzić.

  • Skorzystaj z szacunków deweloperskich, ponieważ szacunki przygotowane przez osoby inne niż te, które wykonają pracę, będą mniej dokładne.

  • Skorzystaj z pomocy kilku różnych osób, aby oszacować i zastosować kilka różnych technik szacowania.

  • Uzgodnij szacunki. Obserwuj zbieżność lub rozrzut między szacunkami. Konwergencja oznacza, że ​​masz dobre oszacowanie. Technikę Wideband Delphi można wykorzystać do zbierania i omawiania szacunków z wykorzystaniem grupy osób, mając na celu uzyskanie dokładnych, obiektywnych szacunków.

  • Ponownie oszacuj projekt kilka razy w trakcie jego cyklu życia.

ZA Function Point(FP) to jednostka miary wyrażająca ilość funkcjonalności biznesowej, jaką system informacyjny (jako produkt) zapewnia użytkownikowi. FP mierzą rozmiar oprogramowania. Są powszechnie akceptowane jako standard branżowy w zakresie wymiarowania funkcjonalnego.

W przypadku oprogramowania do wymiarowania opartego na FP powstało kilka uznanych norm i / lub specyfikacji publicznych. Od 2013 r. Są to -

Normy ISO

  • COSMIC- ISO / IEC 19761: 2011 Inżynieria oprogramowania. Funkcjonalna metoda pomiaru rozmiaru.

  • FiSMA - ISO / IEC 29881: 2008 Technologia informacyjna - Inżynieria oprogramowania i systemów - Metoda pomiaru rozmiaru funkcjonalnego FiSMA 1.1.

  • IFPUG - ISO / IEC 20926: 2009 Inżynieria oprogramowania i systemów - Pomiar oprogramowania - Metoda pomiaru rozmiaru funkcjonalnego IFPUG.

  • Mark-II - ISO / IEC 20968: 2002 Inżynieria oprogramowania - Analiza punktów funkcyjnych Ml II - Podręcznik praktyk liczenia.

  • NESMA - ISO / IEC 24570: 2005 Inżynieria oprogramowania - Metoda pomiaru rozmiaru funkcji NESMA wersja 2.1 - Definicje i wytyczne dotyczące liczenia w zastosowaniu analizy punktów funkcyjnych.

Specyfikacja grupy zarządzania obiektami dla zautomatyzowanego punktu funkcyjnego

Object Management Group (OMG), otwarte członkostwo i non-profit konsorcjum standardów branży komputerowej, przyjęło specyfikację Automated Function Point (AFP), której przewodzi Consortium for IT Software Quality. Zapewnia standard automatyzacji liczenia FP zgodnie z wytycznymi International Function Point User Group (IFPUG).

Function Point Analysis (FPA) techniqueokreśla ilościowo funkcje zawarte w oprogramowaniu w kategoriach, które są zrozumiałe dla użytkowników oprogramowania. W PR uwzględniają liczbę funkcji opracowywanych na podstawie specyfikacji wymagań.

Function Points (FP) Countingpodlega standardowemu zestawowi reguł, procesów i wytycznych określonych przez International Function Point Users Group (IFPUG). Są one opublikowane w Podręczniku praktyk liczenia (CPM).

Historia analizy punktów funkcyjnych

Pojęcie punktów funkcyjnych zostało wprowadzone przez Alana Albrechta z IBM w 1979 r. W 1984 r. Albrecht udoskonalił metodę. Pierwsze wytyczne dotyczące punktów funkcyjnych zostały opublikowane w 1984 r. Międzynarodowa Grupa Użytkowników Punktów Funkcyjnych (IFPUG) jest ogólnoświatową organizacją z siedzibą w USA, zrzeszającą użytkowników oprogramowania metrycznego do analizy punktów funkcyjnych. PlikInternational Function Point Users Group (IFPUG)jest organizacją non-profit, zarządzaną przez członków, założoną w 1986 r. IFPUG jest właścicielem analizy punktów funkcyjnych (FPA), zgodnie z definicją normy ISO 20296: 2009, która określa definicje, zasady i etapy stosowania metody pomiaru rozmiaru funkcjonalnego IFPUG (FSM). IFPUG prowadzi Podręcznik praktyk liczenia punktów funkcyjnych (CPM). CPM 2.0 został wydany w 1987 roku i od tego czasu wykonano kilka iteracji. Wersja CPM 4.3 była w 2010 roku.

Wersja CPM 4.3.1 z wprowadzonymi poprawkami redakcyjnymi ISO została wydana w 2010 roku. Norma ISO (IFPUG FSM) - Pomiar rozmiaru funkcjonalnego, będąca częścią CPM 4.3.1, jest techniką pomiaru oprogramowania pod kątem funkcjonalności, które zapewnia. CPM to międzynarodowy standard zgodny z normą ISO / IEC 14143-1 Information Technology - Software Measurement.

Proces elementarny (EP)

Proces podstawowy to najmniejsza jednostka wymagań funkcjonalnych użytkownika, która -

  • Ma znaczenie dla użytkownika.
  • Stanowi pełną transakcję.
  • Jest samowystarczalny i powoduje, że aplikacja jest liczona w spójnym stanie.

Funkcje

Istnieją dwa rodzaje funkcji -

  • Funkcje danych
  • Funkcje transakcyjne

Funkcje danych

Istnieją dwa typy funkcji danych -

  • Wewnętrzne pliki logiczne
  • Pliki interfejsu zewnętrznego

Funkcje danych składają się z zasobów wewnętrznych i zewnętrznych, które mają wpływ na system.

Internal Logical Files

Wewnętrzny plik logiczny (ILF) to możliwa do zidentyfikowania przez użytkownika grupa logicznie powiązanych danych lub informacji sterujących, która znajduje się całkowicie w granicach aplikacji. Podstawowym celem ILF jest przechowywanie danych przechowywanych przez jeden lub więcej podstawowych procesów liczonej aplikacji. ILF ma nieodłączne znaczenie, że jest wewnętrznie utrzymywany, ma pewną logiczną strukturę i jest przechowywany w pliku. (Patrz rysunek 1)

External Interface Files

Plik interfejsu zewnętrznego (EIF) to możliwa do zidentyfikowania przez użytkownika grupa danych logicznych lub informacji sterujących, która jest używana przez aplikację wyłącznie w celach informacyjnych. Dane znajdują się całkowicie poza granicami aplikacji i są utrzymywane w ILF przez inną aplikację. EFI nieodłącznie oznacza, że ​​jest utrzymywany na zewnątrz, należy opracować interfejs, aby uzyskać dane z pliku. (Patrz rysunek 1)

Funkcje transakcyjne

Istnieją trzy typy funkcji transakcyjnych.

  • Wejścia zewnętrzne
  • Wyjścia zewnętrzne
  • Zapytania zewnętrzne

Funkcje transakcyjne składają się z procesów, które są wymieniane między użytkownikiem, aplikacjami zewnętrznymi i mierzoną aplikacją.

External Inputs

Wejście zewnętrzne (EI) to funkcja transakcyjna, w której Dane trafiają „do” aplikacji z zewnątrz do wewnątrz. Te dane pochodzą z zewnątrz aplikacji.

  • Dane mogą pochodzić z ekranu wprowadzania danych lub innej aplikacji.
  • EI to sposób, w jaki aplikacja uzyskuje informacje.
  • Dane mogą być informacjami kontrolnymi lub informacjami biznesowymi.
  • Dane mogą być wykorzystywane do utrzymywania jednego lub większej liczby wewnętrznych plików logicznych.
  • Jeśli dane są informacjami sterującymi, nie ma potrzeby aktualizowania wewnętrznego pliku logicznego. (Patrz rysunek 1)

External Outputs

Wyjście zewnętrzne (EO) to funkcja transakcyjna, w której dane wychodzą „na zewnątrz” systemu. Ponadto EO może aktualizować ILF. Dane tworzą raporty lub pliki wyjściowe wysyłane do innych aplikacji. (Patrz rysunek 1)

External Inquiries

Zapytanie zewnętrzne (EQ) to funkcja transakcyjna zawierająca zarówno komponenty wejściowe, jak i wyjściowe, które powodują pobranie danych. (Patrz rysunek 1)

Definicja RET, DET, FTR

Typ elementu rekordu

Typ elementu rekordu (RET) to największa możliwa do zidentyfikowania przez użytkownika podgrupa elementów w ramach ILF lub EFI. Najlepiej przyjrzeć się logicznym grupom danych, aby pomóc je zidentyfikować.

Typ elementu danych

Typ elementu danych (DET) to podgrupa danych w ramach FTR. Są unikalne i możliwe do zidentyfikowania przez użytkownika.

Odniesienie do typu pliku

Odwołanie do typu pliku (FTR) to największa możliwa do zidentyfikowania przez użytkownika podgrupa w ramach EI, EO lub EQ, do których się odnosi.

Funkcje transakcyjne EI, EO, EQ są mierzone poprzez zliczanie FTR i DET, które zawierają zgodnie z regułami liczenia. Podobnie funkcje danych ILF i EIF są mierzone przez zliczanie DET i RET, które zawierają następujące reguły liczenia. Miary funkcji transakcyjnych i funkcji danych są używane w zliczaniu FP, co daje w wyniku rozmiar funkcjonalny lub punkty funkcyjne.

Proces liczenia FP obejmuje następujące kroki -

  • Step 1 - Określić rodzaj liczenia.

  • Step 2 - Określ granicę zliczania.

  • Step 3 - Zidentyfikuj każdy proces elementarny (EP) wymagany przez użytkownika.

  • Step 4 - Określ unikalne EP.

  • Step 5 - Funkcje danych pomiarowych.

  • Step 6 - Pomiar funkcji transakcyjnych.

  • Step 7 - Oblicz rozmiar funkcjonalny (nieskorygowana liczba punktów funkcji).

  • Step 8 - Określić współczynnik korekty wartości (VAF).

  • Step 9 - Oblicz skorygowaną liczbę punktów funkcyjnych.

Note- Ogólna charakterystyka systemu (GSC) jest opcjonalna w CPM 4.3.1 i przeniesiona do dodatku. W związku z tym krok 8 i krok 9 można pominąć.

Krok 1: Określ typ liczenia

Istnieją trzy rodzaje zliczania punktów funkcyjnych -

  • Liczba punktów funkcji rozwoju
  • Liczba punktów funkcji aplikacji
  • Liczba punktów funkcji wzmocnienia

Liczba punktów funkcji rozwoju

Punkty funkcyjne można zliczać na wszystkich etapach projektu deweloperskiego od etapu wymagania do etapu wdrożenia. Ten rodzaj liczenia jest związany z nowymi pracami rozwojowymi i może obejmować prototypy, które mogły być wymagane jako rozwiązanie tymczasowe, wspierające wysiłek związany z konwersją. Ten typ liczenia nazywany jest liczbą punktów funkcji linii bazowej.

Liczba punktów funkcji aplikacji

Liczby aplikacji są obliczane na podstawie dostarczonych punktów funkcyjnych i wykluczają wszelkie wysiłki związane z konwersją (prototypy lub rozwiązania tymczasowe) oraz istniejące funkcje, które mogły istnieć.

Liczba punktów funkcji wzmocnienia

Zmiany wprowadzone w oprogramowaniu po produkcji są traktowane jako udoskonalenia. Aby określić rozmiar takich projektów ulepszeń, liczba punktów funkcji zostanie dodana, zmieniona lub usunięta w aplikacji.

Krok 2: Określ granicę liczenia

Granica wskazuje granicę między mierzoną aplikacją a aplikacjami zewnętrznymi lub domeną użytkownika. (Patrz rysunek 1)

Aby określić granicę, zrozum -

  • Cel liczenia punktów funkcji
  • Zakres mierzonego zastosowania
  • Jak i które aplikacje przechowują dane
  • Obszary biznesowe obsługujące aplikacje

Krok 3: Zidentyfikuj każdy elementarny proces wymagany przez użytkownika

Skomponuj i / lub rozłóż wymagania funkcjonalne użytkownika na najmniejszą jednostkę czynności, która spełnia wszystkie poniższe kryteria -

  • Ma znaczenie dla użytkownika.
  • Stanowi pełną transakcję.
  • Jest samowystarczalny.
  • Pozostawia liczenie aplikacji w spójnym stanie.

Na przykład wymóg użytkownika funkcjonalnego - „Utrzymaj informacje o pracowniku” można rozłożyć na mniejsze czynności, takie jak dodanie pracownika, zmiana pracownika, usunięcie pracownika i zapytania o pracownika.

Każda zidentyfikowana w ten sposób jednostka działalności jest procesem elementarnym (EP).

Krok 4: Określ unikalne podstawowe procesy

Porównując dwa już zidentyfikowane EP, policz je jako jeden PE (ten sam PE), jeśli -

  • Wymagają tego samego zestawu DET.
  • Wymagaj tego samego zestawu stawek FTR.
  • Wymagają tego samego zestawu logiki przetwarzania, aby ukończyć EP.

Nie dziel EP z wieloma formami logiki przetwarzania na wiele EPS.

Na przykład, jeśli zidentyfikowałeś „Dodaj pracownika” jako PE, nie należy go dzielić na dwa PE, aby uwzględnić fakt, że pracownik może mieć lub nie mieć na utrzymaniu osób na utrzymaniu. PE wciąż jest „Dodaj pracownika” i istnieje zróżnicowanie w logice przetwarzania i DET uwzględniających osoby pozostające na utrzymaniu.

Krok 5: Pomiar funkcji danych

Sklasyfikuj każdą funkcję danych jako ILF lub EIF.

Funkcję danych klasyfikuje się jako -

  • Wewnętrzny plik logiczny (ILF), jeśli jest utrzymywany przez mierzoną aplikację.

  • Plik interfejsu zewnętrznego (EIF), jeśli odwołuje się do niego, ale nie jest obsługiwany przez mierzoną aplikację.

ILF i EFI mogą zawierać dane biznesowe, dane kontrolne i dane oparte na regułach. Na przykład przełączanie telefoniczne obejmuje wszystkie trzy typy - dane biznesowe, dane reguł i dane sterujące. Dane biznesowe to faktyczna rozmowa. Dane reguł określają sposób, w jaki połączenie powinno być kierowane przez sieć, a dane sterujące to sposób, w jaki przełączniki komunikują się ze sobą.

Rozważ następującą dokumentację dotyczącą liczenia ILF i EFI -

  • Cele i ograniczenia proponowanego systemu.
  • Dokumentacja dotycząca obecnego systemu, jeśli taki system istnieje.
  • Dokumentacja postrzeganych celów, problemów i potrzeb użytkowników.
  • Modele danych.

Krok 5.1: Policz DET dla każdej funkcji danych

Zastosuj następujące zasady do liczenia DET dla ILF / EIF -

  • Policz DET dla każdego niepowtarzalnego pola identyfikowalnego przez użytkownika, niepowtarzalnego pola utrzymywanego w ILF lub EIF lub pobranego z niego w drodze wykonania EP.

  • Policz tylko te DET używane przez aplikację, które są mierzone, gdy dwie lub więcej aplikacji utrzymuje tę samą funkcję danych i / lub odwołuje się do niej.

  • Policz DET dla każdego atrybutu wymaganego przez użytkownika do ustanowienia relacji z innym ILF lub EIF.

  • Przejrzyj powiązane atrybuty, aby określić, czy są one zgrupowane i liczone jako jeden DET, czy też są liczone jako wiele DET. Grupowanie będzie zależeć od tego, w jaki sposób PE wykorzystują atrybuty w aplikacji.

Krok 5.2: Policz RET dla każdej funkcji danych

Zastosuj następujące zasady do liczenia RET dla ILF / EIF -

  • Policz jeden RET dla każdej funkcji danych.
  • Policz jeden dodatkowy RET dla każdej z następujących dodatkowych logicznych podgrup DET.
    • Jednostka skojarzona z atrybutami niebędącymi kluczami.
    • Podtyp (inny niż pierwszy podtyp).
    • Podmiot atrybutywny w relacji innej niż obowiązkowa 1: 1.

Krok 5.3: Określ złożoność funkcjonalną dla każdej funkcji danych

RETS Typy elementów danych (DET)
1-19 20-50 >50
1 L L ZA
2 do 5 L ZA H.
> 5 ZA H. H.

Złożoność funkcjonalna: L = Niski; A = Średnia; H = Wysoki

Krok 5.4: Zmierz rozmiar funkcjonalny dla każdej funkcji danych

Złożoność funkcjonalna Liczba FP dla ILF Liczba PR dla EFI
Niska 7 5
Średni 10 7
Wysoki 15 10

Krok 6: Zmierz funkcje transakcyjne

Aby zmierzyć funkcje transakcyjne, wykonaj następujące kroki:

Krok 6.1: Sklasyfikuj każdą funkcję transakcyjną

Funkcje transakcyjne należy sklasyfikować jako wejście zewnętrzne, wyjście zewnętrzne lub zapytanie zewnętrzne.

Wejście zewnętrzne

Wejście zewnętrzne (EI) to elementarny proces, który przetwarza dane lub kontroluje informacje pochodzące spoza granicy. Podstawowym celem EI jest utrzymanie jednego lub więcej ILF i / lub zmiana zachowania systemu.

Należy zastosować wszystkie poniższe zasady -

  • Dane lub informacje sterujące są odbierane spoza granic aplikacji.

  • Przynajmniej jeden ILF jest utrzymywany, jeśli dane wchodzące do granicy nie są informacją kontrolną, która zmienia zachowanie systemu.

  • W przypadku wskazanego PE musi mieć zastosowanie jedno z trzech stwierdzeń:

    • Logika przetwarzania jest unikalna w porównaniu z logiką przetwarzania wykonywaną przez inne EI dla aplikacji.

    • Zbiór zidentyfikowanych elementów danych różni się od zbiorów określonych dla innych EI we wniosku.

    • Odwołania do plików ILF lub EIF różnią się od plików, do których odwołują się inne EI w aplikacji.

Wyjście zewnętrzne

Wyjście zewnętrzne (EO) to elementarny proces, który wysyła dane lub informacje sterujące poza granice aplikacji. EO obejmuje dodatkowe przetwarzanie poza zapytaniem zewnętrznym.

Podstawowym celem EO jest przedstawienie informacji użytkownikowi poprzez logikę przetwarzania inną niż lub dodatkowo do wyszukiwania danych lub informacji sterujących.

Logika przetwarzania musi -

  • Zawierają co najmniej jedną formułę matematyczną lub obliczenie.
  • Utwórz dane pochodne.
  • Utrzymuj jeden lub więcej ILF.
  • Zmień zachowanie systemu.

Należy zastosować wszystkie poniższe zasady -

  • Wysyła dane lub informacje sterujące poza granicami aplikacji.
  • W przypadku wskazanego PE musi mieć zastosowanie jedno z trzech stwierdzeń:
    • Logika przetwarzania jest unikalna w porównaniu z logiką przetwarzania wykonywaną przez innych EO dla aplikacji.
    • Zbiór zidentyfikowanych elementów danych różni się od innych TE w aplikacji.
    • Odwołania do plików ILF lub EIF różnią się od plików, do których odwołują się inne EO w aplikacji.

Dodatkowo musi obowiązywać jedna z następujących zasad -

  • Logika przetwarzania zawiera co najmniej jedną formułę matematyczną lub obliczenie.
  • Logika przetwarzania obsługuje co najmniej jeden ILF.
  • Logika przetwarzania zmienia zachowanie systemu.

Zapytanie zewnętrzne

Zapytanie zewnętrzne (EQ) to elementarny proces, który wysyła dane lub informacje kontrolne poza granice. Głównym celem EQ jest przedstawienie informacji użytkownikowi poprzez wyszukiwanie danych lub informacji sterujących.

Logika przetwarzania nie zawiera formuł matematycznych ani obliczeń i nie tworzy żadnych danych pochodnych. Podczas przetwarzania nie jest utrzymywany żaden ILF ani nie zmienia się zachowanie systemu.

Należy zastosować wszystkie poniższe zasady -

  • Wysyła dane lub informacje sterujące poza granicami aplikacji.
  • W przypadku wskazanego PE musi mieć zastosowanie jedno z trzech stwierdzeń:
    • Logika przetwarzania różni się od logiki przetwarzania wykonywanej przez inne korektory EQ dla aplikacji.
    • Zestaw zidentyfikowanych elementów danych różni się od innych EQ w aplikacji.
    • Odnośniki ILF lub EIF różnią się od plików, do których odwołują się inne EQ w aplikacji.

Dodatkowo muszą obowiązywać wszystkie poniższe zasady -

  • Logika przetwarzania pobiera dane lub informacje sterujące z ILF lub EIF.
  • Logika przetwarzania nie zawiera wzoru matematycznego ani obliczeń.
  • Logika przetwarzania nie zmienia zachowania systemu.
  • Logika przetwarzania nie obsługuje ILF.

Krok 6.2: Policz DET dla każdej funkcji transakcyjnej

Zastosuj następujące zasady do liczenia DET dla EI -

  • Przejrzyj wszystko, co przekracza (wchodzi i / lub wychodzi) z granicy.

  • Policz jeden DET dla każdego niepowtarzalnego, niepowtarzalnego atrybutu możliwego do zidentyfikowania przez użytkownika, który przekracza (wchodzi i / lub opuszcza) granicę podczas przetwarzania funkcji transakcyjnej.

  • Policz tylko jeden DET na funkcję transakcyjną, aby móc wysłać komunikat odpowiedzi aplikacji, nawet jeśli istnieje wiele komunikatów.

  • Policz tylko jeden DET na funkcję transakcyjną, aby móc zainicjować działanie (a), nawet jeśli istnieje wiele sposobów, aby to zrobić.

  • Nie licz następujących elementów jako DET -

    • Atrybuty generowane w granicach przez funkcję transakcyjną i zapisywane w ILF bez wychodzenia z granicy.

    • Literały, takie jak tytuły raportów, identyfikatory ekranu lub panelu, nagłówki kolumn i tytuły atrybutów.

    • Znaczniki wygenerowane przez aplikację, takie jak atrybuty daty i godziny.

    • Zmienne stronicowania, numery stron i informacje o pozycjonowaniu, np. „Wiersze od 37 do 54 z 211”.

    • Pomoce nawigacyjne, takie jak możliwość poruszania się po liście przy użyciu „poprzedni”, „następny”, „pierwszy”, „ostatni” i ich graficzne odpowiedniki.

Zastosuj następujące zasady, aby policzyć DET dla EO / EQ -

  • Przejrzyj wszystko, co przekracza (wchodzi i / lub wychodzi) z granicy.

  • Policz jeden DET dla każdego niepowtarzalnego, niepowtarzalnego atrybutu możliwego do zidentyfikowania przez użytkownika, który przekracza (wchodzi i / lub opuszcza) granicę podczas przetwarzania funkcji transakcyjnej.

  • Policz tylko jeden DET na funkcję transakcyjną, aby móc wysłać komunikat odpowiedzi aplikacji, nawet jeśli istnieje wiele komunikatów.

  • Policz tylko jeden DET na funkcję transakcyjną, aby móc zainicjować działanie (a), nawet jeśli istnieje wiele sposobów, aby to zrobić.

  • Nie licz następujących elementów jako DET -

    • Atrybuty generowane w granicach bez przekraczania granicy.

    • Literały, takie jak tytuły raportów, identyfikatory ekranu lub panelu, nagłówki kolumn i tytuły atrybutów.

    • Znaczniki wygenerowane przez aplikację, takie jak atrybuty daty i godziny.

    • Zmienne stronicowania, numery stron i informacje o pozycjonowaniu, np. „Wiersze od 37 do 54 z 211”.

    • Pomoce nawigacyjne, takie jak możliwość poruszania się po liście przy użyciu „poprzedni”, „następny”, „pierwszy”, „ostatni” i ich graficzne odpowiedniki.

Krok 6.3: Policz stawki FTR dla każdej funkcji transakcyjnej

Zastosuj następujące zasady do liczenia stawek FTR dla EI -

  • Policz FTR dla każdego utrzymywanego ILF.
  • Policz FTR dla każdego ILF lub EIF odczytanego podczas przetwarzania EI.
  • Policz tylko jeden FTR dla każdego ILF, który jest zarówno utrzymywany, jak i odczytywany.

Zastosuj następującą zasadę, aby policzyć stawki FTR za EO / EQ -

  • Policz FTR dla każdego ILF lub EIF odczytanego podczas przetwarzania EP.

Dodatkowo zastosuj następujące zasady do liczenia stawek FTR dla EO -

  • Policz FTR dla każdego ILF utrzymywanego podczas przetwarzania EP.
  • Policz tylko jeden FTR dla każdego ILF, który jest utrzymywany i odczytywany przez EP.

Krok 6.4: Określ złożoność funkcjonalną dla każdej funkcji transakcyjnej

FTR Typy elementów danych (DET)
1-4 5-15 >=16
0-1 L L ZA
2 L ZA H.
> = 3 ZA H. H.

Złożoność funkcjonalna: L = Niski; A = Średnia; H = Wysoki

Określ złożoność funkcjonalną dla każdego EO / EQ, z wyjątkiem tego, że EQ musi mieć co najmniej 1 FTR -

EQ musi mieć co najmniej 1 FTR

FTR

 Typy elementów danych (DET)
1-4 5-15 > = 16
0-1 L L ZA
2 L ZA H.
> = 3 ZA H. H.

Złożoność funkcjonalna: L = Niski; A = Średnia; H = Wysoki

Krok 6.5: Zmierz rozmiar funkcjonalny dla każdej funkcji transakcyjnej

Zmierz rozmiar funkcjonalny każdego EI na podstawie jego złożoności funkcjonalnej.

Złożoność Liczba PR
Niska 3
Średni 4
Wysoki 6

Zmierz rozmiar funkcjonalny każdego EO / EQ na podstawie jego złożoności funkcjonalnej.

Złożoność Liczba PR dla EO Liczba FP dla EQ
Niska 4 3
Średni 5 4
Wysoki 6 6

Krok 7: Oblicz rozmiar funkcjonalny (nieskorygowana liczba punktów funkcyjnych)

Aby obliczyć rozmiar funkcjonalny, należy postępować według poniższych kroków -

Krok 7.1

Przypomnij sobie, co znalazłeś w kroku 1. Określ rodzaj liczenia.

Krok 7.2

Oblicz rozmiar funkcjonalny lub liczbę punktów funkcji na podstawie typu.

  • Aby uzyskać informacje o liczbie punktów funkcji programowania, przejdź do kroku 7.3.
  • Aby uzyskać informacje o liczbie punktów funkcji aplikacji, przejdź do kroku 7.4.
  • Aby uzyskać informacje o liczbie punktów funkcji wzmocnienia, przejdź do kroku 7.5.

Krok 7.3

Liczba punktów funkcji rozwoju składa się z dwóch elementów funkcjonalności -

  • Funkcjonalność aplikacji zawarta w wymaganiach użytkownika dla projektu.

  • Funkcjonalność konwersji zawarta w wymaganiach użytkownika dla projektu. Funkcjonalność konwersji składa się z funkcji udostępnianych tylko podczas instalacji w celu konwersji danych i / lub zapewnienia innych wymagań konwersji określonych przez użytkownika, takich jak specjalne raporty konwersji. Na przykład istniejąca aplikacja może zostać zastąpiona nowym systemem.

DFP = ADD + CFP

Gdzie,

DFP = Liczba punktów funkcji rozwoju

ADD = Rozmiar funkcji dostarczanych użytkownikowi przez projekt rozwojowy

CFP = Rozmiar funkcji konwersji

ADD = Liczba FP (ILF) + Liczba FP (EIF) + Liczba FP (EI) + Liczba FP (EO) + Liczba FP (EQ)

CFP = Liczba FP (ILF) + Liczba FP (EIF) + Liczba FP (EI) + Liczba FP (EO) + Liczba FP (EQ)

Krok 7.4

Oblicz liczbę punktów funkcji aplikacji

AFP = ADD

Gdzie,

AFP = Liczba punktów funkcji aplikacji

ADD = Rozmiar funkcji dostarczanych użytkownikowi przez projekt programistyczny (z wyłączeniem rozmiaru dowolnej funkcji konwersji) lub funkcjonalność, która istnieje zawsze, gdy aplikacja jest liczona.

ADD = Liczba FP (ILF) + Liczba FP (EIF) + Liczba FP (EI) + Liczba FP (EO) + Liczba FP (EQ)

Krok 7.5

Liczba punktów funkcji rozszerzenia uwzględnia następujące cztery składniki funkcjonalności -

  • Funkcjonalność dodawana do aplikacji.
  • Funkcjonalność, która jest modyfikowana w aplikacji.
  • Funkcjonalność konwersji.
  • Funkcjonalność, która jest usuwana z aplikacji.

EFP = ADD + CHGA + CFP + DEL

Gdzie,

EFP = Liczba punktów funkcji wzmocnienia

ADD = Rozmiar funkcji dodawanych przez projekt ulepszenia

CHGA = Rozmiar funkcji zmienianych przez projekt ulepszenia

CFP = Rozmiar funkcji konwersji

DEL = Rozmiar funkcji usuwanych przez projekt ulepszenia

ADD = Liczba FP (ILF) + Liczba FP (EIF) + Liczba FP (EI) + Liczba FP (EO) + Liczba FP (EQ)

CHGA = Liczba FP (ILF) + Liczba FP (EIF) + Liczba FP (EI) + Liczba FP (EO) + Liczba FP (EQ)

CFP = Liczba FP (ILF) + Liczba FP (EIF) + Liczba FP (EI) + Liczba FP (EO) + Liczba FP (EQ)

DEL = Liczba FP (ILF) + Liczba FP (EIF) + Liczba FP (EI) + Liczba FP (EO) + Liczba FP (EQ)

Krok 8: Określ współczynnik korekty wartości

GSC są opcjonalne w CPM 4.3.1 i przeniesione do Załącznika. W związku z tym krok 8 i krok 9 można pominąć.

Współczynnik korekty wartości (VAF) jest oparty na 14 GSC, które oceniają ogólną funkcjonalność liczonej aplikacji. Sekcje GSC to ograniczenia biznesowe użytkowników niezależne od technologii. Każda cecha ma powiązane opisy określające stopień wpływu.

Ogólna charakterystyka systemu Krótki opis
Komunikacja danych Ile urządzeń komunikacyjnych jest dostępnych, aby pomóc w przekazywaniu lub wymianie informacji z aplikacją lub systemem?
Rozproszone przetwarzanie danych Jak obsługiwane są rozproszone dane i funkcje przetwarzania?
Wydajność Czy użytkownik wymagał czasu odpowiedzi lub przepustowości?
Często używana konfiguracja Jak mocno wykorzystywana jest obecna platforma sprzętowa, na której będzie wykonywana aplikacja?
Kurs transakcji Jak często wykonywane są transakcje codziennie, co tydzień, co miesiąc itd.?
Wprowadzanie danych on-line Jaki procent informacji jest wprowadzanych online?
Wydajność użytkownika końcowego Czy aplikacja została zaprojektowana z myślą o wydajności użytkownika końcowego?
Aktualizacja online Ile ILF jest aktualizowanych przez transakcję online?
Złożone przetwarzanie Czy aplikacja ma obszerne przetwarzanie logiczne lub matematyczne?
Możliwość ponownego użycia Czy aplikacja została stworzona z myślą o potrzebach jednego lub wielu użytkowników?
Łatwość instalacji Jak trudna jest konwersja i instalacja?
Łatwość obsługi Jak skuteczne i / lub zautomatyzowane są procedury uruchamiania, tworzenia kopii zapasowych i odzyskiwania?
Wiele witryn Czy aplikacja została specjalnie zaprojektowana, opracowana i obsługiwana w celu zainstalowania w wielu lokalizacjach w wielu organizacjach?
Ułatw zmiany Czy aplikacja została specjalnie zaprojektowana, opracowana i obsługiwana w celu ułatwienia zmian?

Zakres stopnia wpływu mieści się w skali od zera do pięciu, od braku wpływu do silnego wpływu.

Ocena Stopień wpływu
0 Brak lub brak wpływu
1 Przypadkowy wpływ
2 Umiarkowany wpływ
3 Średni wpływ
4 Znaczący wpływ
5 Silny wpływ w całym tekście

Określ stopień wpływu dla każdego z 14 GSC.

Suma wartości 14 uzyskanych w ten sposób GSC jest określana jako całkowity stopień wpływu (TDI).

TDI = ∑14 Degrees of Influence

Następnie oblicz współczynnik korekty wartości (VAF) jako

VAF = (TDI × 0.01) + 0.65

Każdy GSC może wynosić od 0 do 5, TDI może wahać się od (0 × 14) do (5 × 14), tj. Od 0 (gdy wszystkie GSC są niskie) do 70 (gdy wszystkie GSC są wysokie), tj. 0 ≤ TDI ≤ 70. Stąd VAF może zmieniać się w zakresie od 0,65 (gdy wszystkie GSC są niskie) do 1,35 (kiedy wszystkie GSC są wysokie), tj. 0,65 ≤ VAF ≤ 1,35.

Krok 9: Oblicz liczbę dostosowanych punktów funkcyjnych

Zgodnie z podejściem FPA, które wykorzystuje VAF (wersje CPM przed wersją 4.3.1), jest to określane przez:

Adjusted FP Count = Unadjusted FP Count × VAF

Gdzie nieskorygowana liczba PR to rozmiar funkcjonalny, który obliczyłeś w kroku 7.

Ponieważ VAF może zmieniać się od 0,65 do 1,35, VAF wywiera wpływ ± 35% na końcową skorygowaną liczbę FP.

Korzyści z punktów funkcyjnych

Punkty funkcyjne są przydatne -

  • Mierząc rozmiar rozwiązania zamiast rozmiaru problemu.

  • Ponieważ wymagania są jedyną rzeczą potrzebną do zliczania punktów funkcyjnych.

  • Ponieważ jest niezależny od technologii.

  • Ponieważ jest niezależny od języków programowania.

  • Przy szacowaniu projektów testowych.

  • Przy szacowaniu całkowitych kosztów projektu, harmonogramu i wysiłku.

  • W negocjacjach kontraktowych, ponieważ zapewnia łatwiejszą komunikację z grupami biznesowymi.

  • Ponieważ określa ilościowo i przypisuje wartość do rzeczywistych zastosowań, interfejsów i celów funkcji w oprogramowaniu.

  • Tworząc wskaźniki z innymi danymi, takimi jak godziny, koszt, liczba pracowników, czas trwania i inne metryki aplikacji.

Repozytoria FP

International Software Benchmarking Standards Group (ISBSG) rozwija i utrzymuje dwa repozytoria danych IT.

  • Projekty rozwojowe i ulepszające
  • Aplikacje do konserwacji i wsparcia

W repozytorium projektów rozwoju i ulepszeń znajduje się ponad 6000 projektów.

Dane są dostarczane w formacie Microsoft Excel, co ułatwia dalszą analizę, którą chcesz z nimi zrobić, lub możesz nawet wykorzystać dane w innym celu.

Licencję repozytorium ISBSG można zakupić pod adresem: http://www.isbsg.com/

ISBSG oferuje 10% zniżki dla członków IFPUG na zakupy online, gdy używany jest kod rabatowy „Członkowie IFPUG”.

Aktualizacje wersji danych projektu oprogramowania ISBSG można znaleźć pod adresem: http://www.ifpug.org/isbsg/

COSMIC i IFPUG współpracowały w celu opracowania Słowniczka terminów dotyczących oprogramowania niefunkcjonalnego i wymagań projektowych. Można go pobrać ze strony - cosmic-sizing.org

ZA Use-Case to seria powiązanych interakcji między użytkownikiem a systemem, która umożliwia użytkownikowi osiągnięcie celu.

Przypadki użycia to sposób na uchwycenie wymagań funkcjonalnych systemu. Użytkownik systemu nazywany jest „aktorem”. Przypadki użycia są zasadniczo w formie tekstowej.

Punkty przypadków użycia - definicja

Use-Case Points (UCP)jest techniką szacowania oprogramowania używaną do pomiaru rozmiaru oprogramowania w przypadkach użycia. Koncepcja UCP jest podobna do PR.

Liczba nieuczciwych praktyk handlowych w projekcie opiera się na:

  • Liczba i złożoność przypadków użycia w systemie.
  • Liczba i złożoność aktorów w systemie.

    • Różne wymagania niefunkcjonalne (takie jak przenośność, wydajność, łatwość konserwacji), które nie zostały zapisane jako przypadki użycia.

    • Środowisko, w którym projekt będzie rozwijany (np. Język, motywacja zespołu itp.)

Szacowanie z wykorzystaniem nieuczciwych praktyk handlowych wymaga, aby wszystkie przypadki użycia były napisane z celem i na mniej więcej tym samym poziomie, podając taką samą ilość szczegółów. Dlatego przed dokonaniem oceny zespół projektowy powinien upewnić się, że napisał swoje przypadki użycia z określonymi celami i na poziomie szczegółowym. Przypadek użycia zwykle kończy się w ramach jednej sesji, a po osiągnięciu celu użytkownik może przejść do innej czynności.

Historia punktów przypadków użycia

Metoda szacowania Punktu Przypadku Użycia została wprowadzona przez Gustava Karnera w 1993 roku. Później licencję na pracę uzyskał Rational Software, który połączył się z IBM.

Proces liczenia punktów przypadków użycia

Proces liczenia punktów przypadków użycia obejmuje następujące kroki:

  • Oblicz nieskorygowane UCP
  • Dostosuj się do złożoności technicznej
  • Dostosuj się do złożoności środowiska
  • Oblicz skorygowane UCP

Krok 1: Oblicz nieskorygowane punkty przypadków użycia.

Najpierw obliczasz nieskorygowane punkty przypadków użycia, wykonując następujące kroki:

  • Określ nieskorygowaną wagę przypadku użycia
  • Określ niedostosowaną wagę aktora
  • Oblicz nieskorygowane punkty przypadków użycia

Step 1.1 - Określ nieskorygowaną wagę przypadku użycia.

Step 1.1.1 - Znajdź liczbę transakcji w każdym przypadku użycia.

Jeśli Przypadki Użycia są zapisane z Poziomami Celów Użytkownika, transakcja jest równoważna krokowi w Przypadku Użycia. Znajdź liczbę transakcji, licząc kroki w przypadku użycia.

Step 1.1.2- Klasyfikuj każdy przypadek użycia jako prosty, średni lub złożony w oparciu o liczbę transakcji w przypadku użycia. Przypisz również wagę przypadku użycia, jak pokazano w poniższej tabeli -

Złożoność przypadków użycia Liczba transakcji Waga przypadku użycia
Prosty ≤3 5
Średni 4 do 7 10
Złożony > 7 15

Step 1.1.3- Powtórz dla każdego przypadku użycia i uzyskaj wszystkie wagi przypadków użycia. Nieskorygowana waga przypadku użycia (UUCW) to suma wszystkich wag przypadków użycia.

Step 1.1.4 - Znajdź nieskorygowaną wagę przypadku użycia (UUCW), korzystając z poniższej tabeli -

Złożoność przypadków użycia Waga przypadku użycia Liczba przypadków użycia Produkt
Prosty 5 NSUC 5 × NSUC
Średni 10 NAUC 10 × NAUC
Złożony 15 NCUC 15 × NCUC
Unadjusted Use-Case Weight (UUCW) 5 × NSUC + 10 × NAUC + 15 × NCUC

Gdzie,

NSUC to nie. prostych przypadków użycia.

NAUC to nie. średnich przypadków użycia.

NCUC to nie. złożonych przypadków użycia.

Step 1.2 - Określ nieskorygowaną wagę aktora.

Aktor w Przypadku Użycia może być osobą, innym programem itp. Niektórzy aktorzy, np. System ze zdefiniowanym API, mają bardzo proste potrzeby i tylko nieznacznie zwiększają złożoność Przypadku Użycia.

Niektóre podmioty, takie jak system wchodzący w interakcje za pośrednictwem protokołu, mają większe potrzeby i do pewnego stopnia zwiększają złożoność przypadku użycia.

Inni aktorzy, tacy jak użytkownik wchodzący w interakcję za pośrednictwem GUI, mają znaczący wpływ na złożoność przypadku użycia. Na podstawie tych różnic można sklasyfikować aktorów jako prostych, średnich i złożonych.

Step 1.2.1 - Klasyfikuj aktorów jako prostych, średnich i złożonych oraz przypisz wagi aktorów, jak pokazano w poniższej tabeli -

Złożoność aktora Przykład Waga aktora
Prosty System ze zdefiniowanym API 1
Średni System współdziałający za pośrednictwem protokołu 2
Złożony Użytkownik korzystający z interfejsu GUI 3

Step 1.2.2- Powtórz dla każdego aktora i uzyskaj wszystkie wagi aktorów. Nieskorygowana waga aktora (UAW) to suma wszystkich wag aktora.

Step 1.2.3 - Znajdź nieskorygowaną wagę aktora (UAW), korzystając z poniższej tabeli -

Złożoność aktora Waga aktora Liczba aktorów Produkt
Prosty 1 NSA 1 × NSA
Średni 2 NAA 2 × NAA
Złożony 3 NCA 3 × NCA
Unadjusted Actor Weight (UAW) 1 × NSA + 2 × NAA + 3 × NCA

Gdzie,

NSA to nie. prostych aktorów.

NAA to nie. przeciętnych aktorów.

NCA to nie. złożonych aktorów.

Step 1.3 - Oblicz nieskorygowane punkty przypadków użycia.

Nieskorygowana waga przypadku użycia (UUCW) i nieskorygowana waga aktora (UAW) razem dają nieskorygowany rozmiar systemu, zwany nieskorygowanymi punktami przypadków użycia.

Unadjusted Use-Case Points (UUCP) = UUCW + UAW

Kolejne kroki to dostosowanie nieskorygowanych punktów przypadków użycia (UUCP) do złożoności technicznej i złożoności środowiskowej.

Krok 2: Dostosuj się do złożoności technicznej

Step 2.1 - Rozważ 13 czynników, które wpływają na wpływ złożoności technicznej projektu na punkty przypadków użycia i odpowiadające im wagi, zgodnie z poniższą tabelą -

Czynnik Opis Waga
T1 System rozproszony 2.0
T2 Cele dotyczące czasu reakcji lub przepustowości 1.0
T3 Wydajność użytkownika końcowego 1.0
T4 Złożone przetwarzanie wewnętrzne 1.0
T5 Kod musi być wielokrotnego użytku 1.0
T6 Łatwe do zainstalowania .5
T7 Łatwy w użyciu .5
T8 Przenośny 2.0
T9 Łatwe do zmiany 1.0
T10 Równoległy 1.0
T11 Obejmuje specjalne cele bezpieczeństwa 1.0
T12 Zapewnia bezpośredni dostęp dla stron trzecich 1.0
T13 Wymagane jest specjalne zaplecze szkoleniowe dla użytkowników 1.0

Wiele z tych czynników stanowi niefunkcjonalne wymagania projektu.

Step 2.2 - Dla każdego z 13 czynników oceń projekt i oceń go od 0 (nieistotne) do 5 (bardzo ważne).

Step 2.3 - Oblicz wpływ czynnika na podstawie ciężaru wpływu współczynnika i wartości znamionowej projektu jako

Impact of the Factor = Impact Weight × Rated Value

Step (2.4)- Oblicz sumę wpływu wszystkich czynników. Daje to całkowity współczynnik techniczny (TFactor), jak podano w tabeli poniżej -

Czynnik Opis Waga (W) Wartość znamionowa (od 0 do 5) (RV) Uderzenie (I = W × RV)
T1 System rozproszony 2.0
T2 Cele dotyczące czasu reakcji lub przepustowości 1.0
T3 Wydajność użytkownika końcowego 1.0
T4 Złożone przetwarzanie wewnętrzne 1.0
T5 Kod musi być wielokrotnego użytku 1.0
T6 Łatwe do zainstalowania .5
T7 Łatwy w użyciu .5
T8 Przenośny 2.0
T9 Łatwe do zmiany 1.0
T10 Równoległy 1.0
T11 Obejmuje specjalne cele bezpieczeństwa 1.0
T12 Zapewnia bezpośredni dostęp dla stron trzecich 1.0
T13 Wymagane jest specjalne zaplecze szkoleniowe dla użytkowników 1.0
Total Technical Factor (TFactor)

Step 2.5 - Oblicz współczynnik złożoności technicznej (TCF) jako -

TCF = 0.6 + (0.01 × TFactor)

Krok 3: Dostosuj się do złożoności środowiska

Step 3.1 - Rozważ 8 czynników środowiskowych, które mogą wpłynąć na wykonanie projektu i odpowiadające im wagi, zgodnie z poniższą tabelą -

Czynnik Opis Waga
F1 Znajomość używanego modelu projektu 1.5
F2 Doświadczenie aplikacji .5
F3 Doświadczenie zorientowane obiektowo 1.0
F4 Możliwości głównego analityka .5
F5 Motywacja 1.0
F6 Stabilne wymagania 2.0
F7 Pracownicy zatrudnieni w niepełnym wymiarze godzin -1,0
F8 Trudny język programowania -1,0

Step 3.2 - Dla każdego z 8 czynników oceń projekt i oceń go od 0 (nieistotne) do 5 (bardzo ważne).

Step 3.3 - Oblicz wpływ czynnika na podstawie ciężaru wpływu współczynnika i wartości znamionowej projektu jako

Impact of the Factor = Impact Weight × Rated Value

Step 3.4- Oblicz sumę wpływu wszystkich czynników. Daje to całkowity współczynnik środowiska (EFactor), jak podano w poniższej tabeli -

Czynnik Opis Waga (W) Wartość znamionowa (od 0 do 5) (RV) Uderzenie (I = W × RV)
F1 Znajomość używanego modelu projektu 1.5
F2 Doświadczenie aplikacji .5
F3 Doświadczenie zorientowane obiektowo 1.0
F4 Możliwości głównego analityka .5
F5 Motywacja 1.0
F6 Stabilne wymagania 2.0
F7 Pracownicy zatrudnieni w niepełnym wymiarze godzin -1,0
F8 Trudny język programowania -1,0
Total Environment Factor (EFactor)

Step 3.5 - Oblicz współczynnik środowiskowy (EF) jako -

1.4 + (-0.03 × EFactor)

Krok 4: Oblicz skorygowane punkty przypadków użycia (UCP)

Oblicz skorygowane punkty przypadków użycia (UCP) jako -

UCP = UUCP × TCF × EF

Zalety i wady punktów przypadków użycia

Zalety punktów przypadków użycia

  • UCP opierają się na przypadkach użycia i można je mierzyć na bardzo wczesnym etapie cyklu życia projektu.

  • UCP (oszacowanie wielkości) będzie niezależne od wielkości, umiejętności i doświadczenia zespołu, który wdraża projekt.

  • Oszacowania oparte na nieuczciwych praktykach handlowych są zbliżone do wartości rzeczywistych, gdy oszacowania dokonują doświadczeni ludzie.

  • UCP jest łatwy w użyciu i nie wymaga dodatkowej analizy.

  • Przypadki użycia są szeroko stosowane jako metoda z wyboru do opisu wymagań. W takich przypadkach UCP jest najlepszą odpowiednią techniką szacowania.

Wady punktów przypadków użycia

  • UCP można używać tylko wtedy, gdy wymagania są zapisane w formie przypadków użycia.

  • W zależności od zorientowanych na cel, dobrze napisanych przypadków użycia. Jeśli przypadki użycia nie są dobrze lub jednolicie skonstruowane, wynikający z tego UCP może nie być dokładny.

  • Czynniki techniczne i środowiskowe mają duży wpływ na UCP. Należy zachować ostrożność przy przypisywaniu wartości czynnikom technicznym i środowiskowym.

  • UCP jest przydatny do wstępnego oszacowania całkowitego rozmiaru projektu, ale jest znacznie mniej przydatny w kierowaniu pracą zespołu od iteracji do iteracji.

Delphi Methodto ustrukturyzowana technika komunikacji, pierwotnie opracowana jako systematyczna, interaktywna metoda prognozowania, która opiera się na panelu ekspertów. Eksperci odpowiadają na kwestionariusze w dwóch lub więcej rundach. Po każdej rundzie moderator przedstawia anonimowe podsumowanie prognoz ekspertów z poprzedniej rundy wraz z uzasadnieniem ich ocen. Następnie eksperci są zachęcani do zrewidowania swoich wcześniejszych odpowiedzi w świetle odpowiedzi innych członków panelu.

Uważa się, że w trakcie tego procesu zakres odpowiedzi będzie się zmniejszał, a grupa będzie dążyć do „prawidłowej” odpowiedzi. Ostatecznie, proces jest zatrzymywany po wcześniejszym ustaleniu kryterium zatrzymania (np. Liczba rund, osiągnięcie konsensusu i stabilność wyników), a wyniki określają średnie lub mediany wyników rund finałowych.

Metoda Delphi została opracowana w latach 1950-1960 w RAND Corporation.

Technika szerokopasmowa Delphi

W latach 70. Barry Boehm i John A. Farquhar stworzyli wariant szerokopasmowy metody Delphi. Termin „szerokopasmowy” jest używany, ponieważ w porównaniu z Metodą Delphi, Technika Szerokopasmowa Delphi wymagała większej interakcji i lepszej komunikacji między uczestnikami.

W Wideband Delphi Technique zespół estymacji składa się z kierownika projektu, moderatora, ekspertów oraz przedstawicieli zespołu deweloperskiego, stanowiącego 3-7 osobowy zespół. Są dwa spotkania -

  • Otwarcie spotkania
  • Spotkanie szacunkowe

Szerokopasmowa technika Delphi - kroki

Step 1 - Wybierz zespół szacowania i moderatora.

Step 2- Moderator prowadzi spotkanie inauguracyjne, podczas którego zespołowi zostaje przedstawiona specyfikacja problemu i lista zadań wysokiego poziomu, wszelkie założenia lub ograniczenia projektu. Zespół omawia problem i ewentualne kwestie związane z szacowaniem. Decydują również o jednostkach oszacowania. Moderator prowadzi całą dyskusję, monitoruje czas, a po spotkaniu inauguracyjnym przygotowuje ustrukturyzowany dokument zawierający specyfikację problemu, listę zadań wysokiego poziomu, założenia i ustalone jednostki oceny. Następnie przekazuje kopie tego dokumentu do następnego kroku.

Step 3 - Każdy członek zespołu szacowania następnie indywidualnie generuje szczegółowy WBS, szacuje każde zadanie w WBS i dokumentuje przyjęte założenia.

Step 4- Moderator dzwoni do zespołu ds. Wyceny na spotkanie szacunkowe. Jeśli którykolwiek z członków zespołu szacowania odpowie, że prognozy nie są gotowe, moderator poświęci więcej czasu i ponownie wyśle ​​zaproszenie na spotkanie.

Step 5 - Cały zespół ds. Wyceny zbiera się na spotkanie szacunkowe.

Step 5.1 - Na początku spotkania oceniającego moderator zbiera wstępne szacunki od każdego z członków zespołu.

Step 5.2- Następnie kreśli wykres na tablicy. Przedstawia całkowite oszacowanie projektu każdego członka jako X w linii Rundy 1, bez ujawniania odpowiednich nazwisk. Zespół ds. Estymacji ma pojęcie o zakresie szacunków, który początkowo może być duży.

Step 5.3- Każdy członek zespołu czyta na głos szczegółową listę zadań, które stworzył, identyfikując przyjęte założenia i zgłaszając wszelkie pytania lub problemy. Szacunki zadań nie są ujawniane.

Poszczególne szczegółowe listy zadań po połączeniu tworzą bardziej kompletną listę zadań.

Step 5.4 - Następnie zespół omawia wszelkie wątpliwości / problemy dotyczące zadań, do których doszedł, poczynionych założeń i problemów z szacowaniem.

Step 5.5- Każdy członek zespołu wraca następnie do swojej listy zadań i założeń i wprowadza zmiany, jeśli to konieczne. Szacunki zadań mogą również wymagać korekt opartych na dyskusji, które są oznaczone jako + N godz. za większy wysiłek i –N godz. przy mniejszym wysiłku.

Członkowie zespołu następnie łączą zmiany w szacunkach zadań, aby uzyskać całkowite oszacowanie projektu.

Step 5.6 - Moderator zbiera zmienione szacunki od wszystkich członków zespołu i nanosi je na linię Rundy 2.

W tej rundzie zakres będzie węższy w porównaniu z poprzednim, ponieważ jest bardziej oparty na konsensusie.

Step 5.7 - Następnie zespół omawia wprowadzone przez siebie modyfikacje zadania i założenia.

Step 5.8- Każdy członek zespołu wraca następnie do swojej listy zadań i założeń i wprowadza zmiany, jeśli to konieczne. Szacunki zadań mogą również wymagać korekt na podstawie dyskusji.

Następnie członkowie zespołu ponownie łączą zmiany w oszacowaniu zadania, aby otrzymać całkowite oszacowanie projektu.

Step 5.9 - Moderator ponownie zbiera zmienione szacunki od wszystkich członków i umieszcza je w linii Rundy 3.

Ponownie, w tej rundzie zakres będzie węższy w porównaniu z poprzednim.

Step 5.10 - Kroki 5.7, 5.8, 5.9 są powtarzane aż do spełnienia jednego z poniższych kryteriów -

  • Wyniki są zbieżne w dopuszczalnie wąskim zakresie.
  • Wszyscy członkowie zespołu nie chcą zmieniać swoich najnowszych szacunków.
  • Wyznaczony czas spotkania w sprawie szacowania dobiegł końca.

Step 6 - Kierownik projektu zbiera następnie wyniki ze spotkania szacującego.

Step 6.1 - Zestawia poszczególne listy zadań i odpowiadające im szacunki w jedną główną listę zadań.

Step 6.2 - Łączy też poszczególne listy założeń.

Step 6.3 - Następnie przegląda ostateczną listę zadań z zespołem ds. Wyceny.

Zalety i wady szerokopasmowej techniki Delphi

Zalety

  • Szerokopasmowa technika Delphi jest techniką szacowania opartą na konsensusie służącą do szacowania wysiłku.
  • Przydatne przy szacowaniu czasu na wykonanie zadania.
  • Udział doświadczonych osób i ich indywidualna ocena doprowadziłby do wiarygodnych wyników.
  • Osoby, które wykonałyby tę pracę, dokonują szacunków, a tym samym dokonują wiarygodnych szacunków.
  • Zachowana anonimowość umożliwia każdemu pewne wyrażanie swoich wyników.
  • Bardzo prosta technika.
  • Założenia są dokumentowane, omawiane i uzgadniane.

Niedogodności

  • Wymagane jest wsparcie w zarządzaniu.
  • Wyniki szacunków mogą nie odpowiadać oczekiwaniom kierownictwa.

Szacowanie trzypunktowe uwzględnia trzy wartości -

  • najbardziej optymistyczna ocena (O),
  • najbardziej prawdopodobne oszacowanie (M), i
  • oszacowanie pesymistyczne (najmniej prawdopodobne oszacowanie (L)).

W branży pojawiło się pewne zamieszanie w zakresie szacowania trzech punktów i PERT. Jednak techniki są różne. Zobaczysz różnice, gdy nauczysz się obu technik. Ponadto na końcu techniki PERT różnice są zestawiane i prezentowane. Jeśli chcesz najpierw im się przyjrzeć, możesz.

Oszacowanie trzypunktowe (E) jest oparte na prostej średniej i ma rozkład trójkątny.

E = (O + M + L) / 3

Odchylenie standardowe

W rozkładzie trójkątnym

Średnia = (O + M + L) / 3

Odchylenie standardowe = √ [((O - E) 2 + (M - E) 2 + (L - E) 2 ) / 2]

Trzypunktowe kroki szacowania

Step 1 - Przyjedź do WBS.

Step 2 - Dla każdego zadania znajdź trzy wartości - najbardziej optymistyczne oszacowanie (O), najbardziej prawdopodobne oszacowanie (M) i oszacowanie pesymistyczne (L).

Step 3 - Oblicz średnią z trzech wartości.

Mean = (O + M + L) / 3

Step 4- Oblicz trzypunktowe oszacowanie zadania. Oszacowanie trzypunktowe to średnia. W związku z tym,

E = Mean = (O + M + L) / 3

Step 5 - Oblicz odchylenie standardowe zadania.

Standard Deviation (SD) = √ [((O − E)2 + (M − E)2 + (L - E)2)/2]

Step 6 - Powtórz kroki 2, 3, 4 dla wszystkich zadań w WBS.

Step 7 - Oblicz trzypunktowe oszacowanie projektu.

E (Project) = ∑ E (Task)

Step 8 - Oblicz odchylenie standardowe projektu.

SD (Project) = √ (∑SD (Task)2)

Przekształć szacunki projektu na poziomy ufności

Obliczone w ten sposób trzypunktowe oszacowanie (E) i odchylenie standardowe (SD) są wykorzystywane do konwersji oszacowań projektu na „poziomy ufności”.

Konwersja jest oparta na -

  • Poziom ufności w E +/– SD wynosi około 68%.
  • Poziom ufności w wartości E +/– 1,645 × SD wynosi około 90%.
  • Poziom ufności w wartości E +/– 2 × SD wynosi około 95%.
  • Poziom ufności w wartości E +/– 3 × SD wynosi około 99,7%.

Zwykle 95% poziom ufności, tj. Wartość E + 2 × SD, jest używany do wszystkich szacunków projektów i zadań.

Oszacowanie metodą oceny i przeglądu projektu (PERT) uwzględnia trzy wartości: najbardziej optymistyczne oszacowanie (O), najbardziej prawdopodobne oszacowanie (M) i oszacowanie pesymistyczne (najmniej prawdopodobne oszacowanie (L)). Nastąpiło pewne zamieszanie w zakresie szacowania trzech punktów i PERT w branży. Jednak techniki są różne. Zobaczysz różnice, gdy nauczysz się obu technik. Na końcu tego rozdziału zestawiono i zaprezentowano różnice.

PERT opiera się na trzech wartościach - najbardziej optymistycznej ocenie (O), najbardziej prawdopodobnej ocenie (M) i ocenie pesymistycznej (najmniej prawdopodobna ocena (L)). Najbardziej prawdopodobne oszacowanie jest ważone 4 razy więcej niż pozostałe dwa szacunki (optymistyczne i pesymistyczne).

Szacunek PERT (E) jest oparty na średniej ważonej i jest zgodny z rozkładem beta.

E = (O + 4 × M + L)/6

PERT jest często używany wraz z metodą ścieżki krytycznej (CPM). CPM mówi o zadaniach, które są krytyczne w projekcie. Jeśli wystąpi opóźnienie w tych zadaniach, projekt zostanie opóźniony.

Odchylenie standardowe

Odchylenie standardowe (SD) mierzy zmienność lub niepewność oszacowania.

W dystrybucji beta

Średnia = (O + 4 × M + L) / 6

Odchylenie standardowe (SD) = (L - O) / 6

Etapy szacowania PERT

Step (1) - Przyjedź do WBS.

Step (2) - Dla każdego zadania znajdź trzy wartości: najbardziej optymistyczne oszacowanie (O), najbardziej prawdopodobne oszacowanie (M) i oszacowanie pesymistyczne (L).

Step (3) - Średnia PERT = (O + 4 × M + L) / 6

Średnia PERT = (O + 4 × M + L) / 3

Step (4) - Oblicz odchylenie standardowe zadania.

Odchylenie standardowe (SD) = (L - O) / 6

Step (6) - Powtórz kroki 2, 3, 4 dla wszystkich zadań w WBS.

Step (7) - Oblicz szacunek PERT projektu.

E (projekt) = ∑ E (zadanie)

Step (8) - Oblicz odchylenie standardowe projektu.

SD (projekt) = √ (ΣSD (zadanie) 2 )

Przekształć szacunki projektu na poziomy ufności

Obliczone w ten sposób oszacowania PERT (E) i odchylenie standardowe (SD) są wykorzystywane do konwersji oszacowań projektu na poziomy ufności.

Konwersja jest taka, że

  • Poziom ufności w E +/– SD wynosi około 68%.
  • Poziom ufności w wartości E +/– 1,645 × SD wynosi około 90%.
  • Poziom ufności w wartości E +/– 2 × SD wynosi około 95%.
  • Poziom ufności w wartości E +/– 3 × SD wynosi około 99,7%.

Zwykle poziom ufności 95%, tj. Wartość E + 2 × SD, jest używany do wszystkich szacunków dotyczących projektów i zadań.

Różnice między estymacją trzypunktową a PERT

Poniżej przedstawiono różnice między estymacją trzypunktową a PERT -

Szacowanie w trzech punktach ZUCHWAŁY
Prosta średnia Średnia ważona
Podąża za rozkładem trójkątnym Postępuje zgodnie z dystrybucją beta
Używany do małych, powtarzalnych projektów Stosowany w przypadku dużych, niepowtarzalnych projektów, zwykle projektów badawczo-rozwojowych. Używany razem z metodą ścieżki krytycznej (CPM)

E = średnia = (O + M + L) / 3

To jest prosta średnia

E = średnia = (O + 4 × M + L) / 6

Jest to średnia ważona
SD = √ [((O - E) 2 + (M - E) 2 + (L - E) 2 ) / 2] SD = (L - O) / 6

Analogous Estimationwykorzystuje podobne informacje o wcześniejszym projekcie do oszacowania czasu trwania lub kosztu bieżącego projektu, stąd słowo „analogia”. Możesz użyć analogicznego oszacowania, gdy jest niewiele informacji na temat twojego bieżącego projektu.

Dość często zdarzają się sytuacje, w których kierownicy projektów będą proszeni o oszacowanie kosztów i czasu trwania nowego projektu, ponieważ kierownicy potrzebują danych decyzyjnych, aby zdecydować, czy projekt jest wart realizacji. Zwykle ani kierownik projektu, ani nikt inny w organizacji nigdy nie wykonał projektu podobnego do nowego, ale kierownictwo nadal potrzebuje dokładnych szacunków kosztów i czasu trwania.

W takich przypadkach najlepszym rozwiązaniem jest analogiczne oszacowanie. Może nie być doskonały, ale jest dokładny, ponieważ opiera się na danych z przeszłości. Estymacja analogiczna jest techniką łatwą do wdrożenia. Wskaźnik sukcesu projektu może wynieść do 60% w porównaniu ze wstępnymi szacunkami.

Estymacja analogiczna - definicja

Estymacja analogiczna to technika wykorzystująca wartości parametrów z danych historycznych jako podstawę do oszacowania podobnego parametru dla przyszłej działalności. Przykłady parametrów: zakres, koszt i czas trwania. Miary przykładowych wag - rozmiar, waga i złożoność.

Ponieważ doświadczenie i osąd kierownika projektu i prawdopodobnie zespołu są stosowane w procesie szacowania, uważa się, że jest to połączenie informacji historycznych i oceny eksperckiej.

Analogiczne wymagania dotyczące szacowania

Dla analogicznego oszacowania jest następujący wymóg -

  • Dane z poprzednich i trwających projektów
    • Godziny pracy w tygodniu każdego członka zespołu
    • Koszty związane z ukończeniem projektu
  • Projekt zbliżony do aktualnego projektu
  • W przypadku, gdy bieżący projekt jest nowy i żaden z poprzednich projektów nie jest podobny
    • Moduły z poprzednich projektów, które są podobne do tych w bieżącym projekcie
    • Działania z poprzednich projektów, które są podobne do tych w bieżącym projekcie
    • Dane z tych wybranych
  • Udział kierownika projektu i zespołu kosztorysowego w celu zapewnienia doświadczonej oceny szacunków.

Analogiczne kroki szacowania

Kierownik projektu i zespół muszą wspólnie dokonać analogicznej oceny.

  • Step 1 - Zidentyfikuj dziedzinę bieżącego projektu.

  • Step 2 - Zidentyfikuj technologię obecnego projektu.

  • Step 3- Sprawdź w bazie danych organizacji, czy dostępne są podobne dane projektu. Jeśli to możliwe, przejdź do kroku (4). W przeciwnym razie przejdź do kroku (6).

  • Step 4 - Porównaj bieżący projekt z określonymi wcześniejszymi danymi projektu.

  • Step 5- Przybądź na czas trwania i szacunki kosztów bieżącego projektu. Na tym kończy się analogiczna wycena projektu.

  • Step 6 - Sprawdź w bazie danych organizacji, czy jakiekolwiek wcześniejsze projekty mają podobne moduły jak te w bieżącym projekcie.

  • Step 7 - Sprawdź w bazie danych organizacji, czy jakiekolwiek wcześniejsze projekty mają podobne działania jak te w bieżącym projekcie.

  • Step 8 - Zbierz je wszystkie i wykorzystaj ekspertyzę, aby oszacować czas trwania i kosztorys bieżącego projektu.

Zalety szacowania analogicznego

  • Estymacja analogiczna jest lepszym sposobem oszacowania na początkowych etapach projektu, kiedy znanych jest niewiele szczegółów.

  • Technika jest prosta, a czas potrzebny na oszacowanie jest znacznie krótszy.

  • Można oczekiwać, że wskaźnik sukcesu organizacji będzie wysoki, ponieważ technika opiera się na danych z poprzednich projektów organizacji.

  • Analogiczne oszacowanie można również zastosować do oszacowania nakładu pracy i czasu trwania poszczególnych zadań. Dlatego w WBS podczas szacowania zadań możesz użyć Analogii.

Struktura podziału pracy (WBS) w zarządzaniu projektami i inżynierii systemów to zorientowana na dostarczanie dekompozycja projektu na mniejsze komponenty. WBS to kluczowy element projektu, który organizuje pracę zespołu w zarządzalnych sekcjach. Zespół Wiedzy Zarządzania Projektami (PMBOK) definiuje WBS jako „zorientowaną na dostarczanie, hierarchiczną dekompozycję pracy do wykonania przez zespół projektowy”.

Element WBS może być produktem, danymi, usługą lub dowolną ich kombinacją. WBS zapewnia również niezbędne ramy dla szczegółowego szacowania kosztów i kontroli, a także dostarcza wskazówek dotyczących opracowywania i kontroli harmonogramu.

Reprezentacja WBS

WBS jest reprezentowany jako hierarchiczna lista działań roboczych projektu. Istnieją dwa formaty WBS -

  • Widok konspektu (format z wcięciem)
  • Widok struktury drzewa (schemat organizacyjny)

Najpierw omówmy, jak używać widoku konspektu do przygotowywania WBS.

Widok konspektu

Widok konspektu to bardzo przyjazny dla użytkownika układ. Prezentuje dobry widok na cały projekt i pozwala na łatwe modyfikacje. Używa liczb do rejestrowania różnych etapów projektu. Wygląda trochę podobnie do następującego -

  • Software Development

    • Scope

      • Określ zakres projektu
      • Bezpieczne sponsorowanie projektu
      • Zdefiniuj wstępne zasoby
      • Zabezpiecz podstawowe zasoby
      • Zakres zakończony

    • Analysis/Software Requirements

      • Przeprowadź analizę potrzeb
      • Projekt wstępnych specyfikacji oprogramowania
      • Opracuj wstępny budżet
      • Omów z zespołem specyfikacje / budżet oprogramowania
      • Uwzględnij opinie na temat specyfikacji oprogramowania
      • Opracuj harmonogram dostaw
      • Uzyskaj zgody na kontynuację (koncepcja, harmonogram i budżet)
      • Zabezpiecz wymagane zasoby
      • Analiza zakończona

    • Design

      • Przejrzyj wstępne specyfikacje oprogramowania
      • Opracuj specyfikacje funkcjonalne
      • Uzyskaj zgodę, aby kontynuować
      • Projekt kompletny

    • Development

      • Przejrzyj specyfikacje funkcjonalne
      • Zidentyfikuj modułowe / wielopoziomowe parametry projektowe
      • Opracuj kod
      • Testowanie deweloperskie (debugowanie podstawowe)
      • Rozwój zakończony

    • Testing

      • Opracuj plany testów jednostkowych przy użyciu specyfikacji produktów
      • Opracuj plany testów integracji, korzystając ze specyfikacji produktów

    • Training

      • Opracuj specyfikacje szkoleniowe dla użytkowników końcowych
      • Określ metodologię prowadzenia szkoleń (online, w sali wykładowej itp.)
      • Opracuj materiały szkoleniowe
      • Sfinalizuj materiały szkoleniowe
      • Opracuj mechanizm dostarczania szkoleń
      • Kompletne materiały szkoleniowe

    • Deployment

      • Określ ostateczną strategię wdrożenia
      • Opracuj metodologię wdrażania
      • Bezpieczne zasoby wdrożeniowe
      • Szkolenie personelu pomocniczego
      • Wdrażaj oprogramowanie
      • Wdrożenie zakończone

Przyjrzyjmy się teraz widokowi struktury drzewa.

Widok struktury drzewa

Widok struktury drzewa przedstawia bardzo łatwy do zrozumienia widok całego projektu. Poniższa ilustracja pokazuje, jak wygląda widok struktury drzewa. Ten typ struktury schematu organizacyjnego można łatwo narysować za pomocą funkcji dostępnych w programie MS-Word.

Rodzaje WBS

Istnieją dwa rodzaje WBS -

  • Functional WBS- W funkcjonalnym WBS system jest uszkodzony na podstawie funkcji w aplikacji, która ma być tworzona. Jest to przydatne przy szacowaniu wielkości systemu.

  • Activity WBS- W WBS aktywności system jest uszkodzony na podstawie działań w systemie. Działania są dalej podzielone na zadania. Jest to przydatne przy szacowaniu nakładu pracy i harmonogramu w systemie.

Oszacuj rozmiar

Step 1 - Zacznij od funkcjonalnego WBS.

Step 2 - Rozważ węzły liści.

Step 3 - Użyj metody Analogy lub Wideband Delphi, aby oszacować rozmiar.

Oszacuj wysiłek

Step 1- Użyj szerokopasmowej techniki Delphi do skonstruowania WBS. Sugerujemy, aby zadania nie trwały dłużej niż 8 godzin. Jeśli zadanie trwa dłużej, podziel je.

Step 2 - Użyj szerokopasmowej techniki Delphi lub trzypunktowego oszacowania, aby uzyskać szacunkowe nakłady pracy dla zadań.

Planowanie

Gdy WBS jest gotowy i znane są szacunki dotyczące rozmiaru i nakładu pracy, można przystąpić do planowania zadań.

Planując zadania, należy wziąć pod uwagę pewne rzeczy -

  • Precedence - Zadanie, które musi nastąpić, zanim zostanie powiedziane, że ma pierwszeństwo przed drugim.

  • Concurrence - Zadania współbieżne to takie, które mogą wystąpić w tym samym czasie (równolegle).

  • Critical Path - Określony zestaw zadań sekwencyjnych, od których zależy data zakończenia projektu.

    • Wszystkie projekty mają ścieżkę krytyczną.
    • Przyspieszenie zadań niekrytycznych nie skraca bezpośrednio harmonogramu.

Metoda ścieżki krytycznej

Metoda ścieżki krytycznej (CPM) to proces określania i optymalizacji ścieżki krytycznej. Niekrytyczne zadania ścieżki mogą rozpocząć się wcześniej lub później bez wpływu na datę zakończenia.

Pamiętaj, że ścieżka krytyczna może zmienić się na inną, gdy skracasz obecną. Na przykład dla WBS na poprzednim rysunku ścieżka krytyczna byłaby następująca -

Ponieważ data zakończenia projektu jest oparta na zestawie kolejnych zadań, zadania te nazywane są zadaniami krytycznymi.

Termin zakończenia projektu nie jest oparty na szkoleniu, dokumentacji i wdrożeniu. Takie zadania nazywane są zadaniami niekrytycznymi.

Relacje zależności zadań

W niektórych przypadkach podczas planowania może być konieczne uwzględnienie zależności między zadaniami. Ważnymi relacjami zależności między zadaniami są -

  • Od wykończenia do startu (FS)
  • Wykończenie do wykończenia (FF)

Od wykończenia do startu (FS)

W relacji zależności między zadaniami Finish-to-Start (FS) zadanie B nie może rozpocząć się, dopóki nie zostanie ukończone zadanie A.

Wykończenie do wykończenia (FF)

W relacji zależności zadania od zakończenia do zakończenia (FF) zadanie B nie może zakończyć się do momentu zakończenia zadania A.

Wykres Gantta

Wykres Gantta to rodzaj wykresu słupkowego, zaadaptowany przez Karola Adamieckiego w 1896 roku i niezależnie przez Henry'ego Gantta w latach 1910, który ilustruje harmonogram projektu. Wykresy Gantta ilustrują daty rozpoczęcia i zakończenia elementów końcowych i elementów podsumowujących projektu.

Możesz przenieść format konspektu z rysunku 2 do programu Microsoft Project, aby uzyskać widok wykresu Gantta.

Kamienie milowe

Kamienie milowe to krytyczne etapy Twojego harmonogramu. Będą miały czas trwania równy zero i służą do oznaczenia, że ​​wykonałeś określony zestaw zadań. Kamienie milowe są zwykle przedstawiane jako diament.

Na przykład na powyższym wykresie Gantta, projekt ukończony i ukończony rozwój są pokazane jako kamienie milowe, reprezentowane przez kształt rombu.

Kamienie milowe można powiązać z warunkami umowy.

Zalety szacowania przy użyciu WBS

WBS w znacznym stopniu upraszcza proces wyceny projektów. Oferuje następujące zalety w porównaniu z innymi technikami szacowania -

  • W WBS identyfikowana jest cała praca do wykonania w ramach projektu. W związku z tym, przeglądając WBS z udziałowcami projektu, będzie mniej prawdopodobne, że pominiesz jakąkolwiek pracę potrzebną do dostarczenia pożądanych rezultatów projektu.

  • WBS zapewnia dokładniejsze szacunki kosztów i harmonogramu.

  • Kierownik projektu uzyskuje udział zespołu w sfinalizowaniu WBS. To zaangażowanie zespołu generuje entuzjazm i odpowiedzialność w projekcie.

  • WBS stanowi podstawę do przydziału zadań. Ponieważ konkretne zadanie przydzielane jest konkretnemu członkowi zespołu, który byłby odpowiedzialny za jego wykonanie.

  • WBS umożliwia monitorowanie i kontrolowanie na poziomie zadań. Pozwala to mierzyć postępy i zapewniać, że projekt zostanie dostarczony na czas.

Planowanie szacowania pokera

Planning Poker jest techniką szacowania opartą na konsensusie, używaną głównie do szacowania wysiłku lub względnej wielkości historyjek użytkowników w Scrumie.

Planning Poker łączy trzy techniki szacowania - Wideband Delphi Technique, Analogous Estimation i Estimation using WBS.

Planning Poker został po raz pierwszy zdefiniowany i nazwany przez Jamesa Grenninga w 2002 roku, a później spopularyzowany przez Mike'a Cohna w jego książce „Agile Estimating and Planning”, której firma naznaczyła ten termin.

Planowanie techniki szacowania pokera

W przypadku techniki szacowania w planowaniu pokera, szacunki dla historyjek użytkowników są wyprowadzane z gry w pokera planowania. Zaangażowany jest cały zespół Scruma, co skutkuje szybkimi, ale rzetelnymi szacunkami.

  • W grę Planning Poker używa się talii kart. Ponieważ używany jest ciąg Fibonacciego, karty mają numery - 1, 2, 3, 5, 8, 13, 21, 34 itd. Te liczby reprezentują „Punkty opowieści”. Każdy kalkulator ma talię kart. Numery na kartach powinny być na tyle duże, aby były widoczne dla wszystkich członków zespołu, gdy jeden z członków zespołu trzyma kartę.

  • Jeden z członków zespołu zostaje wybrany na moderatora. Moderator czyta opis historyjki użytkownika, dla której dokonywana jest ocena. Jeśli estymatorzy mają jakieś pytania, właściciel produktu odpowiada na nie.

  • Każdy estymator prywatnie wybiera kartę przedstawiającą jego oszacowanie. Karty nie są wyświetlane, dopóki wszyscy estymatorzy nie dokonają wyboru. W tym czasie wszystkie karty są jednocześnie odwracane i trzymane, aby wszyscy członkowie zespołu mogli zobaczyć każdy szacunek.

  • W pierwszej turze jest bardzo prawdopodobne, że szacunki będą się różnić. Estymatory wysokie i niskie wyjaśniają przyczynę ich oszacowań. Należy uważać, aby wszystkie dyskusje miały na celu jedynie zrozumienie i nie można było niczego brać do siebie. Moderator musi zadbać o to samo.

  • Zespół może omówić historię i swoje szacunki jeszcze przez kilka minut.

  • Moderator może robić notatki z dyskusji, które będą pomocne, gdy zostanie opracowana konkretna historia. Po dyskusji każdy estymator dokonuje ponownej oceny, wybierając ponownie kartę. Karty pozostają ponownie prywatne, dopóki wszyscy nie oszacują, w którym momencie są one jednocześnie odwracane.

Powtarzaj ten proces, aż oszacowania zbiegną się w jedno oszacowanie, które można wykorzystać w historii. Liczba rund oceny może się różnić w zależności od historyjki użytkownika.

Korzyści z Planowania Szacowania Pokera

Poker planistyczny łączy w sobie trzy metody szacowania -

Expert Opinion- W podejściu do oceny opartej na opinii eksperta, ekspert jest pytany, jak długo coś zajmie lub jak duże będzie. Ekspert dokonuje oszacowania, opierając się na swoim doświadczeniu, intuicji lub przeczuciu. Oszacowanie opinii eksperta zwykle nie zajmuje dużo czasu i jest dokładniejsze w porównaniu z niektórymi metodami analitycznymi.

Analogy- Estymacja przez analogię wykorzystuje porównanie historyjek użytkowników. Szacowana historyjka użytkownika jest porównywana z podobnymi historyjkami użytkownika wdrożonymi wcześniej, co daje dokładne wyniki, ponieważ oszacowanie opiera się na sprawdzonych danych.

Disaggregation- Szacowanie dezagregacji odbywa się poprzez podzielenie historyjek użytkownika na mniejsze, łatwiejsze do oszacowania historyjki użytkownika. Opracowanie historyjek użytkownika, które mają być zawarte w sprincie, trwa zwykle od dwóch do pięciu dni. W związku z tym historie użytkowników, które mogą trwać dłużej, należy podzielić na mniejsze przypadki użycia. Takie podejście gwarantuje również, że byłoby wiele porównywalnych historii.

Wysiłki testowe nie są oparte na żadnych ostatecznych ramach czasowych. Wysiłki są kontynuowane aż do ustalenia wcześniej ustalonego harmonogramu, niezależnie od zakończenia testów.

Wynika to głównie z faktu, że tradycyjnie test effort estimation jest częścią development estimation. Tylko w przypadku technik szacowania wykorzystujących WBS, takich jak Wideband Delphi, Three-Point Estimation, PERT i WBS, można uzyskać wartości do oszacowania czynności testowych.

Jeśli otrzymałeś oszacowania jako Punkty Funkcyjne (FP), to zgodnie z Caper Jones,

Number of Test Cases = (Number of Function Points) × 1.2

Gdy masz już liczbę przypadków testowych, możesz pobrać dane produktywności z bazy danych organizacji i określić nakład pracy wymagany do testowania.

Metoda procentowego wysiłku rozwojowego

Wymagany wysiłek testowy to bezpośrednio proporcjonalny lub procentowy wysiłek programistyczny. Wysiłek programistyczny można oszacować za pomocą linii kodu (LOC) lub punktów funkcyjnych (FP). Następnie procent wysiłku związanego z testowaniem jest uzyskiwany z bazy danych organizacji. Uzyskany w ten sposób procent służy do oszacowania nakładu pracy przy testowaniu.

Szacowanie projektów testowych

Kilka organizacji świadczy obecnie niezależne usługi weryfikacji i walidacji dla swoich klientów, co oznaczałoby, że działania projektowe byłyby całkowicie testowaniem.

Szacowanie projektów testowych wymaga doświadczenia w różnych projektach w cyklu życia testów oprogramowania. Podczas szacowania projektu testowego rozważ -

  • Umiejętności zespołowe
  • Wiedza domeny
  • Złożoność aplikacji
  • Dane historyczne
  • Cykle błędów w projekcie
  • Dostępność zasobów
  • Różnice w produktywności
  • Środowisko systemowe i przestoje

Testowanie technik szacowania

Udowodniono, że poniższe techniki szacowania testów są dokładne i są szeroko stosowane -

  • Technika szacowania testów oprogramowania PERT
  • Metoda UCP
  • WBS
  • Technika szerokopasmowa Delphi
  • Analiza punktu funkcyjnego / punktu testowego
  • Rozkład procentowy
  • Technika szacowania testów oparta na doświadczeniu

Technika szacowania testów oprogramowania PERT

Technika szacowania testów oprogramowania PERT jest oparta na metodach statystycznych, w których każde zadanie testowe jest podzielone na podzadania, a następnie dla każdego z podzadań wykonywane są trzy rodzaje oszacowań.

Formuła używana w tej technice to -

Test Estimate = (O + (4 × M) + E)/6

Gdzie,

O = Oszacowanie optymistyczne (najlepszy scenariusz, w którym nic nie idzie źle i wszystkie warunki są optymalne).

M = Najbardziej prawdopodobne oszacowanie (najprawdopodobniej czas trwania i może być jakiś problem, ale większość rzeczy pójdzie dobrze).

L = Oszacowanie pesymistyczne (najgorszy scenariusz, w którym wszystko idzie źle).

Odchylenie standardowe dla tej techniki jest obliczane jako -

Standard Deviation (SD) = (E − O)/6

Metoda punktów przypadków użycia

Metoda UCP opiera się na przypadkach użycia, w których obliczamy nieskorygowane wagi aktorów i nieskorygowane wagi przypadków użycia, aby określić oszacowanie testów oprogramowania.

Przypadek użycia to dokument określający różnych użytkowników, systemy lub inne zainteresowane strony wchodzące w interakcje z daną aplikacją. Nazywa się ich „Aktorzy”. Interakcje realizują określone cele chroniące interesy wszystkich interesariuszy poprzez różne zachowania lub przepływy określane jako scenariusze.

Step 1- Policz nie. aktorów. Aktorzy to pozytywni, negatywni i wyjątkowi.

Step 2 - Oblicz nieskorygowane wagi aktorów jako

Unadjusted Actor Weights = Total no. of Actors

Step 3 - Policz liczbę przypadków użycia.

Step 4 - Oblicz nieskorygowane wagi przypadków użycia jako

Unadjusted Use-Case Weights = Total no. of Use-Cases

Step 5 - Oblicz nieskorygowane punkty przypadków użycia jako

Unadjusted Use-Case Points = (Unadjusted Actor Weights + Unadjusted Use-Case Weights)

Step 6- Określić współczynnik techniczny / środowiskowy (TEF). Jeśli niedostępny, przyjmij go jako 0,50.

Step 7 - Oblicz skorygowany punkt przypadku użycia jako

Adjusted Use-Case Point = Unadjusted Use-Case Points × [0.65 + (0.01 × TEF]

Step 8 - Oblicz całkowity wysiłek jako

Total Effort = Adjusted Use-Case Point × 2

Struktura podziału pracy

Step 1 - Utwórz WBS, dzieląc projekt testowy na małe części.

Step 2 - Podziel moduły na podmoduły.

Step 3 Podziel podmoduły dalej na funkcjonalności.

Step 4 - Podziel funkcjonalności na podfunkcje.

Step 5 - Przejrzyj wszystkie wymagania testowe, aby upewnić się, że zostały dodane do WBS.

Step 6 - Określ liczbę zadań, które musi wykonać Twój zespół.

Step 7 - Oszacuj wysiłek dla każdego zadania.

Step 8 - Oszacuj czas trwania każdego zadania.

Technika szerokopasmowa Delphi

W metodzie Wideband Delphi WBS jest rozprowadzany do zespołu składającego się z 3–7 członków w celu ponownego oszacowania zadań. Ostateczne oszacowanie jest wynikiem zsumowanych szacunków opartych na konsensusie zespołu.

Ta metoda mówi bardziej o doświadczeniu niż o jakiejkolwiek formule statystycznej. Metoda ta została spopularyzowana przez Barry'ego Boehma, aby położyć nacisk na iterację grupy w celu osiągnięcia konsensusu, w którym zespół wizualizował różne aspekty problemów podczas szacowania nakładu pracy.

Analiza punktu funkcyjnego / punktu testowego

FP wskazują funkcjonalność aplikacji z punktu widzenia użytkownika i są wykorzystywane jako technika szacowania wielkości projektu oprogramowania.

W testowaniu oszacowanie opiera się na dokumencie specyfikacji wymagań lub na wcześniej utworzonym prototypie aplikacji. Aby obliczyć PR projektu, wymagane są niektóre główne komponenty. Oni są -

  • Unadjusted Data Function Points - i) Pliki wewnętrzne, ii) Interfejsy zewnętrzne

  • Unadjusted Transaction Function Points - i) dane wejściowe użytkownika, ii) dane wyjściowe użytkownika, iii) zapytania użytkowników

  • Capers Jones basic formula -

    Liczba przypadków testowych = (liczba punktów funkcyjnych) × 1,2

  • Total Actual Effort (TAE) -

    (Liczba przypadków testowych) × (Procent wysiłku programistycznego / 100)

Rozkład procentowy

W tej technice wszystkim fazom cyklu życia oprogramowania (SDLC) przypisuje się nakład pracy w%. Może to być oparte na wcześniejszych danych z podobnych projektów. Na przykład -

Faza % wysiłku
Zarządzanie projektami 7%
Wymagania 9%
Projekt 16%
Kodowanie 26%
Testowanie (wszystkie fazy testowe) 27%
Dokumentacja 9%
Instalacja i szkolenie 6%

Następnie% wysiłku związanego z testowaniem (wszystkie fazy testowe) jest dalej rozdzielane na wszystkie fazy testowania -

Wszystkie fazy testów % wysiłku
Testowanie komponentów 16
Niezależne testy 84
Total 100
Niezależne testy % wysiłku
Testy integracyjne 24
Testowanie systemu 52
Testy akceptacyjne 24
Total 100
Testowanie systemu % wysiłku
Testowanie funkcjonalne systemu 65
Niefunkcjonalne testowanie systemu 35
Total 100
Architektura planowania i projektowania testów 50%
Faza przeglądu 50%

Technika estymacji testowania oparta na doświadczeniu

Ta technika jest oparta na analogiach i ekspertach. Technika zakłada, że ​​przetestowano już podobne aplikacje w poprzednich projektach i zebrano metryki z tych projektów. Zebrałeś również wskaźniki z poprzednich testów. Weź dane wejściowe od ekspertów z danej dziedziny, którzy bardzo dobrze znają aplikację (a także testowanie) i wykorzystaj zebrane metryki i podejmij wysiłek testowania.

ja/tutorial
es/tutorial
de/tutorial
fr/tutorial
th/tutorial
pt/tutorial
ru/tutorial
vi/tutorial
it/tutorial
ko/tutorial
tr/tutorial
id/tutorial
pl/tutorial
hi/tutorial
japost
espost
depost
frpost
thpost
ptpost
rupost
vipost
itpost
kopost
trpost
idpost
plpost
hipost

© Copyright 2021 - 2024 | All Rights Reserved