1. Obszar inżynierii oprogramowania Charakterystyka kryzysu oprogramowania



Pobieranie 53.48 Kb.
Data06.05.2016
Rozmiar53.48 Kb.
1. Obszar inżynierii oprogramowania
Charakterystyka kryzysu oprogramowania:

  • Przekraczanie terminów

 brak właściwych technik budowy oprogramowania

 brak właściwych języków programowania umożliwiających specyfikację oprogramowania i tworzenie kodu źródłówego

 brak doświadczeń w tworzeniu zespołów specjalistów, zajmujących się tworzeniem programów

 nieumiejętne kierowanie przedsięwzięciem programistycznym



  • Przerywanie prac z powodu utraty aktualności przez realizowany projekt

 wydłużony czas tworzenia oprogramowania,

 szybki rozwój sprzętu



 brak właściwego sposobu porozumiewania się klienta z zespołem informatyków

 brak odpowiednich norm jakości oprogramowania

 niska niezawodność sprzętu i oprogramowania

Źródła powstania inżynierii oprogramowania - działu informatyki:



  • metody opanowania kryzysu oprogramowania, trwającego od połowy lat sześćdziesiątych

  • tworzenie oprogramowania na skalę produkcyjną.



Inżynieria oprogramowania jest wiedzą techniczną, która zajmuje się:

  • procesem wytwarzania (produkcją) oprogramowania i jakością tego procesu

  • budową oprogramowania i jakością oprogramowania (czyli uzyskanego produktu)

Zagadnienia inżynierii oprogramowania:


  1. Zarządzanie przedsięwzięciem programistycznym obejmujące:

    1. techniki planowania, szacowania kosztów, harmonogramowania i monitorowania

    2. sposoby przygotowania dokumentacji technicznej i użytkowej

    3. techniki pracy zespołowej

    4. określanie poziomu umiejętności specjalistów

    5. zastosowanie narzędzi CASE (Computer Aided System Engineering)

  1. Metody analizy, projektowania i implementacji (programowania)

  2. Wyznaczanie i badanie atrybutów wewnętrznych oprogramowania obejmujących właściwości struktury oprogramowania  metryki oprogramowania

  3. W

    yznaczanie i badanie atrybutów zewnętrznych oprogramowania:



    1. jakości oprogramowania, obejmującej:

    • niezawodność (testowalność)

    • konserwowalność

    • zrozumiałość

    • wieloużywalność

    • stopień osiągniętej abstrakcji

    1. funkcjonalności

    2. kosztu

  1. Kształtowanie jakości oprogramowania:

    1. sposoby poprawy niezawodności, konserwowalności, wieloużywalności, zrozumiałości, stopnia osiągniętej abstrakcji

    2. sposoby testowania i walidacji systemów

    3. badanie zależności między atrybutami wewnętrznymi i jakością oprogramowania

  2. Rozwój środowisk i narzędzi programistycznych


2. Modele procesu wytwarzania oprogramowania - czyli modele cyklu życia oprogramowania

Model procesu wytwarzania jest ściśle powiązany z:

  • budową oprogramowania (strukturalną, obiektową)

  • zarządzaniem przedsięwzięciem programistycznym


Ogólny model procesu tworzenia oprogramowania


Proces tworzenia oprogramowania

Modelowanie (wymagania, analiza)

Projektowanie

Programowanie

co należy zrobić?

