Zgłoszenia zmian

Zgłoszenia zmian są obsługiwane w podobny sposób jak niezgodności, lecz ich źródło ma inną naturę. Nie dotyczą one błędów w oprogramowaniu, ale postulatów związanych z jego usprawnieniami, zmianami itp. Podzielić je można na trzy kategorie:

Nierealizowalne wymagania - podczas realizacji projektu z różnych przyczyn może okazać się, że niektóre wymagania mogą nie dać się zrealizować, czy to na skutek złego oszacowania zasobów projektu, złożoności problemów, czy też błędów w implementacji innych wymagań.

Rozszerzenia - zwykle dotyczą nowych wymagań, które powstają jako wynik przemyśleń twórców i odbiorców przyszłego systemu i są wynikiem analizy dotychczasowych wymagań albo trendów rynku bądź innych źródeł.

Usprawnienia - dotyczą działań, które poprawiają pielęgnowalność oprogramowania i realizację projektu.

Każde zgłoszenie zmian powinno być zapisane w systemie, a jego status odpowiednio śledzony. Zmiany przed realizacją są oceniane na danym poziomie projektu i klasyfikowane do jednej z kilku możliwych kategorii realizacyjnych, np. do natychmiastowej realizacji (priorytet: wysoki, średni, niski), realizacji w przyszłej wersji, zastanowienia, odrzucenia itd. Przed podjęciem decyzji o wprowadzeniu zmian do projektu analizuje się:

rozmiar i zakres zmian

złożoność

ograniczenia czasowe

wpływ na bieżący stan projektu (prace skończone i przyszłe)

zasoby wymagane do realizacji

koszt

ryzyko niepowodzenia

politykę firmy, produktu, projektu

wymagania udziałowców

alternatywne sposoby realizacji zmian.

Jednym z postulatów dobrego zarządzania konfiguracją jest zasada aktualności danych projektowych. Oznacza ona, że w każdej chwili można otrzymać pełny obraz zmian w projekcie, dotrzeć do źródła ich powstania i prześledzić aktualne losy ich realizacji. Już przy małym projekcie niezbędne jest zautomatyzowane narzędzie do zarządzania bazą danych konfiguracyjnych projektu. Doskonale w tej roli sprawdzają się wszelkiego rodzaju systemy kontroli wersji, które nadają się nie tylko do zarządzania wersjami kodu programu, ale także do przechowywania i śledzenia różnych dokumentów, zarówno tekstowych, jak i binarnych. Przykładem takiego systemu o bogatej funkcjonalności i rozbudowanych możliwościach raportowania stanu prac jest pakiet MS SourceSafe.

Kącik praktyka

Niniejszy artykuł jest ostatnim z cyklu omawiającego kluczowe zagadnienia zarządzania projektami informatycznymi. Celem cyklu było skłonienie czytelników do refleksji nad tematyką, którą dobrze znają ze swojej codziennej praktyki zawodowej, uporządkowanie dotychczasowej wiedzy, dostarczenie nowych przemyśleń i zapoznanie z wybranymi narzędziami, które "sprawdziły" się w praktyce. Jeśli jakaś myśl, idea czy sugestia pomoże czytelnikom w rozwiązaniu problemów, jakie napotykają każdego dnia, uznam, że cel cyklu został osiągnięty.

Na koniec jeszcze kilka praktycznych "drogowskazów" na dalszą drogę.

Poniższe zalecenia (best practices) i ostrzeżenia (worst practices) pochodzą od największych autorytetów w dziedzinie zarządzania projektami i produkcją oprogramowania, którzy tworzą grupę opracowującą narzędzia do doskonalenia procesów wytwarzania oprogramowania dla Departamentu Obrony USA. Grupa ta zorganizowana jest pod nazwą Software Program Managers Network. Zachęcam czytelników do zajrzenia na jej internetową stronę www.spmn.com, gdzie znajduje się obszerne rozwinięcie opisanych poniżej praktyk i wiele interesujących narzędzi wspomagających zarządzanie projektami (np. Earned Value).

<hr size=1 noshade>Zarządzanie projektami informatycznymi - część 10