Projektowanie systemów informatycznych

Transkrypt

1 Projektowanie systemów informatycznych Zarządzanie projektem Autor Roman Simiński Kontakt

2 Cel wykładu Przedstawienie inżynierii wymagań jako istotnego i trudnego elementu zarządzania projektem informatycznym. Zleceniodawca jako źródło wymagań stawianych systemowi. Zdefiniowanie i przedstawienie różnicy pomiędzy różnymi rodzajami wymagań. Przedstawienie metod zarządzania wymaganiami. Ale o co im właściwie chodzi? Copyright Roman Simiński Strona : 2

3 Wymagania w projektowaniu systemów informatycznych Istnieją różne definicje wymagań dla systemów informatycznych. Dla potrzeb niniejszych zajęć przyjmijmy: Wymagania to opis funkcji (usług), które mają być realizowane przez system i opis ograniczeń dla systemu. Wymagania nie opisują jak system ma działać a co ma wykonywać. Wymagania są definiowane na wczesnych etapach rozwoju systemu jako specyfikacja tego, co ma być implementowane. W zakresie zarządzania projektem można wyróżnić różne typy wymagań stawianych systemowi. Wymagania = opis funkcji + opis ograniczeń Copyright Roman Simiński Strona : 3

4 Zarządzanie wymaganiami inżynieria wymagań Inżynieria wymagań to proces pozyskiwania, analizowania, dokumentowania oraz weryfikowania wymagań dla projektowanego systemu. Celem inżynierii wymagań jest: pozyskanie informacji pozwalających na określenie wymagań, zidentyfikowane wymagań i ich kategorii, analiza wymagań (jednoznaczność, spójność, zgodność z założeniami), opisanie wymagań opracowanie specyfikacji wymagań, weryfikacja wymagań, zarządzanie zmianami wymagań w trakcie realizacji projektu. Copyright Roman Simiński Strona : 4

5 Inżynieria wymagań graficzna ilustracja koncepcji Inżynieria wymagań Opracowywanie wymagań Zarządzanie wymaganiami Pozyskiwanie Analiza Specyfikacja Weryfikacja Copyright Roman Simiński Strona : 5

6 Po co inżynieria wymagań? Tak klient opisał, czego wymaga od systemu Tak wymagania klienta zrozumiał analityk Tak projektanci zrozumieli analityka i taki stworzyli projekt Tak programiści zrozumieli projekt i to zaprogramowali Po poprawkach wdrożono coś takiego Za to klient zapłacił Tego klient chciał Oto, do czego się projekt nadawał i jak użyto jego efektów Rysunki pochodzą ze strony: Copyright Roman Simiński Strona : 6

7 Inżynieria wymagań jako metod likwidowania przepaści Czy to tylko zabawna rysunkowa historyjka? Klient Wykonawca Wielki Kanion Copyright Roman Simiński Strona : 7

8 Inżynieria wymagań jako metod likwidowania przepaści Klient Myślę, że system zapewni nam minimalizację stanów magazynowych, co spowoduje mniejsze zaangażowanie bieżących środków na zakup surowców, przy jednoczesnym utrzymaniu płynności produkcji na dotychczasowym poziomie. Napiszę to obiektowo w Javie, ale bazę wykorzystam relacyjną, dla magazynu zrobię aplet, reszta będzie w JSP. Informatyk Copyright Roman Simiński Strona : 8

9 Na marginesie brak ciągłości specyfikacji to też problem Projektant Programista Kolejny Wielki Kanion... Copyright Roman Simiński Strona : 9

10 Inżynieria wymagań spotkanie dwóch światów Wizja klienta Wizja informatyka Współdziałanie, komunikacja, synergia Copyright Roman Simiński Strona : 10

11 Inżynieria wymagań spotkanie dwóch światów Cele strategiczne, strategie biznesowe, oczekiwania, nadzieje, ograniczenia Własne cele biznesowe, technologia, wiedza, zaplecze, doświadczenie, ograniczenia Pozyskiwanie, analiza i specyfikacja wymagań Wymagania Realizowalność + ryzyko Realizacja projektu Copyright Roman Simiński Strona : 11

