Добрый день коллеги и примкнувшие к ним программисты

Допустим есть новый проект
происходит обследование организации
как результат есть документация явлющаяся результатом обследованием -назовем ее  КД1
( в 1 случае когда обследовали с целью внедренияя западной XXX системы  -
это вордовский файлы - с встроенными арис диаграммами)
Проект загнулся по причине (а не важно)
А интеерсует собственно вото что

1 у кого что является резульататом обследования КД1

2 Кто пользуется этим ( заказчик программисты аналитики) и пользуется ли вообще

3 Как КД1 меняется с течением времени и какова вообще ее судьба если внедрение идет скажем >1 года

зы Хотелось бы услышать людей с ПРАКТИЧЕСКИМ ОПЫТОМ

Федор,

Вам сейчас быстренько Боатман по полочкам все разберет, но успею сунуть свои 5 копеек

Ответы на ваши вопросы:
1. Концептуальный документ (Vision), читаем статьи Боатмана по этому поводу.
2. Концептуальным документом пользуются Аналитики и Заказчики
3. Не понятно что Вы имеете ввиду под КД. Если мы говорим о Визион, то он может меняться по мере уточнения требований, но надо стремится к минимуму изменений после фиксации целей и потребностей. Просто тут проблема в том что под документом об обследовании считается просто описание БПроцессов организации, что в корне не верно.

Небольшая ремарка:
* Если целью стало Внедрение, то это роковая ошибка, поэтому и внедрилось ничего.
* Идем в раздел целеполагание и там изучаем все ветки внимательно.
* КД - это что у вас за сокращение?? Обычно это Конструкторская Документация. У вас видимо это комплект документов

--У вас видимо это комплект документов
да
Концептуальный документ (Vision),
? Vision (знаю только Visio) что за оно
ссылку плиз почитаю

-- Концептуальным документом пользуются Аналитики и Заказчики
пару слов сюда расшифруйте КАК пользуются
особенно заказчики - ПРАКТИЧЕСКИ ? (кто)

ps to bas & boatman елси не секрет вы внедряете западные или местные системы,
на базе или писанные с нуля ?
 имхо может быть большая разница

Я внедряю две вещи:
1. Заказные разработки с нуля
2. Кастомизация собственного большого ПО

В чем вопрос то??

Концептуальный документ (Vision),
? Vision (знаю только Visio) что за оно
ссылку плиз почитаю

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

-- Концептуальным документом пользуются Аналитики и Заказчики
пару слов сюда расшифруйте КАК пользуются
особенно заказчики - ПРАКТИЧЕСКИ ? (кто)

В нем зафиксировано понимание того, что нужно сделать на самом общем абстрактном уровне. Он поределяет границы проекта, системы, позволяет выявить риски, составить план проекта, дать общие оценки финансирования, понять, что будет разработано, а что возможно куплено на стороне.

Крэг Ларман, Лиффенгуэлл, Коберн, Кратчен, Рамбо, Блаха - кроме того можно посмотреть здесь: http://www.epfwiki.net/wikis/openupru/

