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

Конечно руководитель проекта может насколько это возможно обезопасить себя, выбрав для реализации наиболее гибкие и функциональные средства для разработки проекта. Однако думаю все со мной согласятся, что РСУБД с SQL и RAD-системы, основанные на ООП не самые лучшие друзья и при любых изменениях вполне быстро можно привести в состояние частичной или полной неработоспособности как клиентскую, так и серверную часть.

На текущий момент одной из самых перспективных насколько я понимаю методологий проектирования является экстремальное программирование (XP). Штука хорошая и действительно показывает прекрасные результаты. Однако есть одно большое "НО" - эта методология предполагает наличие одной среды и одного языка разработки проекта, причем желательно обьектно-ориентированного. В случае 2-х звенных клиент-серверных приложений по схеме "Тонкий клиент-Толстый сервер" это дает существенные затруднения для ее использования. В случае 3-х и более звенных приложений проблем с использованием XP не возникает, однако появляется ряд других, желательно не обсуждаемых здесь проблем (вернее обсуждаемых, но в форуме "Сравнение СУБД").

На текущий момент, наверное даже больше для себя, я взялся за анализ существующих проблем и выработке применения методологии XP для 2-х звенных приложений. Не скажу, что пока вижу возможность полного переноса всех правил XP, например, парное программирование с постоянной сменой обязанностей между архитектором БД, программистом клиентской части и аналитиком отчетных форм приводит меня в дрожь. То же самое касается принципа "Не использовать пока не понадобиться", который не очень соотносится хотя бы с правилами нормализации форм и оптимизации запросов. Однако мне кажется большая часть XP все таки удачно ложиться на 2-х звенки и при должной выработке правильной методологии есть шанс начать использовать этот перспективный способ разработки приложений.

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

2. Проектирование абстрактных режимов серверной части. Проектирование форм ввода входящих данных и отчетных форм и бизнес-логики интерфейса, посредством вызовов абстрактных режимов серверной части.

3. Сдача в опытную эксплуатацию реализованных режимов заказчику с последующей коррекцией по найденным ошибкам и несоответствиям ТЗ.

4. Реализация физической модели базы данных (структуры входящих и исходящих данных, бизнес-логики целостности данных и расчетной части), а так же дополнений к клиентской части. Перевод абстракций в состояние привязки к реализованной физической структуре БД.

5. Сдача в финальную эксплуатацию реализованного режима заказчику. Его корректировка изменений и несоответствий ТЗ, а так же найденных ошибок (сопровождение).

В данном случае можно сказать я попытался обьединить идеи XP и не так давно обсуждаемого на SQL.RU продукта FileMaker, который даже не поленился скачать и посмотреть. Вкратце о достоинствах предполагаемой методологии:

Клиент постоянно участвует при разработке проекта и вместе с членами команды участвует во всех циклах: постановке, созданию интерфейсной части, бизнес-логики и тестированию. Это позволяет ему оценивать направление развития проекта и корректировать его прямо по ходу разработки. Так же это психологически благотворно влияет на его отношение к проекту, фактически делая его полноценным членом в команде разработчиков, заставляя рассматривать проект, как собственный труд и творение и более мягко относиться к неточностям и ошибкам. Изначально интуитивно понятное клиенту представление входящей и исходящей информации в виде форм и отчетов позволяет ему более четко определяться с требованиями по постановке задачи, а членам команды более глубже вникать в постановку.

Малый период итерации между началом и сдачей в эксплуатацию клиенту разрабатываемых режимов позволяет более быстро и точно находить ошибки и несоответствия, исправление которых занимают мало времени и психологически не ущемляют отношение клиента к проекту. Это так же позволяет всем членам команды, быть постоянно в курсе движения проекта и корректировать свое восприятие к нему, что приведет к улучшению качества алгоритмов проекта.

Цикл разработки команды проекта имеет параллейный характер работы «Клиент-Программист клиентской части-Архитектор БД», где во время любой точки реализации проекта все члены команды (включая клиента) всегда должны работать вместе и не возможно возникновение ситуации, что один из членов команды зависит от другого, ждет окончания его работы или вынужден корректировать собственную часть из за ошибок в другой (кроме ошибок ТЗ).

В отличие от визуального и структурного представления, бизнес-логика расчетов и обработки данных реализуется в последнюю очередь, изначально забиваясь заглушками и визуальными представлениями, дающими возможность ручного ввода расчетных данных. Это позволяет получить оптимальную структуру хранения расчетных данных, используемую при других расчетах и отчетных формах, на базе которой можно уже непосредственно реализовывать необходимую заказчику бизнес-логику.

