1106 в МинфинеТребования устаревают?
Но если их писать быстро , то можно успеть?
Дело в том, что концепция склонна меняться - под влиянием "озарений", выхода новых систем, изменения предметной области. Как только изменения достигают некоторого критического значения - нужно уточнять, переписывать и переутверждать требования, особенно варианты использования.
Если написать требования быстро, то после написания последних требований первой версии их можно отдавать разработчикам вместо того, чтобы переписывать заново.

1106 в Минфине
А разработчики успевают за аналитиком?

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

1106 в Минфине
И как в таком случае происходит внедрение?

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

1106 в Минфине
Что это за экстрим такой?

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

1106 в Минфине
А, может, в бизнесе надо порядок навести? ... чтоб требования не устаревали за 3дня/неделю/месяц?
Боюсь, что такой "законсервированный" бизнес довольно быстро вылетит в трубу, если, конечно, речь идёт о коммерческом предприятии. Системы создаются по нескольку лет, за это время может серьёзно измениться рынок, законодательство, бизнес-процессы.

stells2<...>
Часто возникает ситуация, когда общие требования к АС есть, но АС состоит из множества АРМ, стоит ли писать на каждый АРМ требования? или достаточно общей концепции?

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

stells2
<...>Не секрет же, что в РФ, часто, всё пишется уже на то, что сделано..
Не в РФ, а определёнными классами исполнителей для определённых классов заказчиков. А идёт это откуда-то от из СССР, от отраслевых АСУ, когда всё, в чём присутствовало слово "ЭВМ", вызывало трепет, было безумно модным и оправдывало любые издержки, благо, они были не из своего кармана.
Ну и ещё когда программисты работали за интерес и совесть, и обладали, в большинстве своём, научными степенями.

stells2
Где критерий "сложности" определяющий необходимость отдельного описания той или иной части АС?

Критерий - когда разработчик не знает, что делать и с чего начать. Ну или когда пару раз начинает не с того и делает не то.

stells2
Всё должно быть продумано до мелочей, это так.. но такая цель естественно не достижима. :(.

IMHO мелочи лучше всех может продумать разработчик - не надо его недооценивать. Если не давать разработчику возможности принимать решения - ПО будет разрабатываться по принципу "к пуговицам претензии есть?"

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

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

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

stells2<...>Но это приложение никчемно в иных производственных участках, хоть как там формируй интерфейс.
Слишком специфичны задачи.

Наверное, сказывается то, что я имел дело в основном с приложениями, обладающими web-интерфейсом. В этом случае объединение экранов (страниц) в "АРМ" определённой роли сводится к ограничению доступа ко всем остальным экранам.
Согласен, что web-интерфейс применим далеко не всегда: датчик температуры расплавленного чугуна через RS-232 к нему не подключишь, большие объёмы данных анализировать и визуализировать не очень удобно :) .

stells2
Ну да, так должно быть, как много вы знаете «вменяемых» заказчиков? Особо, если платятся деньги, и как правило большие?

Знаю четырёх. Наверное, везёт, и/или мы ухитрились правильно себя поставить.
Можно отказаться и от больших денег - если издержки ещё больше :) .

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

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

stells2
<...>Однако, гонка за прибылью кидает их на ту работу, в которой они, извиняюсь, профаны.
Таких много. Замечательно продают воздух, иногда испорченный :) .

AlexTheRaven
IMHO мелочи лучше всех может продумать разработчик - не надо его недооценивать. Если не давать разработчику возможности принимать решения - ПО будет разрабатываться по принципу "к пуговицам претензии есть?"
Не концептуальные мелочи, конечно. Но GUI без спецификации умный разработчик (НЕ кодер, НЕ работающий по принципу "дайте зарплату и отвалите") делает обычно быстрее, рациональнее и удобнее, чем со спецификацией.

AlexTheRaven
А вот тут и «выплывают» требования, которые должен составлять специалист предметной области, а не разработчик. Разработчик не является экспертом в данной предметной области. Реинжениринг, или оптимизация бизнес процессов – предусматривает многое, но в первую очередь работу экспертов и аналитиков. Далеко не всегда он удается, не только в РФ, но думаю и в мире.. По этому, «оптимальная» модель – это не теория.. Это звено «как будет» в цепочке: «как есть» -> «как надо» -> «как будет» = <что получилось>
ОК. Тогда понятно.
Хотя я всё же считаю, что разработчик должен знать предметную область в рамках концепции системы и её аналитической модели. Он должен понимать, что и зачем разрабатывает, хотя бы в рамках своей задачи и модуля, а если не понимает - спрашивать. Иначе он становится кодером, требует детальнейшей спецификации, которую выполняет в стиле "заставь дурака Богу молиться". Ему самому это не нравится, работа скучная, мотивация падает, количество ошибок на стоку кода растёт, сроки растягиваются...

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

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