12 Inżynieria wymagań kto jest naszym zleceniodawcą? System ma służyć organizacji i wspierać realizację jej celów strategicznych. System wcale nie jest po to, by ludziom pracowało się łatwiej i wygodniej. Kto powinien określać wymagania dla projektowanego systemu? Użytkownik końcowy (operator systemu) często nie rozumie jego działania w sensie globalnym. Copyright Roman Simiński Strona : 12

13 Inżynieria wymagań kto jest naszym zleceniodawcą? Zidentyfikuj przedstawicieli zamawiającego system Rozdziel przedstawicieli na decydentów i operatorów Przeanalizuj ich punkty widzenia Przejdź do wydobywania wymagań Copyright Roman Simiński Strona : 13

14 Rozdzielaj ale nie dyskryminuj każdy jest ważnym źródłem wymagań Wyższe kierownictwo określa cele strategiczne i cele systemu oni wiedzą czego chcą, choć niekoniecznie jak to osiągnąć. Kadra kierownicza średniego szczebla oni zwykle wiedzą jak osiągnąć poszczególne cele cząstkowe. Kadra kierownicza niższego szczebla oni znają procesy biznesowe w ich realnym wymiarze. Szeregowi pracownicy oni wiedzą dokładnie jak wykonać każdą elementarna operację. Copyright Roman Simiński Strona : 14

15 Poziomy i typy wymagań Wyższe kierownictwo określa cele strategiczne i cele systemu oni wiedzą czego chcą, choć niekoniecznie jak to osiągnąć. Kadra kierownicza średniego szczebla oni zwykle wiedzą jak osiągnąć poszczególne cele cząstkowe. Wymagania biznesowe Opisują cel, który chce osiągnąć zleceniodawca dzięki realizacji danego projektu. Pozwalają zespołowi projektowemu poznać wizję i zakres projektowanego systemu oczami decydentów zleceniodawcy. Można stworzyć dokument: Wizja i zakres projektu. Copyright Roman Simiński Strona : 15

16 Poziomy i typy wymagań Kadra kierownicza niższego szczebla oni znają procesy biznesowe w ich realnym wymiarze. Szeregowi pracownicy oni wiedzą dokładnie jak wykonać każdą elementarna operację. Wymagania użytkowe Opisują to, co użytkownicy będą mogli wykonać w systemie. Określają ogólny scenariusz realizacji poszczególnych operacji istotnych dla użytkownika. Scenariusze te mogą być spisane w dokumencie Przypadki użycia. Dokument ten stanowi podstawę do określenia szczegółowych funkcji systemu. Copyright Roman Simiński Strona : 16

17 Wymagania biznesowe i użytkowe Wymagania biznesowe Wizja i zakres projektu Dokument im konkretniejszy tym lepiej, jednak nie stosuje się notacji formalnych Wymagania użytkowe Przypadki użycia Dokument rysunki + opis, zwykle Use Case Diagrams z UML Copyright Roman Simiński Strona : 17

18 Wymagania biznesowe, użytkowe i wymaganie funkcje Wymagania biznesowe Wizja i zakres projektu Wymagania użytkowe Przypadki użycia Wymagane funkcje Wymagane funkcje specyfikują dokładnie to, co system powinien robić czyli to, co zespół programistów powinien zrealizować w formie programu komputerowego. Copyright Roman Simiński Strona : 18

19 Wymagania funkcjonalne Wymagania biznesowe Wizja i zakres projektu Wymagania użytkowe Przypadki użycia Wymagania funkcjonalne to wszystko opisuje co ma oferować system, jak ma reagować na określone dane wejściowe oraz jak ma się zachowywać w określonych sytuacjach. Wymagane funkcje Wymagania funkcjonalne Copyright Roman Simiński Strona : 19

