Odwieczna dyskusja o metodyce
Computerworld, 13 lutego 2007 r., Antoni Bielewicz
W połowie lat dziewięćdziesiątych badacze doliczyli się ponad 1 tysiąca metodyk rozwoju oprogramowania, opartych na różnych cyklach życia systemu. Liczba ta jest zapewne nawet wyższa, gdyż ewolucja modeli cyklu życia systemu i metodyk rozwoju oprogramowania nadal trwa.

Dyskusje o tym który z modeli cyklu życia systemu (System Development Life Cycle) najtrafniej oddaje charakter pracy programistów, a także która z metodyk opartych na tych modelach najlepiej sprawdza się podczas realizacji projektów IT są niemal tak stare jak pierwsze złożone systemy informatyczne. Od prawie trzydziestu lat badacze uporządkować doświadczenia praktyczne, nadając im postać modeli, od tych najprostszych takich jak model kaskadowy, poprzez modele ewolucyjny i przyrostowy, aż po bardziej skomplikowane takie jak np. model spiralny

Opracowywanie kolejnych modeli i opartych na nich metodyk doprowadziło powstania setek mniej lub bardziej dopracowanych metod rozwoju oprogramowania. Jak oszacował Nimal Jayaratna, profesor Manchester Metropolitan University Business School i autor książki „Understanding and Evaluating Methodologies-. NIMSAD: A Systemic Framework" w połowie lat dziewięćdziesiątych programiści korzystali z ponad tysiąca różnych metodologii. Ponad 80% z nich została wykorzystana w mniej niż 10 projektach.

Wiele wskazuje na to, że ewolucja modeli cyklu życia systemu i metodyk rozwoju oprogramowania będzie trwać nadal. „Każdy szef projektu korzysta z modeli i metodyk, które najlepiej przystają do przyjętych celów. Nie można zatem oceniać wypracowanych do tej pory modeli jako lepsze lub gorsze. Można raczej mówić o lepszym lub gorszym dopasowaniu metodyki do realizowanych celów" - mówi Paweł Zawadka, Business Development Director w firmie ATENA Usługi Informatyczne i Finansowe Sp. z o.o.

Na kierunek tej ewolucji mają wpływ co najmniej dwa czynniki. „Przede wszystkim rosnąca wiedza i oczekiwania odbiorców, a więc zamawiających i użytkowników rozwiązań. Są oni coraz bardziej świadomi swoich oczekiwań względem przygotowywanych aplikacji" - podkreśla Paweł Zawadka - „Nowoczesne metodyki projektowe akcentują coraz większą współpracę twórców systemu z użytkownikiem oraz podkreślają znaczenie zarządzania zmianami. Dzięki tym elementom systemy coraz lepiej spełniają oczekiwania i potrzeby użytkowników".

Z drugiej strony stale rosnący stopień komplikacji projektowanych systemów przy jednoczesnym nacisku na tempo ich przygotowania. „„Warto pamiętać o tym, że OS 360 był przygotowywany przez 10 lat. Dziś nikt nie może sobie pozwolić na luksus tak długiej pracy nad rozwiązaniem. Nawet jeśli ma do dyspozycji nieporównywalnie więcej środków" - mówi Jan Pieczykolan, kierownik projektów z firmy DRQ.

Wybór nie do końca niezależny

Wybór modelu i metodyki zależy od kilku czynników. Przede wszystkim od charakteru realizowanego projektu. „Innych będą używali programiści zatrudnieni w firmie, która przygotowuje system na rynek masowy i ma możliwość elastycznego zarządzania zakresem funkcjonalnym oraz terminami realizacji poszczególnych faz projektu. Innych specjaliści zajmujący się realizacją systemów na zamówienie" - mówi Zbigniew Gajewski, dyrektor biura rozwoju systemów ERP w firmie Comarch S.A.

