Эркин-ака. Недавно как раз обсуждал этот вопрос с одним из менеджеров отдела интеграции одной компании. Он высказал такую мысль что современные проекты интеграции несколько изменили свою схему. Раньше это выглядело следующим образом: 1) Приходим к Заказчику 2) Определяем его требования 3) Пытаемся смоделировать наш продукт в соответствии с требованиями Заказчика.
Нынче выглядит иначе: Заказчик избалованный конкурентными предложениями ждет следующего процесса: 1) Приходим говорим что с внедрением это будет вот так. 2) Заказчик нас чуток подправляет и мы внедряем.
На самом деле все происходит следующим образом: 1) Приходим говорим что с внедрением это будет вот так. 2) Заказчик нас чуток подправляет и мы внедряем. 3) Выясняется что здесь, здесь и здесь все совсем не так как хотелось бы.. 4) Переделываем так как надо.
То есть, в итеративном подходе к разработке усиление теперь идет не на первую фазу определения требований, а на вторую, после того как продукт уже вроде как куплен и его надо уже эксплуатировать.

Оффтоп:

Цитата:

Сообщение от Odil Abdullaev (Сообщение 152099) Несколько лет отставания согласитесь достаточно неплохо. Возьмитесь, для примера, сравнивать российские продукты банковского сектора и наши

Это тема для другой ветки :) Я думаю наши коллеги с ASBT и FIDO там к Вам присоединяться к обсуждению :)

Фишка в том, что собственно сама маршрутизация уже была. Не было встроенного редактора маршрутов :)

То есть требования были неопределены или декомпозиция процессов была недостаточна? Другми словами - плохая кваллификация внедренцев? Я даже подозреваю что скорее всего был сделан поверхностный анализ и планируемым результатом проекта было тупая поставка АС, а не законченная автоматизация. Ну бывает... кто тут безгрешен :)

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

Эркин ака, можно тут втиснутся? По части к подходу проведения работ по разворачиванию ИС в предприятии, вы упустили момент который необходим перед подготовкой ТЗ проекта, момент называется ПИР (предварительные исследовательские работы, можно просто изучение объекта). Насколько я знаю для составления проектных документаций с учетом всех требований заказчика, необходимо сначала провести исследование объекта, в котором планируется внедрять систему. Во тогда будут отпадать вопросы связанные с
и конечно отпадает вот этот вопрос
Вам конечно может быть без разницы вопросы доработки ТЗ заказчика, но для заказчика это может быть тормозящим фактором ускорения процесса внедрения.
И мое имхо, ТЗ считаю не конечным документом, так как он определяет только основные моменты предполагаемых работ, то есть цели и задачи, сроки выполнения (он же план-график) и.т.д.
По ТЗ заказчик возможно не получит всю необходимую информацию по проектируемой системе. Соответственно ТЗ должен сопровождаться Техническим проектом, то есть этим документом описываются концептуальные моменты проекта ИС, как в описательной части так и в технической и естественно финансовые затраты (вы же указываете какой этап работы сколько стоит)
Поэтому процесс необходимо провести таким образом, сначала ПИР+ТЗ+ТП(техпроект)+экспертиза проекта= создание+тестирование+внедрение+обучение
(по договорённости можно будет потом провести и сопровождение)

Совершенно верно, предварительные исследования необходимы, но в рамках предварительного обследования проводится анализ положения "как есть" и выбирается объект автоматизации. То есть этот анализ (ПИР) проводят до внедрения какого либо продукта и какого либо решения.
Мы же говорим о уже сделанном выборе объекта автоматизации - управление документами и заданиями :)

Честно, Эркин-ака. Мне непонятна Ваша категоричность. Хотите дам ссылки почитать материалы о современных методологиях. При том что жалуетесь на отставание в развитии продукта на несколько лет, сами пытаетесь использовать методики внедрения 80-х. Гибче надо быть, гибче :naughty:

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

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