fbpx

Blog o IT oraz procesie wytwarzania oprogramowania

Na naszym blogu przeczytaj o najczęściej spotykanych problemach i wyzwaniach podczas wytwarzania decykowanego oprogramowania i nie tylko.

Najpopularniejsze modele wytwarzania oprogramowanie

Bardzo często podczas rozpoczęcia prac nad projektem pada pytanie w jakim modelu będziemy współpracować. Postaram się w tym wpisie przedstawić dwa najważniejsze wg mnie modele wytwarzania oprogramowania oraz pokazać ich wady i zalety.

Model Kaskadowy

Możemy zaczynać. Jako pierwszy na tapetę weźmy Model Kaskadowy z ang. waterfall model. W tym modelu każdy kolejne etap pracy następuję po zakończeniu poprzedniego.

Wybierając ten model najważniejszym etapem prac jest definiowanie wymagań oraz projektowanie. Na tym etapie zapadają najważniejsze decyzje, których zmiana z dalszych częściach procesu będzie bardzo czasochłonna oraz kosztowna. Dla tego ten model powinien być wybierany, jeżeli mamy jasno i dokładnie sprecyzowane wymagania co do produktu który chcemy otrzymać.

Do zalet tego modelu należy na pewno patrząc z punktu widzenia klienta jasno określony czas oraz koszt wytworzenia oprogramowania. Na początku procesu wiemy ile każdy z poszczególnych etapów zajmie oraz z jakimi kosztami musimy się liczyć.

Pierwszy problem pojawią się w momencie „spotkania produktu ze światem rzeczywistym”. Pierwsze testy akceptacyjne przez klienta mogą pokazać, że pewne założenia są nietrafione lub pewne rzeczy chcielibyśmy po prostu zmienić/uprościć. Niestety w tym modelu nie mamy możliwości zrobienia tego w trakcie trwania projektu. Ustalenie sztywnego zakresu prac ogranicza nas w tym zakresie.

Aby dokonać zmian/ulepszeń/rozbudowy naszego systemu musimy rozpocząć cały proces od samego początku co wiąże się z kosztami i czasochłonnością.

Dlatego tak, jak pisałem wcześniej proces projektowania jest tak ważny. Kartka przyjmie wszystko i można dokonywać zmian bardzo łatwo, jednak już po implementacji niektóre zmiany są po prostu niemożliwe bądź ich koszt jest nieproporcjonalny do korzyści. Tutaj ważną rolę odrywa zespół projektowo-analityczny który powinien pomóc klientowi zrozumieć czemu pewne rzeczy powinno się rozwiązać inaczej.

Model Iteracyjny

Jako drugiemu przyjrzymy się Modelowi Iteracyjnemu ang. incremental development. Ten model polega na podzieleniu wymagań klienta na małe „paczki” i dostarczaniu ich do testów w możliwie krótkich odstępach czasu zwanych iteracjami.

Podczas pracy w tym modelu bardzo ważną rolę odgrywa bezpośredni i ciągły kontakt klienta z zespołem programistycznym. Pierwszą rzeczą jako należy określić jest odstęp czasu w jakim będzie następować dostarczanie oprogramowanie do klienta. Najczęściej jest to okres od 2 tygodni do 4 tygodni.

Cykl rozpoczyna się od zaplanowania ile czasu w danej iteracji zespół projektowy poświęci na ten projekt. Najczęściej jest to zależne od wymagań klienta.

Następnie przechodzimy do fazy określenia wymagań i wybrania tych które będziemy realizować w tej iteracji. Po tym etapie zespół programistyczny przechodzi do projektowania określonych wymagań i wraz z klientem następuje ich akceptacja.

Teraz przychodzi czas na implementacje rozwiązania i testowanie wewnętrzne. Gdy ten proces się zakończy możemy przystąpić do sprawdzenia czyli przekazania oprogramowania do klienta aby sprawdził czy wszystko jest tak jak chciał.

Po tym etapie rozpoczynamy wszystko od nowa czyli przechodzimy do planowania.

W ten sposób w krótkich odstępach czasu klient dostaje poszczególne części systemu. Jest częścią całego procesu i może po każdej iteracji wprowadzać zmiany w zależności od tego jak jego spojrzenie na gotowy produkt się zmienia. Koszty zmian są stosunkowo nieduże, ponieważ iterację przebiegają w krótkich odstępach czasu. Do plusów tego modelu należy bez wątpienia fakt, że podczas pracy można już wdrożyć tę cześć systemu która jest gotowa.

Oczywiście są też minusy. Bardzo ciężko jest z góry określić budżet projektu jaki będzie potrzebny na jego realizację, ponieważ wymagania są płynne i mogą ulegać dużym zmianą. Kolejnym problemem może być trudność z określeniem podzbiorów funkcjonalności które będą realizowane w pierwszej kolejności, jednak tutaj ważną rolę odgrywa zespół projektowo-analityczny który powinien pomóc klientowi wyszczególnić te funkcje.

Co w takim razie wybrać? Model kaskadowy czy iteracyjny?

Przeszliśmy do bardzo trudnego pytania. Jestem przekonany, że nie ma na nie jednoznacznej odpowiedzi. Myślę, że ważne pytanie jakie powinien zadać klientowi zespół projektowy jest takie czy ma jasno i precyzyjnie zdefiniowane to co chce osiągnąć. Często jest tak, że klient dokładnie wie czego potrzebuje, wtedy możemy wybrać model kaskadowy. Natomiast jeżeli mamy pomysł na produkt, jednak nasza wizja jest jeszcze do końca nie sprecyzowana, bądź chcemy na bieżąco mieć wpływ na powstający produkt i móc wprowadzać zmiany zdecydowanie lepszy będzie model iteracyjny. Ważne jest również aby zrozumieć od czego zależy również całkowity koszt projektu.

A Ty drogi czytelniku jaki model byś wybrał dla swojego projektu?