REQB Foundation Level Polish Version 1.3 - gasq

Transkrypt

Syllabus
REQB®
Certyfikowany specjalista
inżynierii wymagań
Poziom podstawowy
Wersja 1.2PL
1 Grudnia 2010
Prawa autorskie ® do tej edycji syllabusa dla wszystkich języków należą do Global Association
for Software Quality, gasq
REQB® Certyfikowany specjalista inżynierii wymagao
Poziom podstawowy
Podsumowanie zmian
Wersja Data
Komentarz
0.1
17.04.2006
PIerwsza wersja syllabusa; stworzenie podstawowej struktury syl labusa
0.2
20.07.2006
Rozszerzenie wersji 0.1
0.3
04.09.2006
Dalsze rozszerzenie i rewizja wersji 0.1
0.4
10.10.2006
Rewizja wersji 0.3
0.5
15.12.2006
Rewizja wersji 0.4
0.6
07.02.2007
Kompletnie zrewidowana wersja 0.5
0.7
10.04.2007
Wersja zrewidowana dla przeglądu
0.8
15.06.2007
Wersja Alpha
0.9
01.09.2007
Wersja Beta
1.0
15.01.2008
Wydanie 1.0
1.1
29.05.2008
Zaktualizowana wersja 1.1
1.2
01.07.2008
Zaktualizowana wersja 1.2
1.2PL
01.12.2010
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
Wersja 1.2PL
© gasq – Global Association for Software Quality
1 Grudzieo 2010
Poziom podstawowy
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
Wersja 1.2PL
1 Grudzieo 2010
Poziom podstawowy
1. Spis treści
Wprowadzenie ........................................................................................................................... 6
1.
2.
3.
4.
5.
6.
7.
Podstawy ............................................................................................................................. 8
1.1.
Wymaganie .................................................................................................................. 8
1.2.
Standardy i normy...................................................................................................... 12
Procedury i procesy ........................................................................................................... 14
2.1.
Modele procesowe .................................................................................................... 14
2.2.
Proces inżynierii wymagao ........................................................................................ 16
Zarządzanie projektem i zarządzanie ryzykiem................................................................. 17
3.1.
Zarządzanie projektem .............................................................................................. 17
3.2.
Zarządzanie ryzykiem................................................................................................. 18
Odpowiedzialności i role ................................................................................................... 19
4.1.
Podstawowe role ....................................................................................................... 19
4.2.
Zadania w inżynierii wymagao................................................................................... 20
Identyfikacja wymagao ..................................................................................................... 21
5.1.
Klient .......................................................................................................................... 21
5.2.
Wizja i cele projektu .................................................................................................. 22
5.3.
Identyfikacja interesariuszy ....................................................................................... 22
5.4.
Techniki identyfikacji wymagao................................................................................. 23
5.5.
Wymagania funkcjonalne i niefunkcjonalne ............................................................. 23
5.6.
Opis wymagao............................................................................................................ 24
Specyfikacja wymagao ...................................................................................................... 26
6.1.
Specyfikacja ............................................................................................................... 26
6.2.
Procedura................................................................................................................... 27
6.3.
Formalizacja ............................................................................................................... 27
6.4.
Jakośd Wymagao........................................................................................................ 28
Analiza wymagao............................................................................................................... 29
7.1.
Wymagania i rozwiązania .......................................................................................... 29
4
Wersja 1.2PL
1 Grudzieo 2010
Poziom podstawowy
7.2.
Metody i Techniki ...................................................................................................... 30
7.3.
Analiza zorientowana obiektowo .............................................................................. 30
7.4.
Estymacja Kosztów .................................................................................................... 31
7.5.
Priorytetyzacja ........................................................................................................... 31
7.6.
Akceptacja wymagao ................................................................................................. 32
8.
Śledzenie wymagao ........................................................................................................... 33
8.1.
Śledzenie wymagao w projekcie................................................................................ 33
8.2.
Zarządzanie zmianą.................................................................................................... 34
8.3.
Metryki....................................................................................................................... 35
9.
Zapewnienie jakości .......................................................................................................... 36
9.1.
Czynniki sukcesu ........................................................................................................ 36
9.2.
Zapewnienie jakości poprzez testowalnośd............................................................... 36
10.
Narzędzia ....................................................................................................................... 38
10.1.
Zalety narzędzi........................................................................................................ 38
10.2.
Kategorie narzędzi .................................................................................................. 38
11.
Literatura ....................................................................................................................... 40
5
Wersja 1.2PL
1 Grudzieo 2010
Poziom podstawowy
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 (www.gasq.org) lub na
stronie internetowej REQB (www.reqb.org).
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
Wersja 1.2PL
1 Grudzieo 2010
Poziom podstawowy
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
Wersja 1.2PL
1 Grudzieo 2010
Poziom podstawowy
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 610.12: 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
Wersja 1.2PL
1 Grudzieo 2010
Poziom podstawowy
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
Wersja 1.2PL
1 Grudzieo 2010
Poziom podstawowy
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, modyfik owalna 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
Wersja 1.2PL
1 Grudzieo 2010
Poziom podstawowy
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
Wersja 1.2PL
1 Grudzieo 2010
Poziom podstawowy
1.2. Standardy i normy
ISO 9000:
Wymagania w stosunku do systemu zarządzania jakością.
Zdefiniowana podstawowa koncepcja Systemów Zarządzania Jakością (ang. Quality
Management System, QMS)
Koncepcja niezależna od domeny lub gałęzi przemysłu
ISO 9126:
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
Wersja 1.2PL
1 Grudzieo 2010
Poziom podstawowy
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
Wersja 1.2PL
1 Grudzieo 2010
Poziom podstawowy
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
Wersja 1.2PL
1 Grudzieo 2010
Poziom podstawowy
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
Wersja 1.2PL
1 Grudzieo 2010
Poziom podstawowy
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
Wersja 1.2PL
1 Grudzieo 2010
Poziom podstawowy
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
Wersja 1.2PL
1 Grudzieo 2010
Poziom podstawowy
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
Wersja 1.2PL
1 Grudzieo 2010
Poziom podstawowy
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
Wersja 1.2PL
1 Grudzieo 2010
Poziom podstawowy
Ważne: Identyfikacja wszystkich interesariuszy dla poprawnego rozważenia wszystkich
perspektyw.
4.2. 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
Wersja 1.2PL
1 Grudzieo 2010
Poziom podstawowy
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
Wersja 1.2PL
1 Grudzieo 2010
Poziom podstawowy
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.
5.2. 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
Wersja 1.2PL
1 Grudzieo 2010
Poziom podstawowy
5.4. Techniki identyfikacji wymagao
Cel identyfikacji wymagao (K2)
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
Techniki (K1)
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.
5.5. 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
Wersja 1.2PL
1 Grudzieo 2010
Poziom podstawowy
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).
5.6. 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
Wersja 1.2PL
1 Grudzieo 2010
Poziom podstawowy
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
Wersja 1.2PL
1 Grudzieo 2010
Poziom podstawowy
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
Wersja 1.2PL
1 Grudzieo 2010
Poziom podstawowy
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.
6.2. 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.
6.3. Formalizacja
Różne stopnie formalizacji
Nieformalna
Pół-formalna
Formalna
Dla firm szkoleniowych: dostarczyd opis i rozróżnienie pomiędzy stopniami formalizacji (K2)
27
Wersja 1.2PL
1 Grudzieo 2010
Poziom podstawowy
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
Wersja 1.2PL
1 Grudzieo 2010
Poziom podstawowy
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
Wersja 1.2PL
1 Grudzieo 2010
Poziom podstawowy
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.
7.3. 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
Wersja 1.2PL
1 Grudzieo 2010
Poziom podstawowy
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.
7.5. Priorytetyzacja
Procedura
1. Grupowanie wymagao
2. Analiza wymagao
3. Budowanie planu projektu
4. Testowanie przyrostowe
31
Wersja 1.2PL
1 Grudzieo 2010
Poziom podstawowy
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
Wersja 1.2PL
1 Grudzieo 2010
Poziom podstawowy
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
Wersja 1.2PL
1 Grudzieo 2010
Poziom podstawowy
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.
8.2. 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
Wersja 1.2PL
1 Grudzieo 2010
Poziom podstawowy
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ą.
8.3. 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
Wersja 1.2PL
1 Grudzieo 2010
Poziom podstawowy
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.
9.2. 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
Wersja 1.2PL
1 Grudzieo 2010
Poziom podstawowy
Kryteria akceptacji
Każde wymaganie ma przynajmniej jedno kryterium akceptacji
Stanowi podstawę do testów akceptacyjnych
Metody:
Pokrycie funkcjonalne
Podzbiory równoważności
Dla firm szkoleniowych: opisad metody.
37
Wersja 1.2PL
1 Grudzieo 2010
Poziom podstawowy
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?
10.1. 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.
10.2. 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
Wersja 1.2PL
1 Grudzieo 2010
Poziom podstawowy
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
Wersja 1.2PL
1 Grudzieo 2010
Poziom podstawowy
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 610.12-1990 IEEE Standard Glossary of Software Engineering Terminology
IEEE Standard 1233-1998 IEEE Guide for Developing System Requirements Specifications
40
Wersja 1.2PL
1 Grudzieo 2010
Poziom podstawowy
IEEE Standard 829-1998 IEEE Standard for Siftware Test Documentation
IEEE Standard 830-1998 IEEE Recommended Practice for Software Requirements
Specifications
IEEE Standard 1362-1998 IEEE Guide for Information Technology-System Definition –
Concept of Operations (ConOps) Document
IEEE Standard 1220-1998: IEEE Standard for Application and Management of Systems
Engineering Process
ISO 9000
ISO 9126
ISO 12207
ISO 15288
ISO 15504
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 1999
41
Wersja 1.2PL
1 Grudzieo 2010
Poziom podstawowy
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: http://www.vmodellxt.de/
Wiegers, Karl E.: Software Requirements. Redmond 2005
Wiegers, Karl E.: More About Software Requirements: Thorny Issues and Practical Advice.
Redmond, Washington 2006
42
Wersja 1.2PL
1 Grudzieo 2010

REQB Foundation Level Polish Version 1.3 - gasq

Transkrypt

Podobne dokumenty