SEER-SEM

SEER-SEM
Deweloperzy	Galorath
Wersja stabilna	8.4 / 2020
System operacyjny	Microsoft Windows
Typ	Oprogramowanie do zarządzania projektami
Licencja	Umowa licencyjna
Strona internetowa	Strona główna SEER-SEM

SEER for Software (SEER-SEM) to aplikacja do zarządzania projektami służąca do szacowania zasobów wymaganych do tworzenia oprogramowania.

Historia

1966 System Development Corporation Model oparty na regresjach.

Dona Reifera i Dana Galoratha z 1980 r. , Który skłonił do zbudowania modelu JPL Softcost. Ten model, wczesny przykład szacowania oprogramowania, pozwala na zautomatyzowaną i wykonywaną analizę ryzyka. Softcost został później przekształcony w produkt komercyjny przez Reifer Consultants.

1984 Computer Economics JS-2 i Galorath zaprojektowali System-3 w oparciu o model Jensena.

Zainspirowany Jensenem System-3 i inne systemy modelowania, takie jak COCOMO Barry'ego Boehma i wczesne prace Doty Associates, można postrzegać jako bezpośrednich i pośrednich współtwórców pakietu oprogramowania, który miał zostać opracowany przez Galorath pod koniec lat 80.

W 1988 roku firma Galorath Incorporated rozpoczęła prace nad wstępną wersją SEER-SEM.

Grupa modeli

SEER for Software (SEER-SEM) składa się z grupy współpracujących ze sobą modeli w celu oszacowania nakładu pracy, czasu trwania, personelu i defektów. Modele te można krótko opisać za pomocą pytań, na które odpowiadają:

Rozmiar. Jak duży jest szacowany projekt oprogramowania (linie kodu, punkty funkcyjne, przypadki użycia itp.)
Technologia. Jaka jest możliwa produktywność programistów (możliwości, narzędzia, praktyki itp.)
Kalkulacja nakładu pracy i harmonogramu. Jakiego nakładu pracy i czasu potrzeba, aby ukończyć projekt?
Obliczanie ograniczonego wysiłku/harmonogramu. Jak zmienia się oczekiwany wynik projektu po zastosowaniu ograniczeń dotyczących harmonogramu i personelu?
Aktywność i alokacja pracy. W jaki sposób czynności i robociznę należy przypisać do oszacowania?
Kalkulacja kosztów. Biorąc pod uwagę oczekiwany wysiłek, czas trwania i przydział pracy, ile będzie kosztować projekt?
Obliczanie wad. Biorąc pod uwagę rodzaj produktu, czas trwania projektu i inne informacje, jaka jest oczekiwana, obiektywna jakość dostarczonego oprogramowania?
Obliczanie nakładów na konserwację. Ile wysiłku będzie wymagało odpowiednie utrzymanie i aktualizacja systemu oprogramowania?
Postęp. Jak postępuje projekt i dokąd zmierza. Również jak przeplanować.
Ważność. Czy ten rozwój jest możliwy do osiągnięcia w oparciu o zastosowaną technologię?

Rozmiar oprogramowania

Rozmiar oprogramowania jest kluczowym elementem każdego modelu szacowania i większości parametrycznych modeli oprogramowania . Obsługiwane metryki ustalania rozmiaru obejmują linie źródłowe kodu (SLOC), punkty funkcyjne , ustalanie rozmiaru na podstawie funkcji (FBS) i szereg innych miar. Są one tłumaczone do użytku wewnętrznego na efektywny rozmiar ( ${\ displaystyle S_ {e}}$ ). ${\ displaystyle S_ {e}}$ jest formą wspólnej waluty w modelu i umożliwia mieszanie nowego, ponownie używanego, a nawet komercyjnego gotowego kodu w celu zintegrowanej analizy procesu tworzenia oprogramowania. Ogólne obliczenie dla ${\ displaystyle S_ {e}}$ to: S mi {\ displaystyle S_ {e}}

{\ Displaystyle S_ {e} = ({\ tekst {nowy rozmiar}}) + ({\ tekst { istniejący rozmiar}})\times (0,4\times {\text{redesign}}+0,25\times {\text{reimpl}}+0,35\times {\text{retest}})}

Jak wskazano, $.$ proporcjonalnie do ilości opracowywanego nowego oprogramowania ${\ displaystyle S_ {e}}$ wzrasta o mniejszą ilość, ponieważ wcześniej istniejący kod jest ponownie wykorzystywany w projekcie. Zakres tego wzrostu zależy od ilości przeróbek (przeprojektowania, ponownej implementacji i ponownego przetestowania) wymaganych do ponownego użycia kodu.

Rozmiary oparte na funkcjach

