Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

Wytwórstwo oprogramowania Jarosław Deminet. Powszechna wiedza Komputery są wszystkiemu winne, czyli jak działa czarownica (Prawo Demineta) Informatyka.

Podobne prezentacje


Prezentacja na temat: "Wytwórstwo oprogramowania Jarosław Deminet. Powszechna wiedza Komputery są wszystkiemu winne, czyli jak działa czarownica (Prawo Demineta) Informatyka."— Zapis prezentacji:

1 Wytwórstwo oprogramowania Jarosław Deminet

2 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)

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

4 Kłopoty Jak opisać zakres (zmiany są pewne!) Jak oszacować czas Jak oszacować budżet

5 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

6 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

7 Nie my jedni mamy problemy Lotnisko w Atlancie –1977 – 1980 zgodnie z czasem i budżetem (500 M $) –2003 – 20?? wpadka

8 Cykl życia Czego chcą? Co zrobić? Jak? Strategia biznesowa Wymagania Specyfikacja Projekt Wykonanie i wdrożenie Czy warto? Po co?

9 Ocena kosztów Po fakcie (wariant amerykański) –za roboczogodzinę –za wiersz kodu –za formatkę ekranową Trudna ocena efektywności Konsekwencja: ucieczka za granicę

10 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

11 Informatyka a sprawa polska Biuro na tranzystorach –premiera – 1955 = 1,5 pokolenia Nowa (normalna) ekonomia i organizacja + nowa technika Od wołu do automatycznej skrzyni biegów

12 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?

13 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!!!

14 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ć?

15 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

16 Jest tyle spokojniejszych zawodów, np. można być pogromcą lwów (I zasada Stokalskiego)

17 Model wodospadu Analiza (specyfikacja) Projekt Wykonanie Wdrożenie Zintegrowany System X

18 Iteracje i prototypy Analiza Projekt Wykonanie Wdrożenie Analiza Projekt Wykonanie Wdrożenie Analiza Projekt Wykonanie Wdrożenie Mniejsze ryzyko za znaną cenę

19 Model spiralny

20 Model V

21 Techniki ekstremalne Analiza Projekt Wykonanie Wdrożenie Analiza Projekt Wykonanie Wdrożenie Analiza Projekt Wykonanie WdrożenieAnaliza Projekt Wykonanie Wdrożenie Analiza Projekt Wykonanie Wdrożenie

22 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ą

23 Rational Unified Process

24 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)

25 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

26 Jakość (podejście tradycyjne) Dostawcy Klienci Kontrola jakości (testy) Firma (procesy wytwórcze) Produkt

27 Jakość (podejście kompleksowe, TQM) Dostawcy Klienci Zapewnienie jakości (organizacja) Firma (procesy wytwórcze) Produkt

28 Trzy zasady Podejście systemowe – łańcuch jakości Udział wszystkich pracowników – współpraca i życzliwość Ciągłe doskonalenie

29 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)

30 ISO 9001: Zarządzanie zasobami Ludzie –wykształcenie –szkolenie –umiejętności –doświadczenie Infrastruktura Środowisko

31 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

32 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

33 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

34 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)

35 CMMI – korzyści KategoriaMediana korzyści Koszt34% Terminowość50% Efektywność61% Jakość48% Zadowolenie klienta14% Zwrot z inwestycji4:1

36 Capability Maturity Model Integration

37 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: Support Project Management Process Management Engineering

38 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

39 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

40 Integrated Project Management SP 1.1Establish the Projects Defined Process –Select a lifecycle model –Select the standard processes –Tailor the organizations set of standard processes and other assets to produce the projects defined process –Use other library assets as appropriate –Document the process –Conduct peer reviews –Revice as necessary

41 Zarządzanie przedsięwzięciem Zarządzanie –harmonogramem –konfiguracją –wymaganiami –zasobami –budżetem –ryzykiem –zmianami –jakością

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

43 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

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

45 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

46 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ą

47 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

48 Wymagania użytkownika Metody aktywne –prezentacje istniejących rozwiązań –prototypy i modele –burza mózgów

49 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)

50 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

51 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

52 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)

53 Wymagania użytkownika Obecny system Docelowy system Specyfikacja obecnego systemu Specyfikacja docelowego systemu Zachowanie wymagań biznesowych Nowe możliwości techniczne Jak to zrobić dobrze?

54 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.

55 Hierarchia

56 Atrybuty

57 Przykładowa klasyfikacja

58

59 Zależności

60 Cykl życia wymagania (ITIL) Incydent Problem Żądanie zmiany Wykonanie – nowa wersja Wdrożenie – zmiana konfiguracji

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

62 Dane i funkcje Program dla administratora Program dla użytkownika Zbiory danych lub obiektów Nowy program dla użytkownika Dostęp internetowy

63 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

64 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

65 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)

66 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)

67 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

68 Architektura Prezentacja – terminal Logika biznesowa Dane Prezentacja Logika biznesowa Dane Prezentacja – przeglądarka Logika biznesowa Dane Prezentacja – przeglądarka Logika biznesowa Dane TerminalKlient – serwerCienki klientWielowarstwowa

69 Projekt Baza danych Podstawowe algorytmy Opis modułów Sposób generowania, instalacji, testowania

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

71 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

72 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

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

74 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 ( 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

75 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.

76 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)

77 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.

78 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

79 Weryfikacja Czy produkty spełniają odpowiednie spisane wymagania? (Zrobiłeś to prawidłowo) Weryfikacja ze wszystkimi wymaganiami

80 Testy Dane Program Czarna skrzynka Wyniki 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

81 Testy Dane if (ab) then {C}...for (i=k; ib k>z - na podstawie projektu Te dwa przypadki na pewno są identyczne, nie trzeba tego testować, tu na pewno nie ma błędu. – Programista

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

83 Testowanie Plan testów Przygotowanie danych Scenariusze (skrypty) Automatyzacja

84 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?

85 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

86 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ę!

87 Czynności powdrożeniowe Starość Śmiertelność niemowlęca Dojrzałość Koszt: 20 – 40% rocznie Utrzymanie i modernizacja Gwarancja Migracja 1 rok 5 lat nowe doświadczenia zmiany w prawie zmiany organizacyjne zmiany technologiczne funkcje odroczone błędy

88 Gwarancja Oryginalne moduły Zmienione lub nowe moduły Problem

89 Gwarancja Oryginalny kod Zmiany Poprawki

90 Działania dodatkowe Migracja danych Wsparcie użytkowników –różne kanały –kolejne linie wsparcia

91 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

92 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

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

94 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)

95 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)

96 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)


Pobierz ppt "Wytwórstwo oprogramowania Jarosław Deminet. Powszechna wiedza Komputery są wszystkiemu winne, czyli jak działa czarownica (Prawo Demineta) Informatyka."

Podobne prezentacje


Reklamy Google