Syllabus. REQB Certyfikowany specjalista inżynierii wymagań. Poziom podstawowy

Transkrypt

1 Syllabus REQB Certyfikowany specjalista inżynierii wymagań 1 Grudnia 2010 Prawa autorskie do tej edycji syllabusa dla wszystkich języków należą do Global Association for Software Quality, gasq

2 Podsumowanie zmian Wersja Data Komentarz PIerwsza wersja syllabusa; stworzenie podstawowej struktury syllabusa Rozszerzenie wersji Dalsze rozszerzenie i rewizja wersji Rewizja wersji Rewizja wersji Kompletnie zrewidowana wersja Wersja zrewidowana dla przeglądu Wersja Alpha Wersja Beta Wydanie Zaktualizowana wersja Zaktualizowana wersja PL Tłumaczenie wersji 1.2 na język polski Prawa autorskie do tego syllabusa dla wszystkich języków należą do Global Association for Software Quality, gasq 2

3 Nadrzędna idea Głównym tematem tego syllabusa jest ciągle rosnąca złożonośd oprogramowania i nasza zależnośd od niego. W rezultacie pojawia się wysoki poziom zależności od braku błędów w oprogramowaniu. Requirements Engineering Qualifications Board (REQB) postanowił zatem stworzyd jednolite międzynarodowe standardy w dziedzinie inżynierii wymagao. Standardy są jednak jak języki - tylko wtedy, gdy je zrozumiesz, możesz pracowad efektywnie. Aby stworzyd taki jednolity język w tak ważnej dziedzinie, jak inżynieria wymagao, międzynarodowi eksperci zebrali się w REQB i opracowali niniejszy syllabus. Tłumaczenie Oryginalna wersja syllabusa została przetłumaczona przez zespół gasq.pl oraz testerzy.pl w składzie: Michał Figarski, Dariusz Paczewski, Radosław Smilgin, Karolina Zmitrowicz. 3

4 1. Spis treści Wprowadzenie Podstawy Wymaganie Standardy i normy Procedury i procesy Modele procesowe Proces inżynierii wymagao Zarządzanie projektem i zarządzanie ryzykiem Zarządzanie projektem Zarządzanie ryzykiem Odpowiedzialności i role Podstawowe role Zadania w inżynierii wymagao Identyfikacja wymagao Klient Wizja i cele projektu Identyfikacja interesariuszy Techniki identyfikacji wymagao Wymagania funkcjonalne i niefunkcjonalne Opis wymagao Specyfikacja wymagao Specyfikacja Procedura Formalizacja Jakośd Wymagao Analiza wymagao Wymagania i rozwiązania

5 7.2. Metody i Techniki Analiza zorientowana obiektowo Estymacja Kosztów Priorytetyzacja Akceptacja wymagao Śledzenie wymagao Śledzenie wymagao w projekcie Zarządzanie zmianą Metryki Zapewnienie jakości Czynniki sukcesu Zapewnienie jakości poprzez testowalnośd Narzędzia Zalety narzędzi Kategorie narzędzi Literatura

