wara
Я имел ввиду, что перед моими глазами был действующий "прототип" старой программы зарплата, с довольно удачными решениями и правильной концепцией хранения данных и порядков расчетов. Проект эксплуатируется в различных отраслях, учитывает многие специфические ньансы расчета зп каждой отрасли, в конторе работают уже с десяток лет люди, которые этот проект сопровождают и могут рассказать о динамике развития продукта и проблемах, с которыми им приходилось сталкиватся у различных клиентов. Какой то задокументированной постаноки конечно же не существовало - в нашей стране я пока вопринимаю это больше как с области фантастики. Далее имея на руках работающих прототип и людей, работающих с ним мне не составило сложности по нему расписать бизнес-процессы, структуру входящей и исходящей информации. Проведя анализ того что есть, чего не хватает, что реализовано правильно и что криво я получил на бумаге (каюсь, никаких case) примерную модель проекта, его модулей и описания их функциональных возможностей. После был проведен анализ на выявление характера изменения старого проекта и возникающих трудностей при сопровождении с учетом взаимосвязей модулей, чтобы выявить узкие места, способные при изменении условий постановки усложнить доработку проекта. Так собственно говоря и родилась схема будующего движка расчетов, в котором работает цепочка входящая информация -> входящие кэши -> аглоритмы расчетов -> движок расчетов -> расчетные кэши -> исходящая информация . Такая модель позволила заложить на неком абстрактном уровне независимую от структуры и принципов расчетов модуль расчетов. После этого уже пошла собственная реализация проекта, для начала была разработаны стандарты для клиентских и отчетных частей проекта и необходимое кол-во вспомогательных классов и компонент, чтобы СУБД полностью могла обеспечить уровень их возможностей и легко могла с ними взаимодействовать. Каждый модуль системы разрабатывается как независимая часть, перед началом разработки модуля идет углубление в его постановку, выявление частных случаев отклонения от стандартной постановки и можно сказать "демократическим" путем между мной и людьми, сопровождающими старый проект принимаются решения о необходимости расширения функциональности или же наоборот срезания явно "лишних" возможностей, присутствовавших в старом проекте. Из того, что должно быть реализовано в конкретном модуле проекта реализуется только каркас общих положений постановки, все частные случаи документируются и переносятся по реализации до лучших времен, хотя при реализации каркаса их ньансы в структуре БД учитываются изначально.

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

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

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

Итак что имеем в конце концов:
1. Долгое написание постановки, которое может привести к тому, что во время ее написания могут изменяться сами условия постановки
2. Ошибки и неточности, ведущие к искажениям постановки
3. Скатывание постановки в сторону реализаций других аналогичных проектов, известных постановщику
4. Невозможность полного описания всех ньюансов сложных взаимосвязанных процессов постановщиком (кол-во обрабатываемых уровеней абстрактного мышления у человека как известно имеет пределы)
5. Сложность выделения критических участков постановки, периодически подвергающихся изменениям

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

Насчет привязок к технологиям и СУБД - я считаю, что это уже реализация, которая никак не влияет на постановку и методики ее реализации. В принципе тот же самый свой движок расчетов я мог так же реализовать и на клиенте через классы и на третьем звене и через какой то интерпретатор или макроподстановки. Суть его назначения и использования все равно осталась бы преждней, вне зависимости от выбранной мной технологии и способов его реализации на этой технологии.

Такие вот у меня идеи. Может и не правильные - я все таки не постановщик, а проектировщик, разница на самом деле большая :) Если вдруг мимо профессиональные постановщики пробегать будут, будет интересно выслушать их мнения по этому вопросу.

Большое спасибо. Будем надеятся, что все удастся :)

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

Вдогонку:
Я кстати начал потихоньку многие решения, примененные в проекте, выкладывать в свою рассылку по Sybase ASA . Единственное неудобство, что все скрипты идут на WatcomSQL и с учетом особенностей этой СУБД, но сами принципы легко адаптируются под любую полноценную РСУБД.

valmondЕще годик - два и проект стартует :-)
А кто сказал, что он не работает ? :) Уже к нему пишется модуль учета социальных выплат для крупных холдингов, включена система репликации обмена различными данными различных модулей между центром и филиалами, система переведена на многомодульную архитектуру, где в пределах одной БД могут существовать множество схем модулей зп, кадры и соц.выплаты - фактически ЗП теперь всего один из модулей целой платформы на базе ASA+PB+FastReport+собственные наработки :) Другое дело, что эта система пока не тянет на коробочный вариант - не хватает собственной системы администрирования, а писать времени как всегда нет - сейчас вообще не ей занимаемся, а дописываем и ведем в опытной эксплуатации еще один крупный продукт, ориентированный на крупных застройщиков и агентств недвижимости. Вот допишем и запустим недвижимость, тогда можно будет и о бакофисе для зп подумать :)

valmond ASCRUS valmondЕще годик - два и проект стартует :-)
А кто сказал, что он не работает ? :)

Я сказал, потому как

ASCRUSПроект "расчет зп" уже дописывается, к нему делается отчетная часть

А зарплата без отчетов нужна только разработчику
Гм - отчетная часть - ХП+GBT+FastReport, данные все предрасчитаны. Не понятно, что именно будет дописываться пару годиков :) Видел я проекты зп, где во время построения отчетов вживую расчет идет, как то не очень понравилось.

Богатырев Алексей2 ASCRUS
После детального изложения вашей очень интерестной идеи.
Хотелось бы посмотреть на структуру БД Вашей модели.
Вам схему БД прототипа (девелоперскую) выслать или же полную рабочую, сразу с консолидированными и удаленными узлами ? :) Извините, но патент принадлежит не мне, а организации, у меня только авторское право, так что выкладывать структуру я не могу. Если что то конкретно интересует по реализации, то могу просто поделиться опытом.

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