Wykład 2

Metody i procesy

rozwoju oprogramowania

itm / MVLab (c) 2007-2008

Metody i postępowanie

itm / MVLab (c) 2007-2008

Metodologia planowania
działań

Postępowanie metodyczne

Postępowanie

Zapis / notacja

Koncepcja

Modele

postępowania

Analiza obiektowa,

Projektowanie

obiektowe

Unified Modeling

Language (UML)

itm / MVLab (c) 2007-2008

Modele postępowania

itm / MVLab (c) 2007-2008

Cele wykładu



zrozumienie jakie aspekty powinien zawierać model
postępowania



umiejętność opisu i porównania przedstawionych dalej
modeli postępowania



umiejętność wyboru właściwego modelu dla konkretnego
zastosowania

itm / MVLab (c) 2007-2008

Motywacja



Podział skomplikowanych projektów na szereg faz o wyraźnie

określonym zakończeniu powoduje wzrost efektywności.

Dlatego zostały opracowane modele postępowania dla

projektów z różnych dziedzin, które w odpowiedni sposób

koordynują przebieg tych faz.

przykładowo: przepis kulinarny, plan budowy, rozwój produktu



Powody stosowania modeli w inżynierii oprogramowania:



złożoność programów (rodzaj zadań, wielkość)



duża skala (ludzie, koszty)



długi czas rozwoju (3,5,10 lat)



Cele stosowania modeli:



obniżenie kosztów



zwiększenie jakości



skrócenie czasu projektowania

itm / MVLab (c) 2007-2008

Zawartość modeli postępowania



kolejność prac, (stopnie, fazy)



działania jakie należy wykonać podczas poszczególnych
faz



określenie produktów składowych i dokumentacji



kryteria zakończenia fazy (kiedy cele zostaną osiągnięte)



wymagane kompetencje osób zaangażowanych



odpowiedzialność i kompetencje



standardy i wytyczne dot. projektu

itm / MVLab (c) 2007-2008

Wybór odpowiedniego modelu

stopień innowacyjności

ro

zle

gło

ść

proj

ekt

u

Code&fix

Model

kaskadowy

V-Model

Prototypowanie

Model

sawtooth

Model

spiralny

Model XP

itm / MVLab (c) 2007-2008

Rozwój modeli postępowania

Code and fix

Kaskadowy

V-Model 97

Prototypowanie

Spiralny

Piłozębny

XP

QC

itm / MVLab (c) 2007-2008

Code and fix



typowy model postępowania w przypadku małych,
jednoosobowych projektów lub zadań treningowych

(poziom podstawowy)



Zalety:



brak pracy organizacyjnej,



metoda prób i błędów



Wady:



wysokie prawdopodobieństwo wystąpienia

błędów; błędy ciężkie do wykrycia,



brak prawidłowej dokumentacji,



nieprzejrzysty kod,



ograniczona pielegnowalność



często wymagania klienta nie są spełnione

Pisanie kodu

Testy

Poprawki

itm / MVLab (c) 2007-2008

Model wodospadowy



wszystkie operacje wykonywane są w ściśle
określonym porządku (sekwencyjnie) i do końca



sąsiednie fazy są spięte pętlą sprzężenia
zwrotnego



każda faza jest dokumentowana – model
zintegrowany dokumentacyjnie



kierunek przejścia: top-down

Studium wykonalności

Analiza

Projektowanie

Implementacja

Testowanie

Instalacja

Utrzymanie

Wynik zakończenia jednej fazy

„wpada” do następnej

itm / MVLab (c) 2007-2008

Fazy modelu wodospadowego



Studium wykonalności: oszacowanie kosztów i możliwości

technicznych (wynik: plan projektu, kalkulacja, specyfikacja

wymagań)



Analiza: określenie zapotrzebowań oraz właściwości systemu

(wynik: specyfikacja zobowiązań)



Projekt: określenie architektury i algorytmów (wynik:

dokumentacja projektowa)



Implementacja: realizacja modelu projektowego (wynik: kod

źródłowy, dokumentacja techniczna)



Testowanie: testy modułów i systemu oraz testowanie przez

użytkownika (wynik: protokoły testów)



Instalacja: wdrożenie aplikacji u klienta



Pielęgnacja: optymalizacja, dopasowywanie, rozszerzenia

itm / MVLab (c) 2007-2008

Zalety i wady modelu
wodospadowego



Zalety:



strukturalna konstrukcja programów



tworzenie dokumentacji równolegle z

pozostałymi pracami



wsparcie na etapie organizacji oraz

kończenia projektu



Wady:



konieczność zamrożenia specyfikacji



niebezpieczeństwo że dokumentacja

stanie się ważniejsza niż właściwy
system



Niewielki udział klienta

itm / MVLab (c) 2007-2008

V-Modell 97



