3 folie na stronę
Transkrypt
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