O tak zwanym kryzysie oprogramowania mówi się od tak dawna, tak dużo i często tak mało oryginalne rzeczy, że znudzeni przywyczailiśmy się do niego jako do nieodłącznego składnika informatycznej rzeczywistości. Istotnie, doświadczenia ostatnich lat utwierdziły większość osób w przekonaniu, że faktycznie nie ma "srebrnych kul" i niezależnie od proponowanych co jakiś czas przez speców od inżynierii oprogramowania nowinek, wspomniany kryzys ma się całkiem dobrze. Jest to prawda zarówno w Polsce, gdzie spektakularnym przykładem może być marny los pewnego niezwykle ważnego projektu realizowanego przez jedno z niezwykle ważnych ministerstw, jak i w krajach o znacznie dłuższej tradycji informatycznej.

Rola zarządzania w projektach informatycznych

O tak zwanym kryzysie oprogramowania mówi się od tak dawna, tak dużo i często tak mało oryginalne rzeczy, że znudzeni przywyczailiśmy się do niego jako do nieodłącznego składnika informatycznej rzeczywistości. Istotnie, doświadczenia ostatnich lat utwierdziły większość osób w przekonaniu, że faktycznie nie ma "srebrnych kul" i niezależnie od proponowanych co jakiś czas przez speców od inżynierii oprogramowania nowinek, wspomniany kryzys ma się całkiem dobrze. Jest to prawda zarówno w Polsce, gdzie spektakularnym przykładem może być marny los pewnego niezwykle ważnego projektu realizowanego przez jedno z niezwykle ważnych ministerstw, jak i w krajach o znacznie dłuższej tradycji informatycznej.

Wszystko to nie oznacza jednak, że upowszechnianie się systematycznego podejścia do tworzenia systemów

informatycznych, nowoczesnych sformalizowanych metodyk analizy i projektowania, wreszcie komputerowych narzędzi wspomagających, to tylko sposób na poprawę samopoczucia informatyków i ich szefów, bez realnego znaczenia. Nie jest tak i z pewnością należy się cieszyć, że postępuje modernizacja i systematyzacja metod pracy zespołów projektowych. Nie można jednak uniknąć próby odpowiedzi na pytanie, dlaczego te pozytywne zmiany nie zawsze przynoszą oczekiwane efekty. Ten artykuł to jedna z możliwych odpowiedzi na to pytanie. Według niej przyczyna naszych kłopotów, ale też i szansa na ich zmniejszenie, kryje się w zarządzaniu pracą zespołu.

Dużą popularność zyskały ostatnio prace przeprowadzone w Instytucie Inżynierii Oprogramowania Uniwersytetu Carnegie-Mellon w Pittsburgu, poświęcone dojrzałości procesów produkcji oprogramowania. Proponowany w nich tzw. model CMM wyróżnia kilka typowych poziomów dojrzałości, na których mogą znajdować się organizacje. Nie zagłębiając się w ich omawianie, chcemy polecić uwadze Czytelników podstawową konkluzję wynikającą z omawianych badań. Według niej, zarządzanie pracą zespołów realizujących projekty informatyczne ma zasadnicze znaczenie dla dojrzałości procesu produkcji oprogramowania. Dojrzałość zaś to stabilność, przewidywalność i ciągłe podnoszenie skuteczności, czyli trzy elementy, których brak jest najbardziej dokuczliwy w obecnej praktyce informatycznej.

Zarządzanie: ludzie i ich role

Skoro zarządzanie jest czymś tak ważnym i obiecującym, to warto byłoby wiedzieć dokładniej, co kryje się pod tym

terminem, z pozoru bliższym menedżerom niż informatykom. Najprościej jak można, zarządzanie to proces interakcji

dokonujących się w wieloosobowym środowisku realizacji projektu informatycznego. W jego skład wchodzą ludzie o

