1 Wytwórstwo oprogramowaniaJarosł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ć czasJak 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 problemyEurotunel 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 problemyLotnisko w Atlancie 1977 – 1980 zgodnie z czasem i budżetem (500 M $) 2003 – 20?? wpadka
8 Cykl życia Czy warto? Strategia biznesowa Wymagania SpecyfikacjaPo 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ówPrzewidywanie 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 polskaBiuro 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ówObsł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 PolicjiZdarzenie 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 AirbusieCią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 ProjektWykonanie 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) KlasyczneProgramowanie 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ściUdział 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 zasobamiLudzie wykształcenie szkolenie umiejętności doświadczenie Infrastruktura Środowisko
31 ISO 9001: Realizacja wyrobuPlanowanie 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 wyrobuProjektowanie 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 wyrobuProdukcja 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 mierzonyCM - 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 GoalsGP 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 ManagementSP 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ęciemharmonogramem konfiguracją wymaganiami zasobami budżetem ryzykiem zmianami jakością
42 Zarządzanie harmonogramemWBS – 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 zmianKto 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żytkownikaCMMI: 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żytkownikaMetody aktywne prezentacje istniejących rozwiązań prototypy i modele burza mózgów
49 Wymagania użytkownikaPrzykł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żytkownikaRodzaje 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żytkownikaFunctionality – 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żytkownikaRodzaje 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żytkownikaObecny 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 danychDiagram czynności Macierz uprawnień Opis interfejsów
62 Dane i funkcje Program dla administratora Nowy program dla użytkownikaZbiory 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 reagowaniaprawdopodobień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 InterfejsyPodstawowe 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 PrezentacjaPrezentacja – 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łówSposó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żytkownikaPrzewodnik – 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 technicznaPodrę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 programistyRóż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
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 środowiskaZapewnienie 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żenioweSerwis 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żenioweUtrzymanie 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łykolejne linie wsparcia
91 Sposoby wyceny Wycenić by wygrać (jak bilety lotnicze…) AnalogiaMetoda ekspercka Prawo Parkinsona (według zasobów) Metoda analityczna (KNR – katalog nakładów rzeczowych) Metryki Zawsze potrzebna kalibracja
92 Szacowanie złożonościBardzo 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łuWykorzystanie 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 ConsortiumISO/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)