3 folie na stronę

Inżynieria wymagań
Organizacja i Zarządzanie
Projektem Informatycznym
Jarosław Francik
marzec - kwiecień 2002
Institute of Informatics, Silesian University of Technology, Gliwice, Poland
Plan wykładu
•
•
•
•
•
•
Wstęp: Specyfikacja Wymagań Systemowych
Zakres systemu i zakres wymagań
Odpowiedzialność
Pozyskiwanie wymagań
Konsolidacja wymagań
Specyfikacja wymagań
• Literatura: Inżynieria oprogramowania w projekcie
informatycznym – pod red. J. Górskiego
Institute of Informatics, Silesian University of Technology, Gliwice, Poland
Wstęp
to, co klient zamówił
po uruchomieniu
i wdrożeniu...
to, co opisywał projekt
to, co wykonali
programiści
to, za co klient zapłacił
to, czego klient
potrzebował
Institute of Informatics, Silesian University of Technology, Gliwice, Poland
1
Wstęp
Schemat procesu pozyskiwania wymagań
identyfikacja źródeł wymagań
pozyskiwanie
pozyskiwanie
pozyskiwanie
konsolidacja
analiza zbiorcza
Institute of Informatics, Silesian University of Technology, Gliwice, Poland
Wstęp
• Specyfikacja wymagań: uzasadnienie potrzeby
– koszt błędnej specyfikacji (zasada 1:10)
– klienci i użytkownicy na ogół nie wiedzą, czego chcą!
• Zagrożenia dla procesu zbierania wymagań
–
–
–
–
koszty
brak umiejętności, pośpiech
często zmieniające się informacje od klientów
niewłaściwa polityka kierownictwa
Institute of Informatics, Silesian University of Technology, Gliwice, Poland
Wstęp
• Klucze do sukcesu:
– kontakt z udziałowcami
– ciągła analiza systemu w czasie trwania projektu
– dobra procedura kontroli zmian
• Specyfikacja Wymagań Systemowych - SWS
System Requirements Specification - SRS
Institute of Informatics, Silesian University of Technology, Gliwice, Poland
2
Zakres systemu
i zakres wymagań
Institute of Informatics, Silesian University of Technology, Gliwice, Poland
Zakres systemu
i zakres wymagań
• Planowanie strategiczne
–
–
–
–
–
identyfikacja wymaganych cech systemu
określenie celów biznesowych
ustalenie priorytetów poszczególnych cech i celów
określenie harmonogramu i budżetu
zdefiniowanie zakresu systemu
• Wymagania udziałowców systemu
• Potrzeba „odcięcia” osób nie będących
udziałowcami
Institute of Informatics, Silesian University of Technology, Gliwice, Poland
Zakres systemu
i zakres wymagań
• System ma służyć potrzebom organizacji,
a nie tylko wymaganiom końcowych
użytkowników (priorytety!)
• Wykluczenie niektórych podmiotów nie
będących faktycznymi udziałowcami projektu
Institute of Informatics, Silesian University of Technology, Gliwice, Poland
3
Odpowiedzialność
Klient
Wykonawca
strategia biznesowa, potrzeby,
problemy, możliwości,
ograniczenia
technologia, personel,
doświadczenia, zarządzanie,
ograniczenia
wymagania
pozyskiwanie wymagań
analiza i specyfikacja
proces rozwoju
realizowalność
ryzyko
Institute of Informatics, Silesian University of Technology, Gliwice, Poland
Odpowiedzialność
• Klient?
• Niezależny konsultant?
• Dostawca?
WSPÓŁDZIAŁANIE
Institute of Informatics, Silesian University of Technology, Gliwice, Poland
Pozyskiwanie wymagań
Zidentyfikuj wszystkich udziałowców systemu
Przeanalizuj ich punkty widzenia
Wydobądź wymagania
Institute of Informatics, Silesian University of Technology, Gliwice, Poland
4
Pozyskiwanie wymagań
• Przykładowi udziałowcy:
–
–
–
–
–
–
użytkownicy końcowi (wymagania funkcjonalne)
wyższe kierownictwo (cele biznesowe)
kierownik pielęgnacji
kierownik marketingu
kierownik finansowy
osoby odpowiedzialne za bezpieczeństwo
Institute of Informatics, Silesian University of Technology, Gliwice, Poland
Pozyskiwanie wymagań
• Punkty widzenia
–
–
–
–
–
osoba a udziałowiec
punkty widzenia udziałowców są różne
punkty widzenia mogą być sprzeczne
wszystkie punkty widzenia są znaczące
wszystkie punkty widzenia należy wziąć pod uwagę
Uzgodnienie celów systemu
Institute of Informatics, Silesian University of Technology, Gliwice, Poland
Pozyskiwanie wymagań
• Problemy (podsumowanie):
– sprzeczne punkty widzenia – sprzeczne wymagania
(np. projektant kontra specjalista ds. pielęgnacji)
– pominięte punkty widzenia
(np. kierownik kontra sekretarka)
Institute of Informatics, Silesian University of Technology, Gliwice, Poland
5
Pozyskiwanie wymagań
• Brak rozgraniczenia potrzeb od wymagań
– potrzeby: sformułowane mało konkretnie i ogólnikowo
– wymagania: nie rozpoznane, nie wyartykułowane
– nic nie wnoszące wymagania:
komputeryzacja, informatyzacja, rachunkowość
zarządcza, prognoza wyniku, opłacalność inwestycji
• Błędne sformułowanie wymagań
– wymaganie ma specyfikować co system ma robić,
a nie czym system ma być
– klient ma formułować wymagania
a nie projektować system!
– Klient nie wie, w jaki sposób osiągnąć założone
cele!
Institute of Informatics, Silesian University of Technology, Gliwice, Poland
Pozyskiwanie wymagań
• Wymagania nieuświadomione
• Wymagania uznane za oczywiste
• Wymagania uznane za niemożliwe
– Nie sądziłem, że to ma znaczenie
– Nie sądziłem, że się to da zrobić
Institute of Informatics, Silesian University of Technology, Gliwice, Poland
Pozyskiwanie wymagań
• Problemy (podsumowanie):
– sprzeczne punkty widzenia – sprzeczne wymagania
(np. projektant kontra specjalista ds. pielęgnacji)
– pominięte punkty widzenia
(np. kierownik kontra sekretarka)
– niewłaściwie wyspecyfikowane wymagania
– niewyspecyfikowane wymagania
Institute of Informatics, Silesian University of Technology, Gliwice, Poland
6
Pozyskiwanie wymagań
• Wskazówki techniczne:
– nie ustawać w zadawaniu pytań
(jak porucznik Columbo)
– pytania nie tylko „Co”, ale też:
• dlaczego
• załóżmy, że...
• a co, jeżeli...
–
–
–
–
wywiady
studiowanie istniejących systemów
studiowanie podręczników użytkowania
analiza środowiska docelowego
Institute of Informatics, Silesian University of Technology, Gliwice, Poland
Pozyskiwanie wymagań
Wydobywanie wymagań to najtrudniejsze zadanie
całego cyklu życia projektu
Polega na przepływie informacji od ludzi lub
dokumentów – do analityków systemu
W znacznym zakresie jest to zagadnienie
pozatechniczne, psychologiczne,
wymagające harmonii i dobrych stosunków
międzyludzkich
Institute of Informatics, Silesian University of Technology, Gliwice, Poland
Pozyskiwanie wymagań
Pozyskiwanie wymagań wymaga
całościowej analizy systemu
Klienci i użytkownicy powinni sami oceniać swoje
wymagania i rozumieć ich konsekwencje
Pozyskiwanie wymagań to proces iteracyjny
Institute of Informatics, Silesian University of Technology, Gliwice, Poland
7
Konsolidacja wymagań
Grupowanie wymagań:
• Wymagania funkcjonalne
określają to, co system ma robić:
rezultaty oczekiwane przez użytkownika
(tryby pracy, funkcje, postać interfejsu)
• Wymagania niefunkcjonalne
formułowane w odniesieniu do całości systemu:
• dostępność, niezawodność, odtwarzalność, pielęgnowalność
• rozszerzalność, kompatybilność, przenośność
• Inne: cele biznesowe, ograniczenia techniczne,
polityczne itp.
Institute of Informatics, Silesian University of Technology, Gliwice, Poland
Konsolidacja wymagań
Grupowanie wymagań - Model FURBS+
• Funkcjonalność (Functionality)
• Użyteczność (Usability)
• Niezawodność (Reliability)
• Wydajność (Performance)
• Wspieralność (Supportability)
Institute of Informatics, Silesian University of Technology, Gliwice, Poland
Konsolidacja wymagań
Grupowanie wymagań - Model FURBS+
• Funkcjonalność (Functionality)
– funkcje i możliwości
– bezpieczeństwo
•
•
•
•
Użyteczność (Usability)
Niezawodność (Reliability)
Wydajność (Performance)
Wspieralność (Supportability)
Institute of Informatics, Silesian University of Technology, Gliwice, Poland
8
Konsolidacja wymagań
Grupowanie wymagań - Model FURBS+
• Funkcjonalność (Functionality)
• Użyteczność (Usability)
–
–
–
–
–
czynniki ludzkie (interfejs użytkownika)
estetyka
system pomocy
dokumentacja
materiały szkoleniowe
• Niezawodność (Reliability)
• Wydajność (Performance)
•Institute
Wspieralność
(Supportability)
of Informatics, Silesian University of Technology, Gliwice, Poland
Konsolidacja wymagań
Grupowanie wymagań - Model FURBS+
• Funkcjonalność (Functionality)
• Użyteczność (Usability)
• Niezawodność (Reliability)
– liczba / częstotliwość występowania błędów
– odtwarzalność (po wystąpieniu błędu)
– dokładność
– dostępność
– MTBF – średni czas pomiędzy awariami
• Wydajność (Performance)
• Wspieralność (Supportability)
Institute of Informatics, Silesian University of Technology, Gliwice, Poland
Konsolidacja wymagań
Grupowanie wymagań - Model FURBS+
• Funkcjonalność (Functionality)
• Użyteczność (Usability)
• Niezawodność (Reliability)
• Wydajność (Performance)
–
–
–
–
szybkość
efektywność
czas odpowiedzi
użycie zasobów
• Wspieralność (Supportability)
Institute of Informatics, Silesian University of Technology, Gliwice, Poland
9
Konsolidacja wymagań
Grupowanie wymagań - Model FURBS+
• Funkcjonalność (Functionality)
• Użyteczność (Usability)
• Niezawodność (Reliability)
• Wydajność (Performance)
• Wspieralność (Supportability)
– testowalność, rozszerzalność, adaptowalność,
przenośność, kompatybilność, konfigurowalność,
pielęgnowalność, instalowalność,
możliwość lokazlizacji
Institute of Informatics, Silesian University of Technology, Gliwice, Poland
Konsolidacja wymagań
Grupowanie wymagań - Model FURBS+
• FURBS
• +
– Wymagania projektowe
założenia dotyczące projektowania
– Wymagania implementacyjne
standardy, języki, środowisko, ograniczenia
– Wymagania interfejsu
ograniczenia i założenia interfejsu (np. font nie mniejszy niż...)
– Wymagania fizyczne
kolor, rozmiar itp.
Institute of Informatics, Silesian University of Technology, Gliwice, Poland
Konsolidacja wymagań
• Konsolidacja:
–
–
–
–
–
łączenie wymagań o nakładającej się treści
odnoszenie wymagań do zakresu projektu
usuwanie niespójności (sprzeczności)
usuwanie wymagań wyspecyfikowanych więcej niż raz
identyfikacja wymagań brakujących (luk)
Institute of Informatics, Silesian University of Technology, Gliwice, Poland
10
Specyfikacja wymagań
• Definicja wymagania
• Specyfikacja wymagania
Specyfikacja Wymagań Systemowych - SWS
System Requirements Specification – SRS
wg Rational Unified Process (RUP)
Institute of Informatics, Silesian University of Technology, Gliwice, Poland
Specyfikacja wymagań
Atrybuty wymagań:
• Jednoznaczność (unamiguity)
• Kompletność (completeness)
• Poprawność (corectness)
• Spójność (consistency)
• Weryfikowalność (verifiability)
• Mierzalność (measurablity)
• Modyfikowalność (modifiability)
• Śladowość (traceability)
Institute of Informatics, Silesian University of Technology, Gliwice, Poland
Podsumowanie
PROBLEMY:
• Brak wsparcia analityków systemowych
• Niedostateczna współpraca z klientem,
brak końcowej walidacji specyfikacji
• Brak kwalifikacji (źle sformułowany dokument)
• Niewłaściwa polityka kierownictwa
• Konieczność wprowadzania i śledzenia zmian
Institute of Informatics, Silesian University of Technology, Gliwice, Poland
11