W trakcie pracy nad projektem potrzeba wprowadzenia zmian może pojawić się wielokrotnie. Gdyby było inaczej ju ż dawno powstałyby .szablony wymagań, które pasowałyby do każdego projektu i etap zwany zarządzaniem wymaganiami miałby o wiele mniejsze znaczenie w całym cyklu życia systemu.
Dlatego też istotną rzeczą jest odpowiednie pogrupowanie wymagań, aby można było sprawnie zarządzać nimi, wprowadzać korekty, zbierać historię zmian, pilnować powiązań pomiędzy poszczególnymi wymaganiami itd. W iadomo, że nieodpowiednio zarządzana zmiana pociąga za sobą niebezpieczeństwo niepowodzenia projektu, natomiast wszelkiego rodzaju kontrolowane aktualizacje nie tutaj zagrożenia15. Powody pojawiających się zmian m ogą być różne. Możemy wyróżnić tu cztery podstawowe kategorie tych powodów16:
• Środowiskowe - wymagania, które ewoluują z powodu zmian, zachodzących w otoczeniu biznesowym firmy takie ja k reorganizacja, zmiana przepisów, regulacji - nie są one związane bezpośrednio z projektem, ale maja na niego bezpośredni wpływ.
• Pojawiające się - wymagania, które stają się zrozumiałe dopiero podczas pracy z systemem, wynikające z braku zrozumienia klienta i analityka
• Wynikowe - wymagania, które pojawiają się dopiero po wdrożeniu gotowego produktu
15 IBM Corporation “Rational RequisitePro - User Guide” (2002) http://www306.ibm.com/software/rational/
16 Sommerville Ian “Software Engineering 7th edition” (Pearson Education, 2000)
• W ymagania zgodności - wymagania związane z systemami i procesami działającymi wewnątrz firmy klienckiej, które m ogą zostać zmienione przez klienta
Potrzeba wprowadzenia zmian może wywodzić się z nowej cechy, którą zdefiniował klient lub też może być wynikiem błędu wykrytego podczas testowania lub kodowania (Rys. 4). Jednak bez względu na miejsce odkrycia zmian należy uwzględnić jej wpływ na wymagania, informacje zawarte w dokumencie wizji, napisany kod, przypadki testowe. Aby nie dopuścić do niezgodności i pracy nad nieaktualnymi wymaganiami tego typu zmiany wprowadza się od „góry do dołu”, tj.: najpierw zmienia się informacje zawarte w dokumencie wizji, potem w specyfikacji wymagań, a dopiero potem elementy projektu i przypadki testowe.
W przypadku pojawienia się zmiany nie należy od razu przechodzić do jej wprowadzenia. Najpierw należy dokładnie j ą przeanalizować, a dopiero później podejmować jakieś działania. Z reguły powoływany jest specjalny zespół do zarządzania zm ianą (CCB - Change Control Board), który zajmuje się weryfikacją takich ewentualności17. Dopiero po wydaniu przez nich decyzji związanej z daną
---Rys. 4. Źródła zmian w poszczególnych etapach życia systemu16
W czasie analizowania takiej zmiany należy rozpoznać konsekwencje takich działań, ich wpływ na koszty, ilość pracy, jaka przepadnie w przypadku 17 IBM Corporation “Rational RequisitePro - User Guide” (2002)
http://www306.ibm.com/software/rational/
akceptacji zmiany, wymagania, które ulegną zmianie, a także wpływ tych działań na linię bazową. W momencie, gdy decyzja o zmianie zostanie podjęta to kolejnym krokiem jest analiza jej wpływu na inne elementy systemu (oprogramowanie, kod, interfejsy, inne systemy, testy) oraz oszacowanie związanych z tymi działaniami kosztów. Końcowym etapem jest implementacja takiej zmiany, czyli uwzględnienie jej w dokumentacji wymagań.
Pojawianie się różnego rodzaju zmian wymaga ciągłego sprawdzania, czy definiowane elementy są zgodne z wcześniejszymi założeniami. Dlatego też weryfikacja wymagań jest bardzo ważnym elementem w cały procesie.
Korygowanie wszelkich nieścisłości w późniejszych etapach jest bardzo kosztowne, dlatego też najlepiej wychwycić je na początku. Weryfikacja wymagań definiowana jest następująco:
Def.3: Weryfikacja wymagań je s t procesem oceniania systemu lub jeg o komponentów określający, czy produkt będący na danym etapie spełnia wszystkie oczekiwania zdefiniowane na początku tego etapu ” 18
Ważne jest dopilnowanie, aby wszelkiego rodzaju niepotrzebne wymagania, prowadzące do wykonania niepotrzebnej pracy, zostały usunięte.
Należy przy tym pamiętać, że weryfikacja nie oznacza sprawdzenia poprawności działania, a jest to tylko upewnienie się, że uwzględniono wszystkie aspekty niezbędne z punktu widzenia produktu. Istnieje wiele technik weryfikacji wymagań, np.: analiza tworzonej specyfikacji, przedstawianie klientowi prototypów produktu, przeprowadzenie testów, automatyczna analiza niesprzeczności. Jednak największą rolę w procesie weryfikacji odgrywa możliwość śledzenia wymagań poprzez różne stadia życia systemu, począwszy od analizy aż po jego implementację.
Stosowanie śledzenia wymagań pomaga dopilnować, czy system realizuje całą funkcjonalność i czy wszystkie wymagania zostały uwzględnione podczas jego implementacji. Przedstawienie zebranych wymagań i powiązanie ich ze sobą, pozwala na lepsze ich zrozumienie. W przypadku zmian wymagań łatwiej jest też aktualizować wszystkie elementy mające coś wspólnego ze zmienionym wymaganiem. Istnieje wiele strategii śledzenia, jednak najczęściej polecaną (Rys.
5) jest podejście, w którym śledzenie rozpoczyna się od cech i potrzeb udokumentowanych w dokumencie wizji poprzez przypadki użycia, aż do elementów utworzonych podczas projektowania. Śledzenie może obejmować ogromna liczbę elementów, dlatego trzeba umieć oszacować liczbę tych spośród nich, które zostaną poddane śledzeniu, ponieważ koszty takich zabiegów m ogą być istotne.
18 Software Engineering Standards Committee of the IEEE Computer Society
“IEEE Standard for Software Verification and Validation” (2004)
Rys. 5. Zależności pomiędzy elementami w RUP19
Relationships:
- direct only
STRQ1: Zakupbiletuza... ZakupbiletuzapośrednictwemInternetulub telefonukomórkowego STRQ2: Dostosowanietaryf i ofertdo. Dostosowanietaryf i ofertdopreferencji Klienta STRQ3: Wykonywanieanaliz Wykonywanieanaliz STRQ4: Definiowanieprogramów... Definiowanieprogramówlojalności owych
FEA T! : Rejestracja użytkownika 1Î L 3 M
FE AT 2: Przegląd listy połączeń é> i
FEAT3: Codzienna aktualizacja lokalnej bazy...
FEAT4: Uwierzytelnianie użytkowników systemu [ FEAT5: Z akup biletu
FEATG: Anulowanie zakupionego biletu çù
FEAT7: Generowanie listy rezerwacji dla danego... .... | é>
FEAT8: Zarządzanie użytkownikami __ T _ I ;
FE AT 9: Generowanie statystyk
FE AT 10: Określanie zniżek dla klienta cÛ
FEAT11: W ysyłka ofert marketingowych tS 2 Rys. 6. Śledzenie wymagań w ReąuisitePro
19 IBM Corporation “IBM Rational ReąuisitePro - Evaluation Guide” 2003
W metodyce RUP (Rys. 6) wszystkie elementy zależne od siebie w jakiś określony sposób przedstawia się na tzw. macierzy zależności, gdzie widać wszystkie powiązania. Przy wykorzystaniu narzędzi wspomagających pracę z wymaganiami można szybko znaleźć elementy, które nie zależą od innych.
Przykładem może być utworzenie takiego przypadku użycia, który nie odpowiada żadnej z wcześniej zdefiniowanych cech. Taka sytuacja jest szybko wychwytywana i zgłaszana do korekty. Tego rodzaju weryfikacja nie jest czynnością jednorazow ą i w trakcie pracy nad systemem trzeba j ą przeprowadzać wielokrotnie.
Warto nadmienić, że stosowanie weryfikacji nie daje nam stuprocentowej pewności, że utworzony produkt będzie działał prawidłowo. Istotne jest bowiem przeprowadzenie walidacji wymagań, która jest definiowana następująco:
Def.4.: Walidacja wymagań je s t procesem oceniania systemu lub jeg o komponentów umożliwiającym określenie, czy zrealizowany projekt będzie w pełni zgodny z wyspecyfikowanymi wymaganiami ”20
W zrealizowaniu tego kroku pom agają testy akceptacyjne, które znacznie zmniejszają zagrożenie rozminięcia się z wymaganiami, jeśli przeprowadza się je w każdej iteracji. Można określić je jako zbiór scenariuszy, które stanowią symulację działania tworzonego systemu. Podawany jest tu zestaw wejść do sytemu i oczekiwane wyniki. W prawidłowo prowadzonym projekcie testy akceptacyjne powinny wywodzić się z przypadków użycia. Jednocześnie powinny uwzględniać możliwości sprzętowe, współpracę z innymi systemami, dlatego najczęściej przeprowadza się je u klienta, w środowisku, w jakim system będzie później funkcjonować. W celu zweryfikowania, czy stworzono odpowiednią ilość przypadków testowych, wykorzystuje się tu macierz zależności, która zapewni, że dla każdego przypadku użycia zostanie zaplanowany test.
Metodyka RUP wspiera proces weryfikacji i walidacji poprzez liczne listy kontrolne, które zawierają liczne wytyczne dotyczące wymagań i związanych z nimi artefaktami. Możemy znaleźć tam wskazówki w szczególności dotyczące przypadków użycia, specyfikacji wymagań i ich atrybutów.
Podsumowanie
Etap cyklu życia oprogramowania związany z wymaganiami jest bardzo istotnym aspektem w procesie wytwórczym oprogramowania. N ie bez powodu w wielu podejściach figuruje jako jeden z początkowych kroków pracy nad tworzonym systemem. Jak wiadomo, koszty naprawy wszelkiego rodzaju błędów niewykrytych na początku realizacji przedsięwzięcia będą wzrastać wraz z postępem prac nad projektem, dlatego też istotne jest skompletowanie wymagań we wczesnych etapach.
20 Software Engineering Standards Committee of the IEEE Computer Society
“IEEE Standard for Software Verification and Validation” (2004)
Zdefiniowanie oczekiwanej funkcjonalności jest najistotniejszym elementem pracy nad jakimkolwiek przedsięwzięciem. Oczywiście w zależności od zaistniałej sytuacji przeprowadza się to w sposób bardziej lub mniej szczegółowy, ale wszystko to zależy od dziedziny późniejszego zastosowania tworzonego systemu. Zastosowanie odpowiednich narzędzi wspomagających ten proces umożliwia dostarczenie produktu, który może w lepszym stopniu zadowolić klienta. To zadowolenie może mieć istotne przełożenie na wynik finansowy dostawcy oprogramowania i tutaj koło się zamyka ...
ftî f. >.'■
* «r <:x£ V-'-V ■• .
R O Z D Z IA Ł III
Z A R Z Ą D Z A N IE P R O J E K T A M I IT - M O D E L M A P O W A N IA K O M P E T E N C J I I A K T Y W N O Ś C I Kazimierz FRĄCZKOW SKI, Aleksandra SIDORCZYK
Wprowadzenie
W edług raportu „CHAOS” opracowanego przez Standish Group, w 1994 roku jedynie 16% projektów informatycznych zakończyło się sukcesem [10]. W roku 2000 liczba udanych projektów wzrosła do 28% [9], a w roku 2004 wyniosła jedynie 29% [8]. Liczba projektów kończących się porażką jest niepokojąca, zwłaszcza, że na przestrzeni kilku ostatnich lat obserwuje się lawinowy wzrost zapotrzebowania na oprogramowanie, którego rośnie złożoność oraz obszary zastosowań. Dodatkowo należy pamiętać, że zdecydowana większość przedsięwzięć z innych dziedzin kończy się sukcesem.
Jakie są zatem przyczyny niepowodzeń projektów informatycznych? Jakie są zalecenia, aby zmniejszyć wskaźnik projektów które kończą się klęska? Przede wszystkim informatyka jest stosunkowo m łodą dziedziną, w której brakuje wypracowanych standardów, norm postępowania. „W szystkie kłopoty wynikają ze stosowania niewłaściwych metod (albo z pracowania w ogóle bez metod) ...
Innymi słowy, przyczyną marszu ku klęsce jest nasza głupota albo nieudolność”
[1]. Doświadczenie jest tym czynnikiem, który w znacznym stopniu determinuje sukces podejmowanych działań. Należy zatem pracować nad standaryzacją prowadzenia projektów IT, nad rozwijaniem i porządkowaniem procesu zarządzania przedsięwzięciami informatycznymi. Zarządzanie projektem informatycznym obejmuje całą serię działań niezbędnych do jego satysfakcjonującej realizacji, takich jak: zarządzanie czasem, zakresem, kosztami, a także zasobami ludzkimi. Koncentracja na wszystkich wyżej wymienionych elementach jest warunkiem koniecznym sukcesu przedsięwzięcia. Nie można jednak zapominać, że projekty informatyczne są realizowane przez ludzi i to właśnie zespół projektowy w dużej mierze decyduje o ich powodzeniu. Jak powiedział Bjame Stroupstrup „Projektowanie i programowanie to zajęcia ludzkie;
zapomnij o tym i wszystko stracone”. Ludzie stanowią kluczowy czynnik sukcesu projektu. Od ich kwalifikacji i umiejętności, zachowań i nastawienia zależy czy przedsięwzięcie się powiedzie. „W ybór wykwalifikowanych pracowników jest jak ulokowanie pieniędzy w banku” jak stwierdził John Boudreau. Jednak temat zarządzania kapitałem ludzkim, zarządzania zasobami jest w dalszym ciągu poruszany jedynie w tle innych aspektów realizacji przedsięwzięć informatycznych. Problem polega na tym, że cały proces alokacji zasobów w projektach bazuje przede wszystkim na kryteriach czasowych. „Zarządzanie zasobami to proces kontrolowania ich dostępności, dyspozycyjności” [6]. Jednak zarządzanie zasobami to nie tylko panowanie nad czasem, to również właściwy
39
dobór ludzi do zadań projektowych na podstawie ich kompetencji czyli wiedzy, umiejętności, doświadczenia. „Wiedza to pieniądz.” - jak powiedział Tom Pennington. Jednak, żeby wiedza zaczęła przynosić zyski trzeba umieć nią efektywnie zarządzać, optymalnie j ą wykorzystywać.
Dekompozycja projektu na mniejsze podprojekty, fazy oraz aktywności to zalecenia wynikające z badań Standish Group, które m ają przyczynić się do zwiększenia szans na zakończenie projektu sukcesem. Dopiero aktywności, wyodrębnione w związku z koniecznością wykonania określonej pracy, niezbędnej do dostarczenia zaplanowanego produktu czy usługi, wskazują pożądane kompetencje konieczne do satysfakcjonującego wykonania zlecenia.