Wytwórstwo oprogramowania

Jarosław Deminet

Powszechna wiedza

• Komputery są wszystkiemu winne, czyli jak działa czarownica (Prawo Demineta)

• Informatyka zaczyna się tam, gdzie coś przestaje działać (Prawo Pacholczyka)

• Żadne przedsięwzięcie informatyczne nie kończy się tak, jak powinno (czas/budżet, zakres, jakość)

• Każde przedsięwzięcie może być sukcesem (Prawo Ciećwierza)

Fakty

• Gdzie bylibyśmy bez komputerów • Było źle, ale idzie ku lepszemu

Kłopoty

• Jak opisać zakres (zmiany są pewne!)• Jak oszacować czas• Jak oszacować budżet

Problemy świata

• Krótka historia (pierwszy most – ?, pierwszy tunel – 700 pne, pierwszy program – 1843 , następne ok. 1945)

• Ciągłe i szybkie zmiany technologiczne, nowe możliwości

• Wielka różnorodność• Wielki udział faz intelektualnych (trudnych

do oceny) w koszcie całości

Nie my jedni mamy problemy

• Eurotunel– przetarg – 1985– rozpoczęcie prac – 1987– zakończenie – 1993 – 1994 (+17%)– planowany koszt – 4,9 G £ – 12 G £ (+145%)– zmiana szerokości drzwi z 60 na 70 cm

– 40 M £ i 9 miesięcy opóźnień projektowych

Nie my jedni mamy problemy

• Lotnisko w Atlancie– 1977 – 1980 zgodnie z czasem i budżetem

(500 M $)– 2003 – 20?? wpadka

Cykl życia

Czego chcą?

Co zrobić?

Jak?

Strategia biznesowa

Wymagania

Specyfikacja

Projekt

Wykonanie i wdrożenieCzy warto?

Po co?

Ocena kosztów

• Po fakcie (wariant amerykański)– za roboczogodzinę– za wiersz kodu – za formatkę ekranową

• Trudna ocena efektywności• Konsekwencja: ucieczka za granicę

Prognozowanie kosztów

• Przewidywanie jest trudne, zwłaszcza przyszłości

• Metoda ekspercka, czyli sufitowa• Wg wymagań biznesowych• Wg obiektów analitycznych (zbiory

danych, strumienie danych, zapytania) – Metoda Punktów Funkcyjnych

Informatyka a sprawa polskaBiuro na tranzystorach

– premiera 24.10.1955

1989 – 1955 = 1,5 pokolenia

• Nowa (normalna) ekonomia i organizacja + nowa technika

• Od wołu do automatycznej skrzyni biegów

Co jest celem systemu do obsługi podatków

Obsługa izb i urzędów skarbowych?Wspieranie poboru podatków?Czy to jest to samo?Czy wprowadzenie informatyki powinno

spowodować zmiany procesów biznesowych?

System wspomagania dowodzenia dla Policji

• Zdarzenie trzeba powiązać z policjantem• W opisie policjanta jest zapisany jego

aktualny stopień• Zmiana danych policjanta jest

odnotowywana w jego opisie (bez historii)• Oskarżony twierdzi, że na miejscu był

kapral Nowak, a Policja twierdzi, że to był sierżant Nowak!!!

System sterowania ciągiem wstecznym w Airbusie

• Ciąg wsteczny można włączyć tylko wtedy, gdy samolot kołuje po pasie

• Pilot może nie zauważyć, czy samolot wylądował

• Samolot kołuje po pasie, jeśli kręcą mu się koła (na wszelki wypadek – wszystkie)

• A co jeśli na pasie jest mokro i samolot wpadnie w poślizg?

• Propozycja rozwiązania: może wystarczy, że trzy koła z czterech będą się kręcić?

Informatyka w firmie

• Obserwacja: przedsięwzięcia realizowane wewnętrznie zwalają się szczególnie często

• Diagnoza 1: klient zawsze chce więcej• Diagnoza 2: lepsze jest wrogiem dobrego• Diagnoza 3: księgowy jest ważniejszy od

informatyka

Jest tyle spokojniejszych zawodów,

np. można być pogromcą lwów

(I zasada Stokalskiego)

Model wodospadu

Analiza (specyfikacja)

Projekt

Wykonanie

Wdrożenie

Zintegrowany System X

Iteracje i prototypyAnaliza

ProjektWykonanie

Wdrożenie

AnalizaProjekt

WykonanieWdrożenie

AnalizaProjekt

WykonanieWdrożenie

