Wykład 3 Wymagania. MIS n Inżynieria oprogramowania Październik Kazimierz Michalik Akademia Górniczo-Hutnicza im. S. Staszica w Krakowie

Transkrypt

1 Wykład 3 MIS n Inżynieria Październik 2014 Kazimierz Michalik Akademia Górniczo-Hutnicza im. S. Staszica w Krakowie 3.1

2 Agenda

3 Czynności w czasie produkcji. Inżynieria stara się zidentyfikować i opisać podstawowe fazy tworzenia i funkcjonowania, a także wskazać model optymalnego przebiegu tych faz. Co można robić w czasie tworzenia? Planowanie (w tym opracowanie wymagań). Implementacja. Testowanie. Dokumentowanie. Wdrożenie. Utrzymanie (konserwacja). 3.3

4 Ogólny schemat. 3.4

5 funkcjonalne i niefunkcjonalne. funkcjonalne Sa stwierdzeniami, jakie usługi ma oferować system, jak ma reagować na określone dane wejściowe oraz jak ma się zachowywać w określonych sytuacjach. Opisuja funkcjonalność lub usługi, które system powinien oferować. niefunkcjonalne Ograniczenia usług i funkcji systemu. Obejmuja ograniczenia czasowe, ograniczenia procesu tworzenia, standardy itd. Moga być zwiazane z właściwościami systemu (niezawodność, czas reakcji, zajętość pamięci itd.), definiować ograniczenia systemu itp. Nie dotycza bezpośrednio funkcji systemu. dziedzinowe. Pochodza z dziedziny zastosowania systemu i odzwierciedlaja jej charakterystykę. Moga moga być funkcjonalne lub niefunkcjonalne. 3.5

6 użytkownika. użytkownika Wyrażanie w języku naturalnym oraz diagramy o usługach oczekiwanych od systemu oraz o ograniczeniach, w których system ma działać. dość wysoki poziom abstrakcji nie powinny z góry definiować rozwiazań powinno dać się spełnić takie wymagania korzystajac z różnych podejść wymagaja uściślenia 3.6

7 systemowe. systemowe Szczegółowo ustalaja usługi systemu i ograniczenia. Dokumentacja wymagań systemowych (specyfikacja funkcjonalna) powinna być precyzyjna. Może służyć jako kontrakt między nabywca systemu a wytwórca. Specyfikacja projektu. Abstrakcyjny opis projektu, który jest podstawa bardziej szczegółowego projektu i implementacji. Poszerza specyfikację wymagań systemowych. 3.7

8 Dokumentacja wymagań (IEEE/ANSI ) 1 Wstęp. 2 Ogólny opis. 1 Wizja produktu. 2 Funkcje produktu. 3 Charakterystyka użytkowników. 4 Ogólne ograniczenia. 5 Założenia i zależności. 3 Szczegółowe wymagania. funkcjonalne, niefunkcjonalne, interfejsy etc. Najbardziej istotna części dokumentu. Definicja jak powinna wygladać ta część nie jest zalecana, ponieważ mocno zależy do praktyki w firmie i dziedziny zagadnień. 4 Dodatki. 5 Skorowidz. 3.8

9 .. Proces, który obejmuje wszystkie czynności niezbędne do opracowania i aktualizacji dokumentacji wymagań systemowych. 4 główne czynności: 1 Studium wykonalności. 2 Określenie i analizowanie wymagań. 3 Specyfikowania i dokumentowanie wymagań. 4 Zatwierdzanie wymagań. 3.9

10 Studium wykonalności. Studium wykonalności. Krótki, skumulowane opracowanie, w którym staramy się odpowiedzieć na pytania: 1 Czy system przyczyni się do realizacji ogólnych celów (przedsiębiorstwa)? 2 Czy system może być zaimplementowany z użyciem dostępnych technologii, w ramach ustalonego budżetu i ograniczeń czasowych? 3 Czy system może być zintegrowany z istniej acymi systemami, które już zainstalowano? 3.10

11 Określenie i analiza wymagań. Rozpoznanie dziedziny Analitycy musza zrozumieć dziedzinę zastosowania. Zbieranie wymagań Proces interakcji z uczestnikami systemu, którego celem jest ujawnienie wymagań. Klasyfikacja Podział na grupy. Usuwanie sprzeczności podane przez różne grupy nieuchronnie będzie zawierać sprzeczności. Nadawanie priorytetów Interakcja z uczestnikami w celu wskazania najważniejszych wymagań w grupie. Sprawdzanie wymagań Czy wymagania sa spójne i zgodne z tym czego uczestnicy chca od systemu. 3.11

12 Zatwierdzanie wymagań. Czy wymagania naprawdę definiuja system, którego chce użytkownik? 1 Sprawdzenie ważności. 2 Sprawdzenie niesprzeczności. 3 Sprawdzenie kompletności. 4 Sprawdzenie realności. 5 Możliwość weryfikacji. Metody sprawdzania wymagań: Przeglad wymagań.. Generowanie testów. Zautomatyzowane sprawdzanie niesprzeczności. 3.12