jak należy zrobić?

  • model konceptualny

  • specyfikacja modelu

  • architektura sprzętu i oprogramowania

  • dostęp użytkownika

  • przechowywanie danych




  • specyfikacja programu (deklaracje, definicje

  • dodatkowe struktury danych (struktury „pojemnikowe”, pliki)


Właściwości modelu wytwarzania oprogramowania


Modelowanie

Projektowane i programowanie

  • opis w języku naturalnym, diagramy

  • łatwość zmian i rozwoju modelu

  • składowe powielarne

  • niezależne od implementacji (postulat abstrakcji)

  • optymalna kolejność działań ( podział na podsystemy, przechowywanie danych, sterowanie dostępem do zasobów systemu, system sterowania oprogramowaniem, reakcja systemu na warunki pracy, dostęp użytkownika),

  • właściwy podział zadań między sprzęt i oprogramowanie,

  • zalecana iteracyjna realizacja tworzenia programu

  • testowanie zgodności semantyki programu i modelu



    1. Model kaskadowy (waterfall)



Zalety: łatwość w zarządzaniu projektem
Wady:

  1. reagowanie na błędy dopiero po zakończeniu procesu wytwarzania oprogramowania, czyli kosztowne usuwanie błędów

  2. mały udział klienta w procesie tworzenia programowania

  3. sztywny harmonogram prac – część zespołu czeka na udział w pracach




    1. Model kaskadowy iteracyjny





Zalety:

  1. Możliwość usuwania błędów dzięki nawrotom

  2. Elastyczne zarządzanie procesem tworzenia oprogramowania- różne fragmenty oprogramowania mogą być w różnym stanie realizacji


Wada:

Nawroty ściśle związane z typem tworzonego oprogramowania tzn. niewielkie korzyści przy zastosowaniu programowania strukturalnego, dużo większe przy zastosowaniu technik obiektowych




    1. Model przyrostowy (incremental development)




Zalety:

  1. Możliwość elastycznego zarządzania projektem

  2. Uniknięcie kosztownego usuwania błędów

  3. Możliwość przekazywania fragmentów oprogramowania do klienta


Wady:

1. Duży koszt w wytwarzaniu przekazywanych do klienta fragmentów oprogramowania (specjalny interfejs użytkownika)

2. Nawroty ściśle związane z typem tworzonego oprogramowania tzn. mniejsze korzyści przy zastosowaniu programowania strukturalnego, dużo większe przy zastosowaniu technik obiektowych

2.4. Model programowania odkrywczego (exploratory programming)



Zalety:

Można wykonywać system na zasadzie uzgadniania z klientem, który na podstawie realizacji określa przydatność systemu


Wady:

  1. Testowanie systemu przy udziale klienta

  2. Mała niezawodność systemu

  3. Nieracjonalne zarządzanie projektem

2.5. Model spiralnyBoehm i Belz, 1988

Model ten zapewnia racjonalne zarządzanie tworzeniem programowania, szczególnie w oparciu o techniki obiektowe.



    1. prototyp 1

14- projekt

        1. koncepcja operacji

15- walidacja i weryfikacja projektu

3- plan wymagań cyklu życia

16- integracja i testowanie

4, 11, 17 – analiza ryzyka

18- prototyp operacyjny

5- prototyp 2

19- „benchmarks”- walidacja i weryfikacja za pomocą specjalnych programów

6- symulacja

20- uzupełnienie projektu

7- wymagania oprogramowania

21- kod

8- walidacja oprogramowania

22- test modułów

9- plan rozwoju oprogramowania

23- integracja i test

10- rewizja

24- test akceptacji

12- prototyp 3

25- implementacja

13- modele




2.6. Model zunifikowany - iteracyjny i przyrostowy proces tworzenia oprogramowania

Model ten zapewnia racjonalne zarządzanie tworzeniem oprogramowania w oparciu o techniki obiektowe

3. Atrybuty wewnętrzne i zewnętrzne oprogramowania – wprowadzenie



4. Testowanie programów - wprowadzenie

4.1. Rola testowania w tworzeniu oprogramowania
Kluczową rolę w powstawaniu oprogramowania stanowi proces usuwania błędów w kolejnych fazach rozwoju oprogramowania na drodze testowania (różne metody testowania dostosowane do stopnia rozwoju oprogramowania).

W inżynierii oprogramowania poszukuje się związku między strukturą programu a możliwością powstawania pewnych błędów oraz trudnością ich wykrywania na drodze testowania.


4.2. Definicje

Atestowanie (validation) - testowanie zgodności systemu z rzeczywistymi potrzebami użytkownika (czy zbudowano poprawny produkt).

Weryfikacja (verification) - testowanie zgodności systemu z wymaganiami zdefiniowanymi w fazie określania wymagań (czy zbudowano produkt poprawnie w kolejnych fazach życia)

Błąd (fault, error, defect) jest niepoprawną konstrukcją znajdującą się w oprogramowaniu, która może prowadzić do niewłaściwego działania.

Błędne wykonanie - uszkodzenie (failure) to niepoprawne działanie systemu w trakcie jego pracy na skutek błędów. Takie same błędne wykonanie może pochodzić od różnych błędów. Jednak błędy nie muszą powodować błędnego wykonania programu!
Klasyfikacja błędów

  1. błędy wymagań i analizy: złe sformułowanie problemu, zaniedbanie istotnych parametrów, niewłaściwy algorytm,

  2. błędy projektowania: błędna interpretacja wymagań, błędy logiczne

  3. błędy programowe:

    1. błędy opracowania szczegółowej struktury programu: zła interpretacja wymagań dla programu, niepełność struktury programu, nie uwzględnienie przypadków szczególnych, niedostateczne dopracowanie błędów, zlekceważenie warunków czasowych

    2. błędy kodowania:

      1. syntaktyczne, zazwyczaj rozpoznawane przez kompilator,

      2. błędy merytoryczne (nieprawidłowe korzystanie z indeksów i wskaźników, zły przydział pamięci, pominięcie inicjalizacji zmiennych, pomieszanie parametrów funkcji, błąd w pętlach, zamiana wyników decyzji w instrukcjach warunkowych, błędy deklaracji typów i wymiarów danych, błędy zakresów wartości danych,

    1. błędy kompilacji i konsolidacji: błędy kompilatora, błędy w zakresach nazw itp.)

Klasyfikacja testów:

  1. ze względu na cel:

    1. testy wykrywające błędy

1.2. testy statystyczne, określające przyczyny najczęstszych błędnych wykonań oraz ocena niezawodności systemu

  1. ze względu na technikę wykonania:

    1. testy dynamiczne polegające na wykonaniu fragmentu lub całego programu i porównaniu wyników jego działania z wynikami poprawnymi. Możliwe jest wykonywanie „metaprogramów” wykonanych w różnych fazach powstawania oprogramowania:

testy funkcjonalne: Program traktowany jest jak „czarna skrzynka”. Znane są jedynie wymagania wobec testowanych funkcji programu. Testuje się program w wybranych podzakresach danych, traktując je jako klasy danych wejściowych – testy dla każdej klasy przeprowadza się jedynie dla pewnych wybranych danych w kilku przebiegach, a wnioskuje się o działaniu programu dla całej klasy danych.

strukturalne (metaprogramy): Struktura programu jest znana. Dane wejściowe należy dobrać tak, aby każda instrukcja programu była przynajmniej raz wykonana, oraz tak, aby każda instrukcja warunkowa i pętle były przynajmniej raz wykonane i raz nie wykonane (kryterium pokrycia instrukcji warunkowych).



    1. testy statyczne: inspekcje struktury produktu, udowadnianie poprawności programu (np. logika Hoare), testowanie symboliczne (testowanie oparte na strukturze programu i analizowaniu stanu danych w wyniku wykonania programu dla różnych przebiegów sterowania programem (wykonanie lub nie wykonanie instrukcji warunkowych i pętli podczas przejścia przez program) – p. następny wykład)

Testy dynamiczne i statyczne nie są komplementarne, tzn. mogą służyć do wykrywania różnych błędów.

Kolejność wykonania testów w procesie powstawiania oprogramowania jest zależna od przyjętej metody testowania i tworzenia oprogramowania.

W końcowej fazie wyróżnia się następujące testy:

  • testy modułów

  • testy systemu

  • testy akceptacji (testy alfa i beta).

4.3. Testowalność


Testowanie i wyznaczanie testowalności [A.Bertolino,L.Strigini:On the Use of Testability Assessment,IEEE TRANSACTION ON SOFTWARE ENGINEERING,vol. 22, no. 2, February 1996]

W

yrocznia jest następującą funkcją:



Wyrocznia: D  R  (zbiór_wartości_stanów_programu )  {dobry, zły}

gdzie



D - dziedzina danych wejściowych,

R - dziedzina danych wyjściowych

zbiór_wartości_stanów_programu– zbiór obserwowanych wartości zmiennych
1) Testowalność oprogramowania TestabABS jest prawdopodobieństwem warunkowym, że wynik testu programu dla wejścia określonego funkcją rozkładu prawdopodobieństwa danych wejściowych jest zły (określony przez funkcję wyroczni), pod warunkiem, że wystąpiły błędy w programie.

