Cz 4 Oi ZPI zarzdzanie procesem formuowania wymaga

  • Slides: 29
Download presentation
Część 4 Oi. ZPI >zarządzanie procesem formułowania wymagań w materiałach wykorzystano: K. Subieta: Budowa

Część 4 Oi. ZPI >zarządzanie procesem formułowania wymagań w materiałach wykorzystano: K. Subieta: Budowa i integracja systemów informatycznych A. Kobieliński: Inżynieria Oprogramowania I. Sommerville: Software Engineering IBM Rational: RUP™ S. Wyrcza, B. Marcinkowski: Język Inżynierii Systemów Sys. ML, Architektura i Zastosowanie Organizacja i Zarządzanie Projektem Informatycznym

Zarządzanie procesem formułowania wymagań § Pojęcie inżynierii wymagań § Poziomy szczegółowości wymagań § Dokumentacja

Zarządzanie procesem formułowania wymagań § Pojęcie inżynierii wymagań § Poziomy szczegółowości wymagań § Dokumentacja fazy określania wymagań Organizacja i Zarządzanie Projektem Informatycznym

Wymagania § Wymaganie to najogólniej opis tego, co i przy jakich założeniach system powinien

Wymagania § Wymaganie to najogólniej opis tego, co i przy jakich założeniach system powinien robić by klient osiągnął postawiony sobie cel. § Formułowanie wymagań to proces zamiany celów klienta (określonych w fazie strategicznej) na konkretne wymagania zapewniające osiągnięcie tych celów. § W fazie określania wymagań klient - samodzielnie albo wspólnie z grupą doradców i/lub przedstawicielami producenta - tworzy zbiór wymagań zgodny z jego celami § Uwaga: pojęcie wymagania może odnosić się także do zasad prowadzenia i zarządzania projektem. Organizacja i Zarządzanie Projektem Informatycznym

Metody rozpoznania wymagań §Wywiady i przeglądy. Wywiady powinny być przygotowane (w postaci listy pytań)

Metody rozpoznania wymagań §Wywiady i przeglądy. Wywiady powinny być przygotowane (w postaci listy pytań) i podzielone na odrębne zagadnienia. Podział powinien przykrywać całość tematu i powinny być przeprowadzone na reprezentatywnej grupie użytkowników. Wywiady powinny doprowadzić do szerokiej zgody i akceptacji projektu. §Studia na istniejącym oprogramowaniu. Dość często nowe oprogramowanie zastępuje stare. Studia powinny ustalić wszystkie dobre i złe strony starego oprogramowania. §Studia wymagań systemowych. Dotyczy sytuacji, kiedy nowy system ma być częścią większego systemu. §Studia osiągalności. Określenie realistycznych celów systemu i metod ich osiągnięcia. §Prototypowanie. Zbudowanie prototypu systemu działającego w zmniejszonej skali, z uproszczonymi interfejsami. Organizacja i Zarządzanie Projektem Informatycznym

Metody rozpoznania wymagań §Warsztaty wymagań. Jest to spotkanie z inwestorami i użytkownikami (jeśli takich

Metody rozpoznania wymagań §Warsztaty wymagań. Jest to spotkanie z inwestorami i użytkownikami (jeśli takich można wskazać) mające na celu uświadomienie sobie tego, co powinien robić przyszły system. Osoba prowadząca – analityk systemowy Uczestnicy – inwestorzy, użytkownicy i inne osoby, które mogą znać problemy rozpatrywanej jednostki organizacyjnej Organizacja i Zarządzanie Projektem Informatycznym

Warsztaty wymagań § Przebieg warsztatów Każda z osób przemawia i artykułuje – na ile

Warsztaty wymagań § Przebieg warsztatów Każda z osób przemawia i artykułuje – na ile jest to możliwe, czytelnie swoje problemy Każdy problem zapisuje się – jakikolwiek by ten problem nie był Wszyscy uczestnicy starają się znaleźć – na zasadzie "burzy mózgów" rozwiązanie tego problemu, Rozwiązania zapisuje się obok problemów Przykład: problem: nie mogę się nigdy doliczyć palet na magazynie rozwiązanie: wprowadzić na faktury zakupowe i sprzedażowe pole określające liczbę przyjętych i wydanych palet. Organizacja i Zarządzanie Projektem Informatycznym

Warsztaty wymagań § Inne podejście Analityk najpierw rozpoznaje problemy na niezależnych wcześniejszych spotkaniach Systematyzuje

Warsztaty wymagań § Inne podejście Analityk najpierw rozpoznaje problemy na niezależnych wcześniejszych spotkaniach Systematyzuje problemy tworząc listę pytań, Do każdego pytania można przygotować dodatkową ilustrację (np. . w postaci slajdu z diagramem, rysunkiem, tabelą, itp. Podczas warsztatów analityk objaśnia problem, przedstawia ilustrację Znajduje się rozwiązanie i udziela odpowiedzi na pytania na odpowiednim formularzu (query sheet) przykład: XXX przykład: YYY Organizacja i Zarządzanie Projektem Informatycznym

Problem ewolucji wymagań § Ewolucja wymagań to najpoważniejszy problem projektowania systemów informatycznych. Szacuje się,

Problem ewolucji wymagań § Ewolucja wymagań to najpoważniejszy problem projektowania systemów informatycznych. Szacuje się, że większość niepowodzeń projektów ma swe źródło w zmieniających się wymaganiach. § Niestety zmiany wymagań raczej nie uda się uniknąć - trzeba raczej spróbować się na nią przygotować - wiedzieć co trzeba poprawić, gdy zmienią się wymagania Początkowe zrozumienie problemu Zmiana zrozumienia problemu czas Początkowe wymagania Zmiana wymagań Organizacja i Zarządzanie Projektem Informatycznym

Problem ewolucji wymagań § Należy uznać, że ewolucja wymagań jest naturalną właściwością procesu analizy,

Problem ewolucji wymagań § Należy uznać, że ewolucja wymagań jest naturalną właściwością procesu analizy, w którym wiedza o rozpatrywanym problemie systematycznie wzrasta § Im dłużej zajmujemy się jakimś zagadnieniem, tym większa jest nasza wiedza, tym większa jest świadomość użytkowników § Należy przewidzieć mechanizmy pozwalające kontrolować proces ewolucji wymagań, § Nie należy takiego problemu wykluczać § Kategoryzacja skali zmian – pomocny mechanizm § Poszczególne kategorie odpowiadają zmianom o różnej skali Organizacja i Zarządzanie Projektem Informatycznym

Rodzaje wymagań Wymagania funkcjonalne Wymaganie niefunkcjonalne Organizacja i Zarządzanie Projektem Informatycznym

Rodzaje wymagań Wymagania funkcjonalne Wymaganie niefunkcjonalne Organizacja i Zarządzanie Projektem Informatycznym

Wymagania funkcjonalne opisują operacje wykonywane przez system. Inne aspekty wymagań funkcjonalnych § Określenie wszystkich

Wymagania funkcjonalne opisują operacje wykonywane przez system. Inne aspekty wymagań funkcjonalnych § Określenie wszystkich rodzajów użytkowników, którzy będą korzystać z systemu. § Określenie wszystkich rodzajów użytkowników, którzy są niezbędni do działania systemu (obsługa, wprowadzanie danych, administracja). § Dla każdego rodzaju użytkownika określenie funkcji systemu oraz sposobów korzystania z planowanego systemu. § Określenie systemów zewnętrznych (obcych baz danych, sieci, Internetu), które będą wykorzystywane podczas działania systemu. § Ustalenie struktur organizacyjnych, przepisów prawnych, statutów, zarządzeń, instrukcji, itd. , które pośrednio lub bezpośrednio określają funkcje wykonywane przez planowany system. Organizacja i Zarządzanie Projektem Informatycznym

Metody specyfikacji wymagań funkcjonalnych § Język naturalny najczęściej stosowany. Wady: niejednoznaczność powodująca różne rozumienie

Metody specyfikacji wymagań funkcjonalnych § Język naturalny najczęściej stosowany. Wady: niejednoznaczność powodująca różne rozumienie tego samego tekstu; elastyczność, powodująca wyrazić te same treści na wiele sposobów. Utrudnia to wykrycie powiązanych wymagań i powoduje trudności w wykryciu sprzeczności. § Język naturalny strukturalny Język naturalny z ograniczonym słownictwem i składnią. Tematy i zagadnienia wyspecyfikowane w punktach i podpunktach. § Tablice, formularze Wyspecyfikowanie wymagań w postaci (zwykle dwuwymiarowych) tablic, kojarzących różne aspekty (np. tablica ustalająca zależność pomiędzy typem użytkownika i rodzajem usługi). Organizacja i Zarządzanie Projektem Informatycznym

Metody specyfikacji wymagań funkcjonalnych § Diagramy blokowe forma graficzna pokazująca cykl przetwarzania. § Diagramy

Metody specyfikacji wymagań funkcjonalnych § Diagramy blokowe forma graficzna pokazująca cykl przetwarzania. § Diagramy kontekstowe ukazują system w postaci jednego bloku oraz jego powiązania z otoczeniem, wejściem i wyjściem. § Diagramy przypadków użycia poglądowy sposób przedstawienia aktorów i funkcji systemu. Organizacja i Zarządzanie Projektem Informatycznym

Trudności fazy formułowania wymagań § Klient nie potrafi rozgraniczyć celów od wymagań; te pierwsze

Trudności fazy formułowania wymagań § Klient nie potrafi rozgraniczyć celów od wymagań; te pierwsze często formułuje mało konkretnie i ogólnikowo; tych drugich nie potrafi wyartykułować (trzeba pomóc mu je rozpoznać) § Klient z reguły spodziewa się poprawy stanu aktualnego organizacji, często nie przewidując jakie zmiany w organizacji przedsiębiorstwa spowoduje ulepszony system; najchętniej też nie ponosiłby za nie odpowiedzialności Organizacja i Zarządzanie Projektem Informatycznym

Trudności fazy formułowania wymagań § Klient z reguły nie w jaki sposób osiągnąć założone

Trudności fazy formułowania wymagań § Klient z reguły nie w jaki sposób osiągnąć założone cele; z drugiej strony cele klienta można osiągnąć na wiele sposobów § Duże systemy wykorzystywane są przez wielu użytkowników; ich cele często są sprzeczne; różni użytkownicy mogą posługiwać się inną terminologią mówiąc o tych samych problemach § Inwestorzy i użytkownicy do często inne osoby; głos inwestora, choć decydujący, nie zawsze właściwie potrafi przewidzieć potrzeby rzeczywistych użytkowników Organizacja i Zarządzanie Projektem Informatycznym

Zalecenia § Wymagania użytkowników powinny być wyjaśniane poprzez krytykę i porównanie z istniejącym oprogramowaniem

Zalecenia § Wymagania użytkowników powinny być wyjaśniane poprzez krytykę i porównanie z istniejącym oprogramowaniem i prototypami. § Należy uzyskać stan porozumienia pomiędzy projektantami i użytkownikami dotyczący projektowanego systemu. § Wiedza i doświadczenia potencjalnej organizacji podejmującej się rozwoju systemu powinny wspomóc studia nad osiągalnością systemu. § W wielu przypadkach dużym wspomaganiem jest budowa prototypów. § Wymagania użytkowników powinny być: jasne, jednoznaczne, weryfikowalne, kompletne, dokładne, realistyczne, osiągalne. Organizacja i Zarządzanie Projektem Informatycznym

Wymagania niefunkcjonalne określają jakim ograniczeniom podlegać ma system wypełniając wymagania funkcjonalne. Najczęściej związane są

Wymagania niefunkcjonalne określają jakim ograniczeniom podlegać ma system wypełniając wymagania funkcjonalne. Najczęściej związane są z § wydajnością systemu, § właściwościami interfejsu użytkownika, § dopasowaniem do określonego środowiska – system operacyjny, system zarządzania bazą danych Organizacja i Zarządzanie Projektem Informatycznym

Weryfikowalność wymagań niefunkcjonalnych § Wymagania niefunkcjonalne powinny być weryfikowalne, czyli powinna istnieć możliwość sprawdzenia

Weryfikowalność wymagań niefunkcjonalnych § Wymagania niefunkcjonalne powinny być weryfikowalne, czyli powinna istnieć możliwość sprawdzenia lub zmierzenia czy system je rzeczywiście spełnia, np. wymagania “system ma być łatwy w obsłudze”, „system ma być niezawodny”, „system ma być dostatecznie szybki”, itd. nie są weryfikowalne. § Aby uniknąć nieporozumień na etapie odbioru systemu (testach akceptacyjnych) najlepiej posługi się metryką, która obiektywizuje spełnienie bądź nie wymagań niefunkcjonalnych. Organizacja i Zarządzanie Projektem Informatycznym

Przykłady metryk wymagań niefunkcjonalnych Cecha Metryka Szybkość Liczba transakcji przetwarzanych na sekundę, czas reakcji

Przykłady metryk wymagań niefunkcjonalnych Cecha Metryka Szybkość Liczba transakcji przetwarzanych na sekundę, czas reakcji na sygnał użytkownika / sygnał zewnętrzny Rozmiar KB/MB/GB Łatwość użycia Czas treningu użytkownika, liczba stron systemu pomocy, liczba stron dokumentacji Niezawodność Średni czas międzyawaryjny, prawdopodobieństwo niedostępności, częstotliwość występowania awarii Odporność na błędy Czas restartu po awarii, statystyczny procent zdarzeń powodujących awarie Przenośność Procent instrukcji zależnych od systemu operacyjnego, liczba systemów docelowych Organizacja i Zarządzanie Projektem Informatycznym

Sys. ML - wymagania § Formułowanie wymagań – najbardziej newralgiczny etap pracy nad systemami

Sys. ML - wymagania § Formułowanie wymagań – najbardziej newralgiczny etap pracy nad systemami § W języku Sys. ML wyodrębniono dla wymagań osobną kategorie modelowania § Notacja – diagram wymagań systemowych § Wymaganie – symbol kasy o stereotypie <<requirement>> § Wymaganie jest identyfikowane przez: § Numer – numeracja o strukturze hierarchiczne, notacja Deweya (numerowanie wierzchołków drzewa) § Treść wymagania – spójny, syntetyczny opis właściwości, która powinien posiadać system (nazwa) § Wymaganie można uzupełnić opisem, korzystając z metki „tekst” lub z pola notatek Organizacja i Zarządzanie Projektem Informatycznym

Sys. ML - wymagania Organizacja i Zarządzanie Projektem Informatycznym

Sys. ML - wymagania Organizacja i Zarządzanie Projektem Informatycznym

Sys. ML – wymagania i relacje § W Sys. ML przewidziano siedem kategorii zależności:

Sys. ML – wymagania i relacje § W Sys. ML przewidziano siedem kategorii zależności: § Zagnieżdżenie § Zależność wyprowadzania (<<derive. Reqt>>) § Zależność realizacji (<<satisfy>>) § Zależność powielenia (<<copy>>) § Zależność weryfikowania (<<verify>>) § Zależność precyzowania (<<refine>>) § Zależność śledzenia (<<trace>>) Organizacja i Zarządzanie Projektem Informatycznym

Sys. ML: wymagania i relacje – zagnieżdżenie § Najczęściej spotykana relacja § Znaczenie: łączy

Sys. ML: wymagania i relacje – zagnieżdżenie § Najczęściej spotykana relacja § Znaczenie: łączy wymagania nadrzędne z podrzędnymi pozwalając na tworzenie hierarchicznej struktury powiązań § Na jednym poziomie hierarchii może istnieć tylko jeden element nadrzędny § Przeniesienie pomiędzy elementami nadrzędnymi – zależność kopiowania Organizacja i Zarządzanie Projektem Informatycznym

Sys. ML: wymagania i relacje – zależność wyprowadzania § Znaczenie: wyprowadzanie jednego wymagania z

Sys. ML: wymagania i relacje – zależność wyprowadzania § Znaczenie: wyprowadzanie jednego wymagania z innego § Wyprowadzone wymaganie to wymaganie pochodne § Strzałka wskazuje wymaganie, z którego wyprowadzono wymaganie pochodne Organizacja i Zarządzanie Projektem Informatycznym

Sys. ML: wymagania i relacje – zależność realizacji § Znaczenie: przypisanie wymagania do spełniającego

Sys. ML: wymagania i relacje – zależność realizacji § Znaczenie: przypisanie wymagania do spełniającego go elementu § Strzałka wskazuje spełniane wymaganie Organizacja i Zarządzanie Projektem Informatycznym

Sys. ML: wymagania i relacje – zależność powielania § Znaczenie: wyrażanie tożsamości wymagań §

Sys. ML: wymagania i relacje – zależność powielania § Znaczenie: wyrażanie tożsamości wymagań § Pozwala unikać wielokrotnego definiowania podobnych wymagań § Strzałka wskazuje powielane wymaganie Organizacja i Zarządzanie Projektem Informatycznym

Sys. ML: wymagania i relacje – zależność weryfikowania § Znaczenie: powiązanie testu formalnego z

Sys. ML: wymagania i relacje – zależność weryfikowania § Znaczenie: powiązanie testu formalnego z wymaganiem § Test formalny (ang. testcase) jest odrębna kategoria modelowania Sys. ML (także UML) § Strzałka wskazuje weryfikowane wymaganie Organizacja i Zarządzanie Projektem Informatycznym

Sys. ML: wymagania i relacje – zależność precyzowania § Znaczenie: powiązanie wymagania z elementem

Sys. ML: wymagania i relacje – zależność precyzowania § Znaczenie: powiązanie wymagania z elementem modelu wzbogacającym jego specyfikację § Elementem wzbogacającym może być dowolna kategoria modelowania, ale także specyfikacja tekstowa, projekt interfejsu, itp. § Strzałka wskazuje wzbogacane wymaganie Organizacja i Zarządzanie Projektem Informatycznym

Sys. ML: wymagania i relacje – zależność śledzenia § Znaczenie: pokazanie formalnego związku pomiędzy

Sys. ML: wymagania i relacje – zależność śledzenia § Znaczenie: pokazanie formalnego związku pomiędzy wymaganiem i elementami modelu § Duża swoboda posługiwania się znaczeniem (swoboda interpretacji) § Przykładowe zastosowanie: zależności czasowe Organizacja i Zarządzanie Projektem Informatycznym