Pobierz prezentację
Pobieranie prezentacji. Proszę czekać
1
Inżynieria oprogramowania
Jerzy Nawrocki Holenderskie miasteczko Joure widziane z lotu ptaka
2
Definicja Zastosowanie systematycznego, zdyscyplinowanego, ilościowego
podejścia do rozwoju, eksploatacji i utrzymania oprogramowania. IEEE Std IEEE Standard Glossary of Software Eng. Terminology
3
Computing Curricula 2001
4
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
5
Inżynieria oprogramowania
Wymagania Projektowanie Walidacja Ewolucja Procesy Zarządzanie Narzędzia API M.formalne Sys. specjalne Komponenty Niezawodn.
6
Plan wykładu Specyfikacja wymagań Kontrola jakości artefaktów Testowanie oprogramowania Metody formalne Język UML Zarządzanie konfiguracją Programowanie Ekstremalne Systemy krytyczne
7
Cykl życia Wymagania Projekt Wykonanie
8
Wymagania Projekt Wykonanie
Cykl życia Wymagania Projekt Wykonanie
9
Problem i koncepcja rozwiązania
Inżynieria wymagań Problem i koncepcja rozwiązania Wymagania Zbieranie wymagań Analiza wymagań Negocjacja wymagań
10
Inżynieria wymagań Wymagania Wymagania funkcjonalne Wymagania pozafunkcjonalne
11
Podręcznik użytkownika
Artefakty Specyfikacja wymagań Testy akceptacyjne Kod programu Podręcznik użytkownika
12
Kontrola jakości specyfikacji wymagań
Problem i koncepcja rozwiązania Zbieranie wymagań Analiza wymagań Negocjacja wymagań
13
Rodzaje kontroli jakości
Testowanie Przeglądy
14
Testowanie Testowanie oprogramowania jest wykonaniem kodu dla kombinacji danych wejściowych i stanów w celu wykrycia błędów Robert Binder
15
Przypadek testowy (ang. test case)
Testowanie Przypadek testowy (ang. test case) Testowany system Dane wejściowe Zaobserwowane wyjście Stan wstępny
16
Testowanie Testowany system Oczekiwane wyjście Faktyczne wyjście
Wynik testowania Dane wejściowe Porównanie Testowany system Stan wstępny
17
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.
18
Pracochłonność testowania
Testowanie: ~ % % całkowitej pracochłonności. Testowanie systemów krytycznych: 70% - 80% całkowitej pracochłonności (!) -- Roger Pressman’97 Roger S. Pressman
19
Metody formalne Program Przetestuję. Czy on jest poprawny?
Przeczytam. Udowodnię.
20
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
21
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! ***/
22
Dowodzenie poprawności programów
Specyfikacja 5 000 LOC 7 000 LOC Wolfgang Reif
24
Diagramy UML Diagramy stanów Diagramy przypadków użycia Diagramy sekwencji Diagramy czynności Diagramy klas . . .
25
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
26
Diagram przypadków użycia
Złożenie podania Maturzysta Obejrzenie wyników rekrutacji Zakwalifikowany Nieprzyjęty
27
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
28
Diagramy języka UML
29
Najprostszy system zarządzania zmianami
Zmieńmy wymagania. OK. OK. OK. OK. Programiści Klient
30
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ą
31
Koncepcja systemu zarządzania konfiguracją
Program System zarz. konfiguracją
32
Kryzys oprogramowania
Przekraczanie terminów Przekraczanie budżetu Nadgodziny Kiepska jakość Kryzys
33
Reakcja na kryzys oprogramowania
34
Lekkie metodyki tworzenia oprogramowania
35
Główne zalety Programowania Ekstremalnego
To lubię! Najważniejsza komunikacja ustna. Jedyne artefakty: kod + testy Żadnych nadgodzin!
36
Therac-25 AECL (Atomic Energy Canada Limited) Naświetlanie rentgenowskie – leczenie raka 6 poparzeń (niektóre ze skutkiem śmiertelnym)
37
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
38
Kod etyczno-zawodowy ACM Code of Ethics and Professional Conduct Adopted by ACM Council 10/16/92.
39
Kod etyczno-zawodowy 1. Ogólne nakazy moralne 2. Odpowiedzialność zawodowa 3. Nakazy przywództwa organizacyjnego 4. Zgodność z kodem etyczno-zawodowym
40
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.
41
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?
42
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
Podobne prezentacje
© 2024 SlidePlayer.pl Inc.
All rights reserved.