Уважаемые коллеги, прошу высказаться по теме. Приветствуются любые советы и предложения.
Ситуация такова: команда из трех человек пишет набор приложений, работающих с БД, графикой, железом.
1-й программист делает пользовательский интерфейс на Delphi.
2-й — пишет ядро системы (разнообразные вычисления, всякие навороченные алгоритмы, работа с БД) на C++ Builder'е. Ядро представляет собой набор DLL-библиотек, экспортирующих кучу функций (возможно, впоследствии все это будет переделано на COM-серверы).
3-й — пишет на MSVC++ набор DLL-библиотек, управляющих разнообразными железяками.
Вопрос: что посоветуете для ведения проектной документации — какие виды диаграмм, блок-схем? На данном этапе нам не требуется автоматической генерации кода по диаграммам. Пока нужны только средства, которые позволили бы описать интерфейсы компонентов системы и протоколы взаимодействия между ними. Что-то типа диаграмм UML, но с учетом того, что система не является полностью объектно-ориентированной (некоторые ее части представляют собой просто наборы функций).
Существует ли такой стандарт документирования, который целесообразно применять в небольшой группе программистов и на внедрение которого уйдет не слишком много сил и времени?
Спасибо.

Здравствуйте, sergei74ap, Вы писали:

S>1-й программист делает пользовательский интерфейс на Delphi.
S>2-й — пишет ядро системы (разнообразные вычисления, всякие навороченные алгоритмы, работа с БД) на C++ Builder'е. Ядро представляет собой набор DLL-библиотек, экспортирующих кучу функций (возможно, впоследствии все это будет переделано на COM-серверы).
S>3-й — пишет на MSVC++ набор DLL-библиотек, управляющих разнообразными железяками.

На кой вам каша из такого количества разнокалиберных технологий? Типа, каждый пишет на чем умеет?
Сдается мне, это будет не самый простой, надежный и гибкий проект.

S>Вопрос: что посоветуете для ведения проектной документации — какие виды диаграмм, блок-схем? На данном этапе нам не требуется автоматической генерации кода по диаграммам. Пока нужны только средства, которые позволили бы описать интерфейсы компонентов системы и протоколы взаимодействия между ними. Что-то типа диаграмм UML, но с учетом того, что система не является полностью объектно-ориентированной (некоторые ее части представляют собой просто наборы функций).

Диаграммы компонент, диаграммы активности, по-большому счету на ООП не завязаны, можно их использовать. Описание протоколов взаимодействия можно через диаграммы последовательности нарисовать, плевать что у вас не объекты, либо изложить все в Word-овском документе.

S>Существует ли такой стандарт документирования, который целесообразно применять в небольшой группе программистов и на внедрение которого уйдет не слишком много сил и времени?

Мой скрымный опыт подсказывает, что лучший стандарт, это тот, который вы придумаете сами. Никто не запрещает использовать UML не совсем так как оно задумано. Например, я как-то через диаграмму состояний сайт спроектировал, и
остался очень доволен результатом.

Здравствуйте, slskor, Вы писали:

S>Здравствуйте, sergei74ap, Вы писали:

S>>1-й программист делает пользовательский интерфейс на Delphi.
S>>2-й — пишет ядро системы (разнообразные вычисления, всякие навороченные алгоритмы, работа с БД) на C++ Builder'е. Ядро представляет собой набор DLL-библиотек, экспортирующих кучу функций (возможно, впоследствии все это будет переделано на COM-серверы).
S>>3-й — пишет на MSVC++ набор DLL-библиотек, управляющих разнообразными железяками.

S> На кой вам каша из такого количества разнокалиберных технологий? Типа, каждый пишет на чем умеет?
S>Сдается мне, это будет не самый простой, надежный и гибкий проект.

особенно тяжело придется третьему, управлять железом из длл-ки

S>>Вопрос: что посоветуете для ведения проектной документации — какие виды диаграмм, блок-схем? На данном этапе нам не требуется автоматической генерации кода по диаграммам. Пока нужны только средства, которые позволили бы описать интерфейсы компонентов системы и протоколы взаимодействия между ними. Что-то типа диаграмм UML, но с учетом того, что система не является полностью объектно-ориентированной (некоторые ее части представляют собой просто наборы функций).

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

Здравствуйте, dkon, Вы писали:

D>в проекте из трех человек достаточно личного общения, документация будет только лишней обузой.

А как проект поддерживать без документации?
А если в будующем проект будет расширяться?
Или кто-то решит уйти из проекта?

Здравствуйте, AntoxaM, Вы писали:

AM>Здравствуйте, dkon, Вы писали:

D>>в проекте из трех человек достаточно личного общения, документация будет только лишней обузой.

AM>А как проект поддерживать без документации?
AM>А если в будующем проект будет расширяться?
AM>Или кто-то решит уйти из проекта?

исходники -- самая что ни на есть правильная, понятная, полностью соответствующая текущему положению, документация.

поделись личным опытом, часто тебе помогала документация? я не припомню за 6 лет ни одного случая. запутывала из-за того, что годами не обновлялась — да, было раза три-четыре.

D>поделись личным опытом, часто тебе помогала документация? я не припомню за 6 лет ни одного случая. запутывала из-за того, что годами не обновлялась — да, было раза три-четыре.

делюсь. Помогала. Очень. Видимо, эти 6 лет ты работал в "не очень крупных" проектах. У нас в конторе такие вещи называют "программирование на коленке".

Мин.необходимый документ в проектн.док-ции — "Требования".

Здравствуйте, dkon, Вы писали:

D>Здравствуйте, AntoxaM, Вы писали:

AM>>Здравствуйте, dkon, Вы писали:

D>>>в проекте из трех человек достаточно личного общения, документация будет только лишней обузой.

AM>>А как проект поддерживать без документации?
AM>>А если в будующем проект будет расширяться?
AM>>Или кто-то решит уйти из проекта?

D>исходники -- самая что ни на есть правильная, понятная, полностью соответствующая текущему положению, документация.

D>поделись личным опытом, часто тебе помогала документация? я не припомню за 6 лет ни одного случая. запутывала из-за того, что годами не обновлялась — да, было раза три-четыре.

Помогала и не раз. Ещё мне "повезло" поучаствовать в проекте, на который не было никакой документации. Один программер налабал прогу, и через некоторое время уволился. Человек, с чьих слов её рисовали тоже ушёл. В итоге никто не знает, что и как прога должна делать. Не забываемые впечатления.

Здравствуйте, Аноним, Вы писали:

D>>поделись личным опытом, часто тебе помогала документация? я не припомню за 6 лет ни одного случая. запутывала из-за того, что годами не обновлялась — да, было раза три-четыре.

А>делюсь. Помогала. Очень. Видимо, эти 6 лет ты работал в "не очень крупных" проектах. У нас в конторе такие вещи называют "программирование на коленке".

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

А>Мин.необходимый документ в проектн.док-ции — "Требования".

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

D>я учавствовал в "сделанном на коленке" проекте для нефтегазовой промышленности, продаваемом за сотни килобаксов и делавшимся по науке кучей народа для недопартнера мелкомягких, спущенном в унитаз. мне, конечно, очень интересно как называют такие вещи у тебя в конторе, только что это доказывает?

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

Здравствуйте, dkon,

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

А>>Мин.необходимый документ в проектн.док-ции — "Требования".

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

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

Вероятно, в том проекте:
— небыло профессиональных разработчиков, которые умеют писать сложный софт (например, была толпа рядовых программистов без менеджера проекта, архитектора, тестировщиков адекватной проекту квалификации);
— заказчики проекта постоянно менялись и опять же разработчики не справились с управлением требованиями и выбором архитектуры;
— заказчик проекта вообще не хотел, чтобы проект завершился (участвовал я как-то в таком проекте ). Иногда важен сам факт наличия проекта по автоматизации, к примеру, а не его завершение. Некоторые инвесторы/акционеры могут скушать лапшу о том, что мы работаем над автоматизацией и вскоре наступит светлое будущее. Соответственно, они могут под это дело кому-нибудь из руководства зарплату повысит ;
— еще уйма разных причин, которые могли привести к неудаче.

Здравствуйте, AntoxaM, Вы писали:

AM>>>А как проект поддерживать без документации?
AM>>>А если в будующем проект будет расширяться?
AM>>>Или кто-то решит уйти из проекта?

D>>исходники -- самая что ни на есть правильная, понятная, полностью соответствующая текущему положению, документация.

D>>поделись личным опытом, часто тебе помогала документация? я не припомню за 6 лет ни одного случая. запутывала из-за того, что годами не обновлялась — да, было раза три-четыре.

AM>Помогала и не раз. Ещё мне "повезло" поучаствовать в проекте, на который не было никакой документации. Один программер налабал прогу, и через некоторое время уволился. Человек, с чьих слов её рисовали тоже ушёл. В итоге никто не знает, что и как прога должна делать. Не забываемые впечатления.

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

Здравствуйте, Аноним, Вы писали:


D>>я учавствовал в "сделанном на коленке" проекте для нефтегазовой промышленности, продаваемом за сотни килобаксов и делавшимся по науке кучей народа для недопартнера мелкомягких, спущенном в унитаз. мне, конечно, очень интересно как называют такие вещи у тебя в конторе, только что это доказывает?

А>хм.. ты считаешь, это звучит гордо?

пример личного опыта, с удовольствием выслушаю твою success story.

А>я даже могу предположить пару контор, о которых может идти речь..

давай, давай

А>проект без документации — это несерьезно..

с такими аргументами -- в сад.

Кстати, плохое управление требованиями — это, по статистике, одна из самых частых причин
провала проектов. Кажется эта причина стоит на первом месте.

D>с такими аргументами -- в сад.

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

Здравствуйте, Аноним, Вы писали:

D>>с такими аргументами -- в сад.

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

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

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

товарищ, горбатого могила исправит, знаешь. оценил твои посты, напоминают рассуждения наших студентов последних курсов, услугами которых мы иногда пользуемся. Как сдают проекты — не нужно мне рассказывать, в индустрии уже 15 лет и не таких, как ты, насмотрелся. Если опыта не хватает (т.к. после работы хоть в одной солидной конторе хоть на одном солидном проекте такие рассуждения как у тебя сами отпадают), открой хоть книгу, что ли. По RUP, XP, MSF. Учись, студент.

P.S. это кто из нас еще "нечто", хам.

Здравствуйте, dkon, Вы писали:

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

Везению можно позавидовать

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

Как ты проверял, что пректы действительно сделаны?
Какие действия ты предпринимал в ситуациях, когда разные заинтересованные в проекте лица настаивают на принципиально различной реализации некоторой функциональности?

Так же прошу уточнить размеры проектов (количество строк/трудозатраты/данные по другим метрикам).

Здравствуйте, dkon, Вы писали:

D>и сколько гхм... гхе.. высокооплачиваемых специалистов не смогли разобраться в "проге", написанной одним человеком? у вас людей после увольнения убивают, поэтому у них никак спросить нельзя?

Да разобраться, то разобрались. Только времени на это ушло гораздо больше чем требовалось. Вместо того чтобы почитать доку и начать пилить новый функционал, пришлось разбираться в уже написаном, писать доку и только потом продолжать.
Спросить то можно, но кто через месяц помнит, что он там раньше понаписал?
Фактически вместо зарабатывания денег занимались всякой $#@нёй.
И ирония здесь совершенно не уместна.

Здравствуйте, Аноним, Вы писали:

А>товарищ, горбатого могила исправит, знаешь. оценил твои посты, напоминают рассуждения наших студентов последних курсов, услугами которых мы иногда пользуемся. Как сдают проекты — не нужно мне рассказывать, в индустрии уже 15 лет и не таких, как ты, насмотрелся. Если опыта не хватает (т.к. после работы хоть в одной солидной конторе хоть на одном солидном проекте такие рассуждения как у тебя сами отпадают), открой хоть книгу, что ли. По RUP, XP, MSF. Учись, студент.

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

А>P.S. это кто из нас еще "нечто", хам.

прошу прощения, если обидел, просто реакция на твой тон и "аргументы".

Здравствуйте, dkon, Вы писали:

D>Здравствуйте, Аноним, Вы писали:

А>>товарищ, горбатого могила исправит, знаешь. оценил твои посты, напоминают рассуждения наших студентов последних курсов, услугами которых мы иногда пользуемся. Как сдают проекты — не нужно мне рассказывать, в индустрии уже 15 лет и не таких, как ты, насмотрелся. Если опыта не хватает (т.к. после работы хоть в одной солидной конторе хоть на одном солидном проекте такие рассуждения как у тебя сами отпадают), открой хоть книгу, что ли. По RUP, XP, MSF. Учись, студент.

D>XP обожаю. в полном объеме использовать пока не получается, к сожалению. утверждение, что исходники -- это лучшая документация, как раз из XP. а ты не знал?

А как же User Stories??? — спицифический подход к спецификации требований, но ведь подход же (почему-то у меня несколькими постами раньше появлось убеждение, что речь не о ламерстве, а о недопонимании концепции eXtreme Programming — рад, что угадал)!

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

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