Здравствуйте!

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

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

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

И сразу отмечу, что документы первого периода (Proposals) - они, разумеется, всегда есть, хотя если вам нужно разобраться как работает незнакомое приложение - они вам, скорее всего не помогут.

Также иногда есть документы последнего периода (Внедрения): руководства для пользователей.

А вот в документах перода Разработки чувствуется недостаток.

Но буду изучать UML и, по мере, возможности улучшать ситуацию.

Гм... Ну, исчерпывающий подход к документированию "проектов" закончили продумывать и оформили еще четверть века назад. Это ГОСТ 34 серии. Я до сих пор не сталкивался с проектами (а сталкивался с достаточно большими и серьезными), с которыми он бы не "справился".

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

Это ГОСТ 34 серии.

Спасибо за наводку. Буду посмотреть.

работаю там, где ГОСТы не применяются.

зато все уверены, что применяется одно из базовых принципов Agile: "Working software over comprehensive documentation" - Работающая программа важнее, чем подробное документирование.

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

Спасибо за наводку. Буду посмотреть.

Вас ждет целый новый мир, полный замечательных открытий. Я даже немного завидую.

работаю там, где ГОСТы не применяются.
зато все уверены, что применяется одно из базовых принципов Agile: "Working software over comprehensive documentation" - Работающая программа важнее, чем подробное документирование.

Да, таких мест полно. Во избежание лишних трений, можно не дразнить гусей словом "ГОСТ". Можно просто им руководствоваться.
Принцип, кстати, замечательный. Теплое однозначно важнее, чем мягкое.

так то оно так, но бизнес-приложения - это особый случай

Такой же, как и все остальные, предназначенные для работы в реальном мире.

, так как их логика описывает процессы существующую  внешнего мира, я не какую то внутреннюю, самодостаточные логику.

Страшное по своей разрушительной силе утверждение.

А эти процессы внешнего мира имеют свойства меняться время от времени...

Да. Для отражения изменений документацию актуализируют.

зато все уверены, что применяется одно из базовых принципов Agile: "Working software over comprehensive documentation" - Работающая программа важнее, чем подробное документирование.

Жаль только, что куча людей понимает этот принцип как "Нахрен документацию, мы же крутые и работаем по Agile/Scrum/XP/Kanban!"

Жаль только, что куча людей понимает этот принцип как "Нахрен документацию, мы же крутые и работаем по Agile/Scrum/XP/Kanban!"

более того, порой это единственный Agile/Scrum принцип, который им знаком и которому они "следуют"...

UML вторичен.

Можно составить перечень вопросов, на которые нужны ответы, а потом уже подобрать под них форматы представления ответов, если не просто вики.

Кроме ГОСТ 34 и РД 50 форматы описания проектных решений можно посмотреть в RUP, MSF, в семействах американских военных стандартов и т.д. и т.п.

Можете более точно сформулировать, какой вопрос вас интересует и о чём именно вы хотите поговорить?

Вот например мой старый пост с обобщённым перечнем наиболее часто встречающихся видов документов: http://beskov.livejournal.com/58576.html

Спасибо всем за участие. Могу заниматься вопросами документирования и наведением "рабочего порядка" только "набегами", эпизодически, когда есть свободное время.

Вот например мой старый пост с обобщённым перечнем наиболее часто встречающихся видов документов: http://beskov.livejournal.com/58576.html

Хорошая темка. Похоже на мою матрицу-схему. Если бы пункты документации были бы кликабельны и подгружали документ-пример или шаблон-заготовку, то было бы совсем прекрасно.

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