18-я веснаБывало ли у кого-то такое, что постановка, ТЗ сделаны настолько близко к реальным нуждам заказчика, что после окончания кодирования и внутреннего тестирования - при внедрении, не требовалось бы вносить изменения в исходное ТЗ и соответственно переделывать код?

PS. Речь идет конечно не о мелких утилитах или компиляторах :), а например об АРМ или чем-то посложнее, то есть из области автоматизации предприятий.

Проблема тут не в "постановке", а в "мета-постановке". Порочен сам подход, при котором будущего пользователя вынуждают "расписаться кровью" на документе под названием "требования" или "ТЗ".

Пользователь меняет свои показания по ходу следствия не из-за злокозненности или глупости. (Ну ладно, не только из-за глупости.) Просто сплошь и рядом бизнес меняется быстрее, чем айтишники успевают развернуться со своим циклом проектирования-разработки-отладки-тестирования-опытной эксплуатации. За время, пока закончится внедрения ERP-системы или "свои" айтишники сваяют что-нибудь работоспособное, предприятие три раза перейдет из рук в руки и сменятся три генеральных директора.

Поэтому надо стремиться не пожестче ставить в рамки пользователя и клиента, а самим учиться работать по-другому. Многие, если не большинство, воспринимают ТЗ как священную корову и не понимают как вообще можно жить по-другому. Но альтернатива есть, и материализуется она в связке технологий BPM+SOA.

Одна из привлекательных идей этой связки заключается в следующем. Замечено, что в прикладных системах для автоматизации бизнеса (предприятий) есть части, меняющиеся очень часто, и есть относительно стабильные. Сильная изменчивость характерна для логики верхнего уровня -- того, что принято называть бизнес-процессами. Функции же нижнего уровня -- например, подготовка печатного образа платежки или ввод в базу товарной накладной -- относительно стабильны.

Отсюда рецепт: изменчивую часть выделить и разработать для нее специализированный софт -- систему управления бизнес-процессами (BPMS). Причем сделать его таким, чтобы пользователь смог управляться без участия программиста (очень важный момент!). Функции нижнего уровня разрабатывать традиционным способом, а вязать одно с другим через веб-сервисы.

Разумеется практика BPM-проектов отличается от нарисованной идеальной картины, но факт тот, что ТЗ в них и близко не играет такой роли, как в традиционных проектах разработки и внедрения. Все в них течет, все меняется, и это воспринимается всеми участниками не как катастрофа, а как благо.

Michael Vasilevдумал, думал, не могу представить На пальцах, очень упрощенно: представьте себе систему, в которой имеется графическое средство рисования диаграммы бизнес-процесса. Причем диаграмма эта -- не просто "картинка": по сути она является исполняемой программой для другой компоненты -- движка. "Квадратики" на этой диаграмме можно привязать к веб-сервисам, причем без кодирования -- на уровне заполнения полей в списке атрибутов. Конечно, это не для "тупого пользователя", но пользователь, освоивший написание формул на Excel, способен с этим управляться самостоятельно. Сегодня этот подход пока воспринимается не всеми, но 20 лет назад и ценность СУБД тоже приходилось доказывать.