wzorowany na modelu postępowania dla projektów

programistycznych armii niemieckiej (Bundeswehry)



integracja systemów zapewniania jakości, zarządzania
projektem i konfiguracją w modelu wodospadowym



Podstawowymi elementami są czynności i produkty

Konstrukcja

Zapewnienie jakości

Analiza

Projekt systemu

Implementacja

Odbiór techn.

Test integracji

Test modułów

przypadki

testowe

Projekt obiektów

walidacja

weryfikacja

przypadki

testowe

scenariusze

użycia

itm / MVLab (c) 2007-2008

Weryfikacja a Walidacja

W inżynierii oprogramowania:



weryfikacja rozumiana jest jako

porównanie gotowego produktu z jego

specyfikacją



walidacja to określenie wartości

gotowego programu w konkretnym

zastosowaniu, dla którego został on

zaprojektowany

Czy zrobiłem
to dobrze?

Czy zrobiłem
to co potrzeba?

itm / MVLab (c) 2007-2008

Weryfikacja a Walidacja

W inżynierii oprogramowania:



weryfikacja rozumiana jest jako

porównanie gotowego produktu z jego

specyfikacją



walidacja to określenie wartości

gotowego programu w konkretnym

zastosowaniu, dla którego został on

zaprojektowany

Czy ja żem to,

Halinka, tak zrobił

jak oni chcieli?

Czy ja żem,

Halinka, zrobił to
o co mie, kurde,

chodziło?

weryfikacja
wg Kiepskich

walidacja wg Kiepskich

itm / MVLab (c) 2007-2008

V-Modell 97: zalety i wady



Zalety:



zintegrowana koncepcja budowy systemu, zapewnienia

jakości oraz zarządzania projektem i konfiguracją



ogólny model postępowania z określonymi możliwościami

dopasowania



dobrze dostosowany do dużych projektów



podstawa do certyfikacji (ISO 9000)



dobra dokumentacja tworzona podczas całego procesu



Wady:



niebezpieczeństwo niekontrolowanego rozrostu biurokracji



konieczne wymaga wsparcie narzędziowego



czasochłonny

itm / MVLab (c) 2007-2008

V-Model XT: podział



Jakie czynności są konieczne do realizacji projektu?



Jakie produkty muszą być osiągnięte w czasie jego
realizacji?

wybór

Cechy projektu

Idee

(wyobrażenia) o

projekcie

Uzasadnienie

Czynności

i produkty projektu

Cele:



uniknięcie wykonywania niepotrzebnych czynności



uniknięcie bezsensownych dokumentów



pewność opracowania wszystkich koniecznych dokumentów

itm / MVLab (c) 2007-2008

Podejście nakierowane na
produkt (V-Model XT)

Produkt

Grupa produktów

Grupa czynności

Temat

Podczynność

produkcja

odpowiedzialność

Czynność

Rola

Rola

Rola

współpraca

opracowanie

itm / MVLab (c) 2007-2008

Prototypowanie



Problemy typowego modelu etapowego



wymagania są trudne do pełnego wyspecyfikowania i
zauważenia na początku projektu



prezentacja wyników pracy po jej zakończeniu, brak
komunikacji klient - wykonawca



najlepsze rozwiązania znajduje się dzięki eksperymentom



Rozwiązanie: Prototypowanie



Rodzaje prototypów (wg celów)



demonstracyjny -umożliwia komunikację ze zleceniodawcą



w dosłownym rozumieniu -analiza obszarów zastosowań,
prowizorycznie działający program



wzorzec laboratoryjny -rozwiązanie problemów
konstrukcyjnych, analiza architektury i sposobów wdrożenia



system pilotażowy - podstawy dla produktu

itm / MVLab (c) 2007-2008

Rodzaje prototypów

Interfejs użytkownika

Jądro aplikacji

Patformy

(middleware)

Oprogramowanie systemowe

Dane

Prototyp pionowy:
Realizuje wybrane części systemu ze
wszystkich poziomów; Prototyp
funkcjonalny realizujący wycinek
konkretnych możliwości.

Prototyp poziomy:
Realizuje w pełni
funkcje jednego z
poziomów systemu,
np. interfejs
użytkownika.

itm / MVLab (c) 2007-2008

Prototypy - zalety i wady

Zalety:



redukcja ryzyka



integrowalne w tradycyjnych modelach postępowania



wzrost bezpieczeństwa planowania



lepsza współpraca z użytkownikiem docelowym i zamawiającym

Wady:



wyższe nakłady



niebezpieczeństwo: odrzucenie prototypu z uwagi na ograniczenia czasowe,
wiąże się z produktem końcowym



prototypy są często pojmowane jako usprawiedliwienie dla brakującej
dokumentacji



ograniczenia prototypów często nie są reprezentatywne

