Inżynieria Oprogramowania

Transkrypt

Anna Bobkowska
Maciej Piechówka
Katedra Inżynierii Oprogramowania
rii
z Inżynie
u
d
ła
k
y
w
nicze do
c
TI PG.
o
E
m
o
le
p
ia
z
ły
d
ia
y
Mater
ykładzie.
nia na W
w
a
w
a
o
n
i
m
c
a
ś
r
o
Oprog
uje obecn m celu oraz ich
p
ę
t
s
a
z
a nie
inny
.
Ich lektur nie materiałów w
bronione
a
a
t
z
s
t
y
s
z
r
je
o
Wy k
echnianie
z
s
w
o
p
z
ro
1. Wprowadzenie
2. Motywacje i zakres inżynierii
oprogramowania
3. Klasyczny cykl życia
© KIO
Wprowadzenie do przedmiotu
Cel:
przegląd
wiedzy
dotyczącej
metodycznego
oprogramowania o wysokiej jakości.
Wykład „Przegląd tematyki IO”
• Przedmiot inżynierii oprogramowania;
cykl życia systemu;
• Model kaskadowy
• Faza przedprojektowa
• Inżynieria wymagań i wybrane techniki
modelowania systemów
• UML
• Analiza wymagań; analiza obiektowa
• Projektowanie systemu; projektowanie
obiektowe
• Implementacja;
• Testowanie i walidacja systemu; inspekcje
• Wdrażanie i utrzymanie systemu
• Narzędzia CASE
• Inne podejścia i metodyki
© KIO
wytwarzania
Laboratorium „UML”
• Przygotowanie wizji systemu
• Modelowanie za pomocą
przypadków użycia
• Modelowanie obiektowe
• Modelowanie zachowania
• Elementy projektowania
Zaliczenie:
50% laboratorium
50% egzamin
Literatura
UML
• Booch G., Rumbaugh J., Jacobson I.: UML przewodnik
użytkownika, WNT, 2001
• Górski J. (red.) Inżynieria oprogramowania w projekcie
informatycznym, MIKOM, 2000
• Pressman R., Ince D., Software Engineering: a Practitioner’s
Approach. McGraw-Hill, 2000
• Sommerville I., Inżynieria Oprogramowania, 2003
• Szejko S.(red.), Metody wytwarzania oprogramowania,
MIKOM, 2002
© KIO
Motywacje:
Ważność i złożoność zagadnienia (1)
• System - zbiór wzajemnie
powiązanych elementów,
wyodrębnionych
z
otoczenia,
współdziałających
dla
realizacji wspólnego celu
Sprzęt
Oprogramowanie
Ludzie
Reguły użycia
• Materia (tworzywo)
• Środowisko
– rozproszenie elementów
systemu
© KIO
Środowisko
Motywacje:
Ważność i złożoność zagadnienia (2)
• Rewolucja informacyjna - zastosowania
informatyki:
– transport, produkcja, obsługa pieniądza, ochrona
zdrowia, administracja, rozrywka, telekomunikacja, ...
• Oczekiwania (głównie jakościowe):
–
–
–
–
–
–
–
© KIO
wysoce niezawodne
użyteczne
łatwe w użyciu
trudne do użycia w sposób niewłaściwy
bezpieczne
tanie
dostępne . . .
Specyfika oprogramowania (1)
• zdominowane przez proces projektowania
– pomijalne nakłady na produkcję, większość wysiłku skierowana
na projektowanie; niedojrzała technologia, kompetencje ?
• trudności w wizualizacji
– oprogramowanie to “niematerialny wytwór intelektu”; trudności
w obserwacji wcześniejszych form (specyfikacji wymagań,
projektu,...); dążenie do jak najwcześniejszej implementacji
obniżające szansę na sukces
• nie zużywa się
– nie zużywa się; wadliwe działanie wynika z niedopasowania do
środowiska, z błędów konstrukcji, często ujawniających się bardzo
późno
• duża złożoność
– trudno znaleźć standardy projektowe, trudno prześledzić wszystkie
sytuacje, wypuścić produkt pozbawiony błędów
© KIO
• dowolność struktury
– zwykle niewielkie ograniczenia i duże pole do popisu projektantów złożoność, nieregularność, niezrozumiałość struktury - trudności
modyfikacji i pielęgnacji
• zależność elementów
– niejawne zależności pomiędzy elementami prowadzą do trudności
konstrukcyjnych, błędnych ocen poprawności oprogramowania,
stwarzają problemy modyfikacji i pielęgnacji
• brak ograniczeń (np. prawami fizyki)
– nieznaczna zmiana może spowodować duże odchylenie; „mała
modyfikacja”? „przybliżona analiza”?
• łatwość zmian
– łatwość dokonywania zmian prowadzi do chaosu, błędów i
bylejakości
• trudność testowania
– niematerialność software’u, równoległość działań, skomplikowanie,
zakres możliwych danych istotnie utrudniają eliminacjędefektów
© KIO
Zdecydowana większość użytecznego oprogramowania
powstaje w układzie klient-wykonawca
oczekiwania
DZIEDZINA
PROBLEMOWA
© KIO
oprogramowanie
KLIENT
technologia
WYKONAWCA
DZIEDZINA
INFORMATYCZNA
Krzywe ilości uszkodzeń
ujawniających się w czasie
a) w przypadku sprzętu
© KIO
b) w przypadku oprogramowania
Procentowy rozkład błędów popełnianych
przy konstrukcji systemów
S fo rmuło
wa-nie
wymag ań
56%
Ko ns truk
c ja
26%
Ko do wani
e
7%
Inne błę dy
11%
© KIO
Rozkład kosztów wytworzenia
i utrzymania oprogramowania
100%
utrzymanie
80%
60%
40%
20%
wytworzenie
0%
1975
© KIO
1980
1985
1990
1995
Zauważalne problemy
i tendencje
•
wzrost wymagań użytkowników:
wiarygodność czy efektywność;
•
skomplikowanie systemów, nietrywialne zastosowania, wysoko
specjalizowane zadania
•
niska produktywność procesu wytwarzania
•
brak ‘rzemiosła’ i jednostkowość procesu wytwarzania powoduje
wysokie narzuty i koszty procesu produkcji
•
błędy
•
wzrost znaczenia fazy analizy i udziału użytkownika
•
koszt utrzymania i wzrost znaczenia właściwej dokumentacji
systemu
© KIO
użytkowość,
poprawność,
• Oprogramowanie (software) - zbiór programów, procedur
postępowania i związanej z nimi dokumentacji, w ramach danego
systemu (komputerowego).
• Inżynieria (engineering) - polega na takim zastosowaniu nauk
ścisłych, przyrodniczych i humanistycznych, poprzez które materia
i źródła energii naturalnej stają się użyteczne dla człowieka.
Inżynieria oprogramowania polega na takim zastosowaniu
nauk (ścisłych, przyrodniczych, humanistycznych), poprzez
które własności i możliwości sprzętu komputerowego stają
się, za pośrednictwem oprogramowania, użyteczne dla
człowieka.
© KIO
Podobieństwa inżynierii
oprogramowania
do tradycyjnej inżynierii
techniki rozwiązywania problemów
•
•
•
•
•
•
•
identyfikacja potrzeb
planowanie działań
zarządzanie projektem
systematyczna analiza
kontrola jakości procesu
ocena jakości produktu
bieżąca eksploatacja
© KIO
notacje
metodyki
narzędzia
Podstawowe różnice pomiędzy inżynierią
oprogramowania a inżynierią tradycyjną
© KIO

