У нас на одном проекте, были документы (по Oracle AIM):
вроде MD50 - ТЗ на разработку от аналитиков
и MD70 - вроде дока на код от программиста

Когда через полгода пришлось сопровождал и разбираться с чужим кодом, выяснилось. Что наибольшую ценность несет НЕ информация КАК сделано, а информация ЧТО И ЗАЧЕМ ВООБЩЕ делали. При нормальном ТЗ - понять код проблем уже не составляет. В полном соответствие с принципом "настоящий программист не пишет комментариев, т.к. код программы понятен сам по себе".

AFAIK

Ну обычно вообще никакой документации не бывает )))

Или она в таком бардаке, что фиг она нужна, все равно смысла от нее ноль. В этом плане, мое пред-преддыдушее место работы было уникальным. Все пытались делать по AIM и без MD.70 программист банально зарплату бы не получил (т.к. ему не закрыли бы задачу и тайм-шит) ))).

За редкими исключениями /сам получал Т.З. в виде листочка бумаги с нарисованным домиком, паровозиком и дымом из паровозной трубы. Но с надписью MD.50, номером, датой и подписью менеджера проекта. Т.З. на задачу доработка формы и workflow подтверждение отгрузки))) /

Дык стандартов полно. У меня дома толстая книжка по UML лежит

Лично я сталкивался только с компаниями которые по Oracle AIM пытались софт внедрять / разрабатывать. Но там вообще, "рисунков" (кроме бизнес-процессов) шаблонами документов не предусматривалось

Де факто, тут проблема в том, что если описывать "по стандарту", то можно дойти до того, что кол-во изведенной бумаги значительно превысит кол-во кода. А ценность данной "бумаги" будет под большим вопросом. Т.ч. весь вопрос, какая конкретно документация для вас минимально(приемлимо) достаточна.

Главный недостаток документации - они имеет тенденцию устаревать, а разработчики, тенденцию на нее плевать. Т.ч. без административных мер воздействия и стимулирования (он латинского слова "стимул", stimulus — острый металлический наконечник на шесте, которым погоняют буйвола (быка), запряженного в повозку) очень быстро превращается просто в кипу бумаг, не годных (в силу своей жесткости) даже для употребления по назначению (в сортир).

AFAIK. Возможно, я просто "хорошо информированный оптимист" )))


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

IMHO & AFAIK

BagaBagaЯ бы не сказал, что полный DDL читабельнее нормальной ER-модели :)
По "полному DDL" (с констрейнами, развернутый в базе и заполненным комментариями к столбцам), Эр-Вин вполне способен и сам неплохую ER-модель нарисовать. Если она осмысленна.

А если например БД надстраиваемая или на основе EAV - то ER-модель будет "крайне читабельной и информативной" )))

Лично я пока сталкивался с необходимостью ER-моделей или схем только для одного - красивые картинки к документам, что бы кол-во страниц в отчете о выполненных работах было больше

Работал одно время с Яшей Сироткиным. Было это в начале 2000. UML было модно. Он для сайта из 5 веб-страничек, UML распечатал на всю стенку в кабинете. И еще кипа UML'ей осталась. Место на стенке закончилось ))).

В таких вещах IMHO главное соблюсти баланс. И документацию требовать с разработчика. И вовремя остановится.