różnych kwalifikacjach, spełniający różne role i obarczeni różnymi zakresami odpowiedzialności. Z pewnością postacią najbardziej eksponowaną, na której ciąży największa odpowiedzialność, jest szef projektu.

Jego rola polega na:

a) planowaniu, czyli określaniu, jakie czynności (zadania) muszą być wykonane, aby projekt zakończył się sukcesem

jakie są ich zależności logiczne, techniczne i czasowe, jakich wymagają one zasobów i kwalifikacji oraz wreszcie

jakie są kryteria ich zadowalającego zakończenia

b) szacowaniu złożoności i pracochłonności poszczególnych zadań

c) sporządzaniu na podstawie powyższych oszacowań harmonogramu realizacji projektu, określającego terminy

realizacji poszczególnych zadań (być może w wariantach: optymistyczny, przypuszczalny, pesymistyczny)

d) rozdzielaniu zadań do wykonania poszczególnym członkom zespołu (wykonawcom)

e) śledzeniu na bieżąco wykonywania zadań przez poszczególnych wykonawców

f) kontroli przepływu "półproduktów" pomiędzy wykonawcami

g) interwencjach w przypadku zagrożenia planowej realizacji projektu

h) wyciąganiu wniosków z obserwacji przebiegu realizacji projektu, które pozwolą lepiej zaplanować kolejne projekty.

Wykonawcy projektu realizują zadania zaplanowane i przydzielone im przez szefa projektu, być może korzystając z

"półproduktów" pochodzących od innych wykonawców, i starając się dotrzymać ustalonych terminów. Niezależnie od tego, jak im się to udaje, składają szefowi raporty z postępów swoich prac, umożliwiając mu śledzenie przebiegu realizacji projektu. Oni także wyciągają (czy też powinni wyciągać) wnioski z prac nad aktualnym projektem, które być może pozwolą im na większą skuteczność w przyszłości.

Nieodłącznym składnikiem zarządzania, zarówno z punktu widzenia szefa projektu, jak i podlegających mu członków

zespołu, jest odpowiednia dokumentacja. Dokumentacja taka to nie tylko szczegółowy opis planu, harmonogramu itd. oraz "odfajkowywanie" kolejnych zadań w miarę ich realizacji, lecz także zapis dynamicznego procesu zachodzących w zespole interakcji, bez którego wyciąganie jakichkolwiek usprawniających wniosków na przyszłość byłoby bardzo trudne.

Skoro mniej więcej wiemy, czym jest zarządzanie, łatwiej jest nam z pewnością zrozumieć i docenić jego rolę.

Najbardziej przekonującym argumentem może być, jak się wydaje, próba wybrażenia sobie losów nietrywialnego

wieloosobowego projektu, w którym sprawnego zarządzania nie ma. Realizacja takiego projektu byłaby tak chaotyczna i żywiołowa, że jedynie wybitne kwalifikacje uczestniczących w nim osób mogłyby uchronić go przed rozpaczliwą klęską. Żaden rozsądny sponsor nie będzie jednak opierał sukcesu projektu na dostępie do superinformatyków. Podobnie, nikt nie zechce powierzyć grupie nawet bardzo dobrych programistów wyłącznej kontroli i pełni władzy nad projektem. Tak więc potrzebujemy zarządzania i artykuł ten można by już zakończyć, gdyby miała to być jego jedyna teza. Ale tak naprawdę ma to być artykuł o tym, jak można poprawić zarządzanie, które przecież, chociaż na ogół niedostatecznie sprawne i skuteczne, w większości poważnych organizacji istnieje. Spróbujemy przekonać Czytelników, że w tym ambitnym zadaniu pomocny może być pakiet Process Engineer

firmy LBMS.

LBMS Process Engineer: rządź i zwyciężaj

Nie jest naszym celem ani przedstawienie wszechstronnego opisu produktu, którym się zajmujemy, ani atrakcyjnej

