Analiza i walidacja wymagań

Slides:



Advertisements
Podobne prezentacje
Jakość w procesie wytwarzania oprogramowania
Advertisements

Modelowanie przypadków użycia
Projektowanie w cyklu życia oprogramowania
Zarządzanie projektem informatycznym
1 / 47 WARSZAWA 2005 Przemysław Siekierko Stanisław Andraszek Rational Unified Process.
Projektowanie Aplikacji Komputerowych
Propozycja metodyki nauczania inżynierii oprogramowania
Jerzy Nawrocki Piotr Pawałowski Krzysztof Pospiech
Na Etapie Inżynierii Wymagań
Organizacja Przedsięwzięć Programistycznych Wykład 7, 27.II.03
Dokumentowanie wymagań w języku XML
Inżynieria oprogramowania Copyright, 2000 © Jerzy R. Nawrocki Wprowadzenie do informatyki.
Inżynieria oprogramowania II Wykład 12 Projekty dyplomowe
Zarządzanie konfiguracją Doskonalenie Procesów Programowych Wykład 6 Copyright, 2001 © Jerzy.
Copyright © Jerzy R. Nawrocki Standardy serii ISO Inżynieria oprogramowania II Wykład.
Copyright © Jerzy R. Nawrocki Kontrola jakości oprogramowania Inżynieria oprogramowania.
Inżynieria Oprogramowania Copyright, 2002 © Jerzy R. Nawrocki Wprowadzenie do informatyki.
J. Nawrocki, Inżynieria oprog. Plan wykładu Praktyki XP Wcześniejsze badania Personal Software Process eXtremme Programming Opis eksperymentu WynikiPodsumowanie.
Copyright © Jerzy R. Nawrocki Zbieranie wymagań Analiza systemów informatycznych Wykład.
Copyright © Jerzy R. Nawrocki Wprowadzenie Analiza systemów informatycznych Wykład.
Inżynieria oprogramowania II Wykład 10 PRINCE2 i TSP
Modelowanie i architektura
Testy akceptacyjne Analiza systemów informatycznych Wykład 9
Modelowanie i język UML
Dokument specyfikacji wymagań
Dyscyplina i zwinność w projektach informatycznych
Dyscyplina i zwinność w projektach informatycznych (cz. 2)
Komputerowe systemy sterowania Copyright, 2006 © Jerzy R. Nawrocki Wprowadzenie do informatyki.
Testowanie oprogramowania
Tomasz Pieciukiewicz Rafał Hryniów
Pozyskiwanie i dokumentowanie wymagań
Jakość systemów informacyjnych (aspekt eksploatacyjny)
Rational Unified Process
Projekt zaliczeniowy z przedmiotu "Inżynieria oprogramowania"
Dalsze elementy metodologii projektowania. Naszym celem jest...
Inżynieria Oprogramowania
Wykład 2 Cykl życia systemu informacyjnego
Projekt i implementacja aplikacji wspomagającej testowanie
C.d. wstępu do tematyki RUP
Adam Gabryś , v1.1,
Microsoft Solution Framework
Programowanie obiektowe – język C++
Dr Karolina Muszyńska Na podst.:
Pomiary procesów programistycznych Copyright, 2002 © Jerzy R. Nawrocki Zarządzanie jakością.
Copyright © Jerzy R. Nawrocki Kontrola jakości oprogramowania Inżynieria oprogramowania.
Treści multimedialne - kodowanie, przetwarzanie, prezentacja Odtwarzanie treści multimedialnych Andrzej Majkowski 1 informatyka +
Projekt realizowany w ramach Software Development Studio (SDS) Wizualne środowisko do tworzenia aplikacji webowych.
Zarządzanie zagrożeniami
1 PROINFO System zarządzania informacją o przedsięwzięciu informatycznym Seminarium dyplomowe 2004 WIiZ Politechnika Poznańska.
ŁUKASZ DZWONKOWSKI Modele zwinne i ekstremalne. Podejście tradycyjne
Proces tworzenia oprogramowania Proces tworzenia oprogramowania jest zbiorem czynności i związanych z nimi wyników, które prowadzą do powstania produktu.
Inżynieria oprogramowania
PROINFO System zarządzania informacją o przedsięwzięciu informatycznym Seminarium dyplomowe 2004 WIiZ Politechnika Poznańska.
Audyt wewnętrzny jako źródło oceny kontroli zarządczej w jednostce
(c) Jerzy Nawrocki Jerzy Nawrocki
Analiza ryzyka Analiza systemów inf. Wykład 14
Agile Manifesto Manifest Zwinnego Wytwarzania Oprogramowania
Copyright © Jerzy R. Nawrocki Team Software Process Inżynieria oprogramowania II Wykład.
Ergonomia procesów informacyjnych
7/1/ Projektowanie Aplikacji Komputerowych Piotr Górczyński Cykl życia systemu.
Innowacyjne metody zarządzania jakością oprogramowania Przeglądy oprogramowania i standard IEEE 1028 Bartosz Michalik
(c) InMoST 2006 Plan szkolenia ▪ Wprowadzenie (9:00-10:30): Czym jest szacowanie? (MO) Systematyczne podejście do planowania (ŁO) Planowanie, a kalendarz.
Inżynieria systemów informacyjnych
Inżynieria oprogramowania
Zarządzanie projektami informatycznymi
Inżynieria Oprogramowania Laboratorium
IEEE SPMP Autor : Tomasz Czwarno
Kontrola jakości Inżynieria oprogramowania II
Zapis prezentacji:

Analiza i walidacja wymagań (c) J.Nawrocki Lecture 5 Analiza systemów informatycznych Wykład 8 Analiza i walidacja wymagań Jerzy.Nawrocki@put.poznan.pl www.cs.put.poznan.pl/jnawrocki/wsb-asi/ Req. Eng. & Project Manag.

Analiza i negocjacja wymagań Walidacja wymagań Agenda Analiza i negocjacja wymagań Walidacja wymagań Szacowanie liczby defektów Introduction XPrince Team Project Lifecycle The Analyst Role The Architect Role The Project Manager Role Scaling up Conclusions J.Nawrocki, Analiza i walidacja

Analiza i negocjacja wymagań Agenda Analiza i negocjacja wymagań Walidacja wymagań Szacowanie liczby defektów Introduction XPrince Team Project Lifecycle The Analyst Role The Architect Role The Project Manager Role Scaling up Conclusions J.Nawrocki, Analiza i walidacja

Klasyfikacja dobrych praktyk Podst. Pośred. Zaaw. 8 6 5 4 3 2 36 - 6 2 1 3 21 - 1 2 4 9 Dokument SRS Zbieranie wymagań Analiza i negocjacja wymag. Opisywanie wymagań Modelowanie systemu Walidacja wymagań Zarządzanie wymaganiami IW dla systemów krytycznych J.Nawrocki, Analiza i walidacja

Zdefiniuj granice systemu Praktyki podstawowe Analiza i negocjacja Zdefiniuj granice systemu System Person 1 Person 2 Institution Device Wymagania dot. procesu Wymagania dot. systemu Wymagania dot. oprogramowania J.Nawrocki, Analiza i walidacja

Zdefiniuj granice systemu Stosuj listy kontrolne do analizy wymagań Praktyki podstawowe Analiza i negocjacja Zdefiniuj granice systemu Stosuj listy kontrolne do analizy wymagań J.Nawrocki, Analiza i walidacja

Przykład listy kontrolnej Analiza granic systemu Czy wymaganie implikuje konieczność podejmowania decyzji w oparciu o niekompletną lub niepewną informację? Czy implementacja wymagania będzie wymagała informacji, która jest poza bazą danych budowanego systemu? Czy wymaganie jest związane z kluczową funkcjonalnością systemu? Czy wymaganie jest związane z funkcjonalnością lub wydajnością zewnętrznego sprzętu? J.Nawrocki, Analiza i walidacja

Inny przykład listy kontrolnej IEEE Std 830-1998 a) Poprawne; b) Jednoznaczne; c) Kompletne; d) Spójne; e) Z informacją o ważności i stabilności; f) Weryfikowalne; g) Modyfikowalne; h) Umożliwiające śledzenie wpływu zmian. J.Nawrocki, Analiza i walidacja

Lista kontrolna dla przypadków użycia Czy jest uzgodniona klarowna wizja systemu? Czy są widoczne granice systemu? Czy jest jasna charakterystyka użytkowników końcowych? Czy wszystkie przypadki użycia z poziomu użytkownika mają cechy istotnych dla niego transakcji? Czy każdy przypadek użycia ma kompletny pojedynczy cel? Czy jego nazwa jest jasna i odzwierciedla cel? Czy alternatywy tworzą zbiór wyczerpujący? Czy przypadki użycia opisują jedynie zachowanie? Czy upiększenia są właściwie użyte? Czy warunki są wykrywalne? J.Nawrocki, Analiza i walidacja

Zdefiniuj granice systemu Stosuj listy kontrolne do analizy wymagań Praktyki podstawowe Analiza i negocjacja Zdefiniuj granice systemu Stosuj listy kontrolne do analizy wymagań Zapewnij narzędzia wspomagające negocjacje Planując przygotuj się na konflikty i ich rozwiązywanie Przypisz priorytety wymaganiom J.Nawrocki, Analiza i walidacja

Klasyfikuj wymagania korzystając z podejścia wielowymiarowego Praktyki pośrednie Analiza i negocjacja Klasyfikuj wymagania korzystając z podejścia wielowymiarowego System, User interface, Database, Communications, Security J.Nawrocki, Analiza i walidacja

Klasyfikuj wymagania korzystając z podejścia wielowymiarowego Praktyki pośrednie Analiza i negocjacja Klasyfikuj wymagania korzystając z podejścia wielowymiarowego System, User interface, Database, Communications, Security Korzystaj z macierzy interakcji, aby wykryć konflikty i nakładanie się wymagań. J.Nawrocki, Analiza i walidacja

Macierz interakcji W1 W2 W3 W4 W5 W1 W2 W3 W4 W5 J.Nawrocki, Analiza i walidacja

Macierz interakcji 0 – brak problemu 1 – konflikt W1 W2 W3 W4 W5 W1 W2 J.Nawrocki, Analiza i walidacja

Macierz interakcji 0 – brak problemu 1 – konflikt 1 W1 W2 W3 W4 W5 W1 J.Nawrocki, Analiza i walidacja

Macierz interakcji 0 – brak problemu 1 – konflikt 1 W1 W2 W3 W4 W5 W1 J.Nawrocki, Analiza i walidacja

Macierz interakcji 0 – brak problemu 1 – konflikt 100 – nakładanie się W1 W2 W3 W4 W5 1 W1 W2 W3 W4 W5 J.Nawrocki, Analiza i walidacja

Macierz interakcji 0 – brak problemu 1 – konflikt 100 – nakładanie się W1 W2 W3 W4 W5 1 100 W1 W2 W3 W4 W5 J.Nawrocki, Analiza i walidacja

Macierz interakcji 0 – brak problemu 1 – konflikt 100 – nakładanie się W1 W2 W3 W4 W5 1 100 W1 W2 W3 W4 W5 J.Nawrocki, Analiza i walidacja

Macierz interakcji 0 – brak problemu 1 – konflikt 100 – nakładanie się W1 W2 W3 W4 W5 1 100 102 1 201 101 W1 W2 W3 W4 W5 J.Nawrocki, Analiza i walidacja

Macierz interakcji 0 – brak problemu 1 – konflikt 100 – nakładanie się W1 W2 W3 W4 W5 1 100 102 1 201 101 W1 W2 W3 W4 W5 J.Nawrocki, Analiza i walidacja

Praktyki zaawansowane Analiza i negocjacja Oceń ryzyko wymagań Wydajność, bezpieczeństwo, proces tworzenia oprogramowania, technologia implementacji, baza danych, harmonogram, stabilność. J.Nawrocki, Analiza i walidacja

Walidacja wymagań Agenda Analiza i negocjacja wymagań Szacowanie liczby defektów Introduction XPrince Team Project Lifecycle The Analyst Role The Architect Role The Project Manager Role Scaling up Conclusions J.Nawrocki, Analiza i walidacja

Klasyfikacja dobrych praktyk Podst. Pośred. Zaaw. 8 6 5 4 3 2 36 - 6 2 1 3 21 - 1 2 4 9 Dokument SRS Zbieranie wymagań Analiza i negocjacja wymag. Opisywanie wymagań Modelowanie systemu Walidacja wymagań Zarządzanie wymaganiami IW dla systemów krytycznych J.Nawrocki, Analiza i walidacja

 Praktyki podstawowe Walidacja Sprawdź, czy dokument specyfikacji wymagań jest zgodny z przyjętym standardem Zorganizuj formalną inspekcję wymagań  J.Nawrocki, Analiza i walidacja

Inspekcja (inspection) = Najbardziej sformalizowana postać przeglądu Przegląd (review) = Analiza artefaktu (np.kodu, dokumentu) realizowana przez grupę osób. Inspekcja (inspection) = Najbardziej sformalizowana postać przeglądu Artefakt J.Nawrocki, Analiza i walidacja

Przekazywanie informacji Rola przeglądów Zapewnianie jakości Przekazywanie informacji J.Nawrocki, Analiza i walidacja

Inspekcje Fagana Sesja przeglądu Projektant Implementator Moderator Tester J.Nawrocki, Analiza i walidacja

1. Omówienie (cały zespół) 2. Przygot. (indywidualnie) Inspekcje Fagana Projektant Implem. Moderator Tester Review session 1. Omówienie (cały zespół) 2. Przygot. (indywidualnie) 3. Inspekcja (cały zespół) 4. Naprawa 5. Sprawdzenie J.Nawrocki, Analiza i walidacja

Specyfikacje zewnętrzne (funkcje) Specyfikacje wewnętrzne (moduł) - I0 Inspekcje Fagana Cykl życia Specyfikacje zewnętrzne (funkcje) Specyfikacje wewnętrzne (moduł) - I0 Specyfikacje logiki przetw - I1 inspek projek Projekt Kodowanie (logika) - I2 inspek kodu Testowanie jednostkowe Kod Test Test funkcji (zewn.), składnika, systemu J.Nawrocki, Analiza i walidacja

Oszczędności (godz/KLOC): I1: 94 I2 : 51 I3 : -20 Inspekcje Fagana Design Code Unit test I1 I2 I3 Oszczędności (godz/KLOC): I1: 94 I2 : 51 I3 : -20 J.Nawrocki, Analiza i walidacja

Omówienie (zespół) 500 niepotrzebne Przygotowanie (indyw.) 100 125 Inspekcje Fagana Prędkość (loc/h) I1 I2 Omówienie (zespół) 500 niepotrzebne Przygotowanie (indyw.) 100 125 Inspekcja (zespół) 130 150 Naprawa 50 60 Sprawdzenie - - Spotkanie inspekcyjne <= 2 godz 1 - 2 spotkania na dzień J.Nawrocki, Analiza i walidacja

Czy wszystkie stałe są zdefiniowane? Inspekcje Fagana Lista kontrolna dla inspekcji projektu Czy wszystkie stałe są zdefiniowane? Czy w trakcie manipulacji kolejką może wystąpić przerwanie? Jeśli tak, to czy kolejka jest ujęta w rejon krytyczny? Czy rejestry są odtwarzane przy wyjściu? Czy wszystkie liczniki są odpowiednio inicjowane (0 lub 1)? Czy są literały numeryczne, które powinny być zastąpione stałymi symbolicznymi? Czy wszystkie bloki na schemacie są potrzebne Missing Wr Ex J.Nawrocki, Analiza i walidacja

Akceptacja. Żadne modyfikacje nie są konieczne. Decyzja Akceptacja. Żadne modyfikacje nie są konieczne. Akceptacja warunkowa. Są pewne defekty, ale dodatkowa inspekcja nie jest potrzebna (kierownik projektu sprawdzi, czy wprowadzono poprawki). Odrzucenie. Są poważne defekty i będzie potrzebna dodatkowa inspekcja. J.Nawrocki, Analiza i walidacja

 Praktyki podstawowe Walidacja Sprawdź, czy dokument specyfikacji wymagań jest zgodny z przyjętym standardem Zorganizuj formalną specyfikację wymagań  Wykorzystuj w przeglądach wymagań ekspertów z różnych dziedzin Opracuj listy kontrolne dla walidacji J.Nawrocki, Analiza i walidacja

Inny przykład listy kontrolnej IEEE Std 830-1998 a) Poprawne; b) Jednoznaczne; c) Kompletne; d) Spójne; e) Z informacją o ważności i stabilności; f) Weryfikowalne; g) Modyfikowalne; h) Umożliwiające śledzenie wpływu zmian. J.Nawrocki, Analiza i walidacja

 Praktyki pośrednie Walidacja Wykorzystuj prototypy do walidacji wymagań  J.Nawrocki, Analiza i walidacja

Ekran prototypu wygenerowanego przez UC Workbench J.Nawrocki, Analiza i walidacja

 Praktyki pośrednie Walidacja Wykorzystuj prototypy do walidacji wymagań Napisz roboczą wersję podręcznika użytkownika Zaproponuj przypadki testowe dotyczące wymagań  J.Nawrocki, Analiza i walidacja

Praktyki zaawansowane Walidacja Parafrazuj modele systemu  J.Nawrocki, Analiza i walidacja

Szacowanie liczby defektów Agenda Analiza i negocjacja wymagań Walidacja wymagań Szacowanie liczby defektów Introduction XPrince Team Project Lifecycle The Analyst Role The Architect Role The Project Manager Role Scaling up Conclusions J.Nawrocki, Analiza i walidacja

Capture-Recapture Ile ryb jest w stawie? J.Nawrocki, Analiza i walidacja

Capture-Recapture 1 Złap próbkę ryb J.Nawrocki, Analiza i walidacja

Capture-Recapture 1 Złap próbkę ryb 2 Oznacz je J.Nawrocki, Analiza i walidacja

Capture-Recapture 1 Złap próbkę ryb 2 Oznacz je 3 Wypuść je J.Nawrocki, Analiza i walidacja

4 Złap jeszcze jedną grupę Capture-Recapture 1 Złap próbkę ryb 2 Oznacz je 3 Wypuść je 4 Złap jeszcze jedną grupę J.Nawrocki, Analiza i walidacja

4 Złap jeszcze jedną grupę 5 Ile oznakowanych? Capture-Recapture 1 Złap próbkę ryb 2 Oznacz je 3 Wypuść je 4 Złap jeszcze jedną grupę 5 Ile oznakowanych? J.Nawrocki, Analiza i walidacja

20 30 5 Capture-Recapture 1 Złap próbkę ryb 2 Oznacz je 3 Wypuść je 4 Złap jeszcze jedną grupę 5 Ile oznakowanych? 20 30 5 J.Nawrocki, Analiza i walidacja

20 30 5 Capture-Recapture 1 Złap próbkę ryb Total = 2 Oznacz je 20 * 30 / 5 = 120 1 Złap próbkę ryb 2 Oznacz je 3 Wypuść je 4 Złap jeszcze jedną grupę 5 Ile oznakowanych? 20 30 5 J.Nawrocki, Analiza i walidacja

Liczba defektów = A * B / C Capture-Recapture Artefakt A B C Liczba defektów = A * B / C If C = 0 ... J.Nawrocki, Analiza i walidacja

Więcej niż 2 recenzentów Capture-Recapture Więcej niż 2 recenzentów B A Znalazł najwięcej unikatowych defektów Pozostali Liczba defektów = A * B / C J.Nawrocki, Analiza i walidacja

At last! Podsumowanie Analiza wymagań: Listy kontrolne Negocjacja wymagań Walidacja wymagań: Przeglądy Capture-Recapture Prototypy typu mockup J.Nawrocki, Analiza i walidacja

? Pytania? J.Nawrocki, Analiza i walidacja (c) J.Nawrocki Lecture 5 Req. Eng. & Project Manag.

3. Czego ważnego dowiedziałeś się na wykładzie? 4. Co poprawić i jak? Ocena jakości 1. Wrażenie ogólne? (1 - 6) 2. Tempo wykładu? 3. Czego ważnego dowiedziałeś się na wykładzie? 4. Co poprawić i jak? J.Nawrocki, Analiza i walidacja