Zarządzanie wymaganiami
Z Wikipedii
Zarządzanie wymaganiami jest dziedziną zajmującą się działaniami mającymi na celu przełożenie potrzeb lub oczekiwań użytkowników w stosunku do konstruowanej, fizycznej realizacji produktu końcowego. Pojęcie zarządzania wymaganiami w szerokim kontekście odnosi się do metod specyfikowania użytecznych cech wszelkiego rodzaju produktów (np. umów handlowych, budowli, cech urządzeń, itd.).
Pojęcie zarządzania wymaganiami w inżynierii oprogramowania stanowi proces zbierania i analizowania różnych wymagań. Wymagania te mogą pochodzić od różnych podmiotów, zainteresowanych powstaniem lub modyfikacją określonego produktu (mogą to być użytkownicy, klienci, zarząd firmy). Ze względu na kontekst danego wymagania, możemy określi je jako wymaganie użytkownika, biznesowe, funkcjonalne, techniczne czy procesu wytwarzania.
Wytwarzanym produktem może być zwykła aplikacja, system świadczący jakieś usługi lub nawet serwer aplikacji czy witryna internetowa. Podczas zbierania wymagań dotyczących produktu należy odpowiednio rozdzielić je pomiędzy dostępne klasy. Dobre zaprojektowane systemy gromadzą wymagania w każdej z tych pięciu grup, nie powodując zbyt jednoznacznego nastawienia na jedną z nich.
W zarządzaniu wymaganiami może być zastosowany osobny język do projektowania graficznego SysML, bazujący na standardach UML.
Spis treści |
[edytuj] Etapy wytwarzania oprogramowania
Realizacja zadań związanych z zarządzaniem wymaganiami w dużej mierze zależy od etapu, w jakim jest realizacja projektu. Można wyróżnić pięć podstawowych faz jego powstawania, w których zarządzanie wymaganiami ma znaczenie.
[edytuj] Etap rozpoznawania (Investigation)
Na tym etapie są gromadzone wymagania od przewidywanych docelowych użytkowników systemu (wymagania użytkownika), określa się problemy, jakie ma rozwikłać dany produkt (wymagania biznesowe) oraz pobiera się wymagania od zespołu wytwarzania (wymagania techniczne). To tutaj określa się cele produktu, narzędzia i ogólne zasrysy, możliwości i ograniczenia realizacji. Na podstawie tych zebranych wymagań jesteśmy w stanie stworzyć zarys systemu, jaki chcemy stworzyć. Dzięki temu możemy przystąpić do ustalania wymagań funkcjonalnych.
Na tym wtępnym etapie należy się liczyć z tym, iż nie da się zdefiniować wszystkich możliwych wymagań. Zebrane wymagania z pewnością ulegną zmianom, będącym skutkiem podejmowanych działań wewnątrz projektu lub wpływów zewnętrznych.
Po wykonaniu analizy wymagań, powinien powstać dokument gromadzący wymagania (nazywany specyfikacją wymagań), który będzie zaakceptowany przez wszystkich członków zespołu projektowego (również klientów). Ów dokument ma stanowić element, który będzie zapobiegał nieprzewidzianym i dziwacznym zmianom. W miarę rozwoju projektu często pojawiają się nowe super-pomysły, które tworzą całą serię kolejnych wymagań. Stworzenie takiego dokumentu będzie pozwalało na utrzymanie projektu przy początkowych założeniach i realizowanie wcześniej zaplanowanej wizji. Nie zamyka on oczywiście przed dodaniem nowych wymagań, bynajmniej ogranicza możliwość niekontrolowanego życia projektu.
Sposoby gromadzenia wymagań są różne. W najprostszym wykonaniu może to być zwykły dokument, do którego dopisujemy lub usuwamy wymaganie. W bardziej złożonych narzędziach stosuje się bazy danych, gormadzące wymagania i pozwalające na generowanie dokumentu wymagań. Równocześnie zapewniają możliwość śledzenia zmian czynionych na wymaganiach lub tworzenia dowiązań, określających zależności pomiędzy innymi wymaganiami lub przypadkami użycia.
[edytuj] Analiza wykonalności (Feasibility)
Na tym etapie następuje najczęściej oszacowanie kosztów zrealizowania zaplanowanych wymagań, ustalenie kosztów istnienia obecnego oprogramowania oraz kosztów ich wadliwego funkcjonowania, które ma poprawić nowy produkt. Równocześnie należy oszacować dostępny budżet na realizację produktu oraz zasoby ludzkie. Ważne jest podjęcie próby oszacowania zwrotu jaki uzyska się po wprowadzeniu produktu na rynek.
Należy zadać sobie pytanie, czy posiadamy odpowiednich ludzi do zrealizowania zadań, związanych z projektem, jakie są koszty ich przeszkolenia, jakie narzędzie musimy im zagwarantować, by stworzyć odpowiednie środowisko pracy. Najlepszym rozwiązaniem, jest zapewnienie zespołowi wykonawczemu jak najlepsze stanowisko, aby zaoszczędzić czas ich pracy - zarówno pod względem posiadanego sprzętu jak i oprogramowania.
Kluczowym aspektem, jaki trzeba rozpatrzyć, jest zadanie sobie pytania, na jakim stanowisku będzie pracował projektowany system - czy będzie konieczne postawienie serwera, zorganizowania systemu hostingowego ?
Ten etap również może generować nowe wymagania, dotyczące sprzętu lub oprogramowania jaki należy zakupić dla środowiska wytwórczego lub dla przyszłego systemu, jaki ma być stworzony. Mogą to być także wymagania co do ludzi, jacy mają uczestniczyć w realizacji projektu.
Dokuementem finalnym, jaki powinien zostać przedstawiony z tego etapu, powinien być budżet projektu oraz plan rozkładu kosztów w czasie trwania projektu. Dokument pozwala na podjęcie decyzji, czy projekt warto realizować, czy stać nas na realizację wszystkich z nakreślonych wymagań.
[edytuj] Projektowanie (design)
Kiedy stwierdzimy, że znane są nam koszty powstania projektu i przewidziane są zyski, jakie uzyskamy, można przystąpić do etapu projektowania. Na tym etapie, podstawowym zadaniem związanym z zarządzaniem wymaganiami jest utrzymywanie powstającego projektu w zgodności z granicami, jakie zostały narzucone w wymaganiach.
Należy jednak zachować pewną płynność. Podczas prac projektowych może się okazać, że inne rozwiązanie jest wydajniejsze, tańsze lub lepsze. Zawsze można spróbować delikatnie zreorganizować wymagania i dostosować je do potrzeb czy zewnętrznego rynku. Jednak w najczęstszych przypadkach taki krok podejmuje się rzadko i utworzona lista wymagań powinna pozostać w formie niezmienionej. Projektanci na podstawie tego dokumentu przygotowują projekt systemu.
[edytuj] Konstrukcja i testowanie (construction and test)
Podstawową czynnością, wykonywaną na tym etapie w ramach zarządzania wymaganiami jest upewnienie się, ża prace nad projektem zamykają się w przewidzianym kosztorysie, a powstający produkt realizuje wytyczne, ujęte w wymaganiach. Ważnymi punktami tego etapu jest tworzenie prototypowych szkieletów i testów, które będą pozwalały na szacowanie zgodności z wymaganiami i postępów prac. Dla aplikacji klienckich można stworzyć wstępny graficzny interfejs użytkownika, które będzie podlegał testowaniu, a dla którego realizacja ciała będzie wypełniana z czasem. Pozwala to na usprawnienie powstawania samego projektu.
[edytuj] Wypuszczenie produktu (release)
Jest to etap, który tak naprawdę nie oznacza końca zarządzania wymaganiami. Podczas pracy nad projektem mogą się pojawić nowe, dodatkowe koncepcje, lub wizja postaci produktu może ulec zmianie. Po dobrnięciu do tego etapu wykonuje się całą pracę od nowa, aby uzyskać nowy, lepszy i sprawniejszy produkt.
[edytuj] Narzędzia
- komercyjne:
- niekomercyjne z otwartym kodem:
[edytuj] Zobacz też
- wymagania
- przypadki użycia
- analiza wymagań
