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

От 60-те години на миналия век насам се полагат систематични усилия ИТ да се превърне от „свободно изкуство“ в индустриална дисциплина със съответните формални процедури и процеси. Но борбата с постоянните промени си остава най-важният проблем при ИТ проектите. Необходим е радикално различен способ за управление на проекти в силно нестабилна среда.

Традиционно, управлението на времето в проекта започва със създаването на т. нар. мрежова диаграма, задаваща всички отделни дейности (задачи), както и сроковете и отговорниците за тях. След това се определят взаимните зависимости между дейностите.

Оттам следва последователността на изпълнение на задачите във времето. За онагледяване най-често се използва диаграма на Гант. Голямото предимство на този метод е неговата универсалност – независимо дали проектът е в областта на строителството, енергетиката или ИТ, разполагаме с еднаква методология. Въпреки това, всяка област има своите специфични особености и натрупаната практика води до създаване на специфични стандарти за тях. Области като строителство, енергетика, различните производства, логистика, администрация отдавна имат установени общоприети работни схеми, които се прилагат с малки вариации от всички в бранша.

Спецификата на ИТ – водопадният VS итеративният модел

Теорията и практиката свързани с управлението на ИТ проектите също се развиват в посока на изграждане на свои специфични стандарти. От 60-те години на миналия век насам се полагат систематични усилия ИТ да се превърне от „свободно изкуство“ в индустриална дисциплина със съответните формални процедури и процеси. Първият опит за стандартизиране на разработването на софтуер прави У. Ройс (W. Royce) през 1970 г. с въвеждането на т.нар. водопаден модел (waterfall model). В него се дефинират основните фази, през които преминава една софтуерна разработка:

  • дефиниране на изисквания
  • дизайн на системата
  • реализация
  • интеграция
  • тестване и коригиране на грешки
  • инсталация
  • поддръжка

Работният процес представлява последователност от тези фази, като всяка от тях може да има своя сложна субструктура. Фазите следват в строго последователен ред – за да стартира дадена фаза, предишната трябва да е приключила напълно.

Този модел стриктно следва предписанията на класическата наука за управление на проекти. В това е неговата привлекателност - неслучайно моделът бързо се възприема и прилага в софтуерните проекти за държавните сектори на САЩ: администрация, армия, НАСА. Най-неочаквано обаче, с малки изключения, този модел се проваля.
Основна причина за неуспеха е, че практически не е възможно да се приключат фазите на дефиниране на изискванията и дизайна на системата, преди да се започне реализацията. Някои от изискванията изкристализират на по-късен етап. Някои решения по дизайна се оказват неизпълними на фазата на реализация и трябва да се преосмислят, и т.н. Съседните фази на разработката естествено се припокриват и в някаква степен че по-ранните фази зависят от по-късните. Така основната идея на модела за строга етапност се проваля.
Този проблем е забелязан от самото начало от автора на модела и той сам предлага първата модификация – итеративният модел на разработка.

При итеративният модел фазите са следните:

1. Първоначални изисквания
2. Начален дизайн
3. Цикъл
  • Детайлен дизайн
  • Кодиране
  • Тестване
  • Инсталация
  • Допълнителни изисквания и корекции
4.Окончателна инсталация
5. Поддръжка

След първоначалните изисквания и общия дизайн на системата, проектът навлиза в цикъл, в който се повтарят подетапите на детайлен дизайн, кодиране, тестване и инсталация при клиента.

Последният етап е събиране на обратна информация от клиента (допълнителни изисквания и необходими модификации), след което цикълът се повтаря, докато клиентът прецени, че системата го задоволява. Тогава следва окончателната инсталация и системата влиза в действие. Този модел избягва повечето недостатъци на сляпото следване на класическите методи за управление на проекти. В него за първи път се акцентира на активното участие на крайния потребител на системата в нейното разработване. Въпреки, че е предложен в същата статия, в която се описва и водопадния модел през 1970 г., той остава вън от полезрението на ИТ индустрията за цели 20 години.