Опубликован: 18.06.2007 | Уровень: специалист | Доступ: платный | ВУЗ: Сибирский федеральный университет (г. Красноярск)
Лекция 7:

Формирование видения

< Лекция 6 || Лекция 7: 12 || Лекция 8 >
Аннотация: Работы по формированию видения продукта и границ проекта обычно начинаются на самой ранней фазе проекта, до начала широкомасштабных консультаций по выявлению подробных требований, поэтому этот вопрос нельзя оставлять без внимания.

Видение продукта и границы проекта

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

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

В первом случае речь идет о видении того, какой должна быть система. Обсуждаются высокоуровневые требования (возможности, свойства) продукта и наиболее существенные ограничения. Ряд авторов, напротив, настаивает на том, что видение должно быть "ничем не ограниченным".

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

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

Во втором случае (рамки, границы, контекст) обсуждаются такие вопросы, как граница системы и среды, требуемые ресурсы на создание системы, сроки. Построив "ничем не ограниченное видение", рано или поздно приходится вернуться к таким прозаическим вещам, как бюджет, календарное планирование, подбор персонала, вехи проекта.

Всегда ли нужно создавать документ "Концепция"? Следует ли разделять видение и границы?

Зачастую Заказчик осознает необходимость автоматизации, как способ решения накопившихся проблем. Сформулировав для себя проблему, Заказчик часто видит и вариант ее решения, с которым приходит к Исполнителю ("мне нужен сайт", "требуется CRM-система" и т.п.). Квалифицированный Исполнитель не должен, сломя голову, спешить решать задачу в формулировке Заказчика. По образному выражению Г.Калянова 1Калянов Г. Н. Консалтинг при автоматизации предприятий: Научно-практическое издание. Серия "Информатизация России на пороге XXI века". - М.: СИН-ТЕГ, 1997. автоматизировать процессы "как есть" - все равно, что асфальтировать дорожки, по которым ходят коровы.

В нотации RUP присутствует важная метафора: "Увидеть проблему за проблемой". Концепция как раз и служит для того, чтобы помочь Заказчику выявить именно те требования к системе, которые помогут ему оптимизировать работу своего предприятия в долгосрочной перспективе.

Поэтому этап формирования концепции важен, но он предъявляет и к Заказчику и к Исполнителю достаточно высокие требования: Заказчик должен выделить ресурсы и быть готовым к трудозатратам на совместный поиск решений; Исполнитель должен обладать достаточной квалификацией как в сфере IT-, так и в сфере управления предприятиями, чтобы разрабатываемое средство автоматизации действительно принесло пользу. Все вышесказанное ничуть не исключает возможность работы без концепции: либо речь идет о небольшом проекте, закладывать в бюджет которого этап выработки концепции просто нерентабельно, либо Заказчик сам обладает достаточной квалификацией, чтобы сформулировать требования к АИС, имея "концепцию в голове" и время для консультирования Разработчика.

Некоторые аргументы за разделение видения и границ были приведены выше. Провести четкую границу между этими понятиями предлагает, в частности, процесс MSF. В конечном итоге, вопрос "разделять или не разделять" определяется выбранной методологией.

Рассмотрим основные требования к выработке концепции, заложенные в отечественных ГОСТ, методологиях RUP и MSF.

Концепция в ГОСТ РФ

В соответствии с ГОСТ 34.601-90 "Автоматизированные системы. Стадии создания" [7.2], после этапа формирования (выявления) требований к системе выполняется этап разработки концепции системы.

Основные работы этапа:

  • Изучение объекта;
  • Проведение научно-исследовательских работ (НИР);
  • Разработка вариантов концепции АС;
  • Оформление отчета о выполненной работе.

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

Работы над концепцией начинаются с обследования объекта автоматизации. Выполняются НИР, направленные на исследование принципиальной реализуемости требований и возможных вариантов реализации.

ГОСТ, в отличие от большинства современных методологий, в общем случае закладывает многоальтернативность вариантов концепции системы и планов их реализации. Каждый из проработанных вариантов оценивается с позиций требуемых ресурсов и функциональности. Для вариантов должны быть представлены оценки преимуществ и недостатков. Полезность проработки нескольких вариантов концепции заключается в том, что Заказчику трудно сформулировать самостоятельно видение системы, в то время, как выбор из набора вариантов, представленных Разработчиком - вполне посильная задача.

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

< Лекция 6 || Лекция 7: 12 || Лекция 8 >
Александр Медов
Александр Медов

Здравствуйте, прошел весь курс,хотел заказать версию для печати но она не кликается,когда исправяте данную опцию?

Илья Макаренко
Илья Макаренко

Добрый день.

Вопрос №1

Какова стоимость получения диплома о мини-МБА по данному курсу? Или ориентироваться на указанную на сайте?

Вопрос №2

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

Анатолий Федоров
Анатолий Федоров
Россия, Москва, Московский государственный университет им. М. В. Ломоносова, 1989
Алексей Махонин
Алексей Махонин
Россия, Волжский, Средняя школа №12, 1990