Brak praw fizyki

Program to “czysta” informacja

Statyczny obraz programu

Obserwacja pośrednia

Nie zużywa się
Drogi rozwiązania
Â Systematyczne wytwarzanie, zgodnie z przyjętym cyklem
Â Rozwój notacji modelujących i wspomaganie uznanych cykli rozwoju
oprogramowania, głównie klasycznego
Â Definiowanie nowych cykli wytwórczych, często posiłkujących się
nowymi metodologiami
Â Rozwijanie nowych metodologii systematycznej konstrukcji
oprogramowania, bazujących na istniejących bądź nowych
notacjach; najwięcej prac dotyczy metodologii obiektowych
Â Środowiska i narzędzia wspomagające
Â Wspomaganie zarządzania projektem informatycznym, planowania,
zarządzania ludźmi, minimalizacji ryzyka, zapewniania jakości
© KIO
Podejścia i metodyki
Czym jest metodyka konstrukcji systemu ?
-
© KIO
Jest zbiorem procedur, metod, narzędzi i środków
wspomagających dokumentowanie
Składa się z faz, które same składają się z kolejnych faz
Stanowi 'przewodnik' dla konstruktorów systemu
Stanowi metodę systematycznej budowy systemów
Bazuje na pewnym widzeniu świata, nazywanym podejściem
(ang.: approach)
Podejścia
• Modularyzacja
• Podejście strukturalne
¨
• Wykorzystanie metod formalnej specyfikacji
• Podejście obiektowe
¨
© KIO
Popularne metody
modelowania systemów
Modelowanie danych
Modelowanie
przetwarzania
Modelowanie funkcji
Modelowanie
zachowania
Modelowanie struktury
statycznej i
dynamicznej
© KIO
model relacyjny, diagramy związków encji
model obiektowy
słowniki danych
abstrakcyjne typy danych (ADT)
diagramy przepływu danych
języki opisu, jak Structured English czy Program
Description Language
tablice decyzyjne, drzewa decyzji
diagramy akcji, diagramy przepływu
diagramy przepływu pracy
hierarchie funkcji i macierze powiązań
przypadki użycia (use cases)
abstrakcyjne typy danych
modele grafowe, sieci Petriego
FSMs, automaty, diagramy przejść stanu
diagramy interakcji, diagramy komunikacji (MSC)
drzewa zdarzeń, drzewa błędów
VDM, Z
diagramy struktury
modele obiektowe
modele komunikujących się procesów, CCS , CSP ,
języki formalnej specyfikacji
Środowiska wspomagajace
9 specyfikację wymagań, najcześciej za pomocą notacji graficznych,
9 walidację dokonanej specyfikacji (modelu logicznego), ocenę jej spójności i
kompletności,
9 przekształcenie utworzonego modelu w projekt,
9 weryfikację zgodności projektu z wymaganiami i jego logiczną walidację, często
poprzez prototypowanie lub symulację działania przyjętej konstrukcji,
9 szkieletową lub pełniejsza generację kodu,
9 testowanie, animację i pomiary utworzonej aplikacji,
9 tworzenie dokumentacji, na różnych poziomach i w różnych przekrojach,
9 zarządzanie projektem, od planowania i harmonogramowania po kontrolę realizacji,
9 analizę zamierzonych zmian i wspomaganie ich dokonania,
9 prace zapewniające re-development, zarządzanie konfiguracją lub przeniesienie
aplikacji do nowego środowiska
9 reverse - engineering, czyli pozyskiwanie specyfikacji projektowej oraz analitycznej
na podstawie istniejącego kodu i wiedzy konstruktora,
9 powtórne wykorzystanie wcześniejszych rozwiązań w konstrukcji nowych projektów
9 wersjonowanie projektu oraz zespołową pracę nad nim
© KIO
Cykl życia systemu
Struktura
obrazująca
podstawowe
etapy rozwoju i eksploatacji systemu
wraz z ich produktami, wzajemnymi
relacjami
pomiędzy
tymi
etapami
oraz ich zależnościami w czasie
© KIO
Cykl życia
i cykl wytwarzania systemu
Â Cykl życia oprogramowania reprezentuje powtarzającą się
w czasie całość działań prowadzonych od ujawnienia potrzeby
budowy systemu po zakończenia jego wykorzystania.
Obrazowane są kolejne etapy rozwoju i eksploatacji systemu,
wraz z ich kontekstem, produktami, wzajemnymi relacjami
i zależnościami w czasie.
Â Cykl wytwarzania oprogramowania - ta część cyklu życia,
która obejmuje etapy wytwórcze.
© KIO
Cykl życia systemu
Studium potrzeb
i możliwości
?
Utrzymanie
Nie
Analiza wymagań
Specyfikacja
“Klasyczny cykl życia
systemu”
to całość działań
prowadzonych
od ujawnienia potrzeby
jego budowy,
poprzez analizę
stawianych wymagań,
projektowanie
i implementację
oprogramowania,
Projektowanie
Implementacja
© KIO
jego konserwację,
do zakończenia
wykorzystania
oprogramowania
Model klasyczny (kaskadowy)
Faza
Faza
przedprojektowa
przedprojektowa
(Planowanie)
(Planowanie)
Analiza
Analiza
Projektowanie
Projektowanie
Implementacja
Implementacja
Testowanie
Testowanie
Wdrożenie
Wdrożenie
i ipielęgnacja
pielęgnacja
© KIO
Klasyczny cykl życia - produkty (wg ESA)
UR
UR/R
SR
SR/R
AD
AD/R
DD/R
DD
TR
OM
FAZY
ELEMENTY
DEFINIOWANIE
WYMAGAŃ
UŻYTKOWNIKA
DEFINIOWANIE
WYMAGAŃ SOFTWARE'OWYCH
PROJEKT
KONSTRUKCYJNY
PROJEKT
SZCZEGÓŁOWY
I
WYTWARZANIE
PRZEKAZANIE
UŻYTKOWANI
E
I
UTRZYMANIE
GŁÓWNE
DZIAŁANIA
• ustalenie
środowiska
użytkwania
• identyfikacja
wymagań
użytkownika
• konstrukcja
modelu
logicznego
• identyfikacja
wymagań
software'owych
• konstrukcja
modelu
fizycznego
• zdefiniowanie
podstawowych
komponentów
• instalacja
• testy
wstępnego
odbioru
• testy
ostatecznego
odbioru
• użytkowanie
• utrzymanie
kodu i
dokumentacji
PRODUKTY
Dokument
Wymagań
Użytkownika
Dokument
Wymagań
Software'owych
Dokument
Projektu
Konstrukcyjnego
• projektowanie
modułów
• kodowanie
• testy
segmentów
• testy integracyjne
• testy
systemowe
Dokument
Szczegółowego
Projektu
Dokument
Przekazania
Software'u
Dokument
Historii
Projektu
URD
→
SRD
→
ADD
→
DDD
Kod
→
→
→
STD
→
PHD
SUM
Podręcznik
Użytkownika
Oprogramowani
a
PRZEGLĄDY
GŁÓWNE
ETAPY
AD;ADD;AD/R
DD;DDD;DD/R
PHD
SR;SRD;SR/R
STD
SUM
UR/D/R
© KIO
przeglądy
techniczne
Zatwierdzenie
URD
przeglądy
kontrole
przeglądy
techniczne
Zatwierdzenie
SRD
Architectural Design/Document/Review
Detailed Design and production/Document/Review
Project History Document
Software Requirements/Document/Review
Software Transfer Document
Software User Manual
User Requirements/Document/Review
przeglądy
kontrole
przeglady
techniczne
Zatwierdzenie
ADD
przeglądy
kontrole
przeglądy
techniczn
e
Zatwierdzenie
Kodu/ADD/
SUM
Projekt Konstrukcyjny/Dokument /Przegląd
Szczegółowy Projekt i Wytwarzanie/Dokument /Przegląd
Dokument Historii Projektu
Wymagania Software'owe/Dokument /Przegląd
Dokument Przekazania Oprogramowania
Podręcznik Użytkownika Oprogramowania
Wymagania Użytkownika/Dokument/Przegląd
Powstanie STD
Wstępny odbiór
Powstanie PHD
Ostateczny
odb.
Faza przedprojektowa
•
•
•
•
•
© KIO
Identyfikacja problemu
Studium wykonalności
Decyzja o realizacji projektu
Inicjalizacja projektu + ustalenia
Plan projektu
Zdefiniowanie problemu
• Opis nieformalny
• Opis ustrukturalizowany:
Założenia wstępne
√
√
√
√
zadania systemu
cele biznesowe
wizja systemu: zakres i zadania, użytkownicy, perspektywiczność,
podstawowe założenia, parametry jakościowe i techniczne, zgodność
ze standardami, organizacja działania systemu
uwarunkowania: ograniczenia zasobowe, powiązane projekty,
wymagania i ograniczenia prawne, inne uwarunkowania
• Soft Systems Methodology (SSM)
© KIO
Wizja systemu
1.
Cele systemu
2. Kontekst systemu
Użytkownicy i ich specyfika
Inne systemy i ich interfejsy
3. Zakres funkcjonalności
Opis, jakie usługi system ma udostępniać.
4. Ograniczenia
Ograniczenia, które mają wpływ na kształt systemu:
- dotyczące zasobów projektowych: czasowe, ludzkie, sprzętowe,
oprogramowanie;
- dotyczące produktu: interfejsów, dotyczące działania w
specyficznych warunkach, dokumentacji, specyficzne wymagania
użytkownika.
5. Wymagania jakościowe
Wymagania dotyczące ochrony, bezpieczeństwa, przenośności,
elastyczności, konfigurowalności, niezawodności, wydajności itp.
© KIO
Analiza wykonalności
• Studium wykonalności rozwiązania
problemów i opcji wskazanych
w założeniach projektu
• Dyskusja wariantów rozwiązania
• Podstawy podjęcia decyzji
o kontynuacji (lub nie) projektu
© KIO
•
•
•
•
wykonalność techniczna
wykonalność ekonomiczna
wykonalność organizacyjna
aspekty prawne
Raport studium
wykonalności
© KIO
•
Cel, zakres i uwarunkowania
•
Istniejący system
•
Wymagania użytkownika
•
Opis proponowanego systemu
•
Strategia i harmonogram prowadzenia prac
•
Rozwiązania alternatywne
•
Koszty i korzyści
•
Analiza ryzyka
•
Ramy prawne
Plan projektu
• Cel projektu
• Zakres projektu
• Strategia, priorytety, infrastruktura,
role ...
• Wybór sposobu wytwarzania
• Opis poszczególnych etapów
• Harmonogram
© KIO
Analiza wymagań (co?)
• identyfikacja i specyfikacja wymagań
użytkowych
• specyfikacja wymagań
oprogramowania
modelu logicznego
-Inżynieria Wymagań
-Modelowanie, np. UML
© KIO
dotyczących
konstrukcja
Poziomy specyfikacji wymagań
Wymagania
systemowe (użytkowe)
Modele
koceptualne
Wymagania względem
oprogramowania
© KIO
Diagram przypadków użycia
Biblioteczka domowa
[J. Uścinowicz]
Modyfikowanie
danych o książce
Dodawanie
danych o książce
extends
extends
Przeglądanie
danych o książce
uses
Ewidencja
książek
Usuwanie
danych o książce
© KIO
Użytkownik
extends
Model obiektowy
Biblioteczka domowa
[J. Uścinowicz]
© KIO
Diagram interakcji
Biblioteczka domowa [J. Uścinowicz]
• Modyfikacja danych dotyczących książki
«user»
Wlasciciel
«business»
Ksiazka
Description
Zmiana informacji dotyczacych
danej ksiazki
Sprawdzenie poprawnosci
wprowadzonych danych
Wprowadzenie danych
Komunikatu o blednych danych
Sprawdzenie poprawnosci danych
If dane bledne
Zapisanie rekordu ze
zmodyfikowanymi danymi
do bazy danych.
© KIO
Zapisanie zmodyfikowanego rekordu
Projektowanie
• projekt wysokiego poziomu
• projekt szczegółowy
© KIO
(jak?)
Usytuowanie Projektowania
w cyklu wytwarzania
Model
funkcji
Model
danych
Model
zachowania
Projekt
danych
Projektowanie
Inne
wymagania
Projekt
architektury
Ograniczenia
Implementacja
Projekt
procedur
Kod
programu
Testowanie
Zintegrowane,
po walidacji,
oprogramowanie
© KIO
Przedmiot Fazy
projektowania
[Presmann]
© KIO
Implementacja
• kodowanie
• testowanie (modułów)
© KIO
Testowanie i walidacja
• integracja i testy integracyjne
• walidacja i testy systemowe
• testowanie akceptacyjne
© KIO
Testowanie i walidacja
user requirements
acceptance tests
validation tests
logical design
system testing
system
architecture
integration
testing
detail
design
unit
testing
coding
© KIO
Model V
WYMAGANIA
PROJEKT
SYSTEMU
PROJEKT
SZCZEGÓŁOWY
PLANOWANIE
TESTU
SYSTEMU
PLANOWANIE
TESTU
INTEGRACYJNEGO
PLANOWANIE
TESTÓW
MODUŁÓW
KODOWANIE
© KIO
TEST
SYSTEMU
INSTALACJA
TEST
INTEGRACYJNY
TEST
MODUŁÓW
PIELĘGNACJA
Sterowanie jakością - model V
Project
planning
Q
Requirements
analysis
Q
Design
Q
Implementation
© KIO
Q
User
requirements
Documen
tation
Software
requirements
(software models)
Design proposal
Acceptance test
specification
Systen
architecture
specification
Module (object)
specification
Integration
and module
test plans
Acceptance
testing
Test reports
Integration
tests
Test reports
Module tests
Test reports
Documentation
Code, forms, prototypes,...
Finalising
Q
Testing
Q
Implementation
Wdrożenie systemu
• Złożoność problemu
• Kulminacja błędów i odpowiedzialności
© KIO
Fazy wdrożenia
Â
Â
Â
Â
Â
Â
Â
Â
Â
© KIO
Planowanie wdrożenia
Przygotowanie
Instalacja
Szkolenie
Reorganizacja przedsiębiorstwa
Zmiana systemu
Ocena / audyt
Dostosowanie
Eksploatacja
Utrzymanie
(pielęgnacja, konserwacja)

