Разработка серьёзного ПО

← →
Сергей_77 (2008-06-18 23:54) [0]

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

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

Большая признательность и респект для тех кто поделится опытом.

← →
Eraser © (2008-06-18 23:59) [1]

> [0] Сергей_77 (18.06.08 23:54)

в одиночку довольно сложно, когда 2 человека уже легче.. для начала.

> или существует специальные программы для создания блок-схем
> будующего приложения?

блок-схемы это прошлое тысячилетие, совсем другое дело схемы БД и бизнесс-процессов.

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

← →
Игорь Шевченко © (2008-06-19 00:00) [2]

А что имеется в виду под крупной программой ?

← →
Игорь Шевченко © (2008-06-19 00:02) [3]

> блок-схемы это прошлое тысячилетие

ты эта...словарик возьми, а потом уже про замшелость

← →
имя (2008-06-19 00:07) [4]

Удалено модератором

← →
Eraser © (2008-06-19 00:10) [5]

> [3] Игорь Шевченко © (19.06.08 00:02)

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

← →
Сергей_77 (2008-06-19 00:14) [6]

> А что имеется в виду под крупной программой ?

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

← →
Игорь Шевченко © (2008-06-19 00:18) [7]

Сергей_77 (19.06.08 00:14) [6]

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

Это мелкая программа. Для крупных программ нужно не менее года.

Eraser © (19.06.08 00:10) [5]

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

← →
SergeyIT © (2008-06-19 00:32) [8]

Главное - это правильно понять заказчика.
Мой последний был ужасный зануда - пришлось месяц всякие тонкости/мелкости уточнять. Теперь вроде все нормально (7 лет программы работают), но заказчик о линуксе задумался - возможно что-то переделывать придется, опять договариваться - но слава богу он всегда доступен :) в моем лице.

← →
Riply © (2008-06-19 00:37) [9]

> [0] Сергей_77 (18.06.08 23:54)
> Расскажите, как Вы создаёте крупные программы, когда работаете в одиночку.
> Меня очень интересует сам процесс - как это все происходит

Проклиная и ругая одиночество такими словами, которые Вам еще рано знать :)

P.S.
А создание проекта с котом на пару это "в одиночку" ? :)

← →
SergeyIT © (2008-06-19 00:42) [10]

> с котом на пару это "в одиночку" ?

Это на троих - комп что, забыли?

← →
korneley © (2008-06-19 00:45) [11]

> Riply © (19.06.08 00:37) [9]
> P.S. А создание проекта с котом на пару это "в одиночку"
> ? :)

Это хуже чем 2 человека, но лучше, чем один... Хотя, у кого какой кот...

← →
DrPass © (2008-06-19 01:02) [12]

> Проклиная и ругая одиночество такими словами, которые Вам
> еще рано знать :)
>
> P.S.
> А создание проекта с котом на пару это "в одиночку" ? :)

Замуж вам пора, сударыня :)

← →
Юрий Зотов © (2008-06-19 01:09) [13]

> Zebra-64 (19.06.08 00:07) [4]
Серьезные программы начинаются совсем не с дизайна, да и вообще не с визуалки.

> Сергей_77 (19.06.08 00:14) [6]
Программа, которая делается в за месяц - это мелочь. Почти ничто.

← →
korneley © (2008-06-19 01:17) [14]

> Юрий Зотов © (19.06.08 01:09) [13]

(Мечтательно) Серьёзные программы начинаются с серьёзного финансирования...

← →
wl © (2008-06-19 01:26) [15]

> Расскажите, как Вы создаёте крупные программы, когда работаете
> в одиночку.

иду на http://sf.net

← →
Германн © (2008-06-19 02:09) [16]

> просто сразу пишите код

Именно так.

← →
Riply © (2008-06-19 03:15) [17]

> [12] DrPass © (19.06.08 01:02)
> Замуж вам пора, сударыня :)

"Он жизнь решил закончит холостую
И стал бороться за семейный быт.
«Я, - говорил, - жену найду такую,
От зависти заплачете навзрыд!»
Он все углы облазил – и
В Европе был, и в Азии –
И вскоре раскопал свой идеал.
Но идеал связать не мог
В археологии двух строк, -
И Федя его снова закопал." (c) Высоцкий

Но эт не про меня, просто вспомнилось при Вашей попытке
рассматривать мужа как соучастника создания проектов :)

