Microsoft PowerPoint - IO_wyk2_procesIO

dr inż. Radosław Adamus

Inżynieria

Oprogramowania

Wykład 2

Proces Inżynierii Oprogramowania

Cel:

Zapoznanie z modelami procesu inżynierii
oprogramowania

Opis trzech generycznych modeli procesu IO oraz
ich zastosowanie

Naszkicowanie modeli procesów inżynierii wymagań,
rozwoju oprogramowania, testowania oraz ewolucji

Wprowadzenie do modelu Rational Unified Process

Wprowadzenie do technologii CASE wspierającej
działania procesu IO

dr inż. Radosław Adamus

Proces IO i jego modele

Ustrukturalizowany zbiór czynności
wymaganych do wyprodukowania
oprogramowania:

Specyfikacja

Projektowanie i rozwój

Walidacja

Ewolucja

Model jest abstrakcyjną reprezentacją procesu.
Opisuje go z określonej perspektywy.

Generyczne modele procesu IO

Model kaskadowy

Jednoznacznie wydzielone fazy specyfikacji i
rozwoju

Model ewolucyjny

Specyfikacja, rozwój, walidacja są połączone

Inżynieria oparta na komponentach

System jest asemblowany z istniejących
komponentów

Waterfall

Evolutionary

development

Component
based SE

Istnieje wiele wariantów tych modeli

dr inż. Radosław Adamus

Model kaskadowy

(wodospadowy)

waterfall model

Określenie

wymagań

Projektowanie

Implementacja

Testowanie

Konserwacja

Cele i szczegółowe wymagania wobec systemu.

Szczegółowy projekt systemu

uwzględniający wcześniejsze

wymagania.

Modyfikacje producenta - usunięcie
błędów, zmiany i rozszerzenia.

Analiza

Ocena modelu kaskadowego

Istnieją zróżnicowane poglądy co do przydatności praktycznej modelu

kaskadowego. Podkreślane są następujące wady:

¾ Narzucenie twórcom oprogramowania ścisłej kolejności wykonywania prac
¾ Wysoki koszt błędów popełnionych we wczesnych fazach
¾ Długa przerwa w kontaktach z klientem

Z drugiej strony, jest on do pewnego stopnia niezbędny dla planowania,
harmonogramowania, monitorowania i rozliczeń finansowych.

dr inż. Radosław Adamus

Zmodyfikowany model
kaskadowy z iteracjami

Określenie

wymagań

Analiza

Projektowanie

Implementacja

Testowanie

Konserwacja

Model ewolucyjny

Wytwarzanie „odkrywcze”

Opracowanie końcowego systemu odbywa się przy
współpracy z klientem. System ewoluuje od
początkowego szkicu specyfikacji. Nowe własności
dodawane są zgodnie z propozycjami klienta.

Prototypowanie

Celem jest zrozumienie wymagań dla systemu.
Budując prototyp definiujemy wymagania.

dr inż. Radosław Adamus

Model ewolucyjny

Szkic wymagań

Specyfikacja

Rozwój

Walidacja

Wersja
początkowa

Wersje pośrednie

Wersja końcowa

Czynności równoległe

Model ewolucyjny

Wady:

„Niejawny proces”

System może być w niewielkim stopniu
ustrukturalizowany

Wymagania wiedza w zakresie narzędzi szybkiego
prototypowania

Stosowalność

Małe lub średniej wielkości systemy interaktywne

Fragmenty większych systemów (np. GUI)

Systemy „krótkoterminowe”

dr inż. Radosław Adamus

Inżynieria komponentowa

Bazuje na powtórnym użyciu:

System jest integrowany z istniejących komponentów

COTS (Computer-off-the-shelf)

Fazy procesu:

Analiza komponentów

Modyfikacja wymagań

Projektowanie z powtórnym użyciem

Rozwój i integracja

Podejście coraz częściej wykorzystywane

Proces zorientowany na powtórne
użycie

Specyfikacja
wymagań

Analiza
komponentów

Modyfikacja
wymagań

Projektowanie
Z powt. użyciem

Rozwój i
integracja

Walidacja

dr inż. Radosław Adamus

Proces Inżynierii

Oprogramowania

Iteracje

Iteracje w procesie IO

Wymagania systemu zawsze będą podlegały

zmianom. Iteracje w procesie są nieuniknione i

stanowią integralną część procesu IO dla dużych

systemów.

Mogą pojawić się w każdym ze wspomnianych

modeli.

Dwa podstawowe i powiązane ze sobą podejścia

do iteracji to:

Realizacja przyrostowa

Model spiralny

Incremental
development

Spiral
development

dr inż. Radosław Adamus

Realizacja przyrostowa

System jest dostarczany w następujących po
sobie wydaniach. Każde wydanie posiada
zwiększoną funkcjonalność.

Wymagania użytkownika są priorytetyzowane.
Im wymaganie ma wyższy priorytet tym we
wcześniejszym wydaniu zostanie zrealizowane.

W momencie rozpoczęcia inkrementacji
zamraża się wymagania. Ich ewolucja będzie się
odbywała w iteracji kolejnej.

Realizacja przyrostowa

incremental development

Określenie

wymagań

Ogólny
projekt

Wybór

podzbioru

funkcji

Szczegółowy

projekt,

implementacja

testy

Dostarczenie

zrealizowanej

części

systemu

Proces

realizowany

iteracyjnie

dr inż. Radosław Adamus

Zalety realizacji przyrostowej

Wybrana funkcjonalność systemu jest
dostarczona wcześnie.

Wczesne iteracje można traktować jako
prototypy

Ryzyko niepowodzenia jest minimalizowane.

Najbardziej priorytetowe usługi systemu są
najdłużej testowane.

Programowanie extremalne

Podejście do realizacji przyrostowej zakładające budowę
systemu w bardzo częstych wydaniach o małym
przyroście funkcjonalności.

Opiera się na stałym udoskonalaniu kodu.

Użytkownicy bezpośrednio współpracują z zespołem
budującym system.

Najbardziej rozpoznawalne zasady XP

Programowanie w parach

Rozwój oparty na testach

Ciągła integracja

(XP) eXtreme Programming

pairwise programming

TDD test driven development

Continuous integration

dr inż. Radosław Adamus

Model spiralny

Proces jest reprezentowany jako spirala (a nie
sekwencja z powrotami)

Każda pętla w spirali reprezentuje fazę procesu

Nie ma wyróżnionych faz typu specyfikacja czy
projektowanie – wybierane jest to co jest
obecnie potrzebne.

Istotnym elementem modelu jest ryzyko –
szacowanie i zarządzanie

Spiral
development

Działy modelu spiralnego

Identyfikacja i określanie celów dla kolejnej fazy

Identyfikacja i minimalizacja zagrożeń

Działania mające na celu redukcję najważniejszych
zagrożeń

Rozwój i walidacja

Wybierany jest model rozwoju (może być dowolny)

Planowanie

Przegląd (ewaluacja) projektu, planowanie kolejnej
fazy

dr inż. Radosław Adamus

Spiralny model procesu IO

Określanie celów

ograniczeń,

Rozwiązań alternatywnych

Analiza ryzyka

Ewaluacja, identyfikacja
i minimalizacja zagrożeń,

Analiza

ryzyka

Prototyp1

Prototyp2 Prototyp3

Funkcjo-
nujący
prototyp

Koncepcja
działania

Planowanie cyklu
życia

Przegląd

Plan rozwoju

Plan kolejnej fazy

Plan testów i integracji

Symulacje, modele, benchmarki

Definiowanie
wymagań

Rozwój, weryfikacja
Produkt na kolejnym
poziomie

Walidacja
wymagań

Projektowanie
produktu

Weryfikacja
i walidacja
projektu

Projekt
szczegółowy

Kodowanie

Testy
jednostkowe

Testy
integracyjne

Testy
akceptacyjne

Proces Inżynierii

Oprogramowania

Czynności procesu IO

dr inż. Radosław Adamus

Czynności procesu IO

Specyfikacja oprogramowania

Projektowanie i implementacja oprogramowania

Weryfikacja i Walidacja oprogramowania

Ewolucja oprogramowania

Specyfikacja oprogramowania

Proces, którego celem jest określenie jakie
usługi musi dostarczać projektowany system
oraz jakie są ograniczenia na działanie systemu
oraz proces jego produkcji.

Proces inżynierii wymagań:

Studium osiągalności

Pozyskiwanie i analiza wymagań

Specyfikacja wymagań

Walidacja wymagań

Software specification

dr inż. Radosław Adamus

Proces inżynierii wymagań

Model systemu

Raport
osiągalności

Wymagania użytkowe
I systemowe

Dokument wymagań

Walidacja wymagań

Specyfikacja
wymagań

Pozyskiwanie i
Analiza wymagań

Studium
osiągalności

Projektowanie i implementacja
oprogramowania

Proces, którego celem jest przekształcenie
specyfikacji w działający system

Projektowanie

Określenie struktury oprogramowania, która realizuje
jego specyfikacje.

Implementacja

Translacja struktury na wykonywalny program

Projektowanie i implementacja są ze sobą
mocno powiązane i często równoległe

Software design and implementation

dr inż. Radosław Adamus

Czynności procesu projektowania

Projektowanie architektury

Abstrakcyjna specyfikacja

Projektowanie interfejsów

Projektowanie komponentów

Projektowanie struktur danych

Projektowanie algorytmów

Proces projektowania
oprogramowania

Specyfikacja
wymagań

Projektowanie
architektury

Abstrakcyjna
specyfikacja

Projektowanie
interfejsów

Projektowanie
komponentów

Projektowanie
struktury
danych

Projektowanie
algorytmów

Architektura
systemu

Specyfikacja
oprogramowania

Specyfikacja
interfejsów

Specyfikacja
komponentów

Specyfikacja
struktur
danych

Specyfikacja
algorytmów

aktywności

produkty

dr inż. Radosław Adamus

Metody strukturalne

Systematyczne podejście do procesu
projektowania

Produktem procesu projektowanie jest zbiór
modeli (reprezentowanych graficznie)

Modele obiektów

Modele sekwencji

Model stanów

Model struktury

Model przepływu danych

Kodowanie i debugowanie

Translacja projektu do kodu wykonywalnego
oraz usuwanie błędów

Jest to aktywność nie posiadające specjalnego
procesu – programista indywidualista (?)

Programowanie to również usuwanie błędów!

Zlokalizuj
błąd

Zaprojektuj
poprawkę

Napraw
błąd

Ponownie
uruchom test

dr inż. Radosław Adamus

Walidacja oprogramowania

Celem weryfikacji i walidacji (V&V) jest
wykazanie, że opracowany system jest zgodny
ze specyfikacją i realizuje wymagania klienta

V&V to proces kontroli i przeglądów
oprogramowania plus testowanie systemu

Testowanie systemu to jego uruchamianie z
przypadkami testowymi wywodzących się ze
specyfikacji rzeczywistych danych które system
ma przetwarzać.

Software verification and validation

Proces testowania

Testy
komponentów

Testy
systemowe

Testy
akceptacyjne

dr inż. Radosław Adamus

Etapy testowania

Testy komponentowe (jednostkowe)

Komponenty (obiekty, funkcje lub ich spójne

grupy) są testowane indywidualnie

Testy systemowe

Testowanie systemu jako całości ze

szczególnym uwzględnieniem nowo powstałych

elementów

Testy akceptacyjne

Testowanie z wykorzystaniem rzeczywistych

danych w celu udowodnienia, ze system spełnia

wymagania użytkowników.

Unit

testing

System

(integration)
testing

Acceptance
testing

Fazy testowania

Plan testów
akceptacyjnych

Plan testów
integracyjnych

Plan testów
Integracyjnych
dla podsystemów

Moduły,
kod jednostek,

testy

Specyfikacja
wymagań

Specyfikacja
systemowa

Projekt
systemu

Projekt
szczegółowy

Testy
akceptacyjne

Testy integracyjne
systemu

Testy integracyjne
podsystemów

Usługi

dr inż. Radosław Adamus

Ewolucja oprogramowania

Oprogramowanie musi być elastyczne bo
zmiany są nieuniknione

Zmieniają się uwarunkowania biznesowe -> zmieniają
się wymagania -> ewoluuje system

Pomimo pierwotnego wyróżnienia procesu
budowy i ewolucji systemu granica ta dzisiaj
coraz bardziej się zaciera.

Software evolution

Ewolucja systemu

Definiowanie
wymagań

Ocena
istniejacego
systemu

Propozycja
zmian

Modyfikacja
systemu

Istniejący
system

Nowy system

Proces Inżynierii

Oprogramowania

Nowe lub
zmienione
wymagania

Nowy lub
zmieniony
system

Czyli po prostu…