Съдържание на статията
Планиране на времето при софтуерни и ИТ проекти
стр.2 - SDLC и RUP - методологията в развитие
стр.3 - Философията Agile - новите ценности
стр.4 - Agile организациите
Всички страници

SDLC и RUP - методологията в развитие

Годините между 1980 и 2000 се характеризират с утвърждаването на обектно-ориентираната методология за разработване на софтуер. През същия период върви усилено „индустриализиране“ на ИТ сектора – имайки развито инженерно средство за програмиране (обектно-ориентираният подход) възниква необходимостта от дефиниране и методика за управление на производствените процеси.

Първата цялостна система за управление на софтуерни проекти е Systems Development Life Cycle (SDLC). Тя е разработена от Американското Министерство на правосъдието. Това е подробна методология за разработване и внедряване на информационни системи. Работният процес следва фазите на класическия водопаден модел, но вече има разработена система за водене на документация, за следене на развитието на процеса и за управление на рисковете.
По-късно системата е възприета във Великобритания под името SLC. Добавени са още правила и подробности, например как да процедираме при разработване със собствен екип и как – при аутсорсинг. Цялата система изглежда „супер“ в очите на всеки администратор или класически ръководител на проект. За съжаление, тя страда от проблемите, от които страда и предшестващият я водопаден модел с неговата изолация на отделните фази на разработката. Методът е подходящ за големи държавни проекти, при които изискванията се знаят от години напред и промяната е малко вероятна. Във всички останали случаи обаче, този метод се проваля.

Безспорно върхът в групата методики, базирани на водопадния модел е всеизвестният Rational Unified Process (RUP). Това е най-мащабният подход, който за пръв път обединява техники от традиционното управление на проекти със специфичните за ИТ индустрията елементи. Разработен е специален език – UML, за моделиране на системата на различни нива. За пръв път в моделирането се включват потребителите и техните начини на взаимодействие със системата.

RUP представя системата като серия от модели. На всеки етап се изгражда нов модел, който се извежда от предходния: модел на сценариите (use case), статичен и динамичен обектен модел, код, тест модел и т.н. Отчитайки, че фазите не могат да бъдат напълно завършени поотделно, се предполага те да се застъпват и да си взаимодействат. Въпреки това управлението на промените се свежда до синхронизирането им във вече направените модели. RUP въвежда и множество „дисциплини“ (правила за работа), които допълнително структуризират и формализират процеса: например дисциплина на моделиране, на кодиране, на тестване и т.н. В процеса се дефинират и итерации, но те обикновено се извършват само в рамките на една фаза, например проектирането минава през няколко итерации.

Самите автори на методиката са наясно, че тя е много „церемониална“ и сложна за цялостно прилагане. Ето защо те препоръчват RUP да се специализира за всеки отделен случай като се избират тези елементи, които биха били най-полезни за конкретния проект и конкретния екип.

RUP има няколко производни методики, например OPEN, които се опитват да премахнат някои недостатъци, свързани с езика UML и с цялостния подход към управлението на проекта.

Всички методологии, базирани на класическата теория за управление на проекти се опират на философията „Big Design Up Front“ (BDUF) – т.е. много усилия за планиране и дизайн на ранните етапи на проекта, преди да започне реалното кодиране. Това звучи много разумно – колкото по-добре е обмислена системата, толкова по-лесно ще се напише реалният код; поправянето на един пропуск, открит на фазата на кодирането струва 100 пъти повече, отколкото корекция във фазата на планирането. Всичко това е вярно. Въпреки това BDUF, приложена в чистия й вид е крайно неуспешна стратегия - просто, защото не адресира главния проблем – изключителната динамика на ИТ сектора. Голяма част от изискванията, дефинирани преди 2-3 месеца днес вече са остарели. Съответният дизайн вече е неадекватен.

Ако стриктно спазваме планове и модели правени в миналото, рискуваме да създадем система, която е остаряла още от първия си ден. Като добавим и факта, че клиентът практически никога не знае всички изисквания към системата от самото начало, става ясно, че борбата с постоянните промени е най-важният проблем в управлението на ИТ проектите. Класиците на управлението на проекти биха казали, че за това си има методи за управление на риска и на промените. Да, но тези методи са оптимизирани за случаите, когато промените и рисковите събития се случват рядко. Когато това е по-скоро правило, вместо изключение, стандартните методи стават крайно неикономични. Необходим е радикално различен способ за управление на проекти в силно нестабилна среда.

Самият аз бях голям привърженик на RUP допреди 7 години, когато ми се наложи да го прилагам на практика за сравнително сложен проект за телекомуникационен софтуер. Тогава изпитах „тъмната страна на силата“. Проектът се разработваше за германския пазар в условията на постоянна промяна в изискванията на клиента, съчетани с промени в нормативната уредба (правилата за изграждане на радио комуникационни мрежи). От един момент нататък осъзнахме, че отделяме по-голямата част от времето си за поддържане на промените в различните модели (use case model, object model, interaction model и т.н.), отколкото да пишем код. Клиентът обаче искаше работеща система, а не набор от синхронизирани теоретични модели. В крайна сметка изоставихме синхронизирането на моделите.