Definicja Inżynierii Oprogramowania
Wiedza techniczna dotycząca faz cyklu życia projektu, mająca na celu uzyskanie wysokiej jakości oprogramowania.
Przyczyny Kryzysu Oprogramowania
- Duża złożoność systemów informatycznych
- Niepowtarzalność przedsięwzięć
- Nieprzejrzystość procesu budowy oprogramowania
- Pozorna łatwość wytwarzania i dokonywania poprawek
Definicja projektu
Zarządzany zbiór zadań zmierzających do jednego celu, wykonywany przy określonych ograniczeniach.
Cykl życia projektu (SDLC – System Development Life Cycle) – sekwencja następujących po sobie faz projektowych, zmierzających do wytworzenia oprogramowania
Model kaskadowy
Podział prac nad projektem na fazy. Sam nie jest często wykorzystywany – stanowi bazę dla innych modeli.
Fazy:
- Określenie wymagań
- Projektowanie
- Implementacja
- Testowanie
- Konserwacja
Zalety:
- Ułatwia zarządzanie projektem
- -||- planowanie, harmonogramowanie i monitorowanie przedsięwzięć.
Wady:
- Brak weryfikacji
- Brak elastyczności – nie sprzyja wprowadzaniu zmian
- Wysokie koszty błędów we wczesnych fazach
- Długie przerwy w kontakcie z klientem
- Zbytni formalizm i ścisła kolejność prac
Model kaskadowy “kierowany dokumentami”
Każda faza kończy się sporządzeniem dokumentacji, którą zatwierdza klient, przed przejściem do kolejnej fazy. Możliwość realizacji kolejnych faz przez inne firmy. 50% nakładu pracy to sporządzanie dokumentacji dla klienta.
Model typu V
Modyfikacja modelu kaskadowego, podkreślająca wagi weryfikacji i walidacji systemu. Każdej fazie odpowiadają testy. Każda linia pozioma wskazuje, że w procesach wytwórczych powstają od razu plany testów danego modułu/podsystemu/systemu.
Fazy:
- Specyfikacja – Testy akceptacji
- Projekt systemu – Integracja i walidacja systemu
- Projekt podsystemu – Integracja i walidacja podsystemu
- Projekt modułu – Formalne testy modułu
Model spiralny
Podział realizacji projektu na kroki uwzględniające ryzyko realizacji. Zadania realizowane są zgodnie z modelem kaskadowym. Każda kolejna faza projektu poprzedzona jest określeniem celów, ograniczeń i oceną ryzyka.
Kroki wykonywane dla każdej fazy modelu bazowego (np. kaskadowego):
- Określenie celów i ograniczeń
- Ocena ryzyka
- Tworzenie i weryfikacja kolejnej fazy modelu bazowego
- Planowanie następnej fazy
Prototypowanie
Przed przystąpieniem do realizacji projektu, budowany jest prototyp. Polecane przy budowie nowych dla firmy/projektanta rozwiązań. Pozwala poznać potrzeby klienta, łatwiej wykryć nieporozumienia i braki w specyfikacji. Wady: większe koszty, klient na początku otrzymuje “niemal gotowy projekt”, a później musi czekać i ponosić koszty, w trakcie tworzenia wersji finalnej.
Projektowanie odkrywcze
- Określenie wymagań
- Budowanie systemu
- Weryfikacja przez klienta
- Czy działa poprawnie? Nie – powrót do budowy
- Testowanie
Realizacja przyrostowa
Dostarczenie klientowi nieukończonego projektu i jego stopniowe rozwijanie w kolejnych cyklach – dodawanie funkcjonalności, aż projekt zostanie ukończony.
Modele konceptualne – strukturalne metody analizy:
ERD – Diagram związków encji
Pokazuje powiązania i atrybuty obiektów w systemie.
Konstruktory: Encja, Atrybut, Związek
ENCJA – reprezentuje obiekty materialne i konceptualne
- Encja słaba – nie posiada własnego klucza, jest związana z silną
- Encja silna – posiada własny klucz
- Encja asocjacyjna – łączy encje w relacji m:n
ATRYBUT – modeluje własność encji. Może:
- identyfikować
- opisywać
- klasyfikować
- określać ilość
- wrażać stan
ZWIĄZEK – połączenie pomiędzy encjami
- Stopień: unarny, binarny, ternarny
- Typ asocjacji: 1:1, 1:n, m:n
- Klasa przynależności: opcjonalna, obowiązkowa
DFD – Diagram przepływu danych
Pokazuje przepływ danych między różnymi funkcjami/modułami systemu.
Konstruktory:
- Terminatory – obiekty zewnętrzne – są źródłem danych
- Składnice danych – magazyny – przechowują dane, można je odczytywać i zapisywać
- Procesy – dokonują transformacji danych
- Przepływy – linii łączące obiekty, którymi przesyłane są dane
Diagramy hierarchiczne (kolejne poziomy):
- kontekstowy – cały system przedstawiony jako jeden proces połączony z terminatorami i ew. składnicami zewnętrznymi
- ogólny (zerowy) – najbardziej ogólny diagram (poziom 0)
- n poziomu…
Liczba poziomów nie powinna przekraczać 7+2.
Specyfikacja procesu w diagramach DFD
– opis tego co dzieje się wewnątrz każdego elementarnego procesu – co należy zrobić w celu przekształcenia wejścia w wyjście.
Metody rozwijania hierarchicznych DFD:
- top-down
- bottom-up
- hybrydowe
STD – Diagram przejść przez stany
Pokazuje zachowanie systemu w czasie.
Konstruktory:
- Zdarzenie – informuje o tym co wydarzyło się w danej chwili (ma zerowy czas trwania)
zewnętrzne – z poza systemu – np. wprowadzenie danych przez użytkownika
wewnętrzne – źródło mają w systemie – np. wyjątek lub błąd dzielenia - Stan – czas między zdarzeniami, system różnie reaguje na zdarzenia będąc w różnych stanach
- Przejście – zmiana stanu wywołana przez zdarzenie
- Akcja – czynność wywoływana w momencie zdarzenia (np. wykonanie obliczeń)
- Operacja – ciągła czynność wykonywana w danym zdarzeniu
Zarządzanie jakością
Polityka jakości – deklaracja podpisana przez kierownictwo projektu, wskazująca kierunki działań projakościowych.
Kryteria jakości – zestaw cech na podstawie których oceniana jest jakość produktu.
Zapewnienie jakości – wszystkie działania które są niezbędne do uzyskania i utrzymania odpowiedniego stopnia wiarygodności że produkt spełni wymagania jakości. Fazy: Planowanie, Nadzorowanie, Doskonalenie
Walidacja – proces oceny oprogramowania na zakończenie produkcji lub jej fazy, w celu sprawdzenia czy jest wolny od błędów i niezgodności.
Weryfikacja – proces sprawdzenia czy produkt danej fazy produkcji spełnia postawione mu wymagania.
Model jakości McCalla
– model składający się z obszarów, czynników i metryk jakości, służący do oceny jakości oprogramowania, prezentujący problem z perspektywy producenta.
Obszar: Działanie programu
- Przyjazność/użyteczność
- Bezpieczeństwo/integralność
- Wydajność (efficiency)
- Poprawność (correctness)
- Niezawodność/wiarygodność (reliability)
Obszar: Przystosowanie do modyfikacji
- Pielęgnowalność (maintainability)
- Elastyczność (fexibility)
- Testowalność (testability)
Obszar: Mobilność oprogramowania
- Przenośność (portability)
- Uniwersalność, możliwość powtórnego wykorzystania (reusability)
- Otwartość, łatwość współdziałania (interoperability)
Norma ISO 9126
- Funkcjonalność
- Niezawodność
- Użyteczność
- Wydajność
- Pielęgnowalność
- Przenośność
Miary niezawodności oprogramowania
- Prawdopodobieństwo wystąpienia błędnego wykonania podczas realizacji transakcji
- Częstotliwość występowania błędnych wykonań
- Średni czas między błędnymi wykonaniami
- Dostępność systemu – prawdopodobieństwo że system akurat będzie działał :-)
Logarytmiczny model wzrostu niezawodności oprogramowania
Wraz ze wzrostem liczby wykonywanych testów częstotliwość występowania błędnych wykonań spada logarytmicznie.
Testowanie
– proces sprawdzania/oceny czy produkt lub jego część jest “dobra”.
Testy statystyczne
Generujemy losową populację danych wejściowych (z odpowiednim rozkładem) i sprawdzamy czy system zwraca prawidłowe wyniki dla tych danych.
Testy funkcjonalne
System traktujemy jako czarną skrzynkę, która w nieznany sposób realizuje różne funkcje. Sprawdzamy działanie funkcji dla wszystkich dopuszczalnych warunków wejściowych i opcji, danych na granicach wejść i wyjść, a także danych niepoprawnych.
Testy strukturalne
Zakładamy znajomość sposobu implementacji funkcji (white box). Podajemy na wejście takie dane żeby program przeszedł przez każdą zaimplementowaną ścieżkę – ify, pętle.
Testy statyczne
Analiza kodu bez jego uruchamiania. Są dużo efektywniejsze niż testy strukturalne. Śledzimy przebieg działania programu, udowadniamy jego poprawność i wyszukujemy typowych błędów – np. niezainicjalizowane zmienne, porównania liczb ZP, indeksy wykraczające poza tablice, niekończące się pętle itp.
Testy odporności
Testy sprawdzające odporność na:
- zanik zasilania
- awarię sprzętową
- wprowadzenie niepoprawnych danych
- sekwencje niepoprawnych poleceń
Technika posiewania/wstrzykiwania błędów
Polega na tym, że jedna grupa programistów, celowo dodaje do programu błędu, a druga próbuje je wykryć i naprawić.
Bezpieczeństwo
Systemy są niebezpieczne jeśli błędy wykonania mogą prowadzić do zagrożenia życia, zdrowia lub do złamania przepisów prawa
Drzewo błędów
– to schemat pokazujący w jaki sposób uszkodzenie lub niesprawne funkcjonowanie systemu może być spowodowane przez uszkodzenia jego części składowych lub inne zdarzenia. W drzewie możemy używać logicznych symboli alternatywy, koniunkcji czy wykluczenia. Pokazujemy jakie przyczyny prowadzą do nieprawidłowego działania całości/błędy zagrażającego bezpieczeństwu (wierzchołek).
CMM (Capability Maturity Model)
– model dojrzałości procesu wytwarzania
Celem powstania modelu było uzyskanie metody oceny przydatności potencjalnych wykonawców.
Poziomy:
- początkowy
- powtarzalny
- zdefiniowany
- zarządzany
- optymalizujący
Konserwacja oprogramowania
– modyfikacja i pielęgnacja oprogramowania z punktu widzenia twórcy
Klasy:
- modyfikacje poprawiające – usuwają błędy oprogramowania
- modyfikacje ulepszające – poprawiają jakość oprogramowania, wydajność funkcji, itp.
- modyfikacje dostosowujące – dostosowują oprogramowanie do zmian zachodzących w środowisku pracy, zmian wymagań użytkownika, itp.