← →
имя (2008-06-19 03:16) [18]

Удалено модератором

← →
имя (2008-06-19 03:17) [19]

Удалено модератором

← →
Riply © (2008-06-19 03:23) [20]

> [18] Zebra-64 (19.06.08 03:16)
> прорисовка на бумаге дизайна, расположения элементов, в большинстве случаев это желательно
> Знать, где дуте меню, а где панель с прибамбасами, приблизительно знать надо, чтобы грамотно раположить все элементы,
> а не создавать киш-миш и засовывать всё в одну кучу. Интуитинвый интерфейс - залог того,
> что этот "серьёзный проект" вообще кто-то будет использовать.

Черт побери ! А что же делать если у проекта вообще нет интерфейса
или он состоит всего из пары кнопок да одного Memo ?

:)

← →
имя (2008-06-19 05:02) [21]

Удалено модератором

← →
Riply © (2008-06-19 05:18) [22]

> [21] Орфограф (19.06.08 05:02)
> уууу! :)) Что вы не понимаете: вопрос был про "серьёзный проект", а не про две кнопки на форме с мемкой

Вот ведь. Век живи - век учись.
Я ж и не знала, что, например, проект Руссиновича RootkitRevealer
совсем не серьезный, ибо в нем только одна кнопочка и (вроде) ListView :)

← →
имя (2008-06-19 05:24) [23]

Удалено модератором

← →
atruhin1 (2008-06-19 08:55) [24]

[18] Zebra-64 (19.06.08 03:16)
[23] Орфограф (19.06.08 05:24)
Может мне везет, но редко когда на программирование интерфейса, уходило
более 15-20% времени разработки. Да и начинаются интерфейсные "подвижки"
где то во второй половине разработки, до этого хватает тестов.

← →
Sergey13 © (2008-06-19 09:15) [25]

> [18] Zebra-64 (19.06.08 03:16)

Это важный этап производства. Но он стоит в конце списка важных этапов. Где то перед (вместе с) тестированием.
Кому нужна неработающая (плохо работающая) красота?
ИМХО.

← →
Ega23 © (2008-06-19 09:55) [26]

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

Крупный проект - это тыщ так 200-300 строк кода.
А за месяц - это так. Мелочь.

← →
@!!ex © (2008-06-19 10:01) [27]

200-300 000 строк... в одиночку....
Круто... У меня предел был около 50....

← →
Ega23 © (2008-06-19 10:07) [28]

> 200-300 000 строк... в одиночку....

А кто про одиночку говорит? В одиночку серьёзные проекты не делаются.

← →
SergeyIT © (2008-06-19 10:12) [29]

Как я понимаю - серьезный не значит большой, а значит что решает серьезные задачи, то есть дает большой эффект от внедрения.

← →
БарЛог © (2008-06-19 10:13) [30]

не ешь, не пьёшь, кодишь :)

← →
БарЛог © (2008-06-19 10:13) [31]

хотя, да
Ega23 © (19.06.08 10:07) [28]
+1

← →
VICTOR_ (2008-06-19 10:45) [32]

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

1. Проводится изучение предметной области.
2. Пишется и согласовывается "Техническое задание".

Все основные моменты излагаются на бумаге. В памяти происходит генерация идей и их осмысление. Писать сразу код - это неподходящий метод для крупных (коммерческих) проектов.
Блок-схемы используются для описания наиболее ключевых алгоритмов. Для описания бизнес-логики используются UML-схемы. Для описания модели базы данных могут использоваться Database-схемы.
Для начального уровня для создания схем вполне подойдет Microsoft Visio.

← →
Kostafey © (2008-06-19 10:48) [33]

> [9] Riply © (19.06.08 00:37)
> P.S.
> А создание проекта с котом на пару это "в одиночку" ? :)

Это не точно не в одиночку :)

> [30] БарЛог © (19.06.08 10:13)
> не ешь, не пьёшь, кодишь :)

Да, верно, главное не пить :)

← →
Ega23 © (2008-06-19 10:49) [34]

> Для начального уровня для создания схем вполне подойдет
> Microsoft Visio.
>

"You must be rich!" (c) Back To The Future, part I

← →
MsGuns © (2008-06-19 11:03) [35]

