Фаза проектирования и тех-доки

да

нет

Клево, а поподробнее? Насколько это существенно? Как обычно происходит? Как должно происходить?

> Клево, а поподробнее?

да

> Насколько это существенно?

очень

> Как обычно происходит?

нет

> Как должно происходить?

да

// wbr

Ну спасибо хоть не "всем похуй". Но вот матчасть по вопросу разницы между общим и частным вопросом подтянуть некоторым не повредит...

> Ну спасибо хоть не "всем похуй". Но вот матчасть по вопросу разницы между общим и частным вопросом подтянуть некоторым не повредит...

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

http://www.segfault.kiev.ua/smart-questions-ru.html

// wbr

Блин.

Этот эпический опус не применим к вопросу, который я задаю, ибо оный (вопрос, а не опус) является не зовом о помощи в решении некой проблемы, а суть темой для обсуждения.

Или может для тех, кто на бронепоезде, надо разжевать, что значит "фаза проектирования" и кто такие "тех-доки"? Мнение людей, которым эти слова не ведомы, было бы мало полезно. Ферштейн? :)

введение: Фаза проектирования и тех-доки

основной вопрос: Интересует мнение почтенной публики по отношению к сабжу.

ответ: мнение почтенной публики положительное.

уточнение: Особенно хотелось бы послушать, что говорят люди с богатым опытом лида.

ответ: люди с богатым опытом руководства группами ничего не говорят. да собственно с какой стати им что то говорить?

приведённые ответы более чем исчерпывающи и полностью покрывают заданные вопросы. по крайней мере в их текущей формулировке. если хотите узнать что-то ещё - спрашивайте.

// wbr

> Или может для тех, кто на бронепоезде, надо разжевать, что значит "фаза проектирования" и кто такие "тех-доки"? Мнение людей, которым эти слова не ведомы, было бы мало полезно. Ферштейн? :)

было бы не бесполезно разжевать, что же конкретно вас интересует?

// wbr

> Этот эпический опус не применим к вопросу, который я задаю, ибо оный (вопрос, а не опус) является не зовом о помощи в решении некой проблемы, а суть темой для обсуждения.

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

// wbr

Батенька, ну это уже не серьезно. Я же задал конкретные вопросы, не флейма ради, а обмена опытом для :(

Ладно, переформулирую еще раз.

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

Также, от тех людей, которые не только платонической любовью любят проектную документацию, хотелось бы услышать, какие подходы используются в ее оформлении. Фристайл в текстовом формате, UML, или карандашом на бумаге? С чего вообще должно начинаться проектирование? Когда должны появляться на свет первые строки кода? Как быть с изменением условий ТЗ в процессе разработки, если новое ТЗ противоречит старым докам?

Ну и всякие истории успеха были бы тоже очень полезны.

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

>С другой стороны - написать тонну доков вплоть до имен приватных членов модулей и классов и строго ей следовать.

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

годный троллинг. не то, что недовнедренцы анонимусы. уважаю!

> Также, от тех людей, которые не только платонической любовью любят проектную документацию, хотелось бы услышать, какие подходы используются в ее оформлении. Фристайл в текстовом формате, UML, или карандашом на бумаге? С чего вообще должно начинаться проектирование? Когда должны появляться на свет первые строки кода? Как быть с изменением условий ТЗ в процессе разработки, если новое ТЗ противоречит старым докам?

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

вопрос лишь в том, что многие любят её читать и очень мало людей, которые любят её писать а тем более качественно :)

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

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

// wbr

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

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

>многие любят её читать и очень мало людей, которые любят её писать а тем более качественно :)

ппкс :(

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

Не позже и не раньше? :)

Кстати, буду благодарен за отсылы к хорошей литературе на тему.

> Кстати, буду благодарен за отсылы к хорошей литературе на тему.

"Мифический человеко-месяц" Брукса уже читали? в принципе классика :)

// wbr

>Кстати, буду благодарен за отсылы к хорошей литературе на тему.

Ну можно начать с наших советских ГОСТ-ов. Они охватывают как разработку программного обеспечения, так и требования к документированию.
Например, начать с этих:
ГОСТ 34.201-89 Комплекс стандартов на автоматизированные системы. ВИДЫ, КОМПЛЕКТНОСТЬ И ОБОЗНАЧЕНИЕ ДОКУМЕНТОВ ПРИ СОЗДАНИИ АВТОМАТИЗИРОВАННЫХ СИСТЕМ.
ГОСТ 34.601-90 Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания.

PS: Подробность изложения документации зависит от сложности проекта. Чем больше людских ресурсов завязано на проект (и сложнее проект), тем подробнее должна быть документация.

>Интересует мнение почтенной публики по отношению к сабжу.

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

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

а ты пощщитай.

>"Мифический человеко-месяц" Брукса уже читали? в принципе классика :)

Спасибо, нашел, читаю.

>Ну можно начать с наших советских ГОСТ-ов.

Глянул по диагонали, мне кажется, это не совсем то, о чем я говорю. Госты - это конформизм, педантичность вплоть до штампа на каждом листе ("лист 4 / листов 15" и т.п.) Такие вещи нужны, если заказчик, скажем - госпредприятие, имхо. А для остальных случаев следование таким стандартам скорее всего существенно замедлит стадию проектирования.

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

Значит ли это, что нет смысла тратить время на проектирование и документацию, если все равно в какой-то момент она устраеет?

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

*кидает троллю морковку*

Я закончил технический вуз :)

>а ты пощщитай.

А тебе, похоже, стоило бы наконец в пятый класс перевестись. Удачи! :)

>Глянул по диагонали, мне кажется, это не совсем то, о чем я говорю.
>Госты - это конформизм,
Я привел всего пару гостов, их там больше. Включая процессы начала разработки, жизненные циклы(ну что то в этом духе).
Вовсе не обязательно рисовать штампики и спользовать листы А4. Можно взять, что нужно из процесса, для себя.

> написать тонну доков вплоть до имен приватных членов модулей и классов и строго ей следовать.

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

Документация -- обычный текст, на вики, скажем.

> Значит ли это, что нет смысла тратить время на проектирование и документацию, если все равно в какой-то момент она устраеет?

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

// wbr

мой тарелки перед едой!

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

Вот еще вопрос: вроде как UML позиционируется как сильвер-булет для таких вещей. Насколько это соответствует действительности? Я имею в виду, рисование UML-диаграмм вместо объяснения "на пальцах" в текстовой вике действительно стоит затраченного на него времени? Или это сродни гостовским штампам на каждом листе: так положено, поэтому надо делать так?

> Вот еще вопрос: вроде как UML позиционируется как сильвер-булет для таких вещей. Насколько это соответствует действительности? Я имею в виду, рисование UML-диаграмм вместо объяснения "на пальцах" в текстовой вике действительно стоит затраченного на него времени? Или это сродни гостовским штампам на каждом листе: так положено, поэтому надо делать так?

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

// wbr

> Насколько это соответствует действительности?

Оно ей не соответствует, не соответстовало и никогда соответствовать не будет.