Спасибо ВСЕМ за ответы
1? честно говоря я так и не понял каим образом ЗАКАЗЧИК пользуется КД1-
(сам то я думаю что в 9 из 10 никак а вот про 10 и хотелось бы спросить 

>> В нем зафиксировано понимание того, что нужно сделать на самом общем абстрактном уровне. Он поределяет границы проекта, системы, позволяет выявить риски, составить план проекта, дать общие оценки финансирования, понять, что будет разработано, а что возможно куплено на стороне.

замечательно а вот где бы посмотреть ну хотя бы рыбу из ПРАКТИКИ
(понимаю что это комм. тайна - короче все что ей не является)
те примерно структуру РЕАЛЬНОГО док-та
ЗЫ Я посмотрел http://www.epfwiki.net/wikis/openupru/
все это интеерсно но к сожалению далековато от моей текущей ситуации
+что то там язык то русс. то англ.
вот интересно Stakeholder - имеет доп. задачу Create Test Cases
на нашей практике что-то я сильно сомневаюсь в реальности  такого
более того и тестеров на наших (СНГ) проектах очень мало

Возможно вам поможет эта ссылка:
http://www.intuit.ru/department/itmngt/analisis/7/

Примеры Вы врядли найдете, но поиск в гугле по словам: system/software vision sample/example может помочь

Подыму тему по результатам SEF 2009
был там правда к сожалению не на всех семинарах (накладка по времени с работой) - товарищ был на всех uml2.ru (он там все книжки пеерчитал)
Честно г-ря впечатления средние - в ообщем толковый пересказ учебников
местами интеересно местами не очень
прямо скажем UML мастер класс сильно разочаровал
к сожалению без каких-то примеров РЕАЛЬНЫХ проектов и удачн. решений 
ошибок на них (а не скажем какие штуки есть в UML).
Понятно что время ограничено комм. тайна и т.д и др. сложности
но вообщем бы хотелось бы в след. раз услыашть что-то практическое
ну да ладно платила контора

а больше всего меня интеерсует образец документа Vision ну или хотя бы выдержки из него пусть 10 летней давности
или скажем с замеными названиям ОАО Рога и Копыта
ну хоть шаблон
зы по мотивам беседы с Д.Безуглым я так понял что это нужно в 1 очередь для
самого аналитика - для приведения в порядок мыслей т.к. начальству обычно показываются картинки - поэтому любые образцы и т.д.
ззы гогл я еще в тот раз юзал - безрезультатно

а больше всего меня интеерсует образец документа Vision ну или хотя бы выдержки из него пусть 10 летней давности
или скажем с замеными названиям ОАО Рога и Копыта
ну хоть шаблон

Так и быть, раскрою один профессиональный секрет. Только тс-с-с-с! 

На странице uml2.ru, в левой колонке, есть такой блок "поиск по сайту". Ввожу туда запрос "шаблон концепции". Нажимаю кнопочку. Получаю результат поиска. Кликаю по второй ссылке (первая предлагает версию для печати). А там - опаньки! - вот такая ссылка:

Vision for UML2

 

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

Можете дать ссылки на учебники, в которых раскрыты 1) риски аналитика, 2) проблемы выявления требований и 3) постановка процесса УТ? спасибо.

а больше всего меня интересует образец документа Vision ну или хотя бы выдержки из него пусть 10 летней давности

Вот образцы от Вигерса: http://www.processimpact.com/process_assets/sample_requirements_documents.zip

Федор,

Вот Vision - это реально баян, но мы постарались вроде рассказать на СЕФ что-то действительно новое, чего нет в учебниках. А за отзыв спасибо, будем еще тщательнее думать перед Конференцией. Могли бы Вы назвать темы, которые Вам были интересно услышать на Конференциях?

смодерирую 

Могли бы Вы назвать темы, которые Вам были интересно услышать на Конференциях?

к сожалению без каких-то примеров РЕАЛЬНЫХ проектов и удачн. решений 
ошибок на них (а не скажем какие штуки есть в UML).
вообщем бы хотелось бы в след. раз услыашть что-то практическое

Поддержу fedor'а. Я вчера смотрел презентации. Рекомендации все дельные, подписался бы. Но одно дело, когда ты сам это сто раз пережил на практике, то и все эти слова кажутся само собой разумееющимися. А для новичков, видимо, действительно не хватает ПРИМЕРОВ - была такая-то конкретная проектная ситуация, применили вот такой метод, стало лучше таким-то вот образом, при этом, однако, огребли вот такие наведенные проблемы, но все равно выгоды перевесили минусы потому-то - вот это было бы совсем зачетно.

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

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

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

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

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

Пример 2 вообще коротенький, это делалось в командировке за один день, реально примерно за 1,5 часа - приехали на пресейл, выслушали заказчика, набросали vision (вот этот), согласовали с заказчиком - и пошли делать проект.

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

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

Иногда, конечно, vision делается и по итогам обследования, но это реже, и на этом этапе роль именно vision'а как проектного артефакта существенно ниже. Собственно, на данном этапе уместнее написать отчет об обследовании или даже ТЗ. По крайней мере, те vision'ы, которые делались "по результатам обследования", было безумно трудно запихать хотя бы в 10-15 страниц, потому что аналитики уже нарыли кучу деталей, и вся эта куча страшно выпирает. Эти вижны ОЧЕНЬ похожи на краткие ТЗ. Там 5% информации по целям и границам проекта, 10% про потребности пользователей, еще 5% всякие планы и риски, и 80% - это требования, требования, требования... Имхо теперь когда читаю эти документы задним числом - не могу понять, зачем мы это оформили как vision, почему не написали сразу ТЗ.