Вземете например Waterfall - това дефакто е първият опит да се систематизират основните дейности в софтуерната разработка. И до ден днешен по-неопитните фирми го ползват като прост референтен модел за това как да си организират процеса. Да, всички знаем, че "Waterfall е лош", но предстаяте ли си какво щеше да бъде фирмите изобщо да не знаеха, че трябва да се прави анализ? Или дизайн? Или да вземат да забравят за тестването? Отделно е неговата роля като модел, стартирал първата дискусия на тема итеративния подход и SE като цяло - малко хора знаят, че "създателя" на Waterfall просто е описал какво се прави и именно той първи е предложил итеративния подход като алтернатива.

 В моделирането на бизнес процеси съществуват два типа модели, описващи процеси - Диграми на добавената стойност и процесни описания. Процесните описания отразяват хронологична последователност - всяка дейност се върши след предната във веригата. Диаграмите на добавената стойност описват смислова последователност - всяка следавща дейност зависи от предната. Waterfall е диаграма на добавената стойност, не е процесно описание.

 RUP е новият герой. Въпросите са все "Дали ще бъдем гъвкави или ще ползваме RUP?" "Дали залагаме на човешката интеракция или на тромавите процеси?". Досадната му документация и навлизане в изилшни подробности настрана, RUP е поредната голяма стъпка в теорията на софтуерното инжинерство. Не го познавам целия, никога няма да се запозная с него в подробности, и никога няма да го следвам, но от него вече улових поне две идеи, които ще са ми от огромна полза, и то завинаги.

 Първата е фазовия модел, показан на тази картинка. Макар да изглежда като някаква кардиограма, идеята, представена чрез нея е поне за мен следващата стъпка след итеративният подход. За тези, които не са я виждали (или само са й хвърляли по някой поглед), идеята е следната:

  Това е диаграма, представяща как различните дейности по проекта се движат в периода от неговото започване, до неговото завършване. Реално всяка от дейностите се върши почти във всеки(!) етап, но има моменти, когато има водеща функция и такива, в които има заглъхваща. Това тотално противоречи на дървената представа, според която правим спецификация и свършваме с анализа, правим дизайн, четем документа и го захвърляме. Тази диаграма, според мен, илюстрира посоката, в която ще се движат процесите по разработка на софтуер през следващите 10-на години. Поне това се надявам - иначе песимиста в мен вижда как може да стане като с Waterfall и след 30-40 години още да дъвчем собствените си предразсъдъци вместо да обсъждаме посланието на самия модел.

  Наскоро четох една статия, която показва друга добра идея на RUP - разделението на работата в "широчина" и "дълбочина".

  http://www-128.ibm.com/developerworks/rational/library/apr05/crain/index.html

 Отново невероятна идея за разделението на работата по проекта. Поне в бизнес анализът, който в момента ми е амплоа, ми прави впечатление фрапиращата разлика между идентифицирането на основните необходими функционалности на системата, от една страна, и договарянето на интерфейса на конкретен екран, от друга (и двете в момента водещи се една стъпка от процеса, вършена от един и същи човек). Подобна е разликата, макар и по-малка, между моделирането на цялостният процес на работа на клиента и описанието на конкретната му последователност от действия при ползване на някоя функционалност. За разликата между това да пишеш код и да внимаваш за съвместимостта между компонентите на приложението няма нужда да споменавам, предполагам?

 Накратко, докато защитниците на процесният и гъркавият подход при разработката на софтуер копаят окопи и се готвят за поредния сблъсък, добрите идеи подминават индустрията като вятър. Остава само да последваме старата китайска поговорка и да почнем да строим вятърни мелници. :)