1
Inżynieria Oprogramowania
inżynieria wymagań
Dr inż. Ilona Bluemke
2
Plan wykładu
z
Faza strategiczna
z
Niepowodzenia projektów
z
Koszty usuwania błędów
z
Wymagania
3
Faza strategiczna
Wykonywana zanim zostanie podjęta
decyzja o realizacji dalszych etapów
przedsięwzięcia
z
oprogramowanie zamawiane -
negocjacje i/lub przetarg
z
oprogramowanie rynkowe - rozważana i
planowana produkcja nowego programu
czy nowej wersji
4
Studium wykonalności
(feasibility study) -1
czynności:
z
rozmowy, wywiady z przedstawicielami klienta
z
określenie celów przedsięwzięcia z punktu
widzenia klienta
z
określenie zakresu oraz kontekstu
przedsięwzięcia
z
określenie wymagań - ogólne, zgrubna analiza
i projekt systemu
z
propozycja kilku możliwych sposobów
realizacji
5
Studium wykonalności
(feasibility study) - 2
z
oszacowanie kosztów
z
analiza rozwiązań
z
prezentacja wyników, korekcja
z
określenie wstępnego harmonogramu
oraz przedstawienie struktury zespołu
realizującego
z
określenie standardów zgodnie z którymi
będzie realizacja
6
Decyzje strategiczne
z
wybór modelu, zgodnie z którym będzie
realizowane przedsięwzięcie
z
wybór technik stosowanych w analizie
z
wybór środowiska implementacji
z
wybór narzędzia CASE
z
określenie stopnia wykorzystania gotowych
komponentów
z
podjęcie decyzji o współpracy z innymi
producentami i/lub zatrudnieniu ekspertów
zewnętrznych
2
7
faza strategiczna
Rozważa się kilka możliwych rozwiązań.
Propozycje rozwiązań powinny być poprzedzone
określeniem ograniczeń, przy których
przedsięwzięcie będzie realizowane
z
maksymalne nakłady
z
dostępny personel
z
dostępne narzędzia
z
ograniczenia czasowe
8
W stęp n e z bier a n ie
w ym a g a ń
B u d ow a
p r ototyp u
O cen a
p r ototyp u
O p r a cow a n ie
w ym a g a ń
A n a liz a
P r ojek t d z ied z in y
p r oblem u
P r ojek t in ter fejsu
u ż ytk ow n ik a
P r ojek t b a z y
d a n ych
R ea liz a cja ba z y d .
Im p lem en ta cja
T esty
W d r oż en ie
m iesią ce
9
Normy jakości oprogramowania
ISO/IEC TR 9126 software engineering
product quality standards:
z
part 1- Quality model : 2001
z
part 2 – External metrics : 2003
z
part 3 - Internal metrics : 2002
10
Syndrom LOOP
L
Late
- późno
O
Overbudget
- przekroczony budżet
O
Overtime
- nadgodziny
P
Poor quality
- kiepska jakość
11
Przyczyny niepowodzenia
projektów
(wg Standish Group 1994)
z
13% - brak danych wejściowych
z
12% - niepełne wymagania i specyfikacje
z
12% - zmiany wymagań i specyfikacji
z
4% - nierealny plan, harmonogram
z
6% - nieodpowiedni personel
z
7% - nieznajomość technologii
1/3 projektów stwarza problemy z
gromadzeniem, dokumentowaniem i
zarządzaniem wymaganiami.
12
Udane projekty
projekty dostarczone na czas i w ramach
budżetu:
z
duże firmy - 9%
z
małe firmy – 16%
Przyczyny sukcesu: (wg Standish Group 1994)
z
16% - zaangażowanie użytkownika
z
14% - wsparcie kierownictwa
z
12% - jasne określenie wymagań
3
13
problemy produkcji oprogramowania
ESPITI (European Software Process
Improvement Training Initiative) 1995
najważniejsze problemy :
z
specyfikacje wymagań
z
zarządzanie wymaganiami
14
Podsumowanie wad wg Capersa
Jonesa
0.75
85%
5.00
suma
0.12
70%
0.40
niewłaściwe
poprawki
0.12
80%
0.60
dokumentacja
0.09
95%
1.75
kod
0.19
85%
1.25
projekt
0.23
77%
1.00
wymagania
Dostarczone
wady
Skuteczność
usuwania
Potencjalna
wada
wada
15
Względne koszty usuwania błędów
na różnych etapach (Davies 1993):
Względne koszty usuwania błędów
oprogramowania na różnych etapach (Davies
1993):
z
0.1-0.2 Określania wymagań
z
0.5
Projektowanie
z
1
Kodowanie
z
2
Testowanie jednostek
z
5
Testowanie akceptacyjne
z
20
Pielęgnacja
16
Kategorie błędów projektowych:
z
projekt budowany z poprawnego zbioru
wymagań
z
projekt budowany na błędnych
wymaganiach (kosztowne)
z
projekt będzie przerobiony lub odrzucony,
marnotrawstwo czasu, wysiłku
z
błędy ukryte, wykrywane jako błędy
wymagań po długim czasie
17
Przeciekanie błędów
74 % błędów wymagań wykrywanych na etapie
analizy wymagań
„przeciekanie błędów:
z
(Hughes Aircraft 15 lat)
z
4% - projekt wstępny, zaawansowany
z
7% - projekt szczegółowy
z
4% - pielęgnowanie
Błędy wymagań pochłaniają 25-40% sumy
budżetu
18
Naprawa błędu może pociągnąć
koszty w obszarach:
z
Ponowna specyfikacja
z
Ponowne projektowanie
z
Ponowne kodowanie
z
Ponowne testowanie
z
Dokumentowanie
z
Działania korygujące – likwidacja uszkodzeń
z
Anulowanie np. kodu, projektu bazującego na
błędnych wymaganiach
z
Wycofanie gotowych wersji oprogramowania
z
Koszty gwarancji
z
Koszty serwisu (np. instalacja nowej wersji)
z
Odpowiedzialność karna związana z produktem
4
19
Wymaganie (def Thyler )
z
Możliwość rozwiązania problemu i
osiągnięcia celu wymagana przez
użytkownika
z
Możliwość spełnienia umowy, normy,
specyfikacji lub innej dokumentacji, którą
musi mieć system
20
Zarządzanie wymaganiami
z
Systematyczne podejście do uzyskiwania,
organizowania i dokumentowania wymagań
systemu oraz proces, który ustala i zachowuje
umowę między klientem a zespołem
realizującym przedsięwzięcie w zależności od
zmieniających się wymagań systemu.
z
Zbiór zorganizowanych, uniwersalnych i
usystematyzowanych procesów i technik
zajmowania się wymaganiami stawianymi
złożonemu dużemu przedsięwzięciu.
21
Analiza problemu
Proces rozumienia rzeczywistych problemów i
potrzeb użytkownika oraz proponowanie
rozwiązań spełniających te potrzeby.
z
Uzgodnienie definicji problemu
z
Zrozumienie podstawowych przyczyn
problemu kryjącego się za innym problemem
z
Zidentyfikowanie udziałowców i użytkowników
tworzonego systemu
z
Zidentyfikowanie granicy systemu
z
Zidentyfikowanie ograniczeń nałożonych na
rozwiązanie
22
Uzgodnienie definicji problemu
Rozpisanie i sprawdzenie, czy zgadza się z tym
każdy uczestnik przedsięwzięcia.
Format:
Problem polega na
- opisz
Problem dotyczy
- wskaż udziałowców
Rezultatem problemu jest
- opisz wpływ na
udziałowców i przedsiębiorstwo
Korzyści z rozwiązania problemu
- wskaż
proponowane rozwiązanie i wymień
podstawowe korzyści
23
Zrozumienie podstawowych przyczyn
problemu kryjącego się za innym
Za dużo
odpadów
Niedokładne
zamówienia
Uszkodzenia w
transporcie
Zwroty od
klientów
Starzenie się
wyrobów
Wady
produkcji
Inne
24
Zidentyfikowanie udziałowców i
użytkowników
z
Udziałowiec
– każdy na kogo
implementacja systemu ma zasadniczy
wpływ
z
Potrzeby udziałowców nie będących
użytkownikami muszą być również
określone i uwzględnione
5
25
Pomocne pytania
z
Kim są użytkownicy
z
Jaka jest rola klienta systemu
z
Na kogo jeszcze będą miały wpływ wyniki
działania systemu
z
Kto będzie oceniał i zatwierdzał system po
jego dostarczeniu
z
Czy są inni zewnętrzni i wewnętrzni
użytkownicy systemu, których potrzeby muszą
być uwzględnione
z
Kto będzie pielęgnował system
26
Identyfikacja aktorów
klucz w analizie problemu
z
Kto dostarcza, używa lub usuwa informacje
z
Kto obsługuje
z
Kto utrzymuje, pielęgnuje, konserwuje
z
Gdzie system będzie stosowany
z
Gdzie zostaną wprowadzone dane
z
Jakie inne systemy zewnętrzne będą z nim
oddziaływać
27
Zidentyfikowanie ograniczeń
nałożonych na rozwiązanie
z
Ekonomiczne (ograniczenia finansowe,
budżetowe, licencyjne)
z
Polityczne
z
Techniczne (ograniczenia w wyborze technologii,
platformy, zakupione pakiety)
z
Systemowe (rozwiązanie wbudowane w istniejący
system, kompatybilność z innymi rozwiązaniami,
systemy operacyjne)
z
Środowiskowe (bezpieczeństwo, prawo, normy)
z
Planowanie i zasoby (ograniczenia zasobów, ich
zwiększenie stale, chwilowe, zatrudnienie osób
spoza firmy)
28
Uzyskiwanie wymagań
z
Wywiad, ankieta
z
Warsztaty wymagań
z
Burza mózgów
z
Przypadki użycia
z
Odgrywanie ról
z
Prototypy
29
Proces analizy wymagań
Requirements
validation
Domain
understanding
Prioritization
Requirements
collection
Conflict
resolution
Classification
Requirements
definition and
specification
Process
entry
30
Rodzaje wymagań
z
Wymagania funkcjonalne są to usługi
oczekiwane przez użytkownika (bez
uwag implementacyjnych).
z
Wymagania niefunkcjonalne są to
ograniczenia w jakich system ma
pracować, standardy jakie spełnia np.
9
czas odpowiedzi,
9
zajętość pamięci,
9
niezawodność.
6
31
Wymagania funkcjonalne
Wymagania funkcjonalne powinny być:
z
pełne, czyli zawierać wszystkie
wymagania użytkownika,
z
spójne, nie sprzeczne.
Istnieje wiele metod opisu wymagań np. w
postaci formularzy, diagramów
przypadków użycia, metod formalnych.
32
Przykłady
z
Wymaganie produktu
Komunikacja pomiędzy systemem a
użytkownikiem powinna być wyrażona w
Unicode.
z
Wymaganie organizacyjne
Proces rozwoju systemu i dostarczane
dokumenty muszą być zgodne z normą (ISO
9000, CMMI).
z
Wymaganie zewnętrzne
System nie powinien ujawniać operatorom
żadnych danych osobowych klientów oprócz
nazwisk i numerów identyfikacyjnych.
33
Wymagania niefunkcjonalne
z
Szybkość – czas odpowiedzi użytkownika,
z
liczba przetworzonych transakcji w
sekundzie
z
Rozmiar – kilobajty
z
Łatwości użycia - czas szkolenia,
- liczba ekranów pomocy,
z
Niezawodność – dostępność systemu,
- średni czas pomiędzy błędami,
- częstotliwość pojawiania się błędów,
- prawdopodobieństwo błędu żądanej usługi,
34
Wymagania niefunkcjonalne-2
z
Solidność (robustness) – czas
uruchomienia po awarii,
- procent zdarzeń powodujących awarie,
- prawdopodobieństwo zniszczenia
danych po awarii
z
Przenośność – liczba systemów na
których działa programowanie,
-procent zależnych od systemu instrukcji.
35
Specyfikacje wymagań
z
Strukturalny język naturalny
(formularze, szablony)
z
Pseudokod
(if, else, while, …, operatory logiczne, wcięcia,
tekst)
z
Języki opisu projektu, opisu wymagań
(PDL, PSL/PSA)
z
Notacje graficzne ze strukturalnymi opisami
(SADT, przypadki użycia – use case)
36
Specyfikacje techniczne
z
Maszyny skończenie stanowe (FSM)
(automaty, diagramy stanów)
z
Tabele decyzyjne, Drzewa decyzyjne
z
Diagramy czynności (schematy blokowe)
z
Modele związków encji
z
Modele przepływu danych (DFD)
z
Modele obiektowe dziedziny problemu
z
Modele sieciowe (sieci Petri)
z
Specyfikacje formalne
7
37
Wymaganie użytkownika
3.5.1 Dodawanie węzłów do projektu
3.5.1.1 Edytor będzie udostępniał użytkownikom
udogodnienia do dodawania do swoich
projektów węzłów określonego typu
3.5.1.2 Sekwencja czynności:
1. Użytkownik powinien wybrać typ węzła, jaki
należy dodać
2. Użytkownik powinien przesunąć wskaźnik w
okolice miejsca nowe węzła i zlecić jego dodanie
3. Użytkownik powinien przeciągnąć węzeł do
jego ostatecznego położenia
38
Formularz specyfikacji wymagania
- Funkcja
- Opis
- Dane wejściowe
- Źródło danych wejściowych
- Dane wyjściowe, wynik
- Przeznaczenie
- Ograniczenia
- Warunek wstępny
- Warunek końcowy
- Efekty uboczne
- Uzasadnienie
39
Przykład specyfikacji wymagania
Funkcja Dodaj węzeł
Opis Dodaje węzeł do istniejącego projektu. Użytkownik
wybiera typ i położenie węzła (przesuwa wskaźnik na
właściwy obszar). Po dodaniu węzeł jest zaznaczony.
Dane wejściowe Typ, położenie węzła, Identyfikator
projektu
Źródło danych wejściowych Użytkownik, Baza danych
Dane wyjściowe, wynik Identyfikator projektu
Przeznaczenie Baza danych projektów
Wymagania Identyfikator określa korzeń grafu projektu
Warunek wstępny Projekt jest otwarty i wyświetlony
Warunek końcowy Pozostałe elementy projektu nie ulegają
zmianie
Efekty uboczne Brak
40
Klasy stałości wymagań
z
Wymagania stałe – stabilne wymagania
wynikające z podstawowej działalności firmy.
Można je wywnioskować z modeli dziedziny
zastosowania.
Np. szpitalu zawsze są wymagania dotyczące pacjentów,
lekarzy, pielęgniarek itp.
z
Wymagania niestałe – prawdopodobnie
ulegną zmianie w trakcie tworzenia systemu lub
po przekazaniu go użytkownikowi.
Np. zasady finansowania szpitala wg aktualnej ustawy o
ochronie zdrowia
41
Poziomy identyfikacji wymagań
1) Potrzeby udziałowców
Cele systemu (goals)
- często niejasne i niejednoznaczne
2) Cechy systemu – usługi, których
dostarcza system w celu spełnienia
jednej lub więcej potrzeb udziałowca
3) Wymagania stawiane
oprogramowaniu
42
Atrybuty cech produktu (1)
z
status
śledzi postęp np. zaproponowano, zatwierdzono,
wprowadzono
z
priorytet/korzyść
stosuje się w zarządzaniu zakresem
np. konieczne, ważne, użyteczne
z
wysiłek
oszacowanie liczby osób, tygodni, linii kodu np.
poziom wysiłku niski, średni, wysoki
z
ryzyko
wielkość prawdopodobieństwa, że cecha
spowoduje niepożądane zdarzenie np. poziom
ryzyka niski, średni, wysoki
8
43
Atrybuty cech produktu (2)
z
stabilność
wielkość prawdopodobieństwa, że cecha zmieni się
z
wersja docelowa
w której cecha pojawi się po raz pierwszy
z
przydzielenie do
cechy musza być przydzielone do przyszłych
zespołów odpowiedzialnych za definiowanie, ew.
realizację
z
powód
do śledzenia źródła pożądanej cechy, np. odwołanie
do strony i wiersza specyfikacji
44
Macierz atrybutów
Identyfikator
Pełny tekst
Krótki tekst
Atrybut
Atrybut
45
Miary jakości
Miary jakości do oceny specyfikacji
wymagań stawianych oprogramowaniu
(IEEE 830)
z
poprawny
z
jednoznaczny
z
kompletny
z
spójny
z
uporządkowany wg ważności i stabilności
z
sprawdzalny
z
modyfikowalny
z
możliwy do śledzenia oraz możliwy do
zrozumienia
46
Zatwierdzanie wymagań
z
Przeglądy wymagań
z
Systematyczna analiza przez zespół
recenzentów
z
Prototypowanie
z
Wykonywalny model systemu (poziomy prot.)
z
Generowanie przypadków testowych
z
Zaprojektowanie testów akceptacyjnych dla
wymagań funkcjonalnych i niefunkcjonalnych
z
Automatyczna weryfikacja niesprzeczności
z
Wykrywanie niezgodności w bazie wymagań
zgodnie z regułami (CASE, modele formalne)
47
Zarządzanie zmianami wymagań
z
Planowanie zmian
(atrybut stabilności, rozróżnianie starych, znanych,
nowych, modyfikowanych wymagań)
z
Tolerancja linii bazowej na zmiany
z
Kanał kontroli zmian
(gromadzenie żądań zmian, ocena legalności, wpływu
na system, podejmowanie decyzji, rozpowszechnianie
informacji o zmianach)
z
Dokumentacja historii zmian
z
Zarządzanie konfiguracją wymagań
(wersjonowanie)
48
Śledzenie zależności (Traceability)
Określanie i pielęgnowanie relacji zależności pomiędzy
różnymi artefaktami tworzonymi w cyklu rozwoju
oprogramowania.
z
Pochodzenie
z
Wskazanie na udziałowców, którzy proponowali to
wymaganie
z
Uzależnienie wymagań
z
Powiązania pomiędzy wzajemnie zależnymi
wymaganiami
z
Związki z projektem
z
Powiązania z modułami projektu implementującymi
wymagania, przypadkami testującymi,…
9
49
Macierz zależności
(traceability matrix)
Req.
id
1.1
1.2
1.3
2.1
2.2
2.3
3.1
3.2
1.1
D
R
1.2
D
D
D
1.3
R
R
2.1
R
D
D
2.2
D
2.3
R
D
3.1
R
3.2
R
50
51
Narzędzia wspomagające CASE
z
Przechowywanie wymagań
z
Gromadzenie w sposób bezpieczny i
zorganizowany wymagań i ich atrybutów
z
Zarządzanie zmianami
z
Dokumentowanie procesu zmian
z
Zachowanie spójności zbioru wymagań
z
Zarządzanie konfiguracjami wymagań
z
Wspomaganie śledzenia zależności
z
Automatyczne identyfikowanie zależności
z
Przechowywanie, aktualizacja zależności.
Wyszukiwarka
Podobne podstrony:
więcej podobnych podstron