Вопрос ессно применительно к разработке софта.
Из того что видел я, в разработке софта стадия проектирования практически отсутствует, т.е. берем ТЗ (спек), если есть, и начинаем кодить. Иногда сразу начинаем кодить по ходу выясняя что вообще надо, так называемое, екстремальное программирование,

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

Почему-то в советское время в промышленности были четко расписаны стадии проектирования и производства чего-либо. Были НИР, ОКР, опытное производство, серийное производство...
А сейчас в софте то что называют проектированием иначе как мастурбацией не назовешь, сидят блин несколько челов, считающих себя гуру и спорят о том какой паттерн лучше использовать.

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

Я вообще думал что так - везде, но недавно читал книжку по ASM в оракле,
процитирую
авторBy 2000, Rich Long (a coauthor of this book) became the development manager for the
project. He formed a team of six developers and the project took off. ASM became my full
time job. Several months were spent producing a detailed design document before coding
began.

Собственно вопрос, кто нить видел такое в своей работе?
Чтоб сначала писали детальную проектную документацию, а потом кодили в соответствии с ней? Или это только крупные вендоры могут себе позволить?

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

Petro123НИР\НИОКР есть и сейчас, только программирование причём?
Для того чтоб выпустить продукт выполняется целый комплекс проектных и предпроектных работ.
А в программировании зачем? Можно сразу садится и писать код.
Так повсеместно. Результат - баги, а потом и полная переделка с нуля.
Почему так?
Просто интересно....

ЮВВсё зависит от уровня квалификации Заказчика и его принципиальности.
Если он не хочет рисковать своими деньгами, то ему важно ознакомится перед началом кодирования с теми техническими решениями, которые вы будете воплощать.
А для этого нужна проектная документация, пусть не в полном объеме, а как минимум, "Пояснительная записка" (предусмотрена всеми ГОСТами).

После утверждения Заказчиком технических решений есть два пути:
1 если проект несложный и не длительный по времени, спецификации программирования можно не описывать.
2 если проект сложный, задействовано много людей (которые, к тому же, могут приходить в команду/уходить из неё), предполагается дальнейшее развитие проекта (новые версии), то спецификации программирования (детализация документов технического проекта) крайне важны.
И, конечно, выполнение такой работы зависит от "полноты налитого стакана" (т. е. готов Заказчик или вы сами финансировать эту работу).
имхо такое ощущение что все сначала думают что будет п.1, а на деле всегда выходит п.2
А вообще - все верно. Но почему-то в тех местах где я работал, не было вообще никакой проектной документации?
Это о чем говорит? О жадности заказчиков?

Есть тут вообще такие, кто делал проектную документацию?
Причем до реализации, а не после.

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

Но в программировании наоборот, мы сначала быстро-быстро реализуем то что требуется в ТЗ, а как мы реализовали либо описывается ПОСЛЕ реализации, либо вообще не описывается. Единственный способ что то выяснить - это реверс инжиниринг, по сути ковыряние в чужом коде.

П-ЛЯ фиксирую БТ и ФТ до начала реализации. Тектовый ворд + многочисленные схемы в визио. Одновременно очень-очень предварительно определяется интерфейс. Прорабатывать интрефейс насколько-нибудь детально оказалось бессмысленно, потому что в процессе разработки по ФТ начинают вылезать белые пятна не заявленные и не продуманные бизнес-заказчиком. И реализация БТ и ФТ сопровождается их существенным эволюционированием во время разработки. Обычно реализация более-менее крупного функционального блока занимает квартал. По мере приближения к концу реализации начинается сбор следующих БТ и формирование ФТ. Сам бизнес формулировать ФТ оказался не способен.
БТ ФТ - это что? Бизнес требования и функциональные требования?

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

iscrafm.....
я лично все фиксирую ДО, а не ПОСЛЕ.
А что вы фиксируете? Если не секрет?

iscrafmв основном требования и укрупненные архитектурные наброски. Делается эскиз обычно перед началом детальной проработки.
Вопросы:
Насколько, такие, укрупненные документы помогают, и помогают ли вообще, когда приходит новый сотрудник и ему надо войти в курс дела? Облегчают ли они сопровождение продукта?

AndrewQwerПосле прочтения C. Макконнелл "Совершенный код" совсем по другому смотришь на стадию проектирования.
имхо, эта хрень, наряду с Фаулером - зло.

iscrafm..... А так, конечно помогают
хм, а мне вот что то не повезло. Везде где я работал всегда было так как я описывал: "Сначала пиши код, а потом пиши доку, как и что там у тебя работает".

а уж про такое я даже ни от кого из знакомых не слышал
автор Several months were spent producing a detailed design document before coding began .