Wytwrstwo oprogramowania Jarosaw Deminet Powszechna wiedza Komputery s

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 Po co? Strategia biznesowa Czego chcą? Co zrobić? Wymagania Specyfikacja Jak? Projekt Wykonanie i wdrożenie Czy warto?

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 polska Biuro 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 prototypy Analiza Projekt Wykonanie Wdrożenie Analiza Mniejsze ryzyko za znaną cenę Projekt Wykonanie Wdrożenie Analiza Projekt Wykonanie Wdrożenie

Model spiralny

Model V

Techniki ekstremalne Analiza Projekt Wykonanie Analiza Wdrożenie Projekt Analiza Wykonanie Analiza Wdrożenie Projekt Wdrożenie 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 4 P: 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) Firma (procesy wytwórcze) Produkt Klienci Dostawcy Kontrola jakości (testy)

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

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ści Kategoria Mediana korzyści Koszt 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: Support Project Management Process Management Engineering

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. 1 Establish 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 Obecny system Specyfikacja obecnego systemu Docelowy system Zachowanie wymagań biznesowych Jak to zrobić dobrze? Specyfikacja docelowego systemu Nowe możliwości techniczne

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

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 funkcje Program dla administratora Nowy program dla użytkownika Zbiory danych lub obiektów Dostęp internetowy Program dla użytkownika

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

Program Możliwie różnorodne przypadki biznesowe - na podstawie analizy Wyniki Dane Testy Jak testować reakcję na błędy? Czarna skrzynka Na pozór podobne przypadki mogą być różnie obsługiwane

if (a<b) then {A} else if (a=b) then {B} else if (a>b) then {C}. . . for (i=k; i<z; i++) {D} Pokrycie ścieżek sterowania: a<b a=b a>b k>z - na podstawie projektu Biała skrzynka Wyniki Dane Testy „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 psuje się!

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

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

Gwarancja Oryginalny kod Poprawki Zmiany

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)