Mniejsze ryzyko za znaną cenę

Model spiralny

Model V

Techniki ekstremalneAnaliza

ProjektWykonanie

WdrożenieAnalizaProjekt

WykonanieWdrożenieAnaliza

ProjektWykonanie

WdrożenieAnalizaProjekt

WykonanieWdrożenie

Analiza

Projekt

Wykonanie

Wdrożenie

Metodyki produkcji

Klasyczne• Programowanie jest

rzemiosłem• Mamy różnych

programistów• Programiści są

zastępowalni• Użytkownicy są różni• Zmiany są przykrą

koniecznością

Lekkie (giętkie)• Programowanie jest

sztuką• Mamy artystów

programistów• Programiści są

zindywidualizowani• Użytkownicy są mądrzy i

chętni do współpracy• Zmiany są podstawą

Rational Unified Process

Jakość• Ogół cech i właściwości wyrobu lub usługi decydujących

o zdolności wyrobu lub usługi do zaspokojenia stwierdzonych lub przewidywanych potrzeb (norma ISO 9000)

• Brak wad w produkcie, a wadą produktu jest każda taka negatywna cecha produktu – negatywna z punktu widzenia klienta – której klient ma prawo nie oczekiwać (Leszek Wasilewski)

• Zasada 4P: product, place, promotion, price (np. tani jednorazowy aparat, zepsute mięso dla lwa)

Jakość• 85% problemów z jakością wynika z błędów w systemie,

a 15% z winy pracowników (Joseph Juran – Japonia)• 95% problemów z jakością wynika z błędów w systemie,

a 5% z winy pracowników (Edwards Deming – USA)• Czy płacąc lepiej za dobrą pracę godzimy się na złą

pracę?• Niska jakość kosztuje• Koszt skutków wywołanych przez wadę w produkcie

rośnie bardzo szybko wraz z odległością między miejscem powstania wady a miejscem jej wykrycia

Jakość (podejście tradycyjne)D

osta

wcy

Klie

nci

Kontrola jakości(testy)

Firma(procesy

wytwórcze)Produkt

Jakość (podejście kompleksowe, TQM)

Dos

taw

cy

Klie

nci

Zapewnienie jakości(organizacja)

Firma(procesy

wytwórcze)Produkt

Trzy zasady

• Podejście systemowe – łańcuch jakości• Udział wszystkich pracowników –

współpraca i życzliwość• Ciągłe doskonalenie

Księga procedur• Treść

– instrukcje (np. zasady kodowania)– podręczniki (np. korzystania ze środowiska)– procedury (np. prowadzenia analizy)– regulaminy (np. pracowniczy)– zakresy obowiązków (np. projektantów i programistów)– wzorce dokumentów (np. notatek z wywiadów)

• Odpowiedzialni• Adresaci (dostępność)• Nadzór nad dokumentami (zatwierdzanie, przeglądy,

zmiany)

ISO 9001: Zarządzanie zasobami

• Ludzie– wykształcenie– szkolenie– umiejętności – doświadczenie

• Infrastruktura• Środowisko

ISO 9001: Realizacja wyrobu

• Planowanie– cele (biznesowe)– specyficzne wymagania (specyfikacja)– specyficzne działania weryfikacyjne i

kontrolne (testy) • Obsługa klienta

– wymagania (z różnych źródeł)– przegląd wymagań (po udokumentowaniu)– sposób komunikacji

ISO 9001: Realizacja wyrobu• Projektowanie i rozwój

– podział na etapy, przegląd, weryfikacja– powiązania między grupami– zebranie i przegląd danych wejściowych– dane wyjściowe zgodne z wymaganiami– systematyczne przeglądy i weryfikacja– nadzorowanie zmian

• Zakupy– nadzór nad dostawcą– szczegółowe wymagania– weryfikacja

ISO 9001: Realizacja wyrobu• Produkcja

– informacja o właściwościach– instrukcje– wyposażenie– monitoring i pomiary– walidacja (badanie zgodności z wymaganiami) – gdy

niezbędne– identyfikacja (zarządzanie konfiguracją)

• Wyposażenie do monitorowania i pomiarów• Korygowanie, doskonalenie, zapobieganie

Model dojrzałości

• Poziom początkowy (initial)– kompetentni ludzie i wiele heroizmu

• Poziom zarządzany (managed)– planowanie i wykonywanie zgodnie z polityką

• Poziom definiowany (defined)– standardowe procesy i procedury

• Poziom mierzony (quantitatively managed)– zastosowanie metod statystycznych

