Sztuka prowadzenia projektu

Etap analizy pochłania 30% projektu, 40% zajmuje implementacja. Reszta przypada na testy. Tak rozkłada się w czasie proces powstawania oprogramowania w ComArch SA.

Etap analizy pochłania 30% projektu, 40% zajmuje implementacja. Reszta przypada na testy. Tak rozkłada się w czasie proces powstawania oprogramowania w ComArch SA.

Działająca od ponad 10 lat firma ComArch wypracowała własny standard postępowania ze zleceniami klientów. W momencie podpisywania umowy (kontraktu) wyznaczany jest komitet sterujący, w skład którego wchodzą zarówno przedstawiciele kierownictwa klienta, jak i firmy ComArch oraz - obowiązkowo - kierownicy projektu z obu stron. Komitet spotyka się co najmniej raz w miesiącu lub częściej - zależnie od stanu zaawansowania projektu i bieżących potrzeb. Na każdym spotkaniu kierownicy projektu prezentują stan prac i odpowiadają na pytania uczestników komitetu. Ważne jest, aby w skład komitetu wchodzili ludzie o dużych kompetencjach decyzyjnych zarówno po stronie wykonawcy, jak i odbiorcy systemu. Inaczej żadne uzgodnienia na tym forum nie będą miały mocy sprawczej.

Projektowanie

W grupie projektowej najtrudniejsze zadanie mają analitycy. To na nich spoczywa największa odpowiedzialność. Ich zadaniem jest opisanie modelu biznesu w porozumieniu z klientem, dokonanie wszystkich szczegółowych uzgodnień, a następnie na tej podstawie skonstruowanie podstawowego modelu aplikacji. "Mamy różnych klientów. Są tacy, z którymi schodzimy nawet na poziom pseudokodu, aby lepiej dopracować poszczególne fragmenty algorytmu. Są tacy, których interesuje przede wszystkim wygląd ekranu. Staramy się być elastyczni, ale co do jednego musimy mieć pewność: konieczne jest to samo rozumienie problemu i ten sam obraz rozwiązania" - podkreśla Krzysztof Mendelowski, kierownik projektów informatycznych w ComArch SA.

Informatyka od kuchni

Polskie firmy branży IT znamy z zawieranych przez nie kontraktów, realizowanych wdrożeń, czasem z osiągnięć na rynkach finansowych. Mało o nich wiemy - bo i same się tym nie chwalą - jako o firmach wytwarzających i doskonalących własne produkty, tj. systemy i aplikacje. Bodajże po raz pierwszy postanowiliśmy spojrzeć na krajowe firmy informatyczne, jak na zwykłe przedsiębiorstwa, które projektują, produkują, dbają o serwis i jakość swoich wyrobów. Artykułem o krakowskiej firmie ComArch otwieramy cykl, w którym chcemy przedstawiać krajowych integratorów i domy software'owe "od kuchni".

Efektem pracy analityków jest dokumentacja opisująca bardzo szczegółowo zakres funkcjonalny modułów tworzonego systemu. Zawiera ona opis elementów systemu, warunki operacyjne, algorytmy postępowania, a także zestaw testów, które muszą być wykonane po zakończeniu tworzenia każdego elementu. Zdarza się, że analitycy są informatykami, choć znacznie częściej są specjalistami branżowymi. Podstawowymi umiejętnościami analityka muszą być: myślenie analityczne (np. kompleksowe rozwiązywanie problemów, przewidywanie zagrożeń, tworzenie spójnej i kompleksowej koncepcji rozwiązania), wiedza dziedzinowa, umiejętność konstruktywnej rozmowy z klientem, zdolności interpersonalne i dobra koncentracja.

W tej fazie projektu nie mniej istotna jest rola projektanta. Jest on odpowiedzialny za hamowanie zapędów analityków. Nie wszystko, co da się wymyślić, da się efektywnie zaprogramować. Szef projektantów musi dysponować obszerną wiedzą o technologiach, których używa zespół. Projektanci pracujący nad rozwiązaniami w architekturze dwuwarstwowej przygotowują podstawowe obiekty bazy danych: tabele, procedury składowane, widoki, triggery, zręby kodu. W architekturze trójwarstwowej będzie to, obok modelu danych, model komponentów warstwy środkowej.

Implementacja

Zaprojektowana aplikacja zostaje zaimplementowana przez zespoły prog-ramistyczne prowadzone przez szefów programistów. Ich zadaniem jest stworzenie zadanych przez dokumenty analityczne fragmentów systemu. Programista jednocześnie ma za zadanie wykonanie testów jednostkowych (unit test), czyli podstawowej weryfikacji swojego dzieła. ComArch opracował listę 35. testów standardowych, które dla każdego elementu systemu muszą być wykonane.

Każdy z programistów otrzymuje tzw. niebieską księgę, która zawiera wiele wytycznych, w tym standardy programowania. ComArch wymaga m.in. aby kod był formatowany w konkretny sposób i by nazewnictwo zmiennych było zgodne z pewną konwencją. Istnieją także standardy dotyczące komentarzy. Bardziej doświadczeni pracownicy przeglądają kod stworzony przez mniej doświadczonych i mogą prosić autora o poprawki. Celem wprowadzenia takich procedur w ComArchu jest umożliwienie "przejęcia" kodu przez inną osobę niż jego autor. Zdarza się przecież, że programista, który wykonał dany element systemu, w określonym czasie jest niedostępny. Jeżeli standardy programowania są stosowane prawidłowo, poprawka w kodzie może być wykonana przez inną osobę.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200