20 Specyfikacja wymagań systemu SRS Wymagania biznesowe Wizja i zakres projektu Wymagania użytkowe Specyfikacja wymagań systemu SRS (ang. software requirements specification) Dokument ten jest oficjalna listą wymagań projektowanego systemu dla klienta, użytkowników końcowych oraz zespołu projektowego. Istnieją normy określające postać, cechy i formę takiego dokumentu. Przypadki użycia Wymagane funkcje Specyfikacja wymagań Wymagania funkcjonalne Copyright Roman Simiński Strona : 20

21 Wymagania niefunkcjonalne Wymagania biznesowe Wizja i zakres projektu Wymagania użytkowe? Przypadki użycia Wymagane funkcje Specyfikacja wymagań Wymagania funkcjonalne Wymagania niefunkcjonalne Copyright Roman Simiński Strona : 21

22 Wymagania niefunkcjonalne ogólnie Wymagania niefunkcjonalne nie mają bezpośredniego wpływu na funkcjonalność systemu. Nakładają one ograniczenie na sposób, w jaki sposób wymagania funkcjonalne będą zrealizowane.? Specyfikacja wymagań Wymagania niefunkcjonalne Copyright Roman Simiński Strona : 22

23 Wymagania niefunkcjonalne różne rodzaje Wymagania biznesowe Cele strategiczne Wizja i zakres projektu Polityka firmy Kultura organizacji Wymagania użytkowe Przypadki użycia Wymagane funkcje Specyfikacja wymagań Cele operacyjne Technologia Specyfika dziedziny Wymagania funkcjonalne Wymagania niefunkcjonalne Copyright Roman Simiński Strona : 23

24 Klasyfikacja wymagań wymagania funkcjonalne Wymagania funkcjonalne: określają jaki pożądane z punktu widzenia zamawiającego funkcje powinien posiadać system, powinny pozwolić na realizację określonych wymagań biznesowych i prowadzić do celu systemu określonego w jego wizji i zakresie, specyfikują co system ma realizować a nie jak ma to być zrobione. Przykład Biblioteka : Uproszczone wymagania funkcjonalne w języku naturalnym System obsługi biblioteki powinien umożliwiać klientowi tej biblioteki przeszukiwanie jej zasobów katalogowych w poszukiwaniu konkretnej książki. Wyszukiwanie może odbywać się wg danych autora, tytułu książki lub wydawnictwa. Wyszukaną książkę klient może zarezerwować do wypożyczenia lub wypożyczyć. Wyszukiwanie może realizować każdy klient, rezerwować i wypożyczać może jedynie klient, który przeszedł proces rejestracji w systemie. Rejestracja obejmuje podanie imienia, nazwiska i adresu zamieszkania. Copyright Roman Simiński Strona : 24

25 Klasyfikacja wymagań wymagania niefunkcjonalne Wymagania niefunkcjonalne: określają pożądane cechy systemu, nie wpływając bezpośrednio na istnienie konkretnych funkcji; wpływają jednak zwykle na to, jak te funkcje będą realizowane. Wymagania niefunkcjonalne mogą wypływać z: ustaw, norm, przepisów, kodeksów; strategii biznesowego działania zleceniodawcy, kultury jego organizacji, specyfiki jego działania rynkowego; ograniczeń dziedziny dla której system jest tworzony; technologii i metod realizacji systemu; wymagań jakościowych i technicznych. Copyright Roman Simiński Strona : 25

26 Klasyfikacja wymagań wymagania niefunkcjonalne Przykład Biblioteka : Wymagania niefunkcjonalne kontekst biznesowy Klienci biblioteki nie płacą za korzystanie z niej. Strategia biblioteki zakłada jednak, że aby skorzystać z jej zasobów, klient musi się zarejestrować ujawniając dane obejmujące imię, nazwisko oraz adres zamieszkania. Podając te informacje w trakcie rejestracji klient musi zgodzić się na przetwarzanie jego danych osobowych a system biblioteczny musi przestrzegać ograniczeń narzucanych przez ustawę o ochronie danych osobowych. Przykład Biblioteka : Wymagania niefunkcjonalne kontekst technologiczny System obsługi biblioteki ma być aplikacją WWW, zrealizowaną w architekturze klient-serwer, przy czym warstwa kliencka jest cienka realizuje ją przeglądarka internetowa. W trakcie rejestracji klienta jego dane mają być przekazywane w połączeniu zapewniającym bezpieczeństwo chronionych informacji osobistych. Copyright Roman Simiński Strona : 26

