Inżynieria Oprogramowania – opracowanie zagadnień na egzamin

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.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *