Автор Тема: Периоды разработки бизнес приложения и соответствующие типы проектной документац  (Прочитано 2503 раз)

Денис Кораблев

  • Newbie
  • *
  • Сообщений: 8
  • Рейтинг читателей: 0
    • Просмотр профиля
Здравствуйте!

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

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

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

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

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

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

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


Леонид

  • Hero Member
  • *****
  • Сообщений: 504
  • Рейтинг читателей: 61
    • Просмотр профиля
Re:
« Ответ #1 : 24 Марта 2015, 17:21:32 »
Гм... Ну, исчерпывающий подход к документированию "проектов" закончили продумывать и оформили еще четверть века назад. Это ГОСТ 34 серии. Я до сих пор не сталкивался с проектами (а сталкивался с достаточно большими и серьезными), с которыми он бы не "справился".

И да - если говорить о документировании всего жизненного цикла, советую не углубляться в UML. Он так, частный инструмент для применения на скромном участке.
« Последнее редактирование: 24 Марта 2015, 17:24:11 от Леонид »

Денис Кораблев

  • Newbie
  • *
  • Сообщений: 8
  • Рейтинг читателей: 0
    • Просмотр профиля
Re:
« Ответ #2 : 24 Марта 2015, 17:38:43 »
Это ГОСТ 34 серии.

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

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

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

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

Леонид

  • Hero Member
  • *****
  • Сообщений: 504
  • Рейтинг читателей: 61
    • Просмотр профиля
Re:
« Ответ #3 : 24 Марта 2015, 17:53:12 »
Спасибо за наводку. Буду посмотреть.

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

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

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

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

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

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

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


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

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

davvol

  • Full Member
  • ***
  • Сообщений: 208
  • Рейтинг читателей: 33
    • Просмотр профиля
зато все уверены, что применяется одно из базовых принципов Agile: "Working software over comprehensive documentation" - Работающая программа важнее, чем подробное документирование.

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

Денис Кораблев

  • Newbie
  • *
  • Сообщений: 8
  • Рейтинг читателей: 0
    • Просмотр профиля
Жаль только, что куча людей понимает этот принцип как "Нахрен документацию, мы же крутые и работаем по Agile/Scrum/XP/Kanban!"

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

Denis Beskov

  • Member of CAR
  • Hero Member
  • *****
  • Сообщений: 2406
  • Рейтинг читателей: 90
    • Просмотр профиля
    • Школа системного анализа
UML вторичен.

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

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

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

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

Денис Кораблев

  • Newbie
  • *
  • Сообщений: 8
  • Рейтинг читателей: 0
    • Просмотр профиля
Спасибо всем за участие. Могу заниматься вопросами документирования и наведением "рабочего порядка" только "набегами", эпизодически, когда есть свободное время.


Вот например мой старый пост с обобщённым перечнем наиболее часто встречающихся видов документов: http://beskov.livejournal.com/58576.html
Хорошая темка. Похоже на мою матрицу-схему. Если бы пункты документации были бы кликабельны и подгружали документ-пример или шаблон-заготовку, то было бы совсем прекрасно.

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