TestabABS =P( zły |f. rozkładu prawd. danych wejśc., wyrocznia, błędy)

2) Testowalność oprogramowania TestabHV jest prawdopodobieństwem, że program jest uszkodzony (błędnie wykonany) dla danego wejścia określonego funkcją rozkładu prawdopodobieństwa danych wejściowych, pod warunkiem że wystąpiły błędy w programie.



TestabHV =P( uszkodzony | f.rozkładu prawd. danych wejśc., błędy)

3) Zależność między definicjami jest następująca:

gdzie


Pokrycie jest prawdopodobieństwem, że wynik wyroczni będzie zły dla danego wejścia określonego funkcją rozkładu prawdopodobieństwa danych wejściowych, gdy wystąpił błędny stan programu.

Pokrycie = P( zły | f.rozkładu prawd.danych wejśc., bledny stan programu )

bledny stan programu: błędy w obserwowanych zmiennych

  1. Związek między liczbą przeprowadzonych testów i niezawodnością

Niezawodność programu jest częstotliwością jego błędnych wykonań. Rośnie ona logarytmicznie w zależności od liczby przeprowadzonych testów.

4.4. Ocena liczby błędów metodą posiewania błędów
Na podstawie wszystkich znalezionych błędów oraz błędów sztucznie wprowadzonych do programu można oszacować liczbę błędów w programie.
N - liczba wprowadzonych błędów

M - liczba wszystkich wykrytych błędów

X - liczba wprowadzonych błędów, które zostały wykryte


Szacunkowa liczba błędów przed wykonaniem testów:

Liczba błędów po usunięciu wykrytych, w tym wszystkich sztucznie wprowadzonych:



Współczynnik X/N opisuje efektywność wykonywanych testów..


Metody posiewania błędów:

  • losowe zakłócenia w przypisywaniu danych

  • losowe mutacje kodu - zmiany kodu źródłowego modyfikującego sterowanie lub dane w programie

  • losowe zakłócenia między interfejsami modułów


©absta.pl 2016
wyślij wiadomość

    Strona główna