Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

Organizacja i Zarządzanie Projektem Informatycznym Część 4 OiZPI > zarządzanie procesem formułowania wymagań w materiałach wykorzystano: K.Subieta: Budowa.

Podobne prezentacje


Prezentacja na temat: "Organizacja i Zarządzanie Projektem Informatycznym Część 4 OiZPI > zarządzanie procesem formułowania wymagań w materiałach wykorzystano: K.Subieta: Budowa."— Zapis prezentacji:

1 Organizacja i Zarządzanie Projektem Informatycznym Część 4 OiZPI > 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 SysML, Architektura i Zastosowanie

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

3 Organizacja i Zarządzanie Projektem Informatycznym Wymagania co iprzy jakich założeniach system powinien robić Wymaganie to najogólniej opis tego, co i przy jakich założeniach system powinien robić by klient osiągnął postawiony sobie cel. zamiany celów 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.

4 Organizacja i Zarządzanie Projektem Informatycznym 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.

5 Organizacja i Zarządzanie Projektem Informatycznym 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

6 Organizacja i Zarządzanie Projektem Informatycznym 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.

7 Organizacja i Zarządzanie Projektem Informatycznym 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

8 Organizacja i Zarządzanie Projektem Informatycznym 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 czas Początkowe zrozumienie problemu Początkowe wymagania Zmiana zrozumienia problemu Zmiana wymagań

9 Organizacja i Zarządzanie Projektem Informatycznym 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

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

11 Organizacja i Zarządzanie Projektem Informatycznym Wymagania funkcjonalne 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.

12 Organizacja i Zarządzanie Projektem Informatycznym 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).

13 Organizacja i Zarządzanie Projektem Informatycznym 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.

14 Organizacja i Zarządzanie Projektem Informatycznym 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

15 Organizacja i Zarządzanie Projektem Informatycznym Trudności fazy formułowania wymagań Klient z reguły nie wie 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

16 Organizacja i Zarządzanie Projektem Informatycznym 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.

17 Organizacja i Zarządzanie Projektem Informatycznym Wymagania niefunkcjonalne 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

18 Organizacja i Zarządzanie Projektem Informatycznym 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.

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

20 Organizacja i Zarządzanie Projektem Informatycznym SysML - wymagania Formułowanie wymagań – najbardziej newralgiczny etap pracy nad systemami W języku SysML wyodrębniono dla wymagań osobną kategorie modelowania Notacja – diagram wymagań systemowych Wymaganie – symbol kasy o stereotypie > 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

21 Organizacja i Zarządzanie Projektem Informatycznym SysML - wymagania

22 Organizacja i Zarządzanie Projektem Informatycznym SysML – wymagania i relacje W SysML przewidziano siedem kategorii zależności: Zagnieżdżenie Zależność wyprowadzania ( >) Zależność realizacji ( >) Zależność powielenia ( >) Zależność weryfikowania ( >) Zależność precyzowania ( >) Zależność śledzenia ( >)

23 Organizacja i Zarządzanie Projektem Informatycznym SysML: 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

24 Organizacja i Zarządzanie Projektem Informatycznym SysML: 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

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

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

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

28 Organizacja i Zarządzanie Projektem Informatycznym SysML: 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

29 Organizacja i Zarządzanie Projektem Informatycznym SysML: 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


Pobierz ppt "Organizacja i Zarządzanie Projektem Informatycznym Część 4 OiZPI > zarządzanie procesem formułowania wymagań w materiałach wykorzystano: K.Subieta: Budowa."

Podobne prezentacje


Reklamy Google