27 Specyfikacja wymagań SRS Specyfikacją wymagań dla oprogramowaniu lub systemu ang. Software Requirements Specification (SRS) jest oficjalną deklaracją tego, co jest wymagane od wytwórców systemu przez zleceniodawcę. Dokument SRS nie jest dokumentem projektowym, stanowi materiał wejściowy dla analityków i projektantów systemu. Istnieję standardy wykonywania SRS IEEE Recommended Practice for Software Requirements Specyfication, IEEE std Dokument SRS Copyright Roman Simiński Strona : 27

28 Specyfikacja wymagań a uczestnicy projektu Zleceniodawcy Określają wymagania, weryfikują ich zgodność z potrzebami, określają potrzebę zmian. Zarządzający IT Wymagania pozwalają na zaplanowanie projektu, i zarządzanie jego realizacją Testerzy Wymagania pozwalają opracować plan testów systemu Dokument SRS Analitycy Wymagania pozwalają opracować koncepcję i architekturę systemu Programiści Wymagania weryfikują szczegóły implementacji gdy jest taka potrzeba Projektanci Wymagania pozwalają zaprojektować strukturę systemu Copyright Roman Simiński Strona : 28

29 Specyfikacja wymagań kryteria jakości dokumentu SRS Poprawność. Jednoznaczność. Kompletność. Spójność. Informacja o wydajności i stabilności. Weryfikowalność. Modyfikowalność. Możliwość śledzenia powiązań. Copyright Roman Simiński Strona : 29

30 Dokument SRS struktura ogólna 1 Wprowadzenie 2 Ogólny opis produktu 3 Wymagania funkcjonalne IEEE Recommended Practice for Software Requirements Specification IEEE std Wymagania niefunkcjonalne Dodatki Indeks Copyright Roman Simiński Strona : 30

31 Dokument SRS wprowadzenie 1 Wprowadzenie 1.1 Cel dokumentu 1.2 Zakres produktu IEEE Recommended Practice for Software Requirements Specification IEEE std Definicje, akronimy i skróty 1.4 Odwołania do literatury 1.5 Omówienie dokumentu 2 Ogólny opis produktu 3 Wymagania funkcjonalne 4 Wymagania niefunkcjonalne Dodatki Indeks Copyright Roman Simiński Strona : 31

32 Dokument SRS ogólny opis produktu 1 Wprowadzenie 2 Ogólny opis produktu 2.1 Kontekst funkcjonowania IEEE Recommended Practice for Software Requirements Specification IEEE std Charakterystyka użytkowników 2.3 Główne funkcje produktu 2.4 Ograniczenia 2.5 Założenia i zależności 3 Wymagania funkcjonalne 4 Wymagania niefunkcjonalne Dodatki Indeks Copyright Roman Simiński Strona : 32

33 Dokument SRS wymagania funkcjonalne 1 Wprowadzenie 2 Ogólny opis produktu 3 Wymagania funkcjonalne IEEE Recommended Practice for Software Requirements Specification IEEE std n.. 4 Wymagania niefunkcjonalne Dodatki Indeks Copyright Roman Simiński Strona : 33

34 Dokument SRS wymagania niefunkcjonalne 1 Wprowadzenie 2 Ogólny opis produktu 3 Wymagania funkcjonalne IEEE Recommended Practice for Software Requirements Specification IEEE std Wymagania niefunkcjonalne m.. Dodatki Indeks Copyright Roman Simiński Strona : 34

35 Diagramy przypadków użycia jako narzędzie modelowania wymagań Nazwa diagramu UML: Diagramy przypadków użycia use case diagrams. Cel stosowania: Określenie wymagań stawianych systemowi czyli co system ma robić z punktu widzenia jego otoczenia. Określenie granic systemu jego otoczenia oraz elementów, które wchodzą z nim w interakcję. Diagramy przypadków użycia opisują, co robi system z punktu widzenia zewnętrznego obserwatora. Eksponują to, co robi system, a nie jak to robi. Copyright Roman Simiński Strona : 35

