(Microsoft PowerPoint - WstepIO [tryb zgodno\234ci])

Kontakt
Inżynieria
oprogramowania I
Andrzej Jaszkiewicz
Podejście amatorskie a
inżynierskie
Rynek oprogramowania 2008
Świat 304 miliardy $ (451 miliardów 2013F)
Andrzej Jaszkiewicz
p. 8, CW Berdychowo
tel. 66 52 933
[email protected]
Bez oprogramowania wytwarzanego na własne
potrzeby
Co by tu
wymyślić!?
Do pracy.
Wzrost 6.5% rocznie
W UE 6060-70% oprogramowania jest
wytwarzane w firmach, dla których nie jest to
główną działalnością
Definicje inżynierii
oprogramowania
Duże systemy wymagające pracy wielu
osób – praca grupowa
Wielowersyjność oprogramowania
Definicja inżynierii
oprogramowania
Wiedza
iedza techniczn
technicznaa, dotycząca
dotycząca
wszystkich faz cyklu życia
oprogramowania, której celem jest
uzyskanie wysokiej jakości produktu oprogramowania.
1
Jakość
produktu/oprogramowania
Użyteczność/funkcjonalność (usefulness)
Niezawodność (reliability)
Ergonomia (usability)
Efektywność (efficiency)
Łatwość konserwacji/utrzymania/modyfikacji
(maintability)
Literatura
Koszt
Bezpieczeństwo użytkownika (user safety)
Wygląd
A. Jaszkiewicz, Inżynieria oprogramowania,
Helion, 1997.
G. Booch,
Booch, J. Rambaugh,
Rambaugh, I. Jacobson, UML
przewodnik użytkownika, WNT, 2000.
M. Fowler, K. Scott, UML w kropelce, Oficyna
Wydawnicza LTP, 2002
S. Maguire
Maguire,, Niezawodność oprogramowania,
Helion, 2002
J. W. Cooper, Java. Wzorce projektowe,
Helion, 2001
Literatura
Sommerville Ian Inżynieria oprogramowania,
WNT, 2003.
Pressman Roger S. Praktyczne podejście do
inżynierii oprogramowania, WNT, 2004.
Warmer Jos, Kleppe Anneke,
Anneke, Inżynieria
oprogramowania OCL precyzyjne modelowanie
w UML, WNT, 2003.
Kernighan W. Brian, Pike Rob Inżynieria
oprogramowania. Lekcja oprogramowania,
WNT, 2002.
Literatura
Trochę historii - Rozwój technik
wytwarzania oprogramowania
Program wykładu - semestr I
Wprowadzenie w tym podstawowe modele cyklu życia
Analiza/modelowanie systemów z wykorzystaniem języka UML
Analiza/modelowanie systemów z wykorzystaniem języka UML
UML jako narzędzie projektowania i dokumentowania
oprogramowania
Projektowanie oprogramowania
Projektowanie oprogramowania
Wzorce projektowe
Refaktoryzacja
Niezawodność oprogramowania – unikanie błędów, odporność na
błędy
Niezawodność oprogramowania – testowanie
Konserwacja i ponowne wykorzystanie oprogramowania,
dokumentacja techniczna i użytkowa
Narzędzia inżynierii oprogramowania. Zarządzanie zmianami i
konfiguracją
Kolokwium zaliczeniowe
UML. Inżynieria oprogramowania. Wydanie
IIUML. Inżynieria oprogramowania. Wydanie
II, P. Stevens, Helion, Gliwice, 2007
E. Gamma, R. Helm,
Helm, R. Johnson, J. Vlissides,
Vlissides,
Wzorce projektowe. Elementy
oprogramowania obiektowego wielokrotnego
użytku, WNT, 2008
K. Sacha, Inżynieria oprogramowania, PWN,
2010.
R.C. Martin, M. Martin, Agile, programowanie
zwinne, Helion, 2008.
Lata 5050-te
Sprzęt o bardzo ograniczonych
możliwościach
Ograniczone zastosowania
Małe programy
Programy pisane często dla własnych
potrzeb lub potrzeb dobrze znanych osób
Dobrze wyspecyfikowane zadania
2
Rozwój technik wytwarzania
oprogramowania
Lata 6060-te
Kryzys oprogramowania
Profesjonalni programiści
Nowe języki programowania – COBOL,
Fortran, Algol
Sprzęt o dużo większych możliwościach, np.
pamięć wirtualna
Nowe zastosowania – np. w biznesie
Próba realizacji wielu dużych przedsięwzięć
programistycznych
Rozwój technik wytwarzania oprogramowania
nie nadąża za rozwojem sprzętu
komputerowego
Czy kryzys oprogramowania trwa do dzisiaj?
Zależność osiągnięciaosiągnięciaoczekiwania w wytwarzaniu
oprogramowania
Efekty
Oczekiwania
Przyczyny kryzysu
oprogramowania
Kryzys
Rzeczywiste
osiągnięcia
Czas
Początek inżynierii
oprogramowania
1968 NATO Conference on Software
Engineering
Nadal większość przedsięwzięć przekracza czas
i/lub budżet (choć trend jest pozytywny)
Około 25% przedsięwzięć programistycznych nie
jest kończona
90% firm przyznaje, że dość często zdarzają im się
opóźnienia przedsięwzięć
Powszechna akceptacja kiepskiej jakości
oprogramowania (w pewnych obszarach)
Duża złożoność systemów informatycznych
Złożoność, zmienność, nieadekwatność wymagań
Niepowtarzalność poszczególnych przedsięwzięć
Nieprzejrzystość procesu budowy oprogramowania
Pozorna łatwość wytwarzania i modyfikowania
oprogramowania
oprogramowani
a
Potrzeba kreatywności
Czynnik ludzki
Mało wymagający rynek
Niedoskonałość narzędzi
Zakres inżynierii
oprogramowania
Wytwarzanie oprogramowania i innych
produktów (np. dokumentacji)
Zarządzanie wytwarzaniem
oprogramowania
3
Modele cyklu życia
oprogramowania
Uporządkowanie prac.
Ustalenie kolejności prac.
Planowanie i monitorowanie realizacji.
Programowanie odkrywcze
Ogólne
określenie
wymagań
Ogólny
projekt
Budowa
systemu
Ocena
systemu
Wdrożenie
Model kaskadowy
Tak
System
poprawny
Nie
Dodatkowe fazy w modelu
kaskadowym
Określenie
wymagań
Projektowanie
Implementacja
Testowanie
Konserwacja
Co zastępuje testy w innych
dziedzinach techniki?
Certyfikaty
Zapasy bezpieczeństwa
Symulacje
Prototypy techniczne – spike solutions
Ścisłe i elastyczne
rozumienie modelu
kaskadowego
Określenie
wymagań
Projektowanie
Implementacja
Testowanie
Konserwacja
4
Przykład elastycznego
podejścia do modelu
kaskadowego
analiza
projektowanie
implem entacja testowanie wdrażanie
odniesienie do
12 modelu wodspadowego
100%
Wady i zalety modelu
kaskadowego (rozumianego ściśle)
90%
10
80%
wdrożenie
60%
50%
6
40%
4
30%
im plementacja
projektowanie
współpraca z odbiorcą
zarządzanie konfiguracją
zarządzanie projektem
2
10%
0%
analiza
liczba pracowników
20%
zapewnianie jakości
8
pracownicy
pracochłonność
70%
+ Łatwość zarządzania – planowanie i
monitorowanie
- Wysoki koszt błędów popełnionych we
wstępnych fazach
Koszt błędu w wymaganiach 100100-1000 razy
większy od kosztu błędu programistycznego!
- Długa przerwa w kontaktach z klientem
- Nie lubiany przez wykonawców
0
1
2
3
4
5
6
7
8
9
10
czas
Prototypowanie
Cel – lepsze określenie wymagań
Fazy:
Ogólne określenie wymagań
Budowa prototypu
Weryfikacja prototypu przez klienta
Pełne określenie wymagań
Realizacja pełnego systemu zgodnie z
modelem kaskadowym lub innym
profesjonalnym modelem
Wady i zalety
prototypowania
+ Mniejsze ryzyko popełnienia
kosztownych błędów we wczesnych
fazach.
+ Możliwość szybkiej demonstracji
prototypu i szkolenia użytkowników.
- Koszt budowy prototypu, który może
się nie zwrócić.
- Możliwość nieporozumień z klientem.
Sposoby budowy prototypu
Prototyp musi być zbudowany szybko i niskim
kosztem
Niepełna realizacja
Języki wysokiego poziomu
Wykorzystanie gotowych komponentów
Generatory interfejsu użytkownika
Szybkie programowanie (quick
quick--andand-dirty
programming)
Papier
Programowanie odkrywcze
Realizacja przyrostowa
Określenie
wymagań
i wstępny
projekt
Wybór przyrostu
- podzbioru
funkcji
Proces realizowany
iteracyjnie
Realizacja
przyrostu
Wdrożenie
przyrostu
5
Wady i zalety realizacji
przyrostowej
+ Możliwość wcześniejszego
korzystania z pewnych funkcji systemu
+ Skrócenie przerw w kontaktach z
klientem
+ Możliwość elastycznego reagowania na
opóźnienia
- Kłopoty z integracją oddzielnie
realizowanych modułów
Łączenie realizacji przyrostowej
z prototypowaniem
1.
2.
Jeden prototyp na początku, potem
realizacja przyrostowa
Prototyp w ramach każdego przyrostu
Rational unified process
Realizacja przyrostowa
Zalecana w większości żwawych (agile)
metodyk – np. w programowaniu
ekstremalnym – często małe przyrosty
(kilka tygodni)
Dobrze opisuje realizację wielu
(zwłaszcza udanych) projektów wolnego
oprogramowania (free
(free/
/open source)
source)
Cykl życia w lekich
metodykach
Ogólne określenie
wymagań i
projekt
architektury
Wybór przyrostu
(podzbioru
funkcji)
Analiza wymagań
i projektowanie
Opracowanie
przypadków
testowych
Implementacja
Implementacja
i testy jednostkowe
Integracja i testy
Wdrożenie
przyrostu
Refaktoryzacja
Rational unified process
Faza rozpoczęcia
(Inception phase)
Faza opracowywania
(Elaboration phase)
Faza konstrukcji
(Construction phase)
Faza przekazania
systemu
(Transition phase)
6
Wybór modelu do
konkretnego przedsięwzięcia
Duże przedsięwzięcia, np. > 6 miesięcy –
realizacja przyrostowa, mniejsze m.
Kaskadowy
W żwawych metodykach także dla mniejszych
przedsięwzięć
Trudności w określeniu wymagań:
nowatorski system z punktu widzenia klienta
mała znajomość dziedziny problemu przez
wykonawcę:
Jeżeli tak, to prototypowanie
Typowe zasady nowoczesnych
metodyk
Praca zespołowa z udziałem klienta
Opowieści (scenariusze) użytkownika
Krótkie cykle
Plan iteracji i wydania
Testy akceptacyjne na bazie opowieści
użytkownika
Programowanie w parach
Wytwarzanie sterowane testami
Typowe zasady nowoczesnych
metodyk
Wspólna własność
Ciągła integracja
Równe tempo
Prosty projekt, metafora
Refaktoryzacja
7