Określanie wymagań Inżynieria wymagań

Slides:



Advertisements
Podobne prezentacje
nowoczesny system zarządzania przedsiębiorstwem
Advertisements

Ewidencja Wyposażenia PL+
Project management w procesie budowy grona
Modelowanie przypadków użycia
Projektowanie w cyklu życia oprogramowania
OiZPI Część 4 zarządzanie procesem formułowania wymagań
7-8 października 2003, I Seminarium Integrujące Komponenty B.1 i B.2Projekt Usuwania Skutków Powodzi - Polska, kredyt nr 4264 POL 1 System Monitoringu.
Modelowanie procesów biznesowych
Role w zespole projektowym
Warszawa system IMS 7.0 oprogramowanie dla warsztatów i sklepów branży motoryzacyjnej Copyright by Integra Software. Wszelkie prawa zastrzeżone.
Analiza ryzyka projektu
Referat 3. Planowanie zadań i metody ich obrazowania
MS Access 2000 Normalizacja Paweł Górczyński 2005.
Propozycja metodyki nauczania inżynierii oprogramowania
Od pomysłu do realizacji projektu - procedury. 2. Jakie są źródła finansowania naszego projektu?
Ksantypa2: Architektura
Klawiatura i urządzenia wskazujące
Systemy operacyjne.
Jakość systemów informacyjnych (aspekt eksploatacyjny)
Projektowanie i programowanie obiektowe II - Wykład IV
Praca Inżynierska „Analiza i projekt aplikacji informatycznej do wspomagania wybranych zadań ośrodków sportowych” Dyplomant: Marcin Iwanicki Promotor:
GENERATOR WNIOSKÓW I STUDIUM WYKONALNOŚCI WYBRANE INFORMACJE Wrocław, 22 listopada 2005 r. WOJCIECH WICZKOWSKI Dział Wdrażania Europejskiego Funduszu Rozwoju.
METODYKA PROJEKTOWANIA I DOSKONALENIA STRUKTUR
Projektowanie - wprowadzenie
Analiza, projekt i częściowa implementacja systemu obsługi kina
Wykład 2 Cykl życia systemu informacyjnego
Modelowanie systemu informatycznego
Atlantis INSPECTOR System wspomagania zarządzaniem i ewidencją obiektów sieciowych.
Instytut Tele- i Radiotechniczny WARSZAWA
Diagramy obiegu dokumentów a UML w modelowaniu procesów biznesowych
Model przestrzenny Diagramu Obiegu Dokumentów
Budowa systemu komputerowego
Ramzes Sp. z o. o. ul. Fasolowa 31A Warszawa Dział handlowy tel
Rozwiązania informatyczne dla przedsiębiorstw
Wymiana integracja ? oprogramowania dr Danuta Kajrunajtys.
Comarch OPT!MA użytkowników, mikro, małe i średnie firmy
Podstawy działania wybranych usług sieciowych
Dr Karolina Muszyńska Na podst.:
ZWIĄZKI MIĘDZY KLASAMI KLASY ABSTRAKCYJNE OGRANICZENIA INTERFEJSY SZABLONY safa Michał Telus.
1 Każdy obiekt jest scharakteryzowany poprzez: tożsamość – daje się jednoznacznie wyróżnić; stan; zachowanie. W analizie obiektowej podstawową strukturą
Modelowanie obiektowe Diagramy UML – diagram przypadków użycia
Sebastian Wojczyk Inżynieria wymagań Sebastian Wojczyk
1 (21) Modelowanie i opis wymagań Bogdan Bereza – blogomocja.blogspot.com –
Treści multimedialne - kodowanie, przetwarzanie, prezentacja Odtwarzanie treści multimedialnych Andrzej Majkowski 1 informatyka +
PROCESY W SYSTEMACH SYSTEMY I PROCESY.
Zarządzanie zagrożeniami
Studium osiągalności. Rozmiar projektu (np. w punktach funkcyjny projektu w porównaniu do rozmiaru zakładanego zespołu projektowego i czasu Dostępność.
Proces tworzenia oprogramowania Proces tworzenia oprogramowania jest zbiorem czynności i związanych z nimi wyników, które prowadzą do powstania produktu.
Przykłady analiza i projektowanie
Systemy informatyczne
Treści multimedialne - kodowanie, przetwarzanie, prezentacja Odtwarzanie treści multimedialnych Andrzej Majkowski informatyka +
Dokumentacja techniczna
Dokumentacja obsługi programów Kamil Smużyński Piotr Kościński.
Copyright © Jerzy R. Nawrocki Team Software Process Inżynieria oprogramowania II Wykład.
Eksploatacja zasobów informatycznych przedsiębiorstwa.
Wdrażanie SYSTEMU Jacek WĘGLARCZYK.
Diagramy przepływu danych
Ergonomia procesów informacyjnych
Część 1.  Pierwszym etapem metodyki strukturalnej jest analiza strukturalna której efektem jest model podstawowy systemu.
Witam Państwa!.
Wstęp do systemów informatycznych Model przypadków użycia.
Inżynieria systemów informacyjnych
Projekt modułu BANK INTERNETOWY Moduł funkcji banku
AudaPad / AudaShare AudaShare PRO (2.8)
Ewidencja Wyposażenia PL+
Systemy eksperckie i sztuczna inteligencja
Cykl życia oprogramowania
Zapis prezentacji:

Określanie wymagań Inżynieria wymagań Dr inż. Marek Miłosz Wykład 3

Plan Istota fazy określania wymagań Problemy inżynierii wymagań Metody rozpoznania wymagań Wymagania funkcjonalne i nie- Dokument: Specyfikacja wymagań Formalne metody definiowania wymagań © M.Miłosz

Istota fazy określania wymagań Cel: ustalenie wymagań klienta wobec tworzonego SI Zamiana celów klienta na konkretne wymagania zapewniające osiągnięcie tych celów Proces wspólnej pracy: analityk systemowy + klient + eksperci dziedzinowi Konieczność dużego zaangażowania klienta Weryfikacja wymagań © M.Miłosz

Czynniki uwzględniane przy definiowaniu wymagań (1) Możliwości systemu (zestaw funkcji systemu z pozycji użytkownika) Wielkość systemu (liczba użytkowników, objętość baz danych) Szybkość działania (czas realizacji operacji, natężenie operacji) Dokładność (liczba miejsc znaczących) Ograniczenia (zakres zmienności) © M.Miłosz Wg Software Engineering Guides

Czynniki uwzględniane przy definiowaniu wymagań (2) Interfejsy komunikacyjne (sieć, protokoły) Interfejsy sprzętowe (sprzęt, wymagania środowiska pracy) Interfejsy oprogramowania (kompatybilność) Interakcja człowiek-maszyna (interfejs użytkownika, sprzęt, język, komunikaty) © M.Miłosz

Czynniki uwzględniane przy definiowaniu wymagań (3) Adaptowalność (zmiana) Bezpieczeństwo (poufność, prywatność, odporność) Odporność na awarie Standardy Zasoby (finansowe, ludzkie) Skala czasowa (ograniczenia czasu wykonania) © M.Miłosz

Problemy inżynierii wymagań Klient nie potrafi zdefiniować celów i wymagań Cele klienta mogą być osiągnięte na wiele sposobów Wielu użytkowników - wiele celów, sprzeczność, różnorodność terminologii Zleceniodawcy a użytkownicy - przewidywalność potrzeb, sprzeczność interesów Niejednoznaczność języka © M.Miłosz

Poziomy opisu wymagań Definicja wymagań - opis ogólny w języku naturalnym Specyfikacja wymagań - częściowo ustrukturalizowany zapis wykorzystujący zarówno język naturalny, jak i proste, sformalizowane notacje (tablice, diagramy) Specyfikacja oprogramowania - w pełni formalny opis wymagań © M.Miłosz

Formalizacja Formalny <> matematyczny Formalny = dokładny, jednoznaczny, nie stwarzający okazji do różnej interpretacji Notacje: schematy, formularze Podstawa do testowania akceptacyjnego SI © M.Miłosz

Jakość opisu wymagań Kompletność i niesprzeczność (spójność) Jednoznaczność, dokładność Realistyczność, osiągalność Wyraźna specyfikacja ograniczeń Opis zewnętrznych zachowań SI Możliwość modyfikacji i zmian Opis zachowania się SI i rozwiązywania problemów w sytuacjach wyjątkowych © M.Miłosz

Metody rozpoznania wymagań Wywiady i przeglądy procesów oraz zdarzeń (MBP - jeśli było przeprowadzone) Analiza istniejącego oprogramowania Analiza wymagań innych SI Studium wykonalności Prototypowanie © M.Miłosz

Typy wymagań Funkcjonalne - czynności/operacje które SI musi wykonywać w reakcji na zdarzenia zewnętrzne (obiekty oddziaływujące na SI lub wykorzystujące rezultaty jego pracy) Niefunkcjonalne - ograniczenia i dodatkowe uwarunkowania - inne struktury SI (np. struktura techniczna, typ interfejsu, współpraca z BD, wydajność, odporność na awarię, przenośność, łatwość użytkowania) © M.Miłosz

Dokument: Specyfikacja wymagań Wprowadzenie (cel, zakres i kontekst systemu, częściowe wyniki fazy strategicznej) Opis ewolucji systemu (zakres wprowadzanych zmian) Opis wymagań funkcjonalnych Opis wymagań niefunkcjonalnych Model funkcjonalny SI Wymagania przedsięwzięcia (czas, zasoby) Słownik terminów (informatycznych i specyficznych) © M.Miłosz

Model funkcjonalny - idea Klient SI Zapytanie Faktura Klient Rachunek Funkcje Bank OBIEKTY ZEWNĘTRZNE ZDARZENIA - WE Żądanie zapłaty REZULTATY - ZDARZENIA WY Wykaz Kierownik Zestawienie Dyrektywy Kierownik © M.Miłosz

Model funkcjonalny SI - struktura Identyfikacja zdarzeń, na które ma reagować SI Identyfikacja obiektów zewnętrznych generujących zdarzenia (osoby, systemy,...) Diagram kontekstowy SI (Context diagram) Hierarchiczny model funkcji SI © M.Miłosz

Wykaz zdarzeń Event list Zdarzenie - pojawienie się danych na granicy systemu (do i z systemu) Typy zdarzeń: wymuszone z zewnątrz (obiekty) lub wewnętrzne (związane z upływem czasu) sterowanie (w tym systemowe) Identyfikacja zdarzeń z punktu widzenia otoczenia systemu Identyfikacja wyjątków i zdarzeń niepożądanych © M.Miłosz

Obiekty zewnętrzne Obiekty (lub ich grupy), które dostarczają informacji do SI lub też wykorzystują informację tworzoną w rezultacie pracy SI - generują zdarzenia zewnętrzne Problem: obiekt vs. użytkownik końcowy vs. użytkownik bezpośredni SI Definiowanie granic system-otoczenie © M.Miłosz

Diagram kontekstowy Context diagram © M.Miłosz wg. metodyki SSADM - Structured System Analysis and Design Method

Hierarchiczny model funkcji - techniki przedstawienia (1) Lista hierarchii 1. Funkcja 1 1.1. Funkcja 1.1 1.2. Funkcja 1.2 1.3. Funkcja 1.3 2. Funkcja 2 3. Funkcja 3 3.1. Funkcja 3.1 3.1.1. ........ 3.1.2. ........ 3.1.3. ........ 3.2. Funkcja 3.2 3.2.1. ........ 3.2.2. ........ 3.2.3. ........ Układ pionowy © M.Miłosz

Hierarchiczny model funkcji - techniki przedstawienia (2) Układ poziomy Wyróżnienia graficzne: - kluczowa funkcja - inne (pominięte) - nierozwinięte poziomy - elementarne Układ hybrydowy (zalecany) © M.Miłosz

Model funkcji - zasady Funkcja = działanie (czasownik) Zwięzłość, jednoznaczność opisu, numerowanie funkcji Na każdym poziomie ten sam poziom szczegółowości Kompletność dekompozycji Kolejność funkcji nie ma znaczenia Funkcje z pozycji użytkownika Podejście top-down © M.Miłosz

Dekompozycja Top-down funkcja f1 funkcja f1.4.3 funkcja f1.4.2 funkcja f1.4.1 funkcja f1.4 funkcja f1.3.2 funkcja f1.3.3 funkcja f1.3 funkcja f1.1 funkcja f1.2 funkcja f1.3.1 funkcja f1 funkcja f1.1 funkcja f1 funkcja f1.2 funkcja f1.3 funkcja f1.4 © M.Miłosz

Formularz opisu funkcji © M.Miłosz

Wymagania niefunkcjonalne Dodatkowe uwarunkowania i ograniczenia Wynikają z wymagań użytkownika Weryfikowalność wymagań: liczebniki a nie przymiotniki uzasadnienie (koszt) © M.Miłosz

Podsumowanie Określanie wymagań jest początkiem budowy SI a jednocześnie przygotowaniem do testowania Należy zadbać o dokładność i jednoznaczność określeń Formalizacja i podejście metodyczne jest gwarancją sukcesu Błąd w specyfikacji popełnia się łatwo a jego usunięcie kosztuje bardzo dużo © M.Miłosz

Wypożyczalnia rowerów „Szybki Bill” Przykład Wypożyczalnia rowerów „Szybki Bill”

SI SzyB („Szybki Bill”) Wywiad z właścicielem Właściciel wypożyczalni rowerów „Szybki Bill” potrzebuje system informatyczny, który zautomatyzuje mu obszar ewidencji wypożyczeń rowerów z przygotowaniem danych do posiadanego programu F-K oraz gospodarkę rowerami. Każde wypożyczenie powinno być odnotowywane w systemie w sposób umożliwiające naliczenie opłat, jak też i dokładną identyfikację osoby wypożyczającej. Wypożyczalnia ma sporo stałych klientów. Prowadzi dla nich system rezerwacji rowerów. Rowery niekiedy się psują i wymagają napraw w warsztacie remontowym. © M.Miłosz

SI SzyB Specyfikacja - Wprowadzenie Cel: automatyzacja obsługi procesów ewidencji rowerów, rezerwacji, wypożyczeń, naliczania opłat Zakres: gospodarka rowerami (ewidencja, remonty, złomowanie) ewidencja klientów i wypożyczeń rozliczanie wypożyczeń rezerwowanie rowerów (przyjęcie rezerwacji, rezygnacja) cennik zestawienia wynikowe Kontekst systemu: SI SzyB ma współpracować z istniejącym systemem F-K na istniejącym sprzęcie © M.Miłosz

SI SzyB Wymagania niefunkcjonalne SI SzyB ma być zaimplementowany przy pomocy MS Access 2000 na komputerze z MS Windows 2000 Do szybkiej identyfikacji rowerów mają być użyte naklejki i czytniki kodu kreskowego Musi istnieć możliwość obsługi przy pomocy: myszy, klawiatury i/lub ekranu dotykowego Wymiana z F-K ma się odbywać przy pomocy pliku tekstowego w formacie opisanym w dokumentacji systemu F-K System ma mieć możliwość obsługi w języku polskim i angielskim z przełączaniem „w locie” © M.Miłosz

SI SzyB Identyfikacja zdarzeń i obiektów © M.Miłosz

SI SzyB Diagram kontekstowy Policja Warsztat Dostawca Zgłoszenie kradzieży Rezygnacja Zlecenie naprawy Dane roweru Rezerwacja SzyB F-K Klient Dane klienta Dane o opłacie Oferta Raporty Cennik Dane o zwrocie (braku) Typ roweru Dane o wypożyczeniu Status roweru Właściciel Pracownik © M.Miłosz

SI SzyB Model funkcji © M.Miłosz

Opis funkcji 2.1 © M.Miłosz

SI SzyB Model funkcji (alternatywny) © M.Miłosz