itm / MVLab (c) 2007-2008

Model sawtooth

rozszerzenie V-Modelu o prototypowanie

Zapotrzebowanie

Prototyp 1

Prototyp 2

Testy-klient

Analiza

Koncepcja

systemu

Koncepcja

obiektu

Implementacja

Testy modułów

Testy integralności

Walidacja

klient

projektant

itm / MVLab (c) 2007-2008

Model sawtooth

zalety i wady

Zalety:



Wysokie zaangażowanie klienta podczas procesu

projektowania



Minimalizacja ryzyka



Wysoka jakość produktu

Wady:



Duże nakłady na tworzenie prototypów



Kiepskie dostosowanie do małych i średnich projektów

itm / MVLab (c) 2007-2008

Model spiralny



Model bazujący na analizie ryzyka



Koncentracja na kluczowych
problemach w fazach
początkowych



Cele każdego z cykli
wyprowadzane są na podstawie
wyników cyklu poprzedzającego



Osobne cykle spiralne mogą być
wykorzystane dla różnych
komponentów oprogramowania

itm / MVLab (c) 2007-2008

Model spiralny

zalety i wady

Zalety:



Elastyczny model minimalizujący ryzyko



Możliwość wczesnej eliminacji błędów lub nienadających
się propozycji alternatywnych



Wsparcie ponownego wykorzystania modułów SW dzięki
rozważaniu propozycji alternatywnych

Wady:



Duża trudność zarządzania projektem. Trudno
określić jakie warunki brać pod uwagę dla specyfiki
projektu.



Nieefektywny dla małych projektów

itm / MVLab (c) 2007-2008

eXtreme Programming



szybki model spiralny



opracowany w roku 1995

przez Kenta Becka, Warda
Cunninghama i Rona

Jeffriesa



model postępowania dla

programowania
obiektowego



zwinny proces rozwoju

aplikacji dla małych
zespołów



praca sterowana testami

1. Określ cel.
2. Wykonaj działanie.
3. Odbierz informację zwrotną.
4. Skoryguj działanie tak,
by kolejny efekt był bliższy sukcesowi.

itm / MVLab (c) 2007-2008

XP -to co najważniejsze



Iteracyjność -program tworzy się w iteracjach (krótkie, przyrostowe kroki

programistyczne); planuje tylko następną iterację. Efektem powinna być wersja
spełniającą założenia danej iteracji. Następnie planuje się co zrobić dalej. -Zasada
Open Source: "release early, release often".



Nie projektować z góry -nie można z góry przewidzieć, jaka architektura będzie
najlepsza dla danego problemu -należy ją tworzyć w miarę rozszerzania programu.



Testy podzespołów -testy podzespołów pisze się zanim w ogóle zacznie się pisać kod
- najlepiej na początku iteracji. Potem pisze się kod, który potrafi je wszystkie przejść.
Rezultat: to, co ważne, zostanie zaprojektowane, na resztę nie będzie tracony czas.



Ciągłe modyfikacje architektury -architektura nie jest niczym stałym; jeśli jej

modyfikacja ułatwi przejście danej iteracji i nie zepsuje wyników testów z poprzednich,
należy ją wykonać. Pod tę zasadę podlega także usuwanie wszystkich znanych błędów
przed rozszerzeniem funkcjonalności.



Programowanie parami -programiści piszą w parach: jeden przy klawiaturze (główny
koder), drugi obserwuje, zgłasza poprawki, zadaje pytania wyjaśniające (szybkie
wyłapanie wielu błędów). Kod, którym zajmuje się tylko jedna osoba, ma tendencje do

stawania się całkowicie niezrozumiałym dla kogokolwiek innego niż autor, a więc
dodatkowy programista zwiększa jakość kodu.



Stały kontakt z klientem -specyfikacje są prawie zawsze wieloznaczne, dziurawe i
sprzeczne ze sobą -należy mieć stały kontakt z tym, dla kogo to oprogramowanie jest
tworzone (klient zamawiający program, czy też użytkownicy końcowi).

itm / MVLab (c) 2007-2008

Praktyki XP

Programowanie w parach
Wspólna odpowiedzialność
Otwarta przestrzeń robocza

Refaktoryzacja

Efektywność

Ciągła integracja
i testowanie

Klient jest częścią zespołu

itm / MVLab (c) 2007-2008

Refaktoryzacja



Refaktoryzacja (czasem też refaktoring, ang. refactoring) to pojęcie
związane z wytwarzaniem systemów informatycznych, w
szczególności z programowaniem. Jest to proces wprowadzania
zmian w strukturze wewnętrznej projekcie/programie, w wyniku
którego zasadniczo nie zmienia się funkcjonalność i interfejs
użytkownika. W ramach refaktoryzacji podejmowane są następujące
działania:



modyfikowanie elementów systemu w celu wpasowania ich w przyjęte
standardy i wzorce



poszukiwanie nowych standardów i wzorców, które pojawiły się w systemie
w trakcie jego rozwoju i ich precyzyjne definiowanie (łącznie z
wpasowywaniem istniejących elementów w te definicje)

itm / MVLab (c) 2007-2008

XP - zalety i wady



brak możliwości stosowania w dużych projektach



brak wyraźnej specyfikacji



brak dokumentacji projektowej



testy są jedyną kontrolą poprawności działania
- brak dodatkowej kontroli jakości



duży wpływ klienta podczas procesu projektowania



wysoka motywacja programistów



wiarygodność terminów



pierwsza działająca wersja oprogramowania powstaje bardzo szybko
(choć w bardzo ograniczonej formie)



wysoka jakość produktu końcowego

itm / MVLab (c) 2007-2008

Wybór odpowiedniego modelu

stopień innowacyjności

ro

zle

gło

ść

proj

ekt

u

Code&fix

Model

kaskadowy

V-Model

Prototypowanie

Model

sawtooth

Model

spiralny

Model XP

itm / MVLab (c) 2007-2008

Cykle życia projektów



Opisywanie i przyporządkowywanie trzech istotnych
faz procesu projektowania oprogramowania



Znajomość i zrozumienie zasadniczych koncepcji
rozwoju oprogramowania



Przegląd obydwu najważniejszych koncepcji procesu
tworzenia oprogramowania

Analiza

Projektowanie

Implementacja

itm / MVLab (c) 2007-2008

Analiza–Projektowanie–
Implementacja

Problem

Wymagania

Rozwiązanie

Model w
dziedzinie
problemu
Model Problemu
(np. w UML)

Model w dziedzinie
rozwiązań:
Model Rozwiązania

Analiza wymagań

Analiza systemu

Projektowanie systemu

Implementacja

Podczas analizy i projektowania tworzone są modele problemów lub
ich rozwiązań → redukcja stopnia trudności

itm / MVLab (c) 2007-2008

Definicje



Analiza wymagań (zapotrzebowań): zapotrzebowania

wyznaczają jakościowe i ilościowe właściwości produktu z

punktu widzenia zleceniodawcy. Wymagania są definiowane

podczas fazy analizy



Analiza systemu: przełożenie wymagań na nowy produkt
programistyczny w postaci modelu problemu.



Projektowanie: rozwijanie takich środków technicznych

(programistyczne), które doprowadzą do rozwiązania problemu;
tworzony jest model produktu w przestrzeni rozwiązań; na

końcu otrzymuje się koncepcję rozwiązania.



Implementacja: budowanie działającego rozwiązania

programistycznego na bazie utworzonych koncepcji.

itm / MVLab (c) 2007-2008

Historia metodyk projektowania

Dżungla metodyk

podejście
proceduralne

podejście
obiektowe

Analiza strukturalna (SA)

Analiza obiektowa (OOA)

Strukturalny design (SD)

Obiektowy design (OOD)

Programowanie obiektowe (OOP)

Programowanie

strukturalne (SP)

itm / MVLab (c) 2007-2008

Podstawowe koncepcje
projektowania aplikacji I

Własności koncepcji podstawowych:



koncepcja atomowa



koncepcyjnie długowieczna



koncepcje wielokrotnego użycia



koncepcje stosowalności w
różnych kontekstach

Modele dają odpowiednie podejście do problemu ew. jego rozwiązania.

itm / MVLab (c) 2007-2008

Podstawowe koncepcje
projektowania aplikacji II

Dla różnych sposobów patrzenie na problem z biegiem czasu powstały

różne sposoby ich opisu:



podejście funkcjonalne: funkcjonalna hierarchia, przepływ
informacji,



podejście orientowane na dane: struktury danych, encje i relacje,



podejście orientowane obiektowo: struktury klasowe,



podejście algorytmiczne: struktury sterujące,



podejście regułowe: struktury jeśli-to,



podejście stanowe: automat skończony, struktury współbieżne



podejście oparte na scenariuszach: schematy interakcji

Modele dają odpowiednie podejście do problemu ew. jego rozwiązania.

itm / MVLab (c) 2007-2008

Zastosowanie koncepcji
bazowych

Podejście proceduralne

Metody:



Analiza strukturalna (SA),



Projektowanie strukturalne (SD),

Stosow. koncepcje bazowe:



podejście funkcjonalne



podejście orientowane na dane,



podejście algorytmiczne

Podejście obiektowe

Metody:



Analiza obiektowa (OOA),



Projektowanie obiektowe
(OOD),

Stosow. koncepcje bazowe:



podejście OO



podejście orientowane na dane,



podejście algorytmiczne,



podejście stanowe,



podejście oparte na
scenariuszach