Podczas gdy SLOC jest akceptowanym sposobem pomiaru bezwzględnego rozmiaru kodu z perspektywy programisty, metryki, takie jak punkty funkcyjne, przechwytują funkcjonalnie rozmiar oprogramowania z perspektywy użytkownika. Metryka rozmiaru opartego na funkcjach (FBS) rozszerza punkty funkcyjne, dzięki czemu ukryte części oprogramowania, takie jak złożone algorytmy, mogą być łatwiej określane. FBS przekłada się bezpośrednio na nieskorygowane punkty funkcyjne (UFP).

W SEER-SEM wszystkie metryki rozmiaru są tłumaczone na $.$ tym te wprowadzone za pomocą FBS Nie jest to prosta konwersja, tj. nie dostosowanie językowe, jak ma to miejsce w przypadku bardzo wyśmiewanej metody strzelania wstecznego . Model uwzględnia raczej takie czynniki, jak szacowana faza, środowisko operacyjne, typ aplikacji i złożoność aplikacji. Wszystkie te rozważania znacząco wpływają na mapowanie między rozmiarem funkcjonalnym a ${\ displaystyle S_ {e}}$ . Po przetłumaczeniu FBS na punkty funkcyjne, jest on następnie przekształcany w ${\ Displaystyle S_ {e}}$ jako:

{\ Displaystyle S_ {e} = L_ {x} * (AdjFactor * UFP) ^ {\ frac {Entropia}{1.2}}}

Gdzie,

${\ displaystyle L_ {x}}$ jest czynnikiem ekspansji zależnym od języka.
$\ Displaystyle AdjFactor}$ jest wynikiem obliczeń z udziałem innych czynników wymienionych powyżej. Entropia waha się od 1,04 do 1,2 w zależności od rodzaju opracowywanego oprogramowania.

Obliczenia wysiłku i czasu trwania

Nakład pracy i czas trwania projektu są ze sobą powiązane, co znajduje odzwierciedlenie w ich kalkulacji w ramach modelu. Wysiłek napędza czas trwania, niezależnie od sprzężenia zwrotnego związanego z wydajnością między ograniczeniami czasu trwania a wysiłkiem. Podstawowe równanie wysiłku to:

{\ Displaystyle K = D ^ {0,4} \ cdot \ lewo ({\ Frac {S_ {e}} {C_ {te}}} \ prawej) ^ {

Gdzie,

${\ displaystyle S_ {e}}$ to efektywny rozmiar - wprowadzony wcześniej
$.$ - złożoną metryką, która oddaje czynniki związane z wydajnością lub produktywnością, z jaką można przeprowadzić rozwój Obszerny zestaw parametrów ludzi, procesów i produktów wpływa na efektywną ocenę technologii. Wyższa ocena oznacza, że rozwój będzie bardziej produktywny
$D$ to złożoność personelu — ocena nieodłącznej trudności projektu pod względem tempa, w jakim pracownicy są dodawani do projektu.
$E$ to entropia - W dawnych czasach entropia była ustalona na 1,2. Następnie ewoluował do 1,04 do 1,2 w zależności od atrybutów projektu, przy czym mniejsze projekty zorientowane na IT zmierzały w kierunku niższych. Obecnie entropia jest obserwowana jako 1,0 do 1,2 w zależności od atrybutów projektu. SEER pozwoli na entropię mniejszą niż 1,0, jeśli taka okoliczność zostanie również zaobserwowana.

Po uzyskaniu wysiłku czas trwania jest rozwiązywany za pomocą następującego równania:

Displaystyle t_ {d} = D ^ {- 0,2} \ cdot \ lewo ({\ Frac {S_ {e}} {C_ {te}}} \po prawej)^{0.4}}

Równanie czasu trwania pochodzi z kluczowych zależności formułowych. Jego 0,4 wskazuje, że wraz ze wzrostem rozmiaru projektu wydłuża się również czas trwania, choć mniej niż proporcjonalnie. Ta zależność rozmiar-czas trwania jest również używana w algorytmach planowania na poziomie komponentów, w których nakładanie się zadań jest obliczane tak, aby mieściło się w całkowitym szacowanym czasie trwania projektu.

^ B. Mazel Rola symulacji komputerowej w zarządzaniu przedsiębiorstwem: przegląd , strona 8, grudzień 1975,
^ Dan Galorath Dlaczego SEER zaczął się 18 sierpnia 2008
^ Dan Galorath Dlaczego SEER zaczął się 18 sierpnia 2008
^ Galorath, D & Evans M. (2006) Rozmiar oprogramowania, szacowanie i zarządzanie ryzykiem ISBN 0-8493-3593-0 Strona xxii

Linki zewnętrzne

[1] B. Mazel Rola symulacji komputerowej w zarządzaniu przedsiębiorstwem: przegląd , strona 8, grudzień 1975,

[2] Dan Galorath Dlaczego SEER zaczął się 18 sierpnia 2008

[3] Dan Galorath Dlaczego SEER zaczął się 18 sierpnia 2008

[4] Galorath, D & Evans M. (2006) Rozmiar oprogramowania, szacowanie i zarządzanie ryzykiem ISBN 0-8493-3593-0 Strona xxii