Identyfikacja problemu: ustalenie celu i zakresu Inicjacja projektu identyfikacja i opis problemu wizja rozwiązania ocena rozwiązań studium wykonalności wybór projektu, decyzja Zakres Literatura Górski J. (red.) Inżynieria oprogramowania w projekcie informatycznym, MIKOM, 2000 Pressman R., Software Engineering: a Practitioner s Approach. McGraw-Hill, 92 Szejko S. (red): Metody wytwarzania oprogramowania. MIKOM, 2002 Sommerville I.: Inżynieria oprogramowania. WNT, 2003 Maciej Piechówka macpi@eti.pg.gda.pl KIO, 1
Identyfikacja i zdefiniowanie problemu Opis nieformalny Opis ustrukturalizowany Założenia wstępne (wizja systemu) cele biznesowe Twój problem jest moją możliwością zakres i zadania, użytkownicy, perspektywiczność, podstawowe założenia, kształt architektoniczny, parametry jakościowe i techniczne, zgodność ze standardami, organizacja działania, wdrożenie i eksploatacja systemu uwarunkowania: ograniczenia zasobowe, powiązane projekty, wymagania i ograniczenia prawne, inne uwarunkowania Soft Systems Methodology (SSM, społeczna metoda budowy systemów) KIO, 2
Definicja problemu Element Opis Określenie problemu Problem polega na Problem dotyczy Rezultatem problemu jest Korzyści z rozwiązania problemu Opisz problem Zidentyfikuj udziałowców, których dotyczy problem Opisz wpływ tego problemu na udziałowców i działalność przedsiębiorstwa. Wskaż proponowane rozwiązanie i wymień podstawowe korzyści Udziałowcem problemu jest każdy podmiot (niekoniecznie ożywiony), który ma uzasadnione prawo wywarcia (pośrednio lub bezpośrednio) wpływu lub może znaleźć się pod wpływem rozpatrywanego problemu Słownik pojęć KIO, 3
Cele, wymagania, rozwiązania projektowe Cele wyjaśniają dlaczego potrzebujemy systemu w kontekście organizacji jakie są spodziewane korzyści utracone korzyści gdy go nie będzie Wymagania względem systemu definiują: usługi dostarczane przez system jego otoczeniu, wymaganą jakość tych usług, określają ograniczenia, w ramach których system jest realizowany oraz będzie użytkowany Wymagania przekazują również uzasadnienie dla potrzeby wytworzenia systemu - określają pośrednio cele systemu i wyjaśniają na ile i dlaczego są one ważne Poprawa obsługi klienta (nowe usługi) Zwiększenie konkurencyjności własnych produktów Lepsze szacowanie własnych zasobów Dodatkowe argumenty marketingowe Obniżka kosztów obsługi Zwiększenie własnej płynności finansowej Lepsza jakość własnych produktów... Rozróżnienie polega na tym, czy mówimy Dlaczego potrzebujemy systemu Co on ma robić Jak to chcemy osiągnąć KIO, 4
Udziałowcy i punkty widzenia systemu Udziałowiec reprezentuje określony punkt widzenia systemu doradca klienta w banku reprezentuje punkt widzenia związany z obsługą kont klientów banku Punkt widzenia nie jest tożsamy z udziałowcem - różni udziałowcy mogą reprezentować ten sam punkt widzenia ten sam punkt widzenia reprezentuje również kasjer Ten sam udziałowiec może dostarczać wymagań odnoszących się do różnych punktów widzenia kasjer reprezentuje również punkt widzenia odnoszący się do ogólnych zasad gospodarowania pieniędzmi w banku Punkt widzenia - grupowanie częściowej informacji, w ramach przyjętej perspektywy widzenia systemu. Koncentracja uwagi analityka na wybranym aspekcie systemu. Wspomagają ustalenie właściwego zakresu systemu i uzyskanie kompletności wymagań. Tworzą warunki do powiązania wymagań z ich źródłami. KIO, 5
Udziałowcy i punkty widzenia systemu (2) Udziałowcami są: bezpośredni użytkownicy kierownicy i inne podmioty zaangażowane w procesy i struktury organizacyjne znajdujące się pod wpływem systemu, inżynierowie zaangażowani w budowę i pielęgnację, klienci organizacji, które będą użytkować system, instytucje wydające regulacje prawne i certyfikaty itp. marketing, eksperci, stowarzyszenia zawodowe, opinia publiczna, opozycja, Punkty widzenia związane: z różnymi sposobami użytkowania systemu z organizacją (własną i klientów) ze współpracującymi systemami z wiedzą dziedzinową z regulacjami (prawnymi, normami i standardami itp.) KIO, 6
Ustalenie kontekstu problemu i zakresu systemu Wydzielenie obszaru biznesowego, który ma być wspierany przez system od tych obszarów, których system nie dotyczy - w ten sposób określamy granice problemu podlegającego rozwiązaniu Otoczenie stanowią dziedziny objęte zainteresowaniem, a także wszelkie istniejące systemy, które mogą być źródłem żądań biznesowych i odbiorcą usług i produktów dostarczanych przez wydzielony obszar biznesowy Granica ta jest określona poprzez przepływy występujące pomiędzy rozpatrywanym problemem i jego otoczeniem. Przepływy te mogą dotyczyć dokumentów, komunikacji, przedmiotów, itp KIO, 7
Wybór zakresu systemu - przykład 4 karty kredytowe sprawdź kredyt księgowość 3 potwierdzone zamówienie zamówienie potwierdzenie klienci zamówienie przyjmuj zamówienie klienci 2 zarejestruj zamówienie do realizacji dane dostawców stan magazynu 1 KIO, 8
1. Cele systemu 2. Kontekst systemu Użytkownicy i ich specyfika Inne systemy i ich interfejsy 3. Zakres funkcjonalności Opis, jakie usługi system ma udostępniać. Inżynieria oprogramowania Opis ustrukturalizowany: dokument Założeń Wstępnych 4. Ograniczenia Ograniczenia, które mają wpływ na kształt systemu: - dotyczące zasobów projektowych: czasowe, ludzkie, sprzętowe, oprogramowanie; - dotyczące produktu: interfejsów, dotyczące działania w specyficznych warunkach, dokumentacji, specyficzne wymagania użytkownika. 5. Wymagania jakościowe Wymagania dotyczące ochrony, bezpieczeństwa, przenośności, elastyczności, konfigurowalności, niezawodności, wydajności itp. Wizja systemu KIO, 9
SSM: WZBOGACONY WIZERUNEK (RICH PICTURE) Na początku przedsięwzięcia projektowego zainteresowane osoby mają bardzo nieostre wyobrażenie o aktualnej sytuacji, potrzebach i docelowym kształcie tego, co ma zostać osiągnięte. Nawet jeśli elementy te można określić, konieczne jest wyrażenie ich w sposób czytelny zarówno dla analityka systemu jak i potencjalnych wykonawców. Użyteczną techniką jest utworzenie Rich Picture - wzbogaconego wizerunku. Wizerunek taki odzwierciedla zagadnienia składające się na kontekst i działanie organizacji, sytuację problemową, uwarunkowania. Rich Picture stanowi istotną pomoc dla analityka systemu, jako że zapewnia całościowe spojrzenie na obszar problemu, wymuszając większe jego zrozumienie. Konieczność zgrania punktów widzenia wielu udziałowców i wyrażenia ich na niewielkim obszarze wymusza ostrość spojrzenia na problem. KIO, 10
Aspekty systemu na Rich Picture elementy struktury obszaru problemowego (może to być dekompozycja na wydziały, fizyczne lub geograficzne umiejscowienie, jednostki działające i współdziałające), zachodzące procesy, czyli działania, jakie mają miejsce w systemie oraz związki pomiędzy elementami wizerunku. związki pomiędzy elementami struktury i zachodzącymi procesami stanowiące esencję obszaru problemowego - będą one odzwierciedlać konflikty, obawy, zagrożenia, nieporozumienia pomiędzy nowymi procesami a starymi strukturami. KIO, 11
Wzbogacony wizerunek przychodni lekarskiej i standardowo wykorzystywane symbole KIO, 12
KIO, 13 Inżynieria oprogramowania WZBOGACONY WIZERUNEK Nie ma formalnej techniki rysowania Rich Picture. Rysowanie powinno: skupiać uwagę na najważniejszych zagadnieniach. Częstym błędem analizy jest zbytnie wgłębianie się w szczegóły, zaciemniające obraz na tym etapie prac. To, co jest nieodzowne w dalszych krokach analizy i konstrukcji systemu oraz wspierane przez odpowiednie po temu techniki i narzędzia, na wstępnym etapie prac może spowodować, iż analityk nie będzie widział lasu wśród drzew ; pomóc wszystkim uczestnikom określić role, jaką pełnią oni w działaniu organizacji. Analityk może wytworzyć sobie niewłaściwy, fragmentaryczny lub subiektywny model jej działania - niezgodności takiego modelu są łatwiejsze do wychwycenia gdy nada się mu formę graficzną. Stąd Rich Picture jest ważnym środkiem komunikacji pomiędzy uczestnikami procesu analizy i projektowania; Wzbogacony Wizerunek może być wykorzystany do określenia tej części organizacji, która będzie podlegać informatyzacji; Wzbogacony Wizerunek może być środkiem, służącym do wyrażenia obaw i odpowiedzialności pracowników, jak również konfliktów zachodzących pomiędzy zaangażowanymi osobami.
Przykład CKU [Gutowski, Kuc] CKU zajmuje się dostarczaniem wiedzy na potrzeby firm i klientów indywidualnych, umożliwia odbycie kursów, szkoleń i studiów podyplomowych. Głównym celem CKU jest zapewnienie klientom dostępu do szkoleń przeprowadzanych przez kadrę wydziału. Centrum powstał o z myślą o lepszym kontakcie pomiędzy wydział em a firm ami i klientami indywidualnymi w celu poprawy możliwości podwyższania kwalifikacji na kursach oferowanych przez wydział. Aktualnie oferta CK U obejmuje 4 rodzaje studiów podyplomowych oraz blisko 60 kursów krótkoterminowych. Ś red nia wielkość grupy szkoleniowej wynosi ok.15 osób. Obok informacji o kursach w Inform atorze uczelnianym oraz kontaktów osobistych i telefonicznych, możliwy jest już dziś elektroniczny dostęp do informacji o kursach poprzez kontakty klientów za pośrednictwem Internetu z pracownikami CKU, a także za pośrednictwem istniejącej witryny internetowej. Niestety efektywność owej inform acji jest niewielka ze względu na: w pierwszym przypadku konieczność znajom ości sposobu kontaktu z pracownikami CK U, w drugim statyczność udostępnianej przez WWW informacji, przez co klient ma ograniczone możliwości szybkiego znalezienia interesującej go oferty wraz z potrzebnymi mu informacjami. Nie istnieje też obecnie m ożliwość zapisania się na wybrany kurs za pośrednictwem strony W W W, co byłoby z pewnością bardziej wygodną form ą kontaktu dla klienta szukającego informacji na stronie. Problemem jest słaba komunikacja z klientami, niewystarczająca prom ocja i reklama wśród potencjalnych klientów. Informacje przepływające pomiędzy kierownikiem a prac ownikami CK U na skutek braku systemu je grom adzącego i umożliwiającego aktualizację są czasami nies pójne bądź niek ompletne, co źle wpływa na efektywność pracy Centrum. Brak też jest możliwości szybkiego uzyskania przez kierownika inform acji o historii działania CKU (przeprowadzone kursy i ich terminy, uczestnicy, wydane zaświadczenia, dyplomy itp.), a także informacji finansowych dotyczących kursów. KIO, 14
Jakie kursy są dostępne? Kiedy, ile osób jest już chętnych? Jaką opinią cieszą się kursy? Co mi to da, czy warto?.. Chciałbym zgłosić chęć uczestnictwa w kursie... A czy nie mogliby zorganizować takiego kursu...? Przyjmowanie zgłoszeń, informacje, dopasowanie kursu do potrzeb Wzbogacony wizerunek Przykład CKU Przyjmowanie zgłoszeń, informacje Klienci Informacje o prowadzonych kursach Prorektor ds. Kształcenia Firma X Archiwum Kierownik CKU Jakie kursy są organizowane, jakie uruchamiane, jakie są w toku? Spójność informacji Sieć wydziałowa i uczelniana Uruchamiane kursy, aktualna informacja o kursach Ilu jest chętnych na dany kurs? Jakie kursy są dostępne? Kiedy będą mogły się odbyć? Jakie są terminy kursów? Jak zachęcić klientów? Jak zwiększyć zyski i prestiż CKU? Prowadzący kurs Zlecenie prowadzenia zajęć Czy program kursu się nie zmienił? Czy potrzebne są nowe materiały? Jaki jest harmonogram kursu? Wykładowcy Księgowość KIO, 15 symbolizuje sytuacje konfliktowe, związki, problemy i obawy
nigdy nie wiem czy wystarczy ręczników no, to sobie pośpiewamy Urząd Skarbowy księgowość o, znowu jest! magazyn gość wreszcie odpocznę czy ktoś się nie dowie? recepcja czy to mi się w ogóle opłaca? administracja: przepisy meldunkowe gość gość Stowarzyszenie hotelarzy KIO, 16 właściciel Model udziałowców systemu wspomagającego działanie hotelu
Słownik pojęć katalog opisów i definicji pojęć oraz ich wykorzystania wzajemne zależności między pojęciami informacje o ich użyciu, przetwarzaniu, prawach dostępu kto zdefiniował, kto jest władny zmodyfikować ontologia Nazwa Synonimy Pojęcie lub nazwa danej 1 {kurs} {inne stosowane nazwy} {przedmiot} {Wyjaśnienie pojęcia} Opis Powiązania {Termin stosowany na określenie tematycznego ciągu zajęć, mającego charakter wykładów, seminariów lub ćwiczeń praktycznych}. Kurs składa się z bloków tematycznych, a jego czas trwania zależny jest od konkretnych ustaleń. Kurs ma osobę nadzorującą (kierownika kursu), a każdy z bloków prowadzić może inny wykładowca. Kurs może kończyć się zaliczeniem, będącym sprawdzeniem wiedzy przyswojonej przez słuchaczy}. {z innymi pojęciami} {blok tematyczny, kierownik kursu, zaliczenie} KIO, 17
Analiza (studium) wykonalności Studium wykonalności rozwiązania problemów i opcji wskazanych w założeniach projektu Dyskusja wariantów rozwiązania Podstawy podjęcia decyzji o kontynuacji (lub nie) projektu wykonalność techniczna wykonalność ekonomiczna wykonalność organizacyjna aspekty prawne Wynik: Raport studium wykonalności KIO, 18
Inżynieria wymagań W typowych sytuacjach wymagania stanowią zbiór informacji dotyczących dziedziny problemowej, własności i zachowań systemu, oraz różnego rodzaju ograniczeń (projektowych, wytwórczych, środowiskowych, prawnych itp). Działania: identyfikowanie, pozyskiwanie wymagań dokumentowanie analizowanie specyfikacja weryfikacja i walidacja pielęgnacja Pod pojęciem inżynierii wymagań rozumiemy całość działań związanych z rozpoznawaniem, dokumentowaniem, analizowaniem oraz pielęgnowaniem zbioru wymagań wobec systemu komputerowego oznacza to, że działania te podlegają planowaniu oraz bazują na technikach systematycznych i powtarzalnych KIO, 19
Inżynieria wymagań w modelu kaskadowym (przypomnienie) Planowanie Inżynieria wymagań Analiza Projektowanie zarządzanie wymaganiami zarządzanie zmianami Implementacja Testowanie Wdrażanie i i pielęgnacja KIO, 20
Inżynieria oprogramowania Oprogramowanie nie jest takie, jakiego chce odbiorca! KIO, 21
Procentowy udział błędów wymagań Dokumentacja 5% 5% 6% 6% 7% 2% Człowiek Środowisko Dane Interfejs Inne Projektowanie Wymagania 28% Dane z projektu US Air Force. Sheldon, et al IEEE Software, July 1992 41% Błędy wymagań stanowią najliczniejszą klasę błędów. KIO, 22
Koszt defektów w wymaganiach K o s z t D e f e k t u Budowa Definicja 10-100x 1x Faza usunięcia defektu Użytkowanie i Pielęgnacja 100-1000x WNIOSEK: niedostateczne praktykowanie inżynierii wymagań to ryzyko nadmiarowej pracy! KIO, 23
Problemy w pozyskiwaniu wymagań rzeczywiste potrzeby odczuwane potrzeby wypowiedziane potrzeby pozyskane wymagania satysfakcja klienta: odczucie jakości dostarczony produkt: spełnione wymagania budowa systemu wyspecyfikowane wymagania zgodność: ramy kontraktu Dodatkowa trudność: zmienność w czasie KIO, 24
Proces poszukiwania wymagań to co jest wymagane to co nie jest wymagane Budowanie właściwego systemu! Pytanie: gdzie jest ta granica? potrzebuje ale nie wymaga nie potrzebuje ale wymaga analiza i iteracje KIO, 25
Wymagania względem systemu Wymagania względem systemu definiują usługi dostarczane przez system jego otoczeniu, wymaganą jakość tych usług oraz określają ograniczenia, w ramach których system jest realizowany oraz będzie użytkowany wymagania ogólne, sytuujące system w kontekście wymagania dotyczące systemu funkcjonalne pozafunkcjonalne wymagania i ograniczenia środowiska pracy systemu (eksploatacyjne) wymagania projektowo - wdrożeniowe KIO, 26
Proces inżynierii wymagań Inicjacja projektu Studium wykonalności Pozyskiwanie, określenie i analiza wymagań Specyfikacja wymagań Raport wykonywalności Modele systemu Walidacja i zatwierdzanie wymagań Wymagania użytkownika i systemu Dokumentacja wymagań KIO, 27
Inicjacja Projektu wyniki etapu Cel projektu -określenie jaki efekt biznesowy jest oczekiwany od projektu Klient -określenie, dla kogo jest tworzony produkt Odbiorca -określenie, do kogo trafi system po jego wytworzeniu Użytkownicy - wskazanie i określenie charakterystyk spodziewanych użytkowników Udziałowcy - wskazanie innych podmiotów zainteresowanych produktem Ograniczenia -określenie ograniczeń projektowych, budżetu i terminu realizacji Terminologia i definicje -określenie języka komunikowania się w trakcie projektu Założenia - wszelkie inne informacje istotne dla projektu Zakres -określenie granic produktu i projektu Oszacowanie kosztu - jakie będą nakłady pracy i jaki jest spodziewany koszt projektu Ryzyko - jakie są główne zagrożenia i jak im przeciwdziałać KIO, 28 DECYZJA: kontynuacja/kasacja
Pozyskiwanie wymagań Poziomy pytań: Jakie są cele biznesowe? Co należy zrobić na poziomie biznesu by osiągnąć te cele? Co muszą robić ludzie (aktorzy biznesowi) aby sprostać oczekiwaniom biznesowym? W jaki sposób system będzie wspierał ich działania? Jakie są wymagania względem systemu? Wydobycie wymagań Analiza Reprezentacja problemy źródła wymagań i metody ich pozyskiwania KIO, 29
Problemy przy wydobywaniu wymagań Wiedza związana z wymaganiami często nie jest dostępna w postaci gotowej Wiedza ta może być rozproszona pomiędzy wiele źródeł Wydobycie jej od ludzi wymaga intensywnej komunikacji i nie jest łatwe Ludzie najczęściej prezentują subiektywny punkt widzenia Wiedza pochodząca z różnych źródeł może być wzajemnie sprzeczna Jak zapewnić kompletność?? KIO, 30
Strategia pozyskiwania wymagań Określ potrzeby Jakie są cele systemu Jaki jest zakres systemu (granice, punkty widzenia i związani z nimi udziałowcy) Jaką wiedzę należy pozyskać od udziałowców bezpośrednich i pośrednich Jaką wiedzę należy pozyskać z dziedziny aplikacyjnej Jak dotrzeć do źródeł i z kim komunikować się bezpośrednio Plan sesji związanych z kontaktami Ograniczenia związane z sesjami (czas, personel, itp.) Dobierz metody określ zakres i kontekst poszczególnych sesji wybierz metody pozyskiwania dla poszczególnych sesji przypisz priorytety poszczególnym sesjom KIO, 31
Metody pozyskiwania wymagań Studia dziedzinowe - poznanie literatury przedmiotu Wywiady (interviews) i dyskusje Kwestionariusze Analiza dokumentów Analiza istniejącego systemu Próbkowanie Obserwacje Prezentacje u dostawców i wizytowanie podobnych instalacji Symulacja punktów widzenia Wykorzystanie kilku spośród wskazanych metod KIO, 32
Metody zbierania informacji: poznanie dziedziny przedmiotu Regulacje i przepisy Normy organizacyjne Formaty dokumentacji ewidencyjnej: - schematy organizacji - podręczniki procedur administracji - opisy zadań i specyfikacje zakresu obowiązków - podręczniki ćwiczeniowe - materiały sprzedaży i promocji - księgi obiegu dokumentów Plany strategiczne Książki z dziedziny KIO, 33
Metody zbierania informacji: wywiady (interviews) i dyskusje (1) Typy wywiadów - spotkania bezpośrednie - pisemne (lub przy użyciu innych środków) - 'burza mózgów' Cele dokonywania wywiadów Problemy Wskazówki przeprowadzania wywiadów Odtwarzanie danych z wywiadów i dyskusji Wywiady stanowią najpopularniejszą metodę zbierania informacji. W ich dokonywaniu kluczowe znaczenie ma praktyka. KIO, 34
Metody zbierania informacji: cele dokonywania wywiadów (2) zebranie danych o zachowaniu istniejącego systemu zebranie wymagań dot. zamierzonego systemu weryfikacja zrozumienia przez analityka informacji nt. istniejącego systemu i sformułowanych wymagań zebranie informacji umożliwiającej dokonanie analizy kosztów i zysków walidacja aspektów projektowanego rozwiązania nabranie przez użytkowników zaufania do konstrukcji nowo projektowanego systemu (!) KIO, 35
KIO, 36 Inżynieria oprogramowania Metody zbierania informacji: problemy dokonywania wywiadów (3) wywiad z niewłaściwymi ludźmi lub w niewłaściwym czasie błędne pytania i błędne lub nieadekwatne odpowiedzi: brak odpowiedzi; odpowiedź niedokładna; odpowiedź nie na temat; niewłaściwe pytanie; odpowiedź częściowa koncentrowanie się dyskusji na zagadnieniach implementacyjnych zamiast na wymaganiach pomylenie objawów z przyczynami brak umiejętności użytkownika do wyrażenia swoich potrzeb - zmiana zdania przez użytkownika (!) brak zgody pomiędzy wieloma użytkownikami, pracownikami technicznymi, zarządzającymi pojawianie się obustronnego braku sympatii opory przy wywiadzie; typowe obiekcje: Marnujecie tylko czas; Po co tracić czas na to interview? To zagraża mojej pracy; Nie znacie się na tym więc nie możecie nam pomóc; Tego się nie da skomputeryzować; Zawsze tak robiliśmy i było dobrze; Nie chcemy tego systemu
Metody zbierania informacji: wskazówki dla dokonywania wywiadów (4) Przygotuj całościowy plan wywiadu Zapewnij sobie akceptację na jego przeprowadzenie Zaplanuj szczegóły Można skorzystać ze środków automatyzacji, ale nie w nadmiarze Spróbuj osądzić, w jakiej dziedzinie użytkownik jest najbardziej zainteresowany (kompetentny) Spróbuj osądzić, za co użytkownik jest odpowiedzialny Skorzystaj z odpowiedniego podejścia: - wyszukiwania powiązań - alternatywnych punktów widzenia - sondowania - wychwytywania zależności - powtarzania Dokonaj podsumowania wywiadu Przedstaw kopię do akceptacji KIO, 37
Metody zbierania informacji: Kwestionariusze Pytania zamknięte i otwarte Wskazówki konstrukcji kwestionariusza: - Jasne sformułowanie celów - Precyzyjne, nieprzeciwstawne sformułowanie pytań - Unikanie długich pytań, o złożonych odpowiedziach - Sprawdzenie 'działania' kwestionariusza na wzorcowej grupie ankietowanych - Założenie z góry sposobu analizy odpowiedzi - Narzucenie terminu podania odpowiedzi Zalety - niski koszt - nie jest obciążone błędami prowadzącego interview - daje czas do namysłu i odwołania się do dokumentów -umożliwia pytanie kilku pracowników -umożliwia zapytanie większej ilości respondentów -może zapewnić anonimowość Praktyka? KIO, 38
Metody zbierania informacji: Analiza dokumentów Podstawowe pytania dotyczące dokumentów: - jakie zdarzenie inicjuje powstanie dokumentu? - kto generuje dokument? - jak jest on przygotowywany? -skąd brane są dane? - kto korzysta z dokumentu? - do jakich celów dokument jest wykorzystywany? - jak wygląda? - jak jest przechowywany? - jak długo jest przechowywany? - kiedy wprowadzane są poszczególne dane? przez kogo? - znaczenie, zakres i format każdej pozycji danych? - źródło każdej pozycji danych? - wykorzystanie każdej pozycji danych? -kolejność wypełniania? - sprzeczności? starzenie sie? - objętość dokumentu i szybkość wzrostu - postępowanie z kopiami Zalety - sformalizowanie - odzwierciedlenie przepływu informacji KIO, 39
Podstawowe zakres informacji: Inżynieria oprogramowania Metody zbierania informacji: Analiza istniejącego systemu problemy obecnego użytkowania systemu? przyczyny wprowadzania nowego? istniejące oceny? zmiany funkcjonalności? danych? zmiany efektywności? technologii? jakie zmiany spowoduje w otoczeniu nowy system? Zalety - żywy przykład, doświadczenie, możliwość pomiaru,... KIO, 40
Metody zbierania informacji: Próbkowanie Dokonywanie pomiarów prowadzących do określenia reprezentatywnej wartości wybranych parametrów Typowe zastosowanie: dla oszacowań ilościowych KIO, 41
Metody zbierania informacji: Obserwacje Analityk spędza dłuższe okresy czasu obserwując użytkowników w ich normalnych miejscach pracy. Zalety - wychwycenie cech, które mogłyby zostać pominięte - czasem jest jedyną metodą wykonalną praktycznie KIO, 42
Metody zbierania informacji: Prezentacje u dostawców i wizytowanie podobnych instalacji Zalety - informacja o dostępnych na rynku systemach (sprzęt, oprogramowanie); czasem - o systemach pod klucz -możliwość porównań -możliwość znalezienia innych rozwiązań -możliwość wykrycia pominiętych funkcji lub - wymagań przechowywania danych - korzystanie z cudzych doświadczeń - ocena cech systemów KIO, 43
Metody zbierania informacji: Symulowanie punktów widzenia Analityk stawia siebie w pozycji wybranego udziałowca i symuluje (wyobraża sobie) interakcje i oczekiwania względem systemu z jego punktu widzenia. Wymaga to dobrego zidentyfikowania i zrozumienia punktu widzenia różnych udziałowców, a następnie zdefiniowania i udokumentowania wynikających stąd wymagań. Prototypowanie Budujemy nowy produkt, który dotąd nie istniał i jest trudny do wyobrażenia; użytkownicy nie mają wcześniejszego doświadczenia z podobnym produktem ani z technologią proponowaną do jego wytworzenia. Użytkownicy mają problemy w artykułowaniu swoich wymagań, a analitycy mają problemy w zrozumieniu co jest oczekiwane przez użytkowników. Istnieją wątpliwości, czy dane wymaganie jest wykonalne. KIO, 44
Analizowanie wymagań Wstępna analiza polega na przedstawieniu udokumentowanych wymagań udziałowcowi w celu ich sprawdzenia Czy to jest poprawny zapis tego co powiedziałeś? Czy to odzwierciedla to co miałeś na myśli? Czy moja interpretacja jest właściwa? Daje to możliwość dokonania korekty tak, aby usunąć wątpliwości czy wymagania zostały jasno zrozumiane Połączenie wymagań różnych udziałowców i ich analiza wykorzystanie standardowego wzorca dokumentu specyfikacji wymagań systemowych (SWS) analiza pod kątem nadmiarowości, sprzeczności i konfliktów, względnej ważności wymagań, kompletności (brakujących wymagań) wyjaśnienie niejednoznaczności, wypełnienie luk, potwierdzenie przyjętych założeń Zbiorcza analiza: porównanie wymagań z zakresem projektu Czy zebrano wymagania od wszystkich udziałowców? Czy cały, wcześniej określony zakres projektu jest pokryty wymaganiami? Czy wyłączono wymagania leżące poza zakresem? Czy uwzględniono w wymaganiach biznesowy punkt widzenia (cele systemu)? Czy dla wymagań zdefiniowano mierzalne kryteria akceptowalności? KIO, 45
Specyfikacja Wymagań Wymagania systemowe (użytkowe) Dokument Wymagań Systemowych (Użytkownika) Wymagania względem oprogramowania Dokument Wymagań wobec Oprogramowania dokument nieustrukturalizowany dokument SWS notacje modelujące diagramy i specyfikacje strukturalne przypadków użycia specyfikacje formalne KIO, 46
Id_wymag Opis Źródło/ Priorytet/ Uzasadnienie Powiązania Inżynieria oprogramowania Dokument SWS przykładowy szablon specyfikacji wymagania {nazwa wymagania i kategoria} {szczegółowy opis wymagania} {klient, projektant, badania}./ {kluczowe, ważne, mniej ważne}./ {uzasadnienie} {Powiązania z innymi wymaganiami, przede wszystkim funkcjonalnymi} Uwagi {ewentualne uwagi } Id_wymag {nazwa wymagania i kategoria } Opis {szczegółowy opis wymagania} Źródło/ Priorytet/ Uzasadnienie Powiązania {klient, projektant, badania}./ {kluczowe, ważne, mniej ważne}./ {uzasadnienie} {Powiązania z innymi wymaganiami, przede wszystkim funkcjonalnymi} Uwagi {ewentualne uwagi } KIO, 47
Weryfikacja Polega na upewnieniu się, że reprezentacja będąca rezultatem danego etapu rozwoju systemu jest spójna z reprezentacją utworzoną na etapie poprzedzającym (odpowiada na pytanie, czy to co robimy jest realizowane w sposób właściwy) przydatność metod specyfikacji formalnej Walidacja Polega na upewnieniu się, że to co budujemy jest tym o co nam chodziło (odpowiada na pytanie czy robimy właściwą rzecz) można robić dobrze rzeczy bezsensowne!! KIO, 48
Ocena ryzyka Ryzyko = szansa zaistnienia zdarzenia * konsekwencje Inżynieria oprogramowania Pytanie: Co będzie jeżeli dane wymaganie nie będzie spełnione (lub będzie spełnione częściowo)? Odpowiedź na to pytanie daje podstawę do porównania wagi poszczególnych wymagań i ustalenia priorytetów w ich wypełnianiu, w sytuacji ograniczonych zasobów Potrzeba negocjacji KIO, 49
Zarządzania wymaganiami Wymagania podlegają zmianom (zmiany oczekiwań, technologii, celów, itp.) Wymagania zawierają defekty, które muszą być poprawione Wymagania stanowią część konfiguracji systemu i muszą być spójne z pozostałymi elementami tej konfiguracji PROBLEM: jak utrzymać spójność, kompletność zbioru wymagań w ramach cyklu życia systemu? Zarządzanie procesami Zarządzanie zmianami Zarządzanie śladami KIO, 50