13 Zarzadzanie wymaganiami. Zmiany gospodarcze, organizacyjne i technologiczne nieuchronnie prowadza do zmian wymagań stawianych. Zarzadzanie wymaganiami to proces kierowania i panowania nad tymi zmianami. Proces zarzadzania wymaganiami obejmuje: 1 planowanie, w trakcie którego specyfikuje się proces zarzadzania i zarzadzanie zmianami 1 Analiza problemu u specyfikacja zmiany. 2 Analiza zmiany i ocena kosztów. 3 Implementacja zmiany. 2 zarz adzanie zmianami, które polega na analizowaniu zmian i szacowaniu ich wpływu 3.13

14 Co to sa? Model systemu Graficzna reprezentacja na której przedstawia się, problem do rozwiazania i system do zbudowania. bardziej zrozumiałe niż szczegółowy opis wymagań etap pośredni między analiza a projektowaniem służa wypracowaniu lepszego zrozumienia systemu moga służyć do zobrazowania systemu z różnych punktów widzenia: 1 Zewnętrznego (modeluje się kontekst lub środowisko systemu). 2 Zachowania (modeluje się zachowanie systemu). 3 Strukturalnego (architektura systemu lub struktura danych). 3.14

15 Modele kontekstowe. należy ustalić granice systemu rozróżnić co jest systemem a co jego środowiskiem należy opracować prosty model architektoniczny opisuje się środowisko systemu, nie współpracę system-otoczenie 3.15

16 Modele kontekstowe. 3.16

17 Modele zachowania. Model przepływu danych. pokazuja jak dane przepływaja w sekwencji kroków przetwarzania jak dane podlegaja przekształceniu w modelu analitycznym "kroki"to przetwarzanie przez ludzi i komputery w dokumentacji projektowej"kroki"to funkcje/metody programu Model maszyn stanowych. służa do opisywania zachowania systemu jak reaguje na zewnętrzne i wewnętrzne bodźce zawiera stany(1) i zdarzenia (2), które powoduja przejścia z jednego stanu do drugiego nie obejmuje przepływu danych w ramach systemu 3.17

18 Diagram przepływu danych. 3.18

19 Diagram stanów. 3.19

20 Modele obiektowe. moga przedstawiać sam system (diagramy struktur) jak i jego działanie(diagramy zachowań) posługuja się pojęciem klasy i obiektu. Klasa obiektu. Abstrakcja zbioru obiektów, która identyfikuje ich wspólne atrybuty (w znaczeniu modelu danych) oraz usługi i operacje oferowane przez te obiekty. Obiekt Wykonywalna encja, posiadajaca atrybuty i operacje klasy. Egzemplarz klasy obiektów. Wiele obiektów może powstać z tej samej klasy. na ogół analityczne sa poświęcone klasom obiektów i ich zwiazkom 3.20

21 Modele obiektowe. Diagram hierarchii klas. 3.21

22 Modele obiektowe. Diagram agregacji klas. 3.22

23 Modele obiektowe. Diagram sekwencji. 3.23

24 CASE. Narzędzia CASE. Narzędzia Computer Aided Software Engineering to zbiór narzędzi, które wspomagaja konkretny etap procesu tworzenia. Często łaczone w jeden zestaw narzędzi (warsztat). Zestaw narzędzi CASE do analizy i projektowania, zawiera: Edytory diagramów. Narzędzia do analizy i sprawdzania projektu. Języki zapytań do repozytorium. Słownik danych. Narzędzia do definiowania i generowania raportów. Narzędzia do definiowania formularzy. Udogodnienia do importu i eksportu. Generatory kodu. 3.24

25 w procesie tworzenie. ewolucyjne. Celem jest dostarczenie użytkownikowi działajacego systemu. Zaczyna się od tych wymagań, które sa najlepiej rozpoznane i maja najwyższy priorytet. mniej jasne lub o mniejszym priorytecie sa implementowane tylko gdy zażadaj a tego użytkownicy. z porzuceniem. Celem jest zatwierdzenie lub dostarczenie wymagań systemowych. Zaczyna się od tych wymagań, które nie sa dobrze rozpoznane, aby dowiedzieć się więcej. oczywiste nie musza podlegać prototypowaniu. 3.25

26 Metody błyskawicznego prototypowania. Metody błyskawicznego prototypowania. Metody tworzenia, których przeznaczeniem jest skrócenie czasu dostarczania, a nie poprawa właściwości systemu (efektywności, niezawodności itd...) Istnieja trzy główne metody błyskawicznego prototypowania: 1 Tworzenie za pomoca dynamicznych języków wysokiego poziomu. 2 Programowanie baz danych. 3 Scalanie komponentów i programów użytkowych. 3.26

27 interfejsu użytkownika. 3.27