6 Wprowadzenie Cel syllabusa Niniejszy syllabus definiuje poziom podstawowy (Foundation Level) programu szkolenia umożliwiającego zostanie certyfikowanym specjalistą inżynierii wymagao REQB (w skrócie CPRE - Certified Professional for Requirements Engineering). Syllabus ten został opracowany przez REQB we współpracy z Global Association for Software Quality. Syllabus ma służyd jako podstawa dla organizatorów szkoleo, którzy chcieliby pozyskad akredytację trenerską. Wszystkie obszary niniejszego syllabusa muszą byd odpowiednio włączone do materiałów szkoleniowych. Syllabus powinien jednak również służyd jako przygotowanie do certyfikacji. Wszystkie obszary wymienione tutaj są zatem istotne dla egzaminu, do którego można podchodzid albo po ukooczeniu akredytowanych kursów, albo podczas egzaminów otwartych. Certyfikacja Egzamin na certyfikowanego specjalistę inżynierii wymagao odbywa się na podstawie niniejszego syllabusa, dlatego wszystkie sekcje syllabusa mogą podlegad weryfikacji. Pytania egzaminacyjne muszą byd rozdzielone na poszczególne sekcje. Jedno pytanie może odnosid się do kilku sekcji syllabusa. Format egzaminu to test jednokrotnego wyboru. Do egzaminu można podejśd po uczestnictwie w akredytowanym kursie lub w bez wcześniejszego kursu podczas otwartych egzaminów. Szczegółowe informacje dotyczące terminów egzaminów można znaleźd na stronie internetowej gasq ( lub na stronie internetowej REQB ( Akredytacja Dostawcy kursu na certyfikowanego specjalistę inżynierii wymagao REQB muszą byd akredytowani przez Global Association for Software Quality. Eksperci GASQ dokonują przeglądu dokumentacji szkoleniowej pod kątem zgodności z syllabusem. Kurs akredytowany musi zostad uznany za zgodny z syllabusem. Na zakooczenie kursu prowadzonego na podstawie certyfikowanych materiałów może zostad przeprowadzony oficjalny egzamin na certyfikowanego specjalistę inżynierii wymagao (egzamin CPRE). Egzamin jest 6

7 przeprowadzany przez niezależny instytut certyfikacji (zgodnie z zasadami normy ISO 17024). Akredytowane ośrodki szkoleniowe są identyfikowane poprzez oficjalne logo akredytowanego dostawcy szkoleo REQB. Międzynarodowość Niniejszy syllabus został opracowany we współpracy grupy międzynarodowych ekspertów,. dlatego też jego zawartośd może byd postrzegana jako międzynarodowy standard. Tym samym syllabus umożliwia szkolenie i egzaminowanie na arenie międzynarodowej na jednakowym poziomie. Poziomy K Syllabus ten został podzielony na różne poziomy K. Pozwala to kandydatowi rozpoznad poziom wymaganej wiedzy każdego punktu. W obecnym syllabusie istnieją 3 K-poziomy: K1 zapamiętaj, rozpoznaj, przypomnij K2 zrozum, wyjaśnij, podaj powód, porównaj, sklasyfikuj, podsumuj K3 zastosuj w konkretnej sytuacji 7

8 1. Podstawy Cele nauczania Czym jest wymaganie? Jakie jest znaczenie i cel wymagao? Jak można sklasyfikowad wymagania? Jakie istnieją typy wymagao? Jakie problemy pojawiają się przy okazji wymagao? Jakie koncepcje są ważne w powiązaniu z wymaganiami? Jaka jest różnica pomiędzy Zarządzaniem Wymaganiami a Inżynierią Wymagao? Jakie istotne normy i standardy wiążą się z wymaganiami? Dlaczego zarządzanie wymaganiami jest ważne? 1.1. Wymaganie Definicja tego, co jest rozumiane pod pojęciem Wymaganie (K1) Słownik: IEEE : Wymaganie to warunek lub umiejętnośd potrzebna użytkownikowi do rozwiązania problemu lub osiągnięcia celu. Jakie jest znaczenie i cel wymagao? (K2) Podstawa dla oceny, planowania, przeprowadzania i monitorowania czynności projektowych Oczekiwania klienta Składnik umów, zamówieo, planów projektowych Ustanawianie granic systemu, zakresu dostawy, umownych usług serwisowych 8

9 Klasyfikacja wymagao (zgodnie z Ebert05) (K 2) Wymagania dzielimy na wymagania procesowe i wymagania produktowe. Wymagania procesowe: koszty, marketing, czas przetwarzania, sprzedaż, dystrybucja, organizacja, dokumentacja. Opisują potrzeby i ograniczenia procesów biznesowych. Wymagania produktowe składają się z funkcjonalnych i niefunkcjonalnych wymagao produktowych. Oba rodzaje mogą byd postrzegane z punktu widzenia użytkownika (zewnętrzne) lub klienta oraz z punktu widzenia dewelopera (wewnętrzne). Funkcjonalne wymagania produktowe z punktu widzenia użytkownika to: interfejs użytkownika (UI), aplikacje, usługi. Funkcjonalne wymagania produktowe z punktu widzenia klienta to: interfejs użytkownika (UI), aplikacje, usługi. Uwaga: Użytkownik i klient mogą byd różnymi osobami! Funkcjonalne wymagania produktowe z punktu widzenia dewelopera to: architektura, zasilanie, rozkład obciążenia. Wymagania funkcjonalne opisują funkcje systemu. Niefunkcjonalne wymagania produktowe z punktu widzenia użytkownika to: niezawodnośd, wydajnośd, użytecznośd. Niefunkcjonalne wymagania produktowe z punktu widzenia klienta to: niezawodnośd, wydajnośd, użytecznośd. Niefunkcjonalne wymagania produktowe z punktu widzenia dewelopera to: testowalnośd, utrzymanie, narzędzia. Wymagania niefunkcjonalne opisują atrybuty jakościowe systemu. 9

10 Typy wymagao: wymagania klienta, wymagania systemowe lub też specyficzne dla danego rozwiązania, wymagania produktowe/komponentowe. Problemy związane z wymaganiami (K2): Niejasne cele Problemy komunikacyjne Bariery językowe Bariery wiedzy Ogólnikowe sformułowania Zbyt formalne określenia Dwuznaczne, nadmiernie specyfikowane, niejasne, niemożliwe, sprzeczne sformułowania Niestabilnośd wymagao Zła jakośd wymagao Zbytnie ozłocenie Niewystarczające zaangażowanie użytkowników Pominięte klasy użytkownika Nieprecyzyjne planowanie Minimalna specyfikacja Kryteria jakościowe dla wymagao (według Wiegers05): (K2) 1. Każde wymaganie musi byd kompletne, poprawne, wykonalne, niezbędne, spriorytetyzowane, jednoznaczne, weryfikowalne 2. Specyfikacja wymagao musi byd kompletna, spójna, modyfikowalna i umożliwiająca śledzenie zmian Dla firm szkoleniowych: wyjaśnid poszczególne kryteria jakościowe. Rozwiązanie (K1) Rozwiązanie jest implementacją wymagao. Zobowiązanie (K1) Zobowiązanie jest poziomem zobligowania się do wykonania czegoś. 10

11 Definiowanie zobowiązania poprzez słowa kluczowe. Dla firm szkoleniowych: wyjaśnid słowa kluczowe. Obserwacja aspektów prawnych, szczególnie na okolicznośd usterek. Usterka (K1) Odstępstwo aktualnego stanu od oczekiwanego stanu. Priorytety wymagao (K1) Ocena ważności/pilności. Krytycznośd wymagao (K1) Ocena ryzyka powiązanego z wymaganiem poprzez ocenę szkód w przypadku niespełnienia wymagania. Walidacja (K1) Proces potwierdzania, że specyfikacja danej fazy lub cały system spełnia wymagania klienta. Weryfikacja (K1) Porównanie pośredniego produktu z jego specyfikacją. Weryfikacja jest więc ustaleniem, czy oprogramowanie zostało przygotowane poprawnie i zgodnie ze specyfikacją przygotowaną w poprzednich fazach. Rozgraniczenie pomiędzy zarządzaniem a inżynierią wymagao. (K2) Zarządzanie Wymaganiami obejmuje procesy służące identyfikacji i zarządzaniu wymaganiami. Inżynieria wymagao zawiera podstawowe umiejętności inżynierskie. Dla firm szkoleniowych: rozwinąd opisy poszczególnych obszarów. 11

12 1.2. Standardy i normy ISO 9000: Wymagania w stosunku do systemu zarządzania jakością. ISO 9126: Zdefiniowana podstawowa koncepcja Systemów Zarządzania Jakością (ang. Quality Management System, QMS) Koncepcja niezależna od domeny lub gałęzi przemysłu Definiuje model jakości w sześciu kategoriach: Funkcjonalnośd, niezawodnośd, użytecznośd, efektywnośd, utrzymywalnośd, przenaszalnośd. IEEE 610: Standardowy Słownik dla Terminologii Inżynierii Oprogramowania, IEEE 830: Rekomendowane Praktyki dla Specyfikacji Wymagao Oprogramowania. IEEE 1233: Wytyczne do Opracowywania Specyfikacji Wymagao Oprogramowania. IEEE 1362: Wytyczne dla Technologii Informacyjnych Definicja Systemu. Normy procesowe: ISO 12207: Standard dla Procesu Cyklu Życia Oprogramowania. ISO 15288: Proces Cyklu Życia Oprogramowania. 12

13 ISO 15504: Ulepszanie i określanie możliwości procesu oprogramowania (ang. Software Process Improvement and Capability Determination (SPICE)) CMMI Zintegrowany Model Dojrzałości Zdolności (ang. Capability Maturity Model Integrated) Aby zdad egzamin nie trzeba znad zawartości każdej z tych norm. Ważne jest jednak (K1), by wiedzied, które normy są istotne dla Inżynierii Wymagao. Inżynieria wymagao ma kluczowe znaczenie, jednak nadal jest zaniedbywana. Dla firm szkoleniowych: podkreślid wagę Inżynierii wymagao i powodów, dla których jest często pomijana (K2). Zaniedbywanie z powodu dużej presji czasu Zaniedbanie ze względu na zorientowanie na szybkie rezultaty Zaniedbanie ze względu na ograniczanie kosztów Zaniedbanie ze względu na niewłaściwą interpretację (wiele rzeczy jest postrzeganych tak, jak podano) Możliwe konsekwencje zaniedbao w Inżynierii Wymagao (K2): Wymagania stają się nieprecyzyjne Wymagania są niejednoznaczne Wymagania są sprzeczne Wymagania, które się zmieniają Wymagania niespełniające kryteriów Wymagania, które mogą byd interpretowane w różny sposób Brakujące wymagania 13

14 2. Procedury i procesy Cele nauczania Jakie istnieją modele procesowe? Czym różnią się modele? Czym charakteryzuje się proces inżynierii wymagao? Jakie istnieją fazy procesu inżynierii wymagao? 2.1. Modele procesowe Modele proceduralne (K2) Niezależny od metody opis procesu wytwarzania oprogramowania. Uwzględnione są : role, aktywności, fazy i dokumenty. Cykl życia produktu (ang. Product life cycle (PLC)) (K2) Podstawowe fazy: planowanie, rozwój, utrzymanie, koniec życia. Faza planowania zawiera: wizję, strategię, biznesplan, analizę kosztów/korzyści. Faza rozwoju zawiera: specyfikację, projekt i implementację. Definiuje różne fazy wytwarzania produktu. Ogólny Model V (K 2) Fazy rozwoju oprogramowania: Zdefiniowanie i określenie wymagao (specyfikacja wydajnościowa) Projektowanie systemu od strony funkcjonalnej, analiza systemu (specyfikacja funkcjonalna) Projektowanie techniczne, projekt architektury (projekt oprogramowania) Specyfikacja komponentów 14

15 Implementacja Dla firm szkoleniowych: wymagane graficzne przedstawienie Ogólnego Modelu V, dogłębny opis Modelu V. Rational Unified Process (RUP ) (K2) Model proceduralny od IBM Rational Iteracyjny proces rozwojowy: 4 fazy (powstanie, opracowanie (elaboracja), budowa, przekazanie) 9 dyscyplin (między innym - wymagania) Dla firm szkoleniowych: graficzne przedstawienie RUP, pogłębione e studium dyscypliny wymagao. Programowanie ekstremalne (K2) Model proceduralny stworzony przez Kenta Becka Zarządzanie wymaganiami jako główny komponent Absolutnie bez inwestygacji (dochodzenia) wymagao Dla firm szkoleniowych: wyjaśnid co najmniej trzy modele zwinne włączając w to Scrum i Crystal. Stopieo modelu dojrzałości (K2) Identyfikacja i ulepszanie dojrzałości procesu (ocena procesu i ulepszanie procesu) Definicja stopnia dojrzałości i powiązanej z nim specyfikacji procesowej Dla firm szkoleniowych: pogłębid na przykładzie ISO 15504/SPICE; wraz z opisem typowych wymagao dla Inżynierii Wymagao. 15

16 2.2. Proces inżynierii wymagao Proces nie będący procesem głównym, który dotyczy wszystkich faz rozwoju systemów: Identyfikacja wymagao Analiza wymagao Specyfikacja wymagao Zmiany w wymaganiach Weryfikacja Zapewnienie jakości Opis czynników wpływających negatywnie na procesy. Opis różnych punktów widzenia (klienta, dostawcy). Metoda procesu inżynierii wymagao z klientem w centrum. 16

17 3. Zarządzanie projektem i zarządzanie ryzykiem Cele nauczania Dlaczego inżynieria wymagao jest ważna w projekcie? Jakie błędy mogą się pojawid w inżynierii wymagao? Jakie ryzyka są powiązane z wymaganiami? 3.1. Zarządzanie projektem Wyjaśnienie niezbędności Inżynierii Wymagao w projektach informatycznych (K2) Inżynieria wymagao powinna wnieśd wkład do następujących obszarów: (K 1) Koncepcji projektu Negocjacji kontraktu Definicji projektu Wykonania projektu Dla firm szkoleniowych: bardziej szczegółowy opis inżynierii wymagao w tych obszarach. Jakie błędy mogą wystąpid w inżynierii wymagao? (K2) Niejasne wymagania Zmieniające się wymagania Niestabilna podstawa produktu i projektu dla podwykonawców Niejasne odpowiedzialności Rozbieżnośd pomiędzy oczekiwaniami klienta i treścią projektu Nieefektywne zarządzanie kontaktami z klientem Definicja projektu z nieosiągalnymi kamieniami milowymi Nieprecyzyjne oszacowanie kosztów Nieprecyzyjne oszacowanie wpływu 17

18 3.2. Zarządzanie ryzykiem Wyjaśnij niezbędnośd zarządzania ryzykiem (K3) Efektywne zarządzanie ryzykiem jako klucz do obniżenia ryzyka w projekcie. Dla firm szkoleniowych: dostarcz szczegółowy opis rozwoju środków zaradczych i technik zarządzania ryzykiem, (takich jak, na przykład, analiza przyczyn i skutków awarii (ang. Failure Mode and Effect Analysis (FMEA)). 18

19 4. Odpowiedzialności i role Cele nauczania Jakie są podstawowe role w inżynierii wymagao? Kim jest interesariusz? Jakie zadania stoją za inżynierią wymagao? Jakie jest zadanie specjalisty inżynierii wymagao? Co charakteryzuje specjalistę inżynierii wymagao? 4.1. Podstawowe role Podstawowe role: (K2) Klient Kontraktor (= Dostawca) Klient określa swoje potrzeby. Dostawca dostarcza rozwiązanie. Interesariusz Interesariusz jest osobą (lub rolą), która jest zainteresowana projektem. Interesariusz może byd zarówno osobą fizyczną, osobą prawną, jak i postacią abstrakcyjną. Interesariusze często napotykają na konflikt interesów między sobą. Dla firm szkoleniowych: opisz typowych interesariuszy (np. dyrektor zarządzający, kierownik projektu, klient). 19

20 Ważne: Identyfikacja wszystkich interesariuszy dla poprawnego rozważenia wszystkich perspektyw Zadania w inżynierii wymagao Zadania: (K2) Analiza procesów biznesowych Identyfikacja i analiza wymagao Zapewnienie jakości wymagao i specyfikacji Stworzenie specyfikacji wymagao Analiza ryzyka Specjalista inżynierii wymagao identyfikuje życzenia i cele. Wiedza i charakterystyka specjalisty inżynierii wymagao: (K1) Umiejętnośd moderowania Pewnośd siebie Umiejętnośd przekonywania Umiejętności językowe Umiejętnośd komunikowania się Precyzja Analityczny umysł Zdolnośd do działania w sposób ustrukturyzowany Kompetencje metodologiczne Odpornośd na stres 20

21 5. Identyfikacja wymagao Cele nauczania Co powinien zawierad kontrakt? Co powinno byd uwzględniane przy ocenie wymagao? Co charakteryzuje typową wizję projektową? Jak można zidentyfikowad interesariuszy? Jaki jest cel identyfikacji wymagao? Jakie techniki pomagają identyfikowad wymagania? Czym charakteryzują się wymagania funkcjonalne i niefunkcjonalne? Czym różnią się wymagania funkcjonale i niefunkcjonalne? Co powinno zostad zawarte w dokumentacji wymagao? Czym charakteryzuje się dobre wymaganie? Jak wygląda standardowa zawartośd dokumentu wymagao? Jak zbudowane jest wymaganie? 5.1. Klient Klient musi byd zawsze zaangażowany. Celem zaangażowania jest zrozumienie klienta i jednoczesne stworzenie atmosfery do wzajemnego zrozumienia. Dostawca powinien zawsze stawiad się w sytuacji klienta. Kontrakt: (K2) W umowie powinno byd formalnie określone i opisane to, czego chce klient. Należy zapewnid, że interes klienta jest na pierwszym miejscu. 21

22 Ważne jest, by zdefiniowad realistyczne terminy i ceny, oraz dokonad realnego planowania projektu. Kiedy wymagania są oceniane, należy wziąd pod uwagę różne punkty widzenia Wizja i cele projektu Na początku odbywa się opracowanie wizji projektu. Jest to pierwsza faza inżynierii wymagao. Kluczowe jest posiadanie jasnej definicji wizji projektu. Dla firm szkoleniowych: zaprezentowad typowe wizje projektu. Ważne pytania dotyczące wizji projektu: (K2) Co projekt zmieni? Do czego projekt jest potrzebny? Co się zdarzy kiedy projekt zostanie przerwany? Kto zyska na projekcie? Jakie koszty jesteśmy w stanie ponieśd? Jakie ryzyko jesteśmy gotowi podjąd? Dla firm szkoleniowych: zaprezentowad typowe elementy wpływające na wizje projektu (klienci, strategia, etc.) Dla każdego projektu, wizja musi zostad zdefiniowana na nowo 5.3. Identyfikacja interesariuszy Wszyscy interesariusze po stronie klienta i dostawcy muszą zostad zidentyfikowani. Interesariusze powinni byd podzieleni na grupy interesów. Dla firm szkoleniowych: wyjaśnid identyfikację i ocenę interesariuszy. 22

23 5.4. Techniki identyfikacji wymagao Cel identyfikacji wymagao (K2) Techniki (K1) Identyfikacja wszystkich wymaganych funkcji, charakterystyk, ograniczeo i oczekiwao Zorientowanie wymagao w kierunku wizji projektu Funkcje muszą byd jasno opisane Funkcje, których klient nie chce powinny byd wykluczone Kwestionariusze Wywiady Samodzielna rejestracja Reprezentant klienta po stronie dostawcy Identyfikacja na podstawie istniejących dokumentów Ponowne użycie specyfikacji z podobnych projektów Burza mózgów Obserwacja w terenie Terminowanie (praktykowanie) (ang. apprenticing) Warsztaty po każdym wymienionym procesie Dla firm szkoleniowych: zaprezentowad techniki, włączając opis korzyści i wad. Dla firm szkoleniowych: wyjaśnid opis metod odpytywania dla wywiadów Wymagania funkcjonalne i niefunkcjonalne Wymagania funkcjonalne (K2) Opis funkcji systemu Wyzwalacze (uruchomienie) procesu Wymagania niefunkcjonalne (K2) Opisują atrybuty funkcji lub ich charakterystyki jakościowe Trudne do opisania, dlatego często niejasno sformułowane 23

24 Często trudne do śledzenia i testowania Precyzyjny i jasny opis jest konieczny dla walidacji Dla firm szkoleniowych: dostarczyd przykłady wymagao funkcjonalnych i niefunkcjonalnych. Charakterystyki jakościowe zgodnie z ISO 9126: (K2) Funkcjonalnośd, niezawodnośd, użytecznośd, efektywnośd, utrzymywalnośd, przenaszalnośd Dla firm szkoleniowych uszczegółowid poszczególne charakterystyki jakościowe. Dla firm szkoleniowych: opisad ograniczenia (np. specyfikacje techniczne) Opis wymagao Zawartośd tekstu wymagania: Kto? Co? Jak? Kiedy? Z kim? Na co wpływa? Ważne wskazówki do tworzenia dokumentacji wymagao: (K2) Wymagania muszą byd jednoznaczne, precyzyjne i zrozumiałe Należy unikad zbędnych informacji Szablony jako pomoc do ograniczenia opisów Standardowa zawartośd dokumentu wymagao: (K1) Wprowadzenie Klauzula tajności Regulacje Standardy Interesariusze Przeznaczenie produktu Opis systemu Wymagania funkcjonalne Wymagania niefunkcjonalne 24

25 Założenia Zależności Ryzyka Wymagania bezpieczeostwa Atrybuty jakości oprogramowania Akceptacja Konstruowanie wymagao (K2) 1. Określenie procesu 2. Klasyfikacja czynności systemu 3. Określenie zobowiązao prawnych 4. Poprawienie procesu 5. Ograniczenia logiczne i czasowe Dla firm szkoleniowych: opis poszczególnych kroków w konstruowaniu wymagao. 25

26 6. Specyfikacja wymagao Cele nauczania Czym jest specyfikacja wymagao? Co charakteryzuje specyfikację wymagao? Czym jest specyfikacja rozwiązania? Co charakteryzuję specyfikację rozwiązania? Jakie standardy są ważne dla specyfikacji wymagao i specyfikacji rozwiązao? Jak wygląda typowa procedura w odniesieniu do specyfikowania wymagao? Jakie istnieją poziomy formalizacji dla specyfikacji wymagao? Jakie mogą byd konsekwencje błędów w wymaganiach? Jak unikad błędów w wymaganiach? 6.1. Specyfikacja W specyfikacji wymagania są opisane w ustrukturyzowany sposób i oddzielnie modelowane. Specyfikacja służy do śledzenia i zarządzania wymaganiami. Specyfikacja wymagao (K2) Nazywana również specyfikacją wydajności. Jej stworzenie powinno byd zadaniem klienta. Specyfikacja rozwiązania (K2) Zwana również specyfikacją funkcjonalną. 26

27 Podstawa do dalszego rozwoju systemu. Ważne standardy: (K1) IEEE 1362 (specyfikacje wydajności systemu), IEEE 830 (specyfikacje wymagao systemu), IEEE 1233 (specyfikacje funkcjonalne systemu) Dla firm szkoleniowych: dostarczyd bardziej szczegółowy opis specyfikacji wydajności oraz specyfikacji funkcjonalnej Procedura Specyfikacja jako czynnośd służąca formalizacji wyników analizy wymagao (K2) Dla firm szkoleniowych: opisad kroki specyfikacji problemów i rozwiązao (określanie przestrzeni rozwiązania, opisywanie kontaktów klienta, etc.) Faza identyfikacji zostaje zakooczona, kiedy wszystkie niezbędne umowy zostały podpisane Formalizacja Różne stopnie formalizacji Nieformalna Pół-formalna Formalna Dla firm szkoleniowych: dostarczyd opis i rozróżnienie pomiędzy stopniami formalizacji (K2) 27

28 6.4. Jakość Wymagao Błędy w wymaganiach jako przyczyna wysokich kosztów (K2) Im później błąd zostanie znaleziony, tym większe są koszty jego naprawy. Dlatego używamy ręcznej weryfikacji (czy właściwie produkujemy produkt?) i walidacji (czy produkujemy właściwy produkt?). Dla firm szkoleniowych: opisad miary ulepszania i zapewniania jakości. 28

29 7. Analiza wymagao Cele nauczania Jaki jest cel analizy wymagao? Jakie procedury stosowane są podczas analizy wymagao? Jakie istnieją modele analizy wymagao? Co charakteryzuje UML? Co charakteryzuje SySML? Dlaczego estymujemy koszty? Jakie są ważne czynniki przy estymacji kosztów? Jak wygląd procedura przyznawania priorytetów? Co musi byd brane pod uwagę przy podejmowaniu decyzji dotyczących wymagao? 7.1. Wymagania i rozwiązania Cel analizy wymagao: rozwiązanie dla implementacji wymagao (K2) Procedura: 1. Analiza potrzeb 2. Opis rozwiązania 3. Estymacja kosztów i ustalenie priorytetów 29

30 7.2. Metody i Techniki Różne aspekty systemu są reprezentowane przez różne punkty widzenia. Modele są opracowywane poprzez odpowiednie metody analizy. Zróżnicowanie pomiędzy różnymi typami modeli (K2) Modele wymagao Modele rozwiązania Dla firm szkoleniowych: dostarczyd szczegółowy opis tych dwóch typów i ich widoków. Różne modele (K1) Model kontekstowy Dekompozycja funkcjonalna Model przepływu danych Model przejśd stanów Sied Petriego Model związków encji Dla firm szkoleniowych: szczegółowy opis wymienionych modeli Analiza zorientowana obiektowo UML (Unified Modeling Language) UML dostarcza diagramy dla różnych punktów widzenia systemu. Diagramy przypadków użycia, diagramy klas, diagramy aktywności, diagramy stanów, diagramy obiektów, diagramy komponentów, diagramy pakietów, itd. Dla firm szkoleniowych: dostarczyd przykłady diagramów (co najmniej diagramów przypadków użycia, klas, aktywności i stanów). SysML (Systems Modeling Language) jako rozwinięcie UML. 30

31 7.4. Estymacja Kosztów Estymacja kosztów łączy inżynierię wymagao z zarządzaniem projektem. Typy estymat (K2) Koszty Czas Wymagania Jakośd Estymaty kosztów pomagają rozpoznawad koszty zmian. Dla firm szkoleniowych: opisad czynniki determinujące koszty wytwarzania. Procedury estymacji (K 1) Wnioski przez analogię Procedura algorytmiczna Procedura punktów funkcyjnych Konstruktywny model kosztowy Metoda Delphi (delfijska) Dla firm szkoleniowych: wyjaśnienie procedury estymacji. Procedury estymacji zawsze bazują na danych historycznych i ograniczeniach środowiska Priorytetyzacja Procedura 1. Grupowanie wymagao 2. Analiza wymagao 3. Budowanie planu projektu 4. Testowanie przyrostowe 31

32 7.6. Akceptacja wymagao Umowy (K2) Umowy formalne jako podstawa projektu Lista wymagao musi byd wiążąca Konieczny jest ciągły przegląd wymagao Dla firm szkoleniowych: opis korzyści wynikających z wiążących alokacji. 32

33 8. Śledzenie wymagao Cele nauczania Czym jest możliwośd śledzenia? Dlaczego wymagania się zmieniają? Jaki jest cel śledzenia? Jakie są typy śledzenia? Czym charakteryzuje się zarządzanie zmianą? Jaki jest skład komitetu kontroli zmian? Jakie istnieją metryki? Co umożliwiają metryki? 8.1. Śledzenie wymagao w projekcie Możliwośd śledzenia (K2) Wymagania nie są stabilne i ciągle się rozwijają Powody ciągłych zmian Nowe spojrzenie Nowe potrzeby klienta Kontynuowanie prac Nowe połączenia w ramach projektu Możliwośd śledzenia jako rozwiązanie: Umożliwia sprawdzenie, czy wszystkie istotne etapy procesu rozwoju zostały przeprowadzone. 33

34 Cele: analiza wpływu, analiza pokrycia, analiza użycia potencjału, dowód implementacji, użycie wymagao, itd. W celu zapewnienia dobrej możliwości śledzenia, ważne jest, by precyzyjnie nazywad wymagania. Typy możliwości śledzenia: Śledzenie pionowe i poziome. Dla firm szkoleniowych: opisad, czym jest śledzenie pionowe i poziome Zarządzanie zmianą Zmiany w wymaganiach (zarządzanie zmianą) (K2) Zmiany są sprawdzane, a decyzja o dalszym postępowaniu musi byd podjęta przez komitet kontroli zmian. Komitet podejmuje decyzję odnośnie żądao zmian. Komitet kontroli zmian składa się z (K1) Kierownika projektu Członków zespołu programistów Członków zespołu zapewnienia jakości Menadżera biznesowego (jeśli konieczne) Klienta (jeśli konieczne) itd. Dla firm szkoleniowych: przedstaw zadania komitetu kontroli zmian. Dla zmiany wymagao konieczny jest ustrukturyzowany proces. Ważna jest analiza znaczenia każdej zmiany. Pośpieszne rozwiązania są problematyczne. Rozległe zmiany wymagao mogą byd na tyle poważne, że wymuszą zmiany kontraktów. Dla firm szkoleniowych: opisad cyklu życia wymagania. 34

35 Dla firm szkoleniowych: wyjaśnid wpływ zmian w wymaganiach. Dla firm szkoleniowych: rozróżnid pomiędzy zarządzaniem błędami a zarządzaniem zmianą Metryki Metryki umożliwiają wydanie mierzalnego oświadczenia odnośnie statusu i jakości projektu. Liczby muszą zawsze byd porównane z danymi referencyjnymi. Metryki dla wymagao: (K1) Koszt projektu Śledzenie projektu Stabilnośd projektu Ulepszanie procesu Jakośd specyfikacji Ilośd błędów Typy błędów Pomiar jakości wymagao: (K2) Czy wymagania są poprawne? Czy wymagania są czytelne? Czym wyższa częstotliwośd zmian, tym wyższe ryzyko projektowe. 35

36 9. Zapewnienie jakości Cele nauczania Jakie czynniki wpływają na inżynierię wymagao? Jak można usprawnid zapewnienie jakości? Czym jest kryterium akceptacji? Jakie znamy metody zapewnienia jakości? 9.1. Czynniki sukcesu Czynniki wpływające na sukces inżynierii wymagao: (K2) Produkt, jaki jest wytwarzany Środowisko, w jakim produkt zostaje wytwarzany Przemysł Presja czasu Presja kosztów Czynniki społeczne Takie czynniki muszą byd wzięte pod uwagę w procesie zapewnienia jakości Wyżej wymienione czynniki muszą byd wzięte pod uwagę, jeśli chodzi o zapewnienie jakości Zapewnienie jakości poprzez testowalność Inżynieria wymagao jest obecna w całym cyklu życia produktu. Inżynieria wymagao jest ściśle powiązana z testowaniem. Dobry przypadek testowy wymaga dobrych wymagao, które mogą byd przetestowane (zaangażowanie testerów w specyfikowaniu wymagao jest kluczowe) (K2) 36

37 Kryteria akceptacji Metody: Każde wymaganie ma przynajmniej jedno kryterium akceptacji Stanowi podstawę do testów akceptacyjnych Pokrycie funkcjonalne Podzbiory równoważności Dla firm szkoleniowych: opisad metody. 37

38 10. Narzędzia Cele nauczania Jak narzędzia wspierają inżynierię wymagao? Jakie czynności związane z inżynieria wymagao mogą byd przeniesione do narzędzia? Jakie istnieją wymagania na narzędzia do inżynierii wymagao? Co musi byd brane pod uwagę w odniesieniu do narzędzi? Zalety narzędzi Narzędzia do przechowywania i administracji wymagao wspomagają inżynierię wymagao. Mogą one automatyzowad powtarzalne czynności lub zapewnid łatwy wgląd w wymagania. W ten sposób można utrzymywad trudne, statyczne dokumenty w spójnym i aktualnym stanie. Wybór narzędzia musi nastąpid przed wytworzeniem produktu. W innym wypadku może to spowodowad poważne problemy (K2) Dla firm szkoleniowych: dostarczyd opis wymagao stawianych narzędziom w zakresie inżynierii wymagao. Dla firm szkoleniowych: dostarczyd opis czynności inżynierii wymagao, które mogą byd wspierane przez wykorzystanie narzędzi Kategorie narzędzi Narzędzia przetwarzające tekst, arkusze kalkulacyjne o MS Excel, MS Word itd. Narzędzia do modelowania Narzędzia do zarządzania wymaganiami Narzędzia do zarządzania defektami Narzędzia Open Source 38

39 Koszty narzędzi znacznie się różnią. Wybór narzędzia musi byd dokonany bardzo ostrożnie. Pośpieszne decyzje mogą powodowad wysokie koszty. (K2) 39

40 11. Literatura Beck, Kent: Extreme Programming. Munich 2003 Beck, Kent: Extreme Programming Explained: Embrace Change. Boston 2000 Beck, Kent: Test Driven Development. By Example. Amsterdam 2002 Beck, Kent: Refactoring: Improving the Design of Existing Code. Addison-Wesley Longman 1999 Boehm, Barry: Software Engineering Economics. Englewoods Cliffs, NJ 1981 Bundschuh, Manfred; Fabry, Axel: Aufwandschätzung von IT-Projekten. Bonn 2004 Cockburn, Alistair: Agile Software Development. Addison Wesley 2002 Cockburn, Alistair: Writing Effective Use Cases. Amsterdam 2000 DeMarco, Tom et al.: Adrenalin-Junkies und Formular-Zombies Typisches Verhalten in Projekten. Munich 2007 DeMarco, Tom: Controlling Software Projects: Management, Measurement and Estimates. Prentice Hall 1986 DeMarco, Tom: The Deadline: A Novel About Project Management. New York 1997 Ebert, Christof: Systematisches Requirements Management. Anforderungen ermitteln, spezifizieren, analysieren und verfolgen. Heidelberg 2005 Evans, Eric J: Domain-Driven Design: Tackling Complexity in the Heart of Software. Amsterdam 2003 Graham, Dorothy et al: Foundations of Software Testing. London 2007 Gilb, Tom; Graham, Dorothy: Software Inspection. Reading, MA 1993 Hull, Elizabeth et. All: Requirements Engineering. Oxford 2005 IEEE Standard IEEE Standard Glossary of Software Engineering Terminology IEEE Standard IEEE Guide for Developing System Requirements Specifications 40

41 IEEE Standard IEEE Standard for Siftware Test Documentation IEEE Standard IEEE Recommended Practice for Software Requirements Specifications IEEE Standard IEEE Guide for Information Technology-System Definition Concept of Operations (ConOps) Document IEEE Standard : IEEE Standard for Application and Management of Systems Engineering Process ISO 9000 ISO 9126 ISO ISO ISO Jacobsen, Ivar et al.: The Unified Software Development Process. Reading 1999 Lauesen, Soren: Software Requirements: Styles and Techniques. London 2002 Mangold, Pascal: IT-Projektmanagement kompakt. Munich 2004 McConnell, Steve: Aufwandschätzung für Softwareprojekte. Unterschleißheim 2006 Paulk, Mark, et al: The Capability Maturity Model: Guidelines for Improving the Software Process. Reading, MA 1995 Pfleeger, Shari Lawrence: Software Engineering: Theory and Practice, 2nd edition. Englewood Cliffs, NJ 2001 Pohl, Klaus: Requirements Engineering. Grundlagen, Prinzipien, Techniken. Heidelberg 2007 Project Management Institute: A Guide to the Project Management Body of Knowledge (PMBOK Guide). PMI 2004 Robertson. Suzanne; Robertson, James: Mastering the Requirements Process, Harlow

42 Rupp, Chris: Requirements-Engineering und Management. Professionelle, Iterative Anforderungsanalyse in der Praxis. Munich 2007 Sommerville, Ian: Requirements Engineering. West Sussex 2004 Sommerville, Ian: Software Engineering 8. Harlow 2007 Sommerville, Ian; Sawyer, Pete: Requirements Engineering: A Good Practice Guide. Chichester 1997 Sommerville, Ian; Kotonya, Gerald: Requirements Engineering: Processes and Techniques. Chichester 1998 Spillner, Andreas et all: Software Testing Foundations. Santa Barbara, CA 2007 Thayer, Richard H.; Dorfman, Merlin: Software Requirements Engineering, 2nd edition. Los Alamitos, CA 1997 V-Modell XT: Wiegers, Karl E.: Software Requirements. Redmond 2005 Wiegers, Karl E.: More About Software Requirements: Thorny Issues and Practical Advice. Redmond, Washington