pielęgnacja naprawcza (ang. corrective maintenance)
obejmuje diagnostykę i usuwanie błędów,

adaptacja (ang. adaptive maintenance),
dostosowuje oprogramowanie do zmian środowiska jego pracy,

ulepszanie (ang. perfective maintenance)
ma na celu poprawę funkcjonalności i jakości oprogramowania, np.
dostosowanie oprogramowania do nowych wymagań użytkowników,
zwiększenie wydajności wybranych funkcji systemu,
zmianę interfejsu użytkownika

utrzymanie zapobiegawcze (ang. preventive maintenance)
przygotowuje istniejące oprogramowanie do zwiększenia jego
pielęgnowalności, w tym głównie do wykrycia i poprawienia defektów
zanim one wystąpią.
© KIO
Zalety modelu kaskadowego
•
•
•
•
•
•
© KIO
obejmuje cały cykl życia
wprowadza systematykę
sprawdzony, zweryfikowany praktycznie
dobra strukturalizacja (etapy, czynności)
uwypukla analizę i projektowanie, ze szczególnym
uwzględnieniem aspektów technicznych rozwiązania
pozwala na dobrą dekompozycję pracy
Problemy
•
•
•
•
•
•
•
© KIO
założenie: a priori wiadomo ‘co’
proces silnie zależy od stabilności wymagań, która
w praktyce jest bardzo trudna do uzyskania
oderwanie od użytkownika
walidacja produktu następuje dopiero w końcowych
krokach
poprawa bądź konieczność dopasowania produktu do
rzeczywistych potrzeb użytkownika prowadzi do wzrostu
kosztów (reguła 1:10)
niska produktywność
błędy powodujące znaczne koszty utrzymania
Inne cykle rozwoju
systemów informatycznych
¾ Klasyczny (kaskadowy)
¾
¾
¾
¾
¾
© KIO
Prototypowanie
Rozwój ewolucyjny i przyrostowo-ewolucyjny
Przekształcenia formalne
Wielokrotne użycie oprogramowania (reuse)
Ponowna inżynieria (re-engineering)
Podsumowanie
© KIO