plik


ÿþIn|ynieria oprogramowania wykBad 9 Zasady analizowania wymagaD 1 Analiza wymagaD - wstp nð stanowi pomost midzy in|ynieri systemów (analiza, modelowanie, zarzdzanie wymaganiami stawianymi systemowi) a projektowaniem oprogramowania nð podmioty biorce udziaB w analizie wymagaD: ¡ð klienci ’! powinni precyzyjnie okre[la swoje oczekiwania wobec programu ¡ð twórcy (analitycy)’! przyjmuj uwagi klienta, analizuj je, rozwizuj problemy, negocjuj 2/23 Wyniki analizy wymagaD nð okre[lenie roli oprogramowania (bycie produktem - przetwarzanie danych lub dostarczanie produktu  kontrola, sterowanie, tworzenie) nð okre[lenie funkcjonalno[ci programu nð okre[lenie danych przetwarzanych przez program nð okre[lenie wyników dziaBania programu nð wspomaganie jako[ci produktu nð budowa modeli: danych, architektury, interfejsów 3/23 Czynno[ci analizy wymagaD nð rozpoznanie problemu ’! poznanie aspektu problemu z punktu widzenia klienta  u|ytkownika, poprzedza je zapoznanie si ze specyfikacj systemu i planem przedsiwzicia, nð ocenianie problemu, szukanie rozwizania ’! okre[lenie kontekstu problemu, ustalenie rodzaju przepBywu danych, funkcji systemu, zachowania w konkretnym przypadku, sposobu komunikowania si, co mo|e wspomóc uzyskanie rozwizania nð modelowanie ’! podstawa projektowania oprogramowania i specyfikowania, tworzenie modelu systemu uBatwiajcego analiz sterowania, przepBywu i przetwarzania danych, zachowania programu nð specyfikowanie, zastpowane czasem prototypowaniem nð przegld 4/23 Ustalanie wymagaD dla oprogramowania  wiedza ogólna nð dla kogo przeznaczone ma by nowe rozwizanie nð kto bdzie go u|ywaB nð korzy[ci wynikajce z wprowadzenia nowego rozwizania nð czy problem zgBaszany przez klienta mo|na rozwiza inaczej 5/23 Ustalanie wymagaD dla oprogramowania  lepsze poznanie istoty problemu nð okre[lenie pojcia: dobry wynik dziaBania programu nð w jakich sytuacjach / problemach mo|e mie zastosowanie nowego rozwizania nð [rodowisko dziaBania nowego produktu nð czy znane s wymagania zwizane z efektywno[ci produktu (efektywno[  skuteczno[, sprawno[, wydajno[: efektywno[ czasowa, zu|ycie zasobów, itp..) nð czy znane s ograniczenia w sposobie funkcjonowania produktu (dane wej[ciowe i wyj[ciowe, [rodowisko pracy oraz sprzt, specyficzne wymagania u|ytkowników) 6/23 Ustalanie wymagaD dla oprogramowania  efekty spotkania z klientem nð czy klient jest osob kompetentn do udzielania informacji na poruszane tematy, a odpowiedzi s wi|ce nð czy s inne osoby potrafice udzieli dodatkowych informacji nð czy s inne pytania które powinny zosta dodatkowo postawione 7/23 Techniki uBatwiajce specyfikowanie aplikacji - FAST nð FAST  facilitated application specification techniques nð techniki FAST nastawione s na [cisB wspóBprac twórców i klientów (a czsto bywa odwrotnie, obie strony traktuj si jak przeciwnicy) nð zespoBy zBo|one z twórców i klientów zajmuj si identyfikacj problemów i wspólnie szukaj rozwizaD, tworz specyfikacj wymagaD 8/23 GBówne cechy spotkaD wg FAST nð spotkania na neutralnym gruncie nð ustalone wcze[niej reguBy spotkaD nð swobodny styl wymiany pogldów nð dyskusja na wszystkie istotne tematy nð cel spotkania: identyfikowanie problemów, szukanie rozwizaD, negocjacja dalszych mo|liwo[ci, specyfikacja wymagaD 9/23 Jako[ rozwijania funkcji QFD nð QFD  quality function deployment nð jest to technika z kategorii zarzdzania jako[ci, wspomagajca tBumaczenie potrzeb klienta na techniczne wymagania dla oprogramowania nð celem jest jak najlepsze zrozumienie wymagaD klienta nð technika ta zostaBa opracowana w Japonii, pierwsze zastosowanie: Mitsubishi Heavy Industries (lata 70. XX. wieku) 10/23 Wymagania w technice QFD* nð wymagania normalne ’! wyra|one przez klienta podczas spotkaD z analitykami, speBnienie ich oznacza satysfakcj klienta (funkcje produktu, interfejsy, efektywno[) nð wymagania oczekiwane ’! takie o których klient nie wspomniaB, gdy| uwa|aB je za oczywiste (Batwo[ obsBugi i instalacji, poprawno[ dziaBania), niespeBnienie ich oznacza niezadowolenie klienta nð wymagania ekscytujce ’! ponad oczekiwania klienta, speBnienie ich oznacza du|e zadowolenie klienta, np. dodatkowe mo|liwo[ci konfiguracyjne (dostosowywanie interfejsu, itp.) * R. Zultner:  Quality Function Deployment for Software: Satysfying customers , American Programmer, 1992 11/23 Przypadki u|ycia nð zbiór scenariuszy, zbiór cigów zdarzeD wykonywanych przez system, opisy sposobów u|ycia systemu nð sporzdzane w celu uBatwienia zdefiniowania wymagaD stawianych oprogramowaniu nð pierwszymi krokami s identyfikacja osób i sprztu korzystajcego z systemu nð stanowi opis dziaBania osoby w interakcji z systemem nð mo|e zawiera ograniczenia czasowe lub inne ograniczenia nð przypadki u|ycia mog by ró|nie oceniane przez u|ytkowników, mo|na obliczy [redni priorytet ka|dego przypadku u|ycia stosujc go w modelu przyrostowym proc. wytw. do okre[lania funkcji systemu przygotowywanych w 1. kolejno[ci nð realizacja: np. diagram przypadków u|ycia (UML) 12/23 Zasady analizowania oprogramowania nð identyfikacja dziedziny problemu nð okre[lenie funkcjonalno[ci oprogramowania nð okre[lenie zachowania programu w zale|no[ci od czynników zewntrznych nð okre[lenie struktury warstwowej/hierarchicznej systemu zawierajce modele informacji, funkcji i zachowaD systemu nð kierunek analizy: od cech najistotniejszych do szczegóBów 13/23 ReguBy analizowania wymagaD * nð zrozumienie problemu (zapobieganie sytuacji: [wietny program ale rozwizuje nie to co potrzeba ) nð zastosowanie prototypów - uBatwia ocen przez u|ytkownika nð zapamitanie zródBa i uzasadnienia ka|dego wymagania nð ocena wymagaD z ró|nych punktów widzenia, zapobiega powstaniu sprzeczno[ci i przeoczeD nð uporzdkowanie wymagaD wg wa|no[ci nð eliminacja niejasno[ci, realizowana poprzez wykonywanie formalnych przegldów technicznych * A. Davis:  201 principles of software development , McGraw-Hill 1995 14/23 Dziedzina informacyjna nð jest podstawow czynno[ci analizy wymagaD nð obejmuje: ¡ð model danych - obiekty danych oraz zdarzenia zwizane z ich przetwarzaniem, nale|y zidentyfikowa istniejce midzy nimi zale|no[ci ¡ð przepByw informacji  okre[lenie zmian dotyczcych danych i zdarzeD przemieszczajcymi si midzy ró|nymi cz[ciami systemu ¡ð struktur informacji  organizacja elementów danych i zdarzeD (np. struktura drzewiasta, tablica itp.), zwizki midzy elementami struktury, zapis informacji w strukturach 15/23 Modelowanie nð tworzenie modeli uBatwia zrozumienie funkcjonowanie projektowanego obiektu nð model oprogramowania musi przedstawia przetwarzane informacje, funkcjonalno[ci zwizane z przetwarzaniem danych i zachowanie systemu podczas przetwarzania danych nð modelowanie obejmuje ¡ð model funkcji ’! pobieranie, przetwarzanie i udostpnianie danych, tworzone od prostych modeli kontekstowych do bardziej szczegóBowych ¡ð model zachowaD ’! opis reakcji na zdarzenia, opis mo|liwych stanów i zdarzeD mogcych prowadzi do zmian stanów 16/23 Dzielenie nð zalecane do lepszej obsBugi du|ych skomplikowanych problemów nð pierwszym krokiem jest utworzenie hierarchicznej prezentacji funkcji lub dziedziny informacyjnej nð w kolejnych krokach wykonywany jest podziaB najwy|szego elementu: ¡ð przemieszczajc si w dóB hierarchii (zwikszanie szczegóBowo[ci), lub ¡ð przemieszczajc si w bok (pozostajc na jednym poziomie) i dekomponujc problem 17/23 Prototypowanie nð wykonanie prototypu mo|e pomóc w okre[leniu wymagaD nð prototyp mo|na rozwija i zmienia nð udoskonalony prototyp mo|e sta si finaln wersj oprogramowania nð prototyp podlega ocenie przez klienta ale tak|e przez twórców programu nð typy prototypów ¡ð zamknite ’! jednokrotnego u|ycia, wykorzystywany do ogólnego przedstawienia wymagaD, potem niepotrzebny, nowa wersja tworzona innymi [rodkami ¡ð otwarte ’! wielokrotnego u|ycia, stosowany równie| na etapach projektowania i implementacji, wstpna wersja produktu finalnego 18/23 Wybór prototypu (1) nð prototyp zaleca si do zBo|onych aplikacji, u|ywajcych niebanalnych algorytmów i zaawansowanych metod przetwarzania danych, cechujcych si intensywn komunikacj z u|ytkownikiem nð je|eli przygotowanie prototypu wymaga napisania du|ej ilo[ci kodu, to prototypowanie nie jest zalecane nð czasem wykonywany jest najpierw podziaB na mniejsze moduBy i wykonywane s ich prototypy 19/23 Wybór prototypu (2) * Prototyp Prototyp Konieczna jednokrotnego wielokrotnego dodatkowa Pytanie u|ycia u|ycia analiza Czy ustalono rodzaj i zastosowanie tak tak nie systemu? tak tak nie Czy problem mo|na modelowa? tak/nie tak/nie tak Czy klient jest pewny podstawowych wymagaD stawianych systemowi? Czy wymagania s znane i stabilne? nie tak tak Czy wymagania s niejasne? tak nie tak Czy w wymaganiach wystpuj tak nie tak sprzeczno[ci? * S. Andriole:  Rapid application prototyping , QED 1992 20/23 Specyfikowanie wymagaD  zasady * nð oddzielenie spojrzenia abstrakcyjnego na funkcje systemu od szczegóBów implementacji nð okre[lenie modelu oczekiwanego zachowania systemu (dane i reakcje na zdarzenia) nð kontekst dziaBania programu, sposób komunikacji z innymi elementami systemu nð [rodowisko aplikacji nð przygotowanie modelu opisujcego dziaBanie widziane oczami u|ytkownika nð specyfikacja odporna na przeoczenia i Batwa do uzupeBniania nð mo|liwo[ Batwej zmiany specyfikacji * R. Balzer, N. Goodman:  Principles of good specification and their implications for specification languages , Addison-Wesley 1986 21/23 Przegld specyfikacji nð specyfikacja jest podstaw pózniejszych prac, dlatego musi by wykonana z nale|yt staranno[ci nð klienci i twórcy powinni dokona przegldu specyfikacji nð nale|y sprawdzi kompletno[ i spójno[ specyfikacji, dokBadno[ opisu funkcji i zachowaD, dziedziny informacyjnej nð po wykonaniu przegldu nastpuje akceptacja specyfikacji nð mo|liwe s dalsze zmiany w specyfikacji, jednak mog one prowadzi do zmiany kosztów i harmonogramu realizacji przedsiwzicia 22/23 Dzikuj za uwag zródBo:  Praktyczne podej[cie do in|ynierii oprogramowania , R.S. Pressman 25

Wyszukiwarka

Podobne podstrony:
io w5 analiza i zarz ryzykiem
Zakres nowelizacji norm cementowych PN EN Analiza wymagań oraz warunków wykorzystania w technol
Etapy analizy wymagan
IO wyk3 wymagania v2 2
Analiza Matematyczna 2 Zadania
analiza
amd102 io pl09
ANALIZA KOMPUTEROWA SYSTEMÓW POMIAROWYCH — MSE
Analiza stat ścianki szczelnej
Analiza 1
Analiza?N Ocena dzialan na rzecz?zpieczenstwa energetycznego dostawy gazu listopad 09
java io InvalidClassException
Analizowanie działania układów mikroprocesorowych
Analiza samobójstw w materiale sekcyjnym Zakładu Medycyny Sądowej AMB w latach 1990 2003
Elementy wymagan organizacyjne
Komunikacja w świetle wymagań normy ISO 9001(1)
MicrosoftWord Wymaganiatechniczneorazzasadykształtowaniaprofilupodłużnegoipoprzecznegobudowlipodziem

więcej podobnych podstron