• Poziom usprawniany (optimizing)

CMMI – korzyściKategoria Mediana korzyściKoszt 34%

Terminowość 50%

Efektywność 61%

Jakość 48%

Zadowolenie klienta 14%

Zwrot z inwestycji 4:1

Capability Maturity Model Integration

Process Areas• Poziom zarządzany

– CM - Configuration Management– MA - Measurement and Analysis– PMC - Project Monitoring and Control– PP - Project Planning– PPQA - Process and Product Quality Assurance– REQM - Requirements Management

• Poziom definiowany– DAR - Decision Analysis and Resolution– IPM - Integrated Project Management– OPD - Organizational Process Definition– OPF - Organizational Process Focus– OT - Organizational Training– PI - Product Integration– RD - Requirements Development– RSKM - Risk Management– TS - Technical Solution– VAL – Validation– VER – Verification

• Poziom mierzony– QPM – Quantitative

Project Management– OPP – Organizational

Process Performance

• Poziom usprawniany– CAR – Causal Analysis

and Resolution– OIP – Organizational

Innovation and Deployment

Kategorie:SupportProject ManagementProcess ManagementEngineering

Goals and practices• Generic

– GG 1 Achieve Specific Goals– GP 1.1 Perform Specific Practices

– GG 2 Institutionalize a Managed Process – GP 2.1 Establish an Organizational Policy– GP 2.2 Plan the Process– GP 2.3 Provide Resources– GP 2.4 Assign Responsibility– GP 2.5 Train People– GP 2.6 Manage Configurations– GP 2.7 Identify and Involve Relevant Stakeholders– GP 2.8 Monitor and Control the Process– GP 2.9 Objectively Evaluate Adherence– GP 2.10 Review Status with Higher Level Management

– GG 3 Institutionalize a Defined Process– GP 3.1 Establish a Defined Process– GP 3.2 Collect Improvement Information

• Specific

Goals and practices• Generic

• Specific (Configuration Management)– SG 1 Establish Baselines

– SP 1.1 Identify Configuration Items– SP 1.2 Establish a Configuration Management System– SP 1.3 Create or Release Baselines

– SG 2 Track and Control Changes– SP 2.1 Track Change Requests– SP 2.2 Control Configuration Items

– SG 3 Establish Integrity– SP 3.1 Establish Configuration Management Records– SP 3.2 Perform Configuration Audits

Integrated Project Management• SP 1.1Establish the Project’s Defined Process

– Select a lifecycle model– Select the standard processes– Tailor the organization’s set of standard processes and other assets to

produce the project’s defined process– Use other library assets as appropriate– Document the process– Conduct peer reviews– Revice as necessary

Zarządzanie przedsięwzięciem• Zarządzanie

– harmonogramem– konfiguracją – wymaganiami– zasobami– budżetem– ryzykiem– zmianami– jakością

Zarządzanie harmonogramem• WBS – Work Breakdown Structure• Nadzorowanie stanu realizacji• Mierzalne kryteria – kamienie milowe• Analiza wykorzystania zasobów• Akcje naprawcze – „Plan B”

Zarządzanie konfiguracją• Określenie konfiguracji stabilnej• Nadzorowanie zmian• Zapewnienie spójności• Udostępnianie stabilnej wersji wykonawcom, użytkownikom,

klientom itp.

• Plany• Opisy procesów• Wymagania• Diagramy• Moduły kodu• Scenariusze testowe• Dokumentacja

Zarządzanie konfiguracją• Sposób przechowywania i nazywania• Procedury• Narzędzia

Zarządzanie zmianami• Kto ma prawo zgłaszać żądania zmian

• Kto zgłosił zmianę• Powód zmiany i jej ważność• Wpływ zmiany na cechy produktu• Sposób realizacji zmiany• Koszt zmiany i jej wpływ na harmonogram• Tryb realizacji – decyzja • Status realizacji

Wymagania użytkownika• CMMI: celem jest zarządzanie wymaganiami stawianymi

produktom przedsięwzięcia oraz wskazywanie niezgodności między tymi wymaganiami a planami i produktami roboczymi.

• Cykl życia wymagania:– zgłoszenie przez uprawnioną osobę– przegląd i sprecyzowanie, usunięcie sprzeczności– włączenie do planu – zobowiązanie– zarządzanie zmianą

Wymagania użytkownika• Źródła wymagań:

– istniejące procedury– istniejące dokumenty i formularze (wypełnione, z dopiskami i

skreśleniami)– plany rozwoju– wywiady– obserwacja na stanowisku pracy (a także samego stanowiska –

karteczki, kalkulator, notatki)• Wymagania formułowane nieformalnie, w języku

użytkowników• Narzędzia do wspomagania:

– uporządkowanie, nazewnictwo– hierarchia, priorytety, zależności

Wymagania użytkownika• Metody aktywne

– prezentacje istniejących rozwiązań– prototypy i modele– burza mózgów

Wymagania użytkownika• Przykładowe kryteria oceny wymagań:

– zrozumiałe i prawidłowo sformułowane– zupełne– spójne– jednoznacznie zidentyfikowane– możliwe do zrealizowania– możliwe do zweryfikowania/przetestowania– możliwe do prześledzenia w cyklu życia (w obie strony)

Wymagania użytkownika

• Rodzaje wymagań:– funkcjonalne, określające funkcje widoczne

dla użytkowników– pozafunkcjonalne, określające inne cechy –

wydajność, bezpieczeństwo, przenośność, modyfikowalność; zwykle określają informatycy

Wymagania użytkownika

• Functionality – cechy funkcjonalne, bezpieczeństwo

• Usability – ergonomia, estetyka, spójność, dokumentacja

• Reliability – odporność na błędy i awarie, przewidywalność, dokładność

• Performance – szybkość, efektywność, wykorzystanie zasobów, czas odpowiedzi

• Supportability – rozszerzalność, łatwość instalacji, konfigurowania i zarządzania

Wymagania użytkownika

• Rodzaje wymagań:– biznesowe, wynikające z procesu

biznesowego (faktura przed zapłaceniem musi być zaakceptowana przez właściwego kierownika działu)

– implementacyjne, wynikające z konkretnych rozwiązań technicznych (przysłana faktura jest rejestrowana w odpowiedniej księdze w kancelarii ogólnej)

Wymagania użytkownika

Obecnysystem

Docelowysystem

Specyfikacjaobecnegosystemu

Specyfikacjadocelowego

systemu

Zachowaniewymagań

biznesowych

Nowemożliwościtechniczne

Jak to zrobić dobrze?

A software requirement can be defined as:

• A software capability needed by the user to solve a problem or achieve an objective.

• A software capability that must be met or possessed by a system or system component to satisfy a contract, specification, standard, or other formally imposed documentation.

Hierarchia

Atrybuty

ClearQuest

zgłoszenie

RequisitePro

cecha produk tuasocjacja

U se C aseW ym aganie funkc jonalneW ym aganie n iefunkcjonalneG U IProcesy work flowW ym aganie testoweInne...

Przykładowa klasyfikacja

Zależności

Cykl życia wymagania (ITIL)

• Incydent• Problem• Żądanie zmiany• Wykonanie – nowa wersja• Wdrożenie – zmiana konfiguracji

Modelowanie systemu

• Role• Przypadki użycia• Model danych• Diagram czynności• Macierz uprawnień• Opis interfejsów

Dane i funkcjeProgram

dlaadministratora

Programdla

użytkownikaZbiory danychlub obiektów

Nowy programdla

użytkownika

Dostępinternetowy

Zarządzanie ryzykiem• Zidentyfikowanie zagrożeń zanim się zmaterializują• Przygotowanie działań zapobiegawczych i

naprawczych• Ograniczenie wpływu negatywnych zdarzeń na

cele projektu

• Strategia zarządzania• Zidentyfikowanie i analiza• Obsługa zdarzeń• Regularne przeglądy i aktualizacja

Zarządzanie ryzykiem• Ryzyka (wewnętrzne)

– złe oszacowanie czasochłonności – opóźnienie realizacji

– problemy ze stabilnością środowiska produkcyjnego– odejście jednego z programistów

• Zagrożenia (zewnętrzne)– zła współpraca z personelem zamawiającego– zmiana priorytetów po stronie zamawiającego– zmiany w prawie w trakcie realizacji przedsięwzięcia– nieprzewidywany wzrost obciążenia

Zarządzanie ryzykiem• Atrybuty

– prawdopodobieństwo wystąpienia– waga – wpływ na realizację przedsięwzięcia (od

pomijalnego do katastroficznego)– moment wykrycia / pojawienia się

• Sposoby reagowania– unikanie (omijanie)– sterowanie (aktywne)– przeniesienie (transfer – na inne podmioty lub

przedsięwzięcia)– monitorowanie– akceptacja (ryzyko pozostałe – residualne)