Вопрос в тему: Что автор имеет в виду под "крупным проектом" ?
Можно крестики-нолики зафуговать в миллион строк, а можно в какой-нибудь ERP маленьким модулем реализовать задачу расчета незавершенного производства для цеха или изделия.

← →
VICTOR_ (2008-06-19 12:07) [36]

> "You must be rich!" (c) Back To The Future, part I
>

Ну я ж не предлагаю для начального уровня - Power Designer или продукты от IBM/Rational :)
Автор топика может и сам поискать бесплатные (или более дешевые) аналоги, если ему не подходит Microsoft Visio по цене либо функциональности.

← →
VirEx © (2008-06-19 12:32) [37]

блок схемы, и вобще рисование на листочке - дисциплинирует

← →
Сергей_77 (2008-06-19 12:37) [38]

а про крупные проекты имхо самое сложное (как мне кажется) обеспечить распределение ролей между программерами, чтобы небыло как у Майкрософт "правая рука не знает что делает левая" ))

← →
Ega23 © (2008-06-19 12:41) [39]

> как у Майкрософт "правая рука не знает что делает левая"

Пардон, а откуда у Вас такая информация????

← →
Сергей_77 (2008-06-19 12:55) [40]

> Ega23 ©
> Пардон, а откуда у Вас такая информация????

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

← →
Mystic © (2008-06-19 13:25) [41]

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

← →
den303 © (2008-06-19 14:04) [42]

Как можно быстро узнать количество строк кода в проекте? Где-то было, но забыл.

← →
VirEx © (2008-06-19 14:08) [43]

> [42] den303 © (19.06.08 14:04)
> Как можно быстро узнать количество строк кода в проекте?
> Где-то было, но забыл.

распечатать на принтере весь исходный код, отсканировать файнридером в один документ, распознать в обычный текст, скопировать в блокнот, поставить галку "вид-строка состояния", нажать end

← →
DVM © (2008-06-19 14:19) [44]

> den303 © (19.06.08 14:04) [42]

Скомпилировать - там скажут сколько строк

← →
MsGuns © (2008-06-19 14:38) [45]

Самое важное в крупном проекте - это грамотная, максимально исчерпывающая ПОСТАНОВКА ЗАДАЧИ, т.е. упрощенно говоря, что из чего получается, в каком виде и для чего собственно все это делается. Потом идет МОДЕЛИРОВАНИЕ ДОКУМЕНТООБОРОТА и РАЗРАБОТКА ТЕХЗАДАНИЯ.
А вот уже потом всякие там распределения по людям, выбор инструментария, требования к интерфейсу и прочая лабуда

← →
isasa © (2008-06-19 14:40) [46]

Mystic © (19.06.08 13:25) [41]

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

:)
Этап циклический.
Перемежающийся с мыслью "На хрена я это делал?". Далее, поиск путей взаимодействия "кусков". Далее слияние. Далее - как разбить.

← →
DVM © (2008-06-19 14:42) [47]

> Самое важное в крупном проекте - это грамотная, максимально
> исчерпывающая ПОСТАНОВКА ЗАДАЧИ

Это точно! Пока заказчик сам не поймет, что он все таки действительно хочет.

← →
isasa © (2008-06-19 15:09) [48]

DVM © (19.06.08 14:42) [47]

> Самое важное в крупном проекте - это грамотная, максимально
> исчерпывающая ПОСТАНОВКА ЗАДАЧИ

Это точно! Пока заказчик сам не поймет, что он все таки действительно хочет.

Заказчик НИКОГДА САМ не поймет, чего он хочет, т.к. он считает, что это должен сделать исполнитель. За все оплачено. :)

← →
Mystic © (2008-06-19 15:22) [49]

Как я понял, изначально ставился вопрос о крупном проекте для себя :) Тут ТЗ может быть достаточно простым. Например, я сейчас в свободное время выполняю проект с ТЗ: "Написать движок го-программы, которая бы играла в силу первого про дана". В общем, никаких проблем с тем, что я хочу нет. Основной вопрос КАК?

← →
Anatoly Podgoretsky © (2008-06-19 15:33) [50]

> Ega23 (19.06.2008 9:55:26) [26]

А ты спроси Панова, как он компилятор и среду тестировал, сколько у него миллионов строк было и спроси крупный ли это проект.

← →
Anatoly Podgoretsky © (2008-06-19 15:36) [51]

> Kostafey (19.06.2008 10:48:33) [33]