Zależy także od rozmiarów zespołu. Inaczej wyglądać będzie model pracy programistów w dużej firmie, w której nad projektem pracuje, kilkadziesiąt, a nawet kilkaset osób. Inaczej w małej firmie programistycznej, gdzie nie ma praktycznie barier komunikacyjnych i każdy z członków zespołu może niemal bez przeszkód przekazać wszelkie uwagi.

W tym drugim przypadki zarządzający zespołem mogą sobie pozwolić na pewną elastyczność. „Rozwijając system rozpoczynamy od zgrubnego zarysu projektu: architektury bazowej oraz podziału na komponenty" - mówi Marcin Kosieradzki, główny architekt w firmie P2Ware zajmującej się rozwojem pakietu wspomagającego zarządzanie projektami. To bardzo istotny element każdego projektu. Pozwala na podział pracy, dalszy rozwój poszczególnych elementów systemu niezależnie od siebie, a także dodawanie lub rezygnowanie z różnych funkcjonalności. „W takim modelu pracy najważniejsze jest dobre zdefiniowanie komponentów oraz punktów styku pomiędzy nimi, a także konsekwentnego trzymania się przyjętej architektury" - mówi Marcin Kosieradzki.

Oczywiście taka metoda tworzenia oprogramowania wymaga wysokich kwalifikacji od pracowników. Muszą być to przede wszystkim ludzie o wysokich kwalifikacjach oraz samodyscyplinie. Dyscyplina jest w takim modelu potrzebna m.in. po to by uniknąć prac robionych skróty. „Jednym z najważniejszych kryteriów jakości kodu jest jego utrzymywalność, a więc możliwość dalszego rozwoju" - mówi Marcin Kosieradzki - „Żeby uniknąć kłopotów wiedzę o tym jak dany kod działa rozpraszamy pomiędzy programistów".

W przypadku firm realizujących systemy „pod klucz" wybór modelu i metodyki jest związany także ze specyfiką zamawiającego. Bardzo silnie zależy od stopnia znajomości zagadnień związanych z implementacją systemów, czy ewentualną historią współpracy pomiędzy dostawcą, a klientem. „Wciągnięcie klienta w realizację projektu, także jeśli chodzi o metodologię jest bardzo ważne." - mówi Przemysław Gnitecki, dyrektor ds. technicznych w firmie ABG Ster-Projekt - „Dzięki takiemu działaniu odbiorca systemu zaczyna lepiej rozumieć uwarunkowania związane z realizacją projektu. Ma świadomość, że to co dostaje w postaci systemu jest wynikiem analiz, a nie tylko naszej nieskrępowanej inwencji". Z tego m.in. powodu firma ABG Ster-Projekt szkoli swoich klientów z metodologii, a nawet elementów analizy systemowej.

Jak mówi Przemysław Gnitecki jego firma stosuje szereg różnych metodyk projektowych. „Tam gdzie problem nie jest nadmiernie złożony, a termin realizacji zadań jest krótki uciekamy się do różnego rodzaju metodyk lekkich" - przyznaje - „W przypadku gdy współpracujemy z klientem po raz pierwszy zwykle korzystamy z tradycyjnych metodyk, ze ścisle podzielonymi etapami prac, regularnymi spotkaniami podsumowującymi z klientem". Taki model pracy pozwala na pewną niezależność zespołów. Opóźnienia w jednym z etapów nie mają dużego wpływu na terminowość zakończenia całego projektu. Zupełnie inaczej niż w przypadku lekkich metodyk takich jak chociażby Scrum, w których brak przygotowania jednego członka zespołu może zaważyć na efekcie pracy całej grupy.

Umiejętny wybór i kompromis pomiędzy metodami lekkimi i ciężkimi to jeden z czynników ułatwiających terminową realizację projektów.

Artykuł powstał na podstawie dyskusji poświęconej ewolucji modeli cyklu życia systemów (Software Develompent Life Cycle) zorganizowanej przez tygodnik Computerworld 24 stycznia br. w Warszawie. Sponsorem Okrągłego Stołu był Microsoft Polska.

Copyright 2016 Atena Usługi Informatyczne i Finansowe S.A.