Wytwórstwo oprogramowania

Prezentacja na temat: "Wytwórstwo oprogramowania"— 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 Czy warto? Strategia biznesowa Wymagania Specyfikacja
Po co? Strategia biznesowa Czego chcą? Wymagania Co zrobić? Specyfikacja Jak? Projekt Wykonanie i wdrożenie Czy warto?

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 1989 – 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 Analiza (specyfikacja)
Model wodospadu Analiza (specyfikacja) Projekt Wykonanie Wdrożenie Zintegrowany System X

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

19 Model spiralny

20 Model V

21 Techniki ekstremalne Analiza Projekt Wykonanie Analiza Wdrożenie

22 Metodyki produkcji Lekkie (giętkie) 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)
Kontrola jakości (testy) Dostawcy Klienci Firma (procesy wytwórcze) Produkt

27 Jakość (podejście kompleksowe, TQM)
Zapewnienie jakości (organizacja) Dostawcy Klienci 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ść Odpowiedzialni Adresaci (dostępność)
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 Kategoria Mediana korzyści Koszt 34% Terminowość 50%
Efektywność 61% Jakość 48% Zadowolenie klienta 14% Zwrot z inwestycji 4:1

36 Capability Maturity Model Integration

37 Process Areas Poziom zarządzany Poziom definiowany Poziom mierzony
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 Specific 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 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

41 Zarządzanie przedsięwzięciem
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 Zachowanie wymagań biznesowych Specyfikacja obecnego systemu Specyfikacja docelowego systemu 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 Nowy program dla użytkownika
Zbiory danych lub obiektów 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) Zagrożenia (zewnę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 Sposoby reagowania
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 Prezentacja
Prezentacja – przeglądarka Prezentacja – przeglądarka Logika biznesowa Logika biznesowa Logika biznesowa Logika biznesowa Dane Dane Dane Dane Terminal Klient – serwer Cienki klient Wielowarstwowa

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 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 Czarna skrzynka

81 Testy Dane Wyniki Pokrycie ścieżek sterowania: a<b
if (a<b) then {A} else if (a=b) then {B} else if (a>b) then {C} ... for (i=k; i<z; i++) {D} Wyniki Pokrycie ścieżek sterowania: a<b a=b a>b k>z - na podstawie projektu „Te dwa przypadki na pewno są identyczne, nie trzeba tego testować, tu na pewno nie ma błędu.” – Programista Biała skrzynka

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
Utrzymanie i modernizacja Gwarancja Migracja błędy nowe doświadczenia zmiany w prawie zmiany organizacyjne zmiany technologiczne funkcje odroczone 1 rok 5 lat Śmiertelność niemowlęca Dojrzałość Koszt: 20 – 40% rocznie Starość

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

89 Gwarancja Oryginalny kod Poprawki Zmiany

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)