По крайней мере одному из двух.

← →
MsGuns © (2008-06-19 16:16) [52]

>isasa © (19.06.08 15:09) [48]
>Заказчик НИКОГДА САМ не поймет, чего он хочет, т.к. он считает, что это должен >сделать исполнитель. За все оплачено. :)

Ерунда ! Заказчик всегда точно знает что он хочет. Но выразить это в "наших" терминах не может и понятно почему. ИсТр и составляются для того, чтобы на языке, понятном и ему и разработчкику описать что он хочет и в каком виде. При этом всякие рюшечки-бантики, сервисы-плагины его не интересуют - это делается для тех, кто будет сидеть за компом. Ему же нужна прежде всего ЭКОНОМИЧЕСКАЯ ВЫГОДА, которую ощутит лично он после внедрения и запуска проекта в эксплуатацию.

Сергей_77 (18.06.08 23:54)

Если что-то сложное в двоем или более. Особо эффективно если у всех разные точки зрения.

> Ерунда ! Заказчик всегда точно знает что он хочет.

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

> [52] MsGuns © (19.06.08 16:16)

+1

> [54] Mystic © (19.06.08 16:20)
Мне нужны штаны. Пойду выбирать - померяю, посмотрю как сидят, с женой посоветусь. Какие-нибудь куплю. Теща, если что подошьет немного. Какая же тут непределенность?

> Мне нужны штаны. Пойду выбирать - померяю, посмотрю как
> сидят, с женой посоветусь. Какие-нибудь куплю.

Ну видишь, изначально-то неопределённость.
Сколько раз я от директора слышал: "Мне пофиг ваши заморочки, мне нужно штоб работало и было красиво."

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

во-во.

> [56] Ega23 © (19.06.08 16:34)

Так это самые золотые клиенты! 8-)
Сделал им красивую анимашку и кнопку "Выход". Все красиво работает. Можно зарплату получать. 8-)

Все таки сайт и штаны вещи достаточно стандартные.
Вот если задача стоит как "комплексная автоматизация всего предприятия" - тут да, неопределенность. Но для этого и существует этап (очень кстати недешевый) обследования предприятия и составления ТЗ.

при разработке коробочных продуктов процесс немного иной, imho. Конечно всякие гиганты вроде MS, 1C, Abobe и т.п. могут себе позволить составлять полную проектную документацию, но в подавляющем большенстве продуктов вся документация сводится к системе баг-трекинга.

> Все таки сайт и штаны вещи достаточно стандартные.

Этот пример описан у К. Бека. В частности, ему не понравилось, что когда его фирма решила создать сайт, то им предложили несколько типовых проектов. А он сразу не мог понять, нужны они ему или нет. И предлагал вести разработку по XP, чтобы в процессе понять, какой сайт он действительно нужен :)

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

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

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

Mystic © (19.06.08 17:21) [61]

> И предлагал вести разработку по XP

При всем уважении к Беку, все-таки являюсь ярым противником XP или, скорее, интерпретаций XP, таких, что мол, давайте сделаем, а потом будем переделывать.

> Сайт - это скорее из области рекламы и маркетинга, а там
> несколько по-другому считается эффект.

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

Разумеется, как и я не имею представления в каких я должен быть штанах, чтобы все бабы дружно меня зажаждали ;)

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

Во-первых, это работает в комплексе с остальными методиками XP, в частности работа с заказчиком должна быть в стиле XP. Ну и разумные рамки должны быть. Если что-то описано в ТЗ, естественно, это придется реализовывать. И сделаем/переделаем тут на работает. А вот если некая возможность не присутствует напрямую в TЗ, но фигурирует якобы в перспективе... Стоит ли на нее закладываться? Например, ходят слухи о том, что заказчик хочет портировать систему под Linux, но в ТЗ этого нет. Стоит ли в этом случае сразу закладываться на возможный переход под Linux? Которого может и не быть?

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

> Разумеется, как и я не имею представления в каких я должен
> быть штанах, чтобы все бабы дружно меня зажаждали ;)

Но это не факт, что такие штаны невозможно изготовить. Это просто пример того, что ни заказчик, ни разработчик могут и не знать, что конкретно требуется, и что вписать в ТЗ :)

Mystic © (19.06.08 19:52) [66]

> Во-первых, это работает в комплексе с остальными методиками
> XP

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

