Inżynieria oprogramowania Jerzy Nawrocki www.cs.put.poznan.pl/jnawrocki/wdi  Holenderskie miasteczko Joure widziane z lotu ptaka

Definicja Zastosowanie systematycznego, zdyscyplinowanego, ilościowego podejścia do rozwoju, eksploatacji i utrzymania oprogramowania. IEEE Std 610.12-1990 IEEE Standard Glossary of Software Eng. Terminology

Computing Curricula 2001

Computing Curricula 2001 Struktury dyskretne Podstawy programowania Algorytmy i złożoność Architektura sys. komputerowych Systemy operacyjne Technologie sieciowe Języki i paradygmaty program. Komunikacja człowiek-komputer Grafika komputerowa Sztuczna inteligencja Bazy danych Problemy społeczne i zawodowe Inżynieria oprogramowania Nauki obliczeniowe

Inżynieria oprogramowania Wymagania Projektowanie Walidacja Ewolucja Procesy Zarządzanie Narzędzia API M.formalne Sys. specjalne Komponenty Niezawodn.

Plan wykładu Specyfikacja wymagań Kontrola jakości artefaktów Testowanie oprogramowania Metody formalne Język UML Zarządzanie konfiguracją Programowanie Ekstremalne Systemy krytyczne

Cykl życia Wymagania Projekt Wykonanie

Wymagania Projekt Wykonanie Cykl życia Wymagania Projekt Wykonanie http://groups.sims.berkeley.edu/CDE-Events/SMJ-UML.jpg

Problem i koncepcja rozwiązania Inżynieria wymagań Problem i koncepcja rozwiązania Wymagania Zbieranie wymagań Analiza wymagań Negocjacja wymagań

Inżynieria wymagań Wymagania Wymagania funkcjonalne Wymagania pozafunkcjonalne

Podręcznik użytkownika Artefakty Specyfikacja wymagań Testy akceptacyjne Kod programu Podręcznik użytkownika

Kontrola jakości specyfikacji wymagań Problem i koncepcja rozwiązania Zbieranie wymagań Analiza wymagań Negocjacja wymagań

Rodzaje kontroli jakości Testowanie Przeglądy

Testowanie Testowanie oprogramowania jest wykonaniem kodu dla kombinacji danych wejściowych i stanów w celu wykrycia błędów Robert Binder

Przypadek testowy (ang. test case) Testowanie Przypadek testowy (ang. test case) Testowany system Dane wejściowe Zaobserwowane wyjście Stan wstępny

Testowanie Testowany system Oczekiwane wyjście Faktyczne wyjście Wynik testowania Dane wejściowe Porównanie Testowany system Stan wstępny

Cele testowania wg Glena Myersa (1979) Jakość przypadku testowego: prawdopodob. znalezienia jeszcze nie wykrytego błędu. Udany test : taki, który wykrywa jeszcze nie wykryty błąd.

Pracochłonność testowania Testowanie: ~ % - % całkowitej pracochłonności. 30 40 Testowanie systemów krytycznych: 70% - 80% całkowitej pracochłonności (!) -- Roger Pressman’97 Roger S. Pressman

Metody formalne Program   Przetestuję. Czy on jest poprawny? Przeczytam. Udowodnię.  

Ograniczenia testowania Testowaniem można wykazać, że błędy są, ale nie można w ten sposób pokazać, że ich nie ma. E.W. Dijkstra

Silnia int Silnia (int n) { /*** PRE n >= 0 ***/ int k, s; k= 0; s= 1; /*** INV s== k! ***/ while (k != n) { k= k + 1; s= s * k; /*** INV s== k! ***/ } return s; /*** POST s== n! ***/

Dowodzenie poprawności programów Specyfikacja 5 000 LOC 7 000 LOC Wolfgang Reif

www.uml.org

Diagramy UML Diagramy stanów Diagramy przypadków użycia Diagramy sekwencji Diagramy czynności Diagramy klas . . .

Diagram stanów /Zdanie Matury Maturzysta /Złożenie podania na studia Kandydat Nieprzyjęty Zakwalifikowany /Złożenie oryginału świadectwa Przyjęty /Złożenie ślubowania Student

Diagram przypadków użycia Złożenie podania Maturzysta Obejrzenie wyników rekrutacji Zakwalifikowany Nieprzyjęty

Diagram sekwencji Maturzysta System rekrutacji KReM Składa podanie i wprowadza oceny Czy oceny są poprawne? Są poprawne Potwierdza przyjęcie podania i ocen Wnosi opłatę rekrutacyjną Potwierdza przyjęcie opłaty

Diagramy języka UML

Najprostszy system zarządzania zmianami Zmieńmy wymagania. OK. OK. OK. OK. Programiści Klient

Formalne podejście do zarządzania zmianami Żądanie zmiany Żądanie zmiany Err Użytkownik Kierownik konfig. Programista Raport Tak Kierownik projektu Żądanie zmiany Decyzja Komitet Zarządzania Konfiguracją

Koncepcja systemu zarządzania konfiguracją Program System zarz. konfiguracją

Kryzys oprogramowania Przekraczanie terminów Przekraczanie budżetu Nadgodziny Kiepska jakość Kryzys

Reakcja na kryzys oprogramowania

Lekkie metodyki tworzenia oprogramowania

Główne zalety Programowania Ekstremalnego To lubię! Najważniejsza komunikacja ustna. Jedyne artefakty: kod + testy Żadnych nadgodzin!

Therac-25 AECL (Atomic Energy Canada Limited) Naświetlanie rentgenowskie – leczenie raka 1983-87 6 poparzeń (niektóre ze skutkiem śmiertelnym)

Therac-25: Przyczyny Personel AECL początkowo zaprzeczał błędom Brak niezależnej inspekcji oprogramowania Brak zabezpieczeń sprzętowych Beztroskie powtórne użycie kodu Założono, że sensory zawsze dobrze działają Błąd programistyczny

Kod etyczno-zawodowy ACM Code of Ethics and Professional Conduct Adopted by ACM Council 10/16/92. http://www.acm.org/constitution/code.html

Kod etyczno-zawodowy 1. Ogólne nakazy moralne 2. Odpowiedzialność zawodowa 3. Nakazy przywództwa organizacyjnego 4. Zgodność z kodem etyczno-zawodowym

2. Odpowiedzialność zawodowa 2.1 Starać się osiągać najwyższą jakość w odniesieniu do procesu i produktu. 2.2 Pozyskiwać i pielęgnować kompetencje zawodowe. 2.3 Znać i respektować istniejące prawo związane z pracą zawodową. 2.4 Akceptować i realizować przeglądy o charakterze zawodowym. 2.5 Dostarczać dogłębne oceny systemów komputerowych i związanego z nimi ryzyka. 2.6 Respektować kontrakty, uzgodnienia i związaną z nimi odpowiedzialność. 2.7 Doskonalić publiczne rozumienie informatyki. 2.8 Nie korzystać z zasobów, bez upoważnienia.

Budowa systemów krytycznych Utwórz listę kontrolną dla wymagań dot. bezpieczeństwa Czy system startuje w stanie bezpiecznym? Czy ważne zmienne mają nadane wart. pocz? Co się dzieje, gdy system jest odłączony? Co się dzieje, gdy reakcja jest spóźniona? Jaki wpływ mają nieoczekiwane wejścia? Jak można wycofać komendę operatora? Jak przechodzi się do stanu fail-safe?

Budowa systemów krytycznych Utwórz listę kontrolną dla wymagań dot. bezpieczeństwa Włącz do procesu walidacji zewnętrznych ekspertów HAZOP Identyfikuj i analizuj hazardy