Projekt• Ocena i wybór sposobu realizacji, która może spełnić

zaakceptowane wymagania (z kilku wariantów)• Ustalenie szczegółów realizacji, na poziomie

wystarczającym do produkcji• Zakres prototypów• Architektura• Wykorzystanie gotowych produktów (COTS –

Commercial off-the-shelf)• Wykorzystanie posiadanych modułów• Ustalenie konfiguracji (np. bazy danych)

Architektura

• Podział na części i powiązania między nimi• Interfejsy• Podstawowe składniki• Infrastruktura• Wzorce, ramy techniczne• Reguły kodowania, powtórne wykorzystanie• Procesy i wątki, podstawowe algorytmy• Powiązanie oprogramowania i sprzętu

Architektura

Prezentacja – terminal

Logika biznesowa

Dane

Prezentacja

Logika biznesowa

Dane

Prezentacja – przeglądarka

Logika biznesowa

Dane

Prezentacja –przeglądarka

Logika biznesowa

Dane

Terminal Klient – serwer Cienki klient Wielowarstwowa

Projekt

• Baza danych• Podstawowe algorytmy• Opis modułów• Sposób generowania, instalacji,

testowania

Projekt

• Kryteria oceny:– modularność– prostota– jasność– możliwość utrzymania– przenośność– niezawodność– dokładność– bezpieczeństwo– skalowalność– użyteczność

Dokumentacja użytkownika

• Przewodnik – Reference Manual• Podręcznik• Instrukcja stanowiskowa – jak to zrobić (How to)• FAQ• Pomoc kontekstowa (help)• Baza wiedzy dla zespołu wsparcia• Dokumentacja jest podstawą do testów• Konieczność zachowania standardów

Dokumentacja techniczna

• Podręcznik administratora – opis instalacji, konfiguracji, archiwizowania/przywracania

• Opis poszczególnych modułów, bibliotek i interfejsów

• Opis bazy danych• Opis standardów kodowania i

nazewnictwa, zalecenia dot. modyfikacji

Organizacja zespołu• Kierownictwo (administracyjne i techniczne)• Partner jakości• Zespoły produkcyjne• Administracja i utrzymanie środowiska

Zespół głównego programisty• Różnica w wydajności programistów 1:10 (raczej

rzemiosło i sztuka niż masowa produkcja)• Zespół chirurgiczny• IBM – New York Times (późne ‘60)• Zespół

– główny programista (83.000 wierszy kodu w ciągu roku, na kartach perforowanych!)

– zapasowy programista– administrator– asystent narzędziowy– asystent techniczny

Kolejne próby były mało udane

Manifesto for Agile Software Development (2001)

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools Working software over comprehensive documentation

Customer collaboration over contract negotiation Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Metodyki zwinne (Agile)• Satysfakcja klienta dzięki wczesnemu i częstemu

dostarczaniu wartościowego oprogramowania• Zachęcanie do zgłaszania zmian, nawet w późnym okresie• Dostarczanie oprogramowania co kilka tygodni (w

najgorszym przypadku – co kilka miesięcy)• Codzienna bliska współpraca użytkowników i programistów• Budowanie przedsięwzięć wokół zmotywowanych,

zaufanych indywidualności• Wiara z osobiste przekazywanie wiedzy• Miarą sukcesu jest działający program (a nie np.

dokumentacja)

Metodyki zwinne (Agile)• Stały rozwój, utrzymujący się w czasie.• Stałe utrzymywanie doskonałości technicznej i dobrego

projektowania.• Nacisk na prostotę – maksymalizowanie ilości pracy,

która nie musi być wykonana.• Samoorganizacja zespołów zapewniająca najlepszą

architekturę, wymagania i projekt.• Regularne auto-przeglądy – jak pracować efektywniej,

połączone z dostrajaniem i dostosowywaniem.

Walidacja• Czy wybrane produkty spełniają zamierzony cel

użytkowy działając w zamierzonym środowisku? (Zrobiłeś to, co trzeba)

• Dotyczy przedmiotów i usług (np. dokumentacja, szkolenia, migracja danych)

• Do decyzji: które produkty i w jakim środowisku mają być walidowane, jakie procedury, jakie kryteria oceny

• Prototypy, beta-testy, pilotaże, symulacje

Weryfikacja• Czy produkty spełniają odpowiednie spisane

wymagania? (Zrobiłeś to prawidłowo)• Weryfikacja ze wszystkimi wymaganiami

TestyD

ane

Program

Czarna skrzynka

Wyn

iki

Możliwie różnorodne przypadki biznesowe

- na podstawie analizy

Jak testować reakcję na błędy?

Na pozór podobne przypadki mogą być różnie obsługiwane

TestyD

ane if (a<b) then {A}

else if (a=b) then {B}else if (a>b) then {C}...for (i=k; i<z; i++) {D}

Biała skrzynka

Wyn

iki

Pokrycie ścieżek sterowania: a<ba=ba>bk>z- na podstawie projektu

„Te dwa przypadki na pewno są identyczne, nie trzeba tego testować, tu na pewno nie ma błędu.”

– Programista

Testowanie

• Testy komponentów (w środowisku!)• Testy integracyjne (stabilność)• Testy akceptacyjne (spełnienie wymagań)• Testy regresji• Testy wydajności, bezpieczeństwa itp.

Testowanie

• Plan testów• Przygotowanie danych• Scenariusze (skrypty)• Automatyzacja

Inspekcja kodu• Czy nazwa każdego obiektu jest zgodna z

instrukcją?• Czy każda zmienna jest zainicjowana?• Czy każda pętla jest opisana a jej warunek

wyjściowy można zweryfikować?• Czy każda pętla zachowa się poprawnie jeśli

warunek nie będzie spełniony na wejściu?• Czy każdy wskaźnik przyjmuje wartości

odpowiedniego typu?• Czy każdy wyjątek jest prawidłowo obsłużony?

Integracja produktu• Określenie kolejności zadań• Zapewnienie środowiska• Zapewnienie procedur i kryteriów gotowości

• stan testów• weryfikacja interfejsów• pomiary wydajności• dostępność personelu

• Scalenie i dostarczenie produktu

Czynności powdrożeniowe

• Serwis gwarancyjny – naprawa oraz usuwanie błędów, czyli niezgodności ze specyfikacją

• Utrzymanie (pielęgnacja) – usuwanie niezgodności z faktycznymi potrzebami

• Modernizacja – uwzględnianie zmian w środowisku

• Rozwój (nowe funkcjonalności)

• Oprogramowanie nie psuje się!

Czynności powdrożeniowe

StarośćŚmiertelność niemowlęca Dojrzałość

Koszt: 20 – 40% rocznie

Utrzymanie i modernizacja

Gwarancja Migracja

1 rok5 lat

• nowe doświadczenia

• zmiany w prawie

• zmiany organizacyjne

• zmiany technologiczne

• funkcje odroczone

• błędy

Gwarancja

Oryginalne moduły

Zmienione lub nowe moduły

Problem

Gwarancja

Oryginalny kod

Zmiany

Poprawki

Działania dodatkowe

• Migracja danych• Wsparcie użytkowników

– różne kanały– kolejne linie wsparcia

Sposoby wyceny

• Wycenić by wygrać (jak bilety lotnicze…)• Analogia• Metoda ekspercka• Prawo Parkinsona (według zasobów)• Metoda analityczna (KNR – katalog

nakładów rzeczowych)• Metryki• Zawsze potrzebna kalibracja

Szacowanie złożoności

• Bardzo zgrubnie – po analizie wymagań• W miarę dokładnie, ale z założeniami – po

modelowaniu• Dość dokładnie – po projekcie• Dokładnie – po wykonaniu

Dodatkowe czynniki

• Doświadczenie zespołu• Wykorzystanie gotowych komponentów• Wykorzystanie narzędzi CASE i RAD

Punkty funkcyjne (A.J.Albrecht 1979)

• Elementy programu (z modelu funkcjonalnego):– Zewnętrzne dane wejściowe (pliki, formatki)– Zewnętrzne dane wyjściowe (pliki, raporty)– Interakcje z użytkownikiem (zapytania)– Interfejsy do innych programów– Pliki wewnętrzne

• Wagi od 3 do 15 punktów• Dodatkowe czynniki skalujące• Doświadczenie pokazuje, że jest zachowana

liniowość (w pewnym zakresie)

COCOMO II

• Pracochłonność i czas rzeczywisty w funkcji złożoności (nieliniowej)

• Złożoność: wiersze kodu lub punkty funkcyjne• Dodatkowe współczynniki zależne od rodzaju

programu, cech zespołu i środowiska (np. pośpiech)

COSMIC

• Common Software Measurement International Consortium

• ISO/IEC 19761:2003• Podział na moduły funkcjonalne• Identyfikacja

– obiektów danych– przepływów danych z i do modułów (Entry i Exit)– operacji zapisu / odczytu danych (Read i Write)