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)
Top Related