dr inż. Radosław Adamus

1

Inżynieria

Oprogramowania

Wykład 2

Proces Inżynierii Oprogramowania

Cel:

z

Zapoznanie z modelami procesu inżynierii
oprogramowania

z

Opis trzech generycznych modeli procesu IO oraz
ich zastosowanie

z

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

z

Wprowadzenie do modelu Rational Unified Process

z

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

dr inż. Radosław Adamus

2

Proces IO i jego modele

z

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

z

Specyfikacja

z

Projektowanie i rozwój

z

Walidacja

z

Ewolucja

z

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

Generyczne modele procesu IO

z

Model kaskadowy

z

Jednoznacznie wydzielone fazy specyfikacji i
rozwoju

z

Model ewolucyjny

z

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

z

Inżynieria oparta na komponentach

z

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

3

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

4

Zmodyfikowany model
kaskadowy z iteracjami

Określenie

wymagań

Analiza

Projektowanie

Implementacja

Testowanie

Konserwacja

Model ewolucyjny

z

Wytwarzanie „odkrywcze”

z

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.

z

Prototypowanie

z

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

dr inż. Radosław Adamus

5

Model ewolucyjny

Szkic wymagań

Specyfikacja

Rozwój

Walidacja

Wersja
początkowa

Wersje pośrednie

Wersja końcowa

Czynności równoległe

Model ewolucyjny

z

Wady:

z

„Niejawny proces”

z

System może być w niewielkim stopniu
ustrukturalizowany

z

Wymagania wiedza w zakresie narzędzi szybkiego
prototypowania

z

Stosowalność

z

Małe lub średniej wielkości systemy interaktywne

z

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

z

Systemy „krótkoterminowe”

dr inż. Radosław Adamus

6

Inżynieria komponentowa

z

Bazuje na powtórnym użyciu:

z

System jest integrowany z istniejących komponentów

z

COTS (Computer-off-the-shelf)

z

Fazy procesu:

z

Analiza komponentów

z

Modyfikacja wymagań

z

Projektowanie z powtórnym użyciem

z

Rozwój i integracja

z

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

7

Proces Inżynierii

Oprogramowania

Iteracje

Iteracje w procesie IO

z

Wymagania systemu zawsze będą podlegały

zmianom. Iteracje w procesie są nieuniknione i

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

systemów.

z

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

modeli.

z

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

do iteracji to:

z

Realizacja przyrostowa

z

Model spiralny

Incremental
development

Spiral
development

dr inż. Radosław Adamus

8

Realizacja przyrostowa

z

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

z

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

z

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

9

Zalety realizacji przyrostowej

z

Wybrana funkcjonalność systemu jest
dostarczona wcześnie.

z

Wczesne iteracje można traktować jako
prototypy

z

Ryzyko niepowodzenia jest minimalizowane.

z

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

Programowanie extremalne

z

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

z

Opiera się na stałym udoskonalaniu kodu.

z

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

z

Najbardziej rozpoznawalne zasady XP

z

Programowanie w parach

z

Rozwój oparty na testach

z

Ciągła integracja

(XP) eXtreme Programming

pairwise programming

TDD test driven development

Continuous integration

dr inż. Radosław Adamus

10

Model spiralny

z

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

z

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

z

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

z

Istotnym elementem modelu jest ryzyko –
szacowanie i zarządzanie

Spiral
development

Działy modelu spiralnego

z

Identyfikacja i określanie celów dla kolejnej fazy

z

Identyfikacja i minimalizacja zagrożeń

z

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

z

Rozwój i walidacja

z

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

z

Planowanie

z

Przegląd (ewaluacja) projektu, planowanie kolejnej
fazy

dr inż. Radosław Adamus

11

Spiralny model procesu IO

Określanie celów

ograniczeń,

Rozwiązań alternatywnych

Analiza ryzyka

Analiza ryzyka

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

12

Czynności procesu IO

z

Specyfikacja oprogramowania

z

Projektowanie i implementacja oprogramowania

z

Weryfikacja i Walidacja oprogramowania

z

Ewolucja oprogramowania

Specyfikacja oprogramowania

z

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.

z

Proces inżynierii wymagań:

z

Studium osiągalności

z

Pozyskiwanie i analiza wymagań

z

Specyfikacja wymagań

z

Walidacja wymagań

Software specification

dr inż. Radosław Adamus

13

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

z

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

z

Projektowanie

z

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

z

Implementacja

z

Translacja struktury na wykonywalny program

z

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

Software design and implementation

dr inż. Radosław Adamus

14

Czynności procesu projektowania

z

Projektowanie architektury

z

Abstrakcyjna specyfikacja

z

Projektowanie interfejsów

z

Projektowanie komponentów

z

Projektowanie struktur danych

z

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

15

Metody strukturalne

z

Systematyczne podejście do procesu
projektowania

z

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

z

Modele obiektów

z

Modele sekwencji

z

Model stanów

z

Model struktury

z

Model przepływu danych

Kodowanie i debugowanie

z

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

z

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

z

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

Zlokalizuj
błąd

Zaprojektuj
poprawkę

Napraw
błąd

Ponownie
uruchom test

dr inż. Radosław Adamus

16

Walidacja oprogramowania

z

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

z

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

z

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

17

Etapy testowania

z

Testy komponentowe (jednostkowe)

z

Komponenty (obiekty, funkcje lub ich spójne

grupy) są testowane indywidualnie

z

Testy systemowe

z

Testowanie systemu jako całości ze

szczególnym uwzględnieniem nowo powstałych

elementów

z

Testy akceptacyjne

z

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

18

Ewolucja oprogramowania

z

Oprogramowanie musi być elastyczne bo
zmiany są nieuniknione

z

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

z

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…

dr inż. Radosław Adamus

19

Do poczytania…

z

Sommerville: Inżynieria Oprogramowania,
rozdział 3.