broszury reklamowej. Skupimy się zatem, unikając przy tym nadmiernej szczegółowości, na wybranych właściwościach pakietu, wybranych oczywiście z uwzględnieniem wszystkiego, co napisaliśmy wyżej. Będziemy się w ten sposób starali zaprezentować go jako zestaw współpracujących ze sobą narzędzi, które łącznie tworzą komputerowe środowisko w pragmatyczny sposób wspomagające zarządzanie w projektach informatycznych. Nie próbując zautomatyzować czegoś, czego zautomatyzować się nie da - procesu dynamicznych interakcji

w wieloosobowym zespole - narzędzia te pozwalają poszczególnym jego członkom pełnić swoje role bardziej

sprawnie i skutecznie.

Process Enginer, dostępny od niedawna w wersji 3.0, to pakiet złożony z czterech zasadniczych komponentów: Project Manager, Activity Manager, Process Library i Process Manager, które są narzędziami działającymi w środowisku Windows. W tej właśnie kolejności, najlepiej odpowiadającej celom tego artykułu, poświęcimy nieco uwagi każdemu z tych komponentów.

PE/Project Manager: warsztat pracy szefa projektu

Narzędzie to wspomaga szefa projektu we wszystkich jego codziennych czynnościach i aby ogólnie omówić zakres jego funkcji, należałoby powtórzyć tu zamieszczone wyżej wielopunktowe wyliczenie określające typowy zakres

obowiązków osoby kierującej realizacją projektu informatycznego. Oczywiście nie zamierzamy tego robić

próbując w zamian trochę bliżej scharakteryzować sposób, w jaki Project Manager może pomóc w wykonywaniu niektórych z tych czynności.

Sprawą pierwszą, nie tylko co do chronologii, lecz i co do znaczenia, jest planowanie. Otóż szef projektu dostaje

możliwość zautomatyzowanego utworzenia szczegółowego planu projektu. Plan taki powstaje na podstawie szablonu wybranego z biblioteki procesów, o której będzie mowa dalej, przez jego konkretyzację i dopasowanie do konkretnych wymogów danego projektu. Automatyzacji podlega zarówno wybór najbardziej odpowiedniego szablonu, jak i jego odpowiednia modyfikacja.

Uzyskany w wyniku tego postępowania plan prezentowany jest jako hierarchiczny diagram opisujący logiczną strukturę projektu w dekompozycji na zadania i podzadania. Dla każdego z nich można następnie oszacować złożoność (pracochłonność) za pomocą przypisanej mu odpowiednej metryki, określonej przez wykorzystywany szablon (ewentualnie zmodyfikowanej), co bezpośrednio prowadzi do wygenerowania harmonogramu i

przypisania poszczególnych zadań wykonawcom w sposób zapewniający właściwy przepływ pracy. Ułatwia to zapewniona przez program Project Manager integracja z popularnymi narzędziami szeregowania zadań w projektach, np. Microsoft Project.

Z kolei dzięki sprzężeniu z innym komponentem pakietu, PE/Activity Manager oraz z wykorzystaniem poczty

elektronicznej (np. Microsoft Mail, Lotus Notes) szef projektu może członkom zespołu zlecać zadania do wykonania.

Więcej o tym, co zawierają takie zlecenia i co się z nimi dzieje, powiemy dalej. Jeśli ostatecznie wykonawca wykonana

swoje zadanie, powstały w wyniku jego pracy produkt wyjściowy może być jednym z produktów wejściowych dla innego wykonawcy realizującego inne zadanie. Szef projektu może, stosownie do planu i harmonogramu projektu, sterować tym przepływem "półproduktów".

Jak już wiemy, komunikacja szefa projektu z wykonawcami nie ogranicza się do zlecenia zadań i przyjęcia wyników. Za pomocą tych samych mechanizmów szef na bieżąco śledzi przebieg realizacji poszczególnych zadań, otrzymując od członków zespołu raporty. Pozwala mu to na natychmiastowe reagowanie na ewentualne zagrożenia dla sukcesu całego przedsięwzięcia, np. przez korekty harmonogramu, modyfikację oszacowań pracochłonności, przesunięcie niektórych zadań na innych wykonawców itd. Dokumentacja całego tego procesu powstaje w formie elektronicznej bez żadnego dodatkowego kosztu, w pełni automatycznie.