36 Diagramy przypadków użycia jako narzędzie modelowania wymagań Główne zastosowania: Określanie i doprecyzowanie funkcji systemu opisywane przypadki użycia zwykle generują nowe wymagania, a projekt przybiera coraz wyraźniejszy kształt. Komunikacja z klientami prostota notacji i intuicyjność sprawiają, że diagramy przypadków użycia są dobrym sposobem porozumiewania się projektantów z przyszłymi użytkownikami systemu. Generowanie przypadków testowych opis danego przypadku użycia może zasugerować sposoby testowania i konkretne dane testowe. Zrozumienie różnych scenariuszy wykorzystania projektowanego systemu. Porozumiewanie się projektantów systemu i jego przyszłych użytkowników. Copyright Roman Simiński Strona : 36

37 Komponenty diagramów przypadków użycia Aktor Aktor Przypadek użycia Przypadek użycia Związek Copyright Roman Simiński Strona : 37

38 Komponenty diagramów przypadków użycia aktorzy Aktorami mogą być ludzie, urządzenia, inne systemy informatyczne. Pojęcia aktora odpowiada roli jaką on odgrywa w stosunku do systemu. Pojęcia aktora nie odpowiada zawsze np. konkretnej osobie fizycznej, bo ta może wcielać się w różne role (ta sama osoba fizyczna może się logować do systemu raz jako administrator, a innym razem jako zwykły użytkownik). Jeden aktor może reprezentować całą grupę fizycznych użytkowników systemu (aktor Klient reprezentuje wszystkich potencjalnych klientów systemu). Aktorzy są zwykle aktywni inicjują przypadku użycia, choć mogą być również pasywni (np. aktor tyko zatwierdzający przelew bankowy). <<Actor>> System obsługi kart płatniczych <<Actor>> System weryfikacji podpisu elektronicznego Klient Admin Kierownik Copyright Roman Simiński Strona : 38

39 Komponenty diagramów przypadków użycia przypadki użycia Przypadek użycia reprezentuje sekwencję operacji wykonywanych przez system, inicjowanych przez aktora. Przypadek użycia modeluje oczekiwanie zachowanie systemu wobec danego aktora, nie precyzując sposobu realizacji tego zachowania. Uruchomienie danego przypadku użycia ma dostarczyć aktorowi wymiernych wyników. Przypadek użycia zwykle opisuje pewien większy, dłuższy, bardziej złożony proces a nie elementarną akcję. Porada lekarska Sprzedaż towaru Wystawienie faktury Copyright Roman Simiński Strona : 39

40 Komponenty diagramów przypadków użycia związki Związek pomiędzy aktorem a przypadkiem użycia opisuje udział aktora w danym przypadku użycia. Pomiędzy przypadkami użycia mogą występować związki zostaną przedstawione za chwilę. Porada lekarska Pacjent Aktor Pacjent inicjuje przypadek użycia Porada lekarska. Jest to pewien nieelementarny proces, wynikiem którego jest umówienie wizyty lekarskiej oraz przygotowanie kartoteki pacjenta. Ten przypadek użycia dostarcza aktorowi konkretnych efektów działania systemu. Copyright Roman Simiński Strona : 40

41 Związki pomiędzy przypadkami użycia zawieranie Czasem wiele przypadków użycia posiada pewną wspólną sekwencję operacji (wspólne zachowanie) można ją wyróżnić w postaci odrębnego przypadku użycia. Wspólny, odrębny przypadek użycia włącza się do przypadku bazowego wykorzystując związek zawierania, opisany stereotypem <<include>>. Przypadek bazowy występuje jako pierwszy i zawsze używa przypadku składowego. Składowy przypadek użycia reprezentuje podzadanie, zadania jakim jest przypadek bazowy. Przypadek bazowy <<include>> Przypadek składowy Copyright Roman Simiński Strona : 41

42 Związki pomiędzy przypadkami użycia zawieranie, przykład Biblioteka Rezerwacja książki <<include>> Wyszukanie książki Klient Wypożyczenie książki <<include>> Klient pewnej biblioteki może przeszukiwać jej zasoby katalogowe w poszukiwaniu konkretnej książki. Klient pewnej biblioteki może rezerwować konkretną książkę przed jej fizycznym wypożyczeniem, co wymaga zwykle jej wyszukania. Klient pewnej biblioteki może wypożyczyć konkretną książkę, co wymaga zwykle jej wyszukania. Copyright Roman Simiński Strona : 42

43 Związki pomiędzy przypadkami użycia zawieranie, przykład Konto Klient Złożenie zlecenia stałego Wykonanie przelewu Sprawdzenie stanu konta Przeglądnie transakcji <<include>> <<include>> <<include>> <<include>> <<include>> Dodatkowe uwierzytelnienie <<include>> Standardowa autoryzacja Zalogowany klient pewnego systemu bankowości elektronicznej, może wykonywać przelewy i składać zlecenia stałe. Wymaga to jednak zawsze dodatkowego uwierzytelnienia klienta. Przegląd transakcji i sprawdzenie stanu konta wymaga zawsze standardowej autoryzacji klienta. Copyright Roman Simiński Strona : 43

44 Związki pomiędzy przypadkami użycia rozszerzanie Czasem pewien przypadek bazowy opcjonalnie realizuje jakaś czynność opcjonalną. Przypadek bazowy może działać samodzielnie i nie wykonywać funkcji opcjonalnej. Jednak po dojściu do pewnego punktu rozszerzającego, może zostać uruchomiony przypadek rozszerzający. Po zakończeniu przypadku rozszerzającego, wznawiane jest wykonanie przypadku bazowego. Rozszerzający przypadek użycia opisany jest stereotypem <<extend>> Notacja wykorzystująca komentarz z warunkiem rozszerzenia: Przypadek bazowy Extension points Opis punktu <<extend>> Przypadek rozszerzający Condition: opis warunku Extension point: opis punktu Copyright Roman Simiński Strona : 44

45 Związki pomiędzy przypadkami użycia rozszerzanie, przykład Biblioteka Rezerwacja książki <<include>> Wyszukanie książki Klient Wypożyczenie książki Extension points Opłata karna <<include>> <<extend>> Zapłata opłaty karnej Klient pewnej biblioteki może wypożyczyć konkretną książkę. Jednak na tym etapie sprawdza się, czy nie zalega z opłatą karną za nieterminowe oddawanie książek, jeżeli tak, użytkownik musi opłacić wszystkie zaległości. Copyright Roman Simiński Strona : 45

46 Związki pomiędzy przypadkami użycia uogólnienie Czasem pewien można zidentyfikować przypadki określające ten sam rodzaj przetwarzania realizowanego przez system. Przypadki są podobne, lecz nie jednakowe. W stosunku do przypadków można zastosować związek generalizacjaspecjalizacja, i zastosować podejście analogiczne do klas. Przypadek będący specjalizacją pewnego przypadku uogólnionego, dziedziczy po nim całe zachowanie. Potomek może dodać nowe elementy do odziedziczonego zachowania lub wręcz całkowicie zmienić odziedziczone zachowanie. Przypadek ogólny Przypadek specjalizowany Copyright Roman Simiński Strona : 46

47 Związki pomiędzy przypadkami użycia uogólnienie, przykład Biblioteka Rezerwacja książki <<include>> Wyszukanie książki Klient Wypożyczenie książki Extension points Opłata karna <<include>> Wypożyczenie książki z odbiorem osobistym <<extend>> Zapłata opłaty karnej Wypożyczenie książki z dostawą do domu Copyright Roman Simiński Strona : 47

48 Zadanie na ćwiczenia: opracuje SRS i dopracuj diagram dla Biblioteka Inni aktorzy... Inne przypadki użycia... Rejestracja klienta Bibliotekarz Do tworzenia diagramów Use Case można wykorzystać darmowy system ArgoUML dostępne via Internet Copyright Roman Simiński Strona : 48