> А вот если некая возможность не присутствует напрямую в
> TЗ, но фигурирует якобы в перспективе... Стоит ли на нее
> закладываться? Например, ходят слухи о том, что заказчик
> хочет портировать систему под Linux, но в ТЗ этого нет.
> Стоит ли в этом случае сразу закладываться на возможный
> переход под Linux? Которого может и не быть?

Да, стоит. Однозначно. Хотя бы архитектурно отделять системно-зависимые части от системно-независимых. И средствао разработки выбирать соответствующее. А то напишем, скажем, на delphi, а заказчик все-таки решит на Линукс перейти сдуру или спьяну. И все по новой писать (FreePascal не предлагать)

← →
Галинка (2008-06-19 23:49) [69]

isasa © (19.06.08 14:40) [46]

прямо философия... анализ (разбить), синтез (слить), анализ, синтез, ... и так до бесконечности...

← →
-koha (2008-06-19 23:57) [70]

говорят блокнот в windows разрабатывали и доводили до совершенства аж 3 года - чем не серьезное проектирование?

← →
Галинка (2008-06-19 23:59) [71]

правильно поставленная задача - это минимум 75% успешного решения. Поэтому надо начинать с ТЗ и плана разработки. ТЗ определит средства разработки, основные алгоритмы, структуру классов/данных. Средства определят специфические алгоритмы и реализацию всех алгоритмов и классов. А вот после этого наступит фаза:

> БарЛог © (19.06.08 10:13) [30]
>
> не ешь, не пьёшь, кодишь :)

> правильно поставленная задача - это минимум 75% успешного
> решения. Поэтому надо начинать с ТЗ и плана разработки.
> ТЗ определит средства разработки, основные алгоритмы, структуру
> классов/данных. Средства определят специфические алгоритмы
> и реализацию всех алгоритмов и классов.

Да глупости все это. Я кучу раз слышал подобное. И как раз от тех, кто сам ничего серьезного никогда и не писал. Для сложного проекта невозможно заранее задать техзадание. Можно лишь описать расплвывчатую рыбу. И начинать нужно с простого - с поставления себя любимого на место пользователя, и попытки понять - что он делать, как, чем ему прога сможет помочь и как, удобно ли ему, нравится ли ему и т.д.
Т.е. идет постоянная вилка: интерфейс/алгоритмы.

И уж поверьте, я знаю о чем говорю, бо более 100000 юзеров используют прогу которую я написал именно так, как указано. И написал один. Впрочем, когда было около 50000 юзеров, ко мне подключились небезызвестные Гаврила, Розыч, и Джек который 128. :)
И вот нету у нас никаких техзаданий, всяких дармоедов аналитиков и т.п.

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

← →
VICTOR_ (2008-06-20 11:42) [74]

> И вот нету у нас никаких техзаданий, всяких дармоедов аналитиков
> и т.п.

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

Очень часто проекты имеют другую специфику
- финансовые ограничения Заказчика
- временные ограничения Заказчика
- требования к функциональности от Заказчика

И тут без Технического задания (в письменном виде), "дармоедов-аналитиков" и т.п. никак не обойтись. Все сводится к разговору "для бедных": "А как же Вы не предусмотрели, что нужно было сделать еще то и то и это. Для меня это очень важно, но я просто забыл сразу Вам про это сказать. Я заплатил Вам такие огромные деньги, а Вы сделали совсем не то. Переделайте пожайлуста". И все в тот же срок и за те же деньги.

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

> "А как же Вы не предусмотрели, что нужно было сделать еще
> то и то и это. Для меня это очень важно, но я просто забыл
> сразу Вам про это сказать. Я заплатил Вам такие огромные
> деньги, а Вы сделали совсем не то. Переделайте пожайлуста".
>

Знакомо. :) Вот только никакой аналитик этой ситуации не исключит. Потому и бездельник. Чтобы избежать таких вопросов, нужно чтобы постановщик задачи/программист/ну или пусть аналитик :) был глубоко в теме предметной. Что практически всегда нереально. Бывают впрочем и исключения. А раз не в теме, то никакого толкового ТЗ не выйдет. Что и наблюдается повсеместно. Хотя способы выхода из ситуации конечно есть.

> В одном из последних проектов (коробочный продукт)

А что за продукт если не секрет?

Разработка серьёзного ПО Найти похожие ветки