Вот вкратце мое видение технологии XP на РСУБД. Хотелось бы обсудить с увлекающимися подобной "чепухой" коллегами достоинства и недостатки этой модели и провести ее коррекцию в более правдоподобный вид. Я специально нигде не упоминал про используемые платформы, так как считаю что до обсуждения реализации еще дело не дошло и скорее всего для каждой платформы будет своя, уникальная реализация. Так что допустим, что в обсуждении данной технологии мы будем ориентироваться на некоторую абстрактную СУБД, поддерживающую представления, хранимые процедуры и триггеры, а так же любое RAD средство, позволяющее быстро по вызову ХП построить визуальное представление возвращаемых ею данных и организовать сохранение изменяемой информации через ХП. Это вполне могут быть связки MSSQL + Access/VB/C#, Oracle+Java, ASA+PB и т.д.

На текущий момент например у меня по диаграмме возникла серия вопросов:
а) Стоит ли при разработке визуального представления и прототипа хранения данных в БД сразу закладываться на проектирование постоянной для проекта таблицы, имея ввиду, что если прототип (таблица) пройдет опытную эксплуатацию и не будет иметь изменений в пункте 5 (физическая реализация), то значит он не требует доработок и его можно считать полноценной физической реализацией в БД.
б) С учетом того, что единственный легко реализуемый способ абстракции в РСУБД - это хранимые процедуры, насколько этот слой, реализованный на них будет действительно абстрактным. С одной стороны в случае изменения физической модели таблицы будет достаточно переписать запрос в ХП на ее уровне абстракции, сохранив структуру возвращаемых данных. Это позволит выжить как клиентской. так и серверной части, ссылающихся на эту таблицу через абстрактный слой и снизить кол-во переделок взаимосвязанных обьектов до уровня обоснованной необходимости. С другой стороны нет дыма без огня - изменения в структуре БД штука серьезная и смогут ли такие ХП взять на себя весь удар мне честно говоря пока не понятно.
в) Стоит ли задумываться о создании или использование существующего ПО, частично или полностью автоматизирующих этапы разработки проекта или же не заморачиваться и проводить реализацию проверенными дедовскими методами.

Буду рад любым мыслям в этой области по XP для 2-х звенных приложений. Если никто не будет против и эта тема не перерастет в какой нибудь очередной флуд, то по мере сил и возможностей своих буду дальше сюда выкладывать свои идеи на эту тему :)

Засим разрешите откланяться, нужно все таки пойти чуть поспать :)

Old NickНа прежнем месте работы мы проектировали логику набором сущностей. Каждая сущность - это класс. Но довольно абстрактный, так как состоял из различных объектов связанных между собой только логически.

После этого определялись конкретные объекты сущности
Например, сущность Накладная состояла из нескольких таблиц, нескольких форм и нескольких операций.

И поскольку сначала все это делалось на бумаге, проблем не было.
Речь немного о другом. Я не пытаюсь здесь рассмотреть способы разработки приложений, я пытаюсь подружить сам процесс разработки клиент-серверных приложений с экстремальных программированием. Вот например по Вашему примеру все равно возникает множество вопросов:
1. Как определялись аттрибуты и взаимосвязи сущностей - по готовому ТЗ или в ходе работ ?
2. Сколько человек участвовало в разработке сущности, могли ли эти люди взаимозаменять друг друга и если могли, достаточно ли у всех было квалификации для проектирования БД ?
3. Принимал ли непосредственное участие в ходе работ заказчик ?
4. Насколько быстро можно было запустить в опытную эксплуатацию сделанный проект у заказчика, кем и как осуществлялось тестирование ?
5. Как происходила сборка сущностей и связей между ними ?
6. Как осуществлялась реализация сложных расчетов и отчетных выходных форм ?
7. На каком этапе работ выявлялись неточности, несоотвествия и изменения ТЗ по отношению к проекту, что предпринималось, если из за изменений в ТЗ нарушались характеристики сущностей и связей между ними, производился ли рефакторинг кода и как потом тестировались изменения ?

В принципе тут я задал все технические вопросы, на которые экстремальное программирование имеет четкие и ясные ответы. Так же существует ряд психологических аспектов - смена членов команды, их разный уровень квалификации, узкая специализация, отсутствие знаний в предметной области с присутствием повышенной фантазии и т.д. Это тоже вопросы, которые имеют исключительное влияние на успешность разработки крупного проекта и на них тоже экстремальное программирование дает более менее четкие ответы. Поэтому я сейчас и пытаюсь на базе экстремального программирования сформировать некоторые концепции и разработать вспомогательное ПО и компоненты, позволяющие превратить для команды процесс разработки проектов в быстрое, безболезненное и даже играбельное занятие, а мне как руководителю проектов сосредоточиться на контроле процесса и кода сверху, подтягивании уровня команды (обучению методикам программирования) и вмешиваться только в случаях дипломатической необходимости между членами команды и заказчиком, или же при пробуксовке команды на сложных алгоритмах.