PE/Activity Manager: warsztat pracy członków zespołu

Oczywiście, podstawowymi narzędziami pracy dla członków zespołu projektowego są te, którymi posługują się w celu wykonania przydzielonych im zadań. Jednak Activity Manager może im istotnie pomóc, zanim w ogóle przystąpią do realizacji zadania, w jej trakcie, jak i po jej zakończeniu. W jaki sposób?

Project Manager, którym posługuje się szef projektu, pozwala mu na przesyłanie zadań wykonawcom za pomocą poczty elektronicznej. Otóż właśnie na drugim końcu tego kanału transmisyjnego jest Activity Manager. Jego użytkownik odbiera przekazane mu przez szefa zlecenie, które obejmuje specyfikację zadania do wykonania, określenie dostępnych na wejściu zasobów i "półproduktów" oraz wymagań, jakie muszą spełniać produkty wyjściowe, proponowaną metodę realizacji i listę narzędzi, jakie w tym celu należy wykorzystać. W przypadku wątpliwości co do metody wykonawca może odświeżyć sobie jej znajomość korzystając z automatycznie realizowanej referencji do jej hipertekstowej szczegółowej instrukcji (pochodzącej z odpowiedniej biblioteki). Każde z

proponowanych narzędzi można zaś od razu uruchomić za pomocą jednego ruchu myszą.

Mimo tych wszystkich atrakcji wykonawca może jednak być niezbyt uszczęśliwiony nadesłanym mu zleceniem. Być może oceniając własne kwalifikacje uzna, że nie jest w stanie go zrealizować, bądź nie uda mu się tego zrobić w wymaganym czasie. Nieuwzględnienie przez środowisko zarządzania możliwości takiej sytuacji byłoby przejawem braku realizmu, toteż Activity Manager pozwala wykonawcy na przyjęcie wobec zlecenia jednej z trzech możliwych postaw: akceptacji, odrzucenia lub negocjowania warunków. W tym ostatnim przypadku proces negocjacji, które mogą dotyczyć np. osłabienia wymagań lub wydłużenia terminu, jak i cała komunikacja w omawianym środowisku, odbywają się za pomocą poczty elektronicznej, jest automatycznie dokumentowany. Dokumentacja ta może stać się źródłem wniosków służących poprawieniu planowania w przyszłych projektach.

Jeśli, być może po negocjacjach, wykonawca przyjmie zadanie do realizacji, szefowi projektu składa raporty na temat jej przebiegu. Jak już wspomniano wyżej, raporty te pozwalają temu ostatniemu na śledzenie postępu prac w projekcie i wczesne wykrywanie zagrożeń, informują go także o rzeczywistej pracochłonności poszczególnych zadań, dając podstawy do poprawy dokładności oszacowań i modyfikacji stosowanych metryk.

PE/Process Library: sprawdzone wzory

Biblioteka Process Library dostarcza rozbudowywalnego zestawu tzw. szablonów procesów, szczegółowo opisujących wiele sprawdzonych w praktyce cykli projektowych. Przykładowe standardowo dostępne cykle, to klient/serwer, cykl obiektowy albo RAD (ang. Rapid Application Development). Opis każdego procesu obejmuje hierarchiczną dekompozycję na podzadania, zależności czasowe między nimi (następstwa), wykorzystywane do ich realizacji metody i narzędzia, role poszczególnych członków zespołu realizującego proces oraz metryki wykorzystywane do szacowania pracochłonności, tworzenia harmonogramu i oceny postępu pracy. Dla poszczególnych zadań procesu dostępne są szczegółowe hipertekstowe instrukcje, z których mogą

korzystać wykonawcy podczas ich realizacji. Właśnie jeden z takich szablonów, najlepiej odpowiadający aktualnym wymogom, wybiera szef projektu przystępując do jego planowania za pomocą narzędzia Project Manager.

Biblioteka procesów zawiera również standardowy zestaw predefiniowanych modeli metryk, służących do szacowania złożoności, oceny ryzyka, mierzenia faktycznej pracochłonności i modyfikacji harmonogramu. Różne modele odpowiadają różnym poziomom szczegółowości i mogą być stosowane na różnych etapach realizacji projektu.

Ważne jest, że organizacje używające pakietu Process Engineer nie są ograniczone w swojej działalności do

standardowej zawartości Process Library w postaci dostarczonej przez LBMS. Oprócz możliwości tworzenia

własnych procesów i modyfikacji istniejących, o czym będzie mowa dalej, mogą one wykorzystać szereg innych procesów udostępnianych w ramach zainicjowanego przez LBMS programu ProcessWare. Jest to program współpracy, który zachęca organizacje do gromadzenia najlepiej sprawdzonych w praktyce procedur postępowania, które zasługują na to, aby stać się powszechnie stosowanymi standardami, i udostępniania ich jako elektronicznych szablonów procesów. W ramach tego programu zawarte zostały porozumienia z wiodącymi dostawcami

oprogramowania, m.in. Lotus Development Corp., Powersoft Corp. i SQA Inc. W wyniku tej współpracy powstały szablony procesów:

* Lotus ViP Process, opracowany we współpracy z Lotusem, który dostarcza instrukcji na temat tworzenia aplikacji

Lotus Notes za pomocą pakietu Lotus ViP (Visual Programmer)

* Powersoft PowerProcess, opracowany przy współdziałaniu z firmą Powersoft, dostarcza szczegółowych instrukcji

dotyczących tworzenia aplikacji klient/serwer za pomocą pakietu PowerBuilder tej firmy

* SQA Process, szablon do metodycznego testowania aplikacji klient/serwer z wykorzystaniem pakietu TeamTest firmy SQA.

PE/Process Manager: zarządzanie procesami

Process Manager jest narzędziem, które służy do modyfikacji zawartości biblioteki procesów. Może się to odbywać przez definiowanie nowych procesów oraz doskonalenie istniejących, na podstawie obserwacji zgromadzonych w trakcie realizacji projektów, w których je zastosowano. Podobnie, można definiować nowe lub modyfikować istniejące metryki szacowania złożoności i postępu prac. W ten sposób organizacja może w kontrolowany i udokumentowany sposób poprawiać stosowane w niej metody pracy.

Podsumowanie, czyli dlaczego to się opłaca

Sprawne i skuteczne zarządzanie w projektach informatycznych opłaca się wszystkim zainteresowanym. Wykonawcom, ponieważ dostają dobrze określone zadania do wykonania, z realistycznie ustalonymi terminami i możliwością negocjacji oraz, przekazując swoje obserwacje i doświadczenia, mają wpływ na poprawę planowania i szacowania w przyszłości. Szefowi projektu, ponieważ może łatwiej i bardziej wiarygodnie planować, lepiej kontrolować realizację i skutecznie interweniować w celu zapobieżenia ewentualnym zagrożeniom. Organizacji, w ramach której realizowany jest projekt, ponieważ zwiększa wydajność pracy, umożliwia ocenę i zarządzanie personelem, daje większą stabilność i bezpieczeństwo realizacji projektów. I wreszcie klientowi, dla którego projekt jest wykonywany, ponieważ może on otrzymać produkt lepszej jakości, spełniający jego wymagania, bez drastycznego przekroczenia terminu i budżetu. Artykuł ten wskazał jedną z możliwości obiecujących

przybliżenie się do wszystkich tych korzyści.

Paweł Cichosz jest doktorantem na Wydziale Elektroniki i Technik Informacyjnych Politechniki Warszawskiej i współpracownikiem firmy InfoViDE.