Видение продукта и границы проекта
Работы по формированию видения продукта и границ проекта обычно начинаются на самой ранней фазе проекта, до начала широкомасштабных консультаций по выявлению подробных требований, хотя в целом наличие и последовательность данных шагов зависит от выбранной методологии. На практике данные работы зачастую совмещаются. Правила извлечения требований, рассмотренные в "Выявление требований" , могут быть использованы и при формировании видения.
Анализируя литературу по рассматриваемой тематике, можно выделить следующие широко употребимые ключевые слова: с одной стороны - концепция, видение, образ, с другой - рамки, границы, контекст.
В первом случае речь идет о видении того, какой должна быть система. Обсуждаются высокоуровневые требования (возможности, свойства) продукта и наиболее существенные ограничения. Ряд авторов, напротив, настаивает на том, что видение должно быть "ничем не ограниченным".
Понятие видения широко употребимо в бизнес-анализе. Если у топ-менежмента компании имеется представление о том, какие ключевые цели, сегменты рынка, товарные позиции, прибыль должны быть достигнуты, допустим, через 5 лет - значит, компания имеет долгосрочное видение себя на рынке. Способ снятия ограничений при выработке видения позволяет выработать новый взгляд на вещи, "подняться над ситуацией", планировать будущее, отталкиваясь не от текущих ресурсов и ограничений, а от стратегических целей, применяя инновации, ноу-хау и т.п.
|
|
|
Данный опыт формирования видения во многом переносим и на процесс разработки информационных систем: нужно "увидеть" в горизонте средне- и (или) долгосрочного планирования, как АИС впишется в организационные процессы предприятия, какие ключевые выгоды она даст, какие проблемы позволит разрешить. При поиске новых методов и средств управления предприятием на основе информационных технологий зачастую приходится "перекраивать" существующие бизнес-процессы; по сути внедрение АИС, затрагивающей существенный процент процессов предприятия, неизбежно приводит к перестройке этих процессов с целью оптимизации деятельности предприятия, достижения ключевых факторов эффективности и пр.
Во втором случае (рамки, границы, контекст) обсуждаются такие вопросы, как граница системы и среды, требуемые ресурсы на создание системы, сроки. Построив "ничем не ограниченное видение", рано или поздно приходится вернуться к таким прозаическим вещам, как бюджет, календарное планирование, подбор персонала, вехи проекта.
Всегда ли нужно создавать документ "Концепция"? Следует ли разделять видение и границы?
|
|
|
Зачастую Заказчик осознает необходимость автоматизации, как способ решения накопившихся проблем. Сформулировав для себя проблему, Заказчик часто видит и вариант ее решения, с которым приходит к Исполнителю ("мне нужен сайт", "требуется CRM-система" и т.п.). Квалифицированный Исполнитель не должен, сломя голову, спешить решать задачу в формулировке Заказчика. По образному выражению Г.Калянова 1 автоматизировать процессы "как есть" - все равно, что асфальтировать дорожки, по которым ходят коровы.
В нотации RUP присутствует важная метафора: "Увидеть проблему за проблемой". Концепция как раз и служит для того, чтобы помочь Заказчику выявить именно те требования к системе, которые помогут ему оптимизировать работу своего предприятия в долгосрочной перспективе.
Поэтому этап формирования концепции важен, но он предъявляет и к Заказчику и к Исполнителю достаточно высокие требования: Заказчик должен выделить ресурсы и быть готовым к трудозатратам на совместный поиск решений; Исполнитель должен обладать достаточной квалификацией как в сфере IT-, так и в сфере управления предприятиями, чтобы разрабатываемое средство автоматизации действительно принесло пользу. Все вышесказанное ничуть не исключает возможность работы без концепции: либо речь идет о небольшом проекте, закладывать в бюджет которого этап выработки концепции просто нерентабельно, либо Заказчик сам обладает достаточной квалификацией, чтобы сформулировать требования к АИС, имея "концепцию в голове" и время для консультирования Разработчика.
|
|
|
Некоторые аргументы за разделение видения и границ были приведены выше. Провести четкую границу между этими понятиями предлагает, в частности, процесс MSF. В конечном итоге, вопрос "разделять или не разделять" определяется выбранной методологией.
Рассмотрим основные требования к выработке концепции, заложенные в отечественных ГОСТ, методологиях RUP и MSF.
Концепция в ГОСТ РФ
В соответствии с ГОСТ 34.601-90 "Автоматизированные системы. Стадии создания" [7.2], после этапа формирования (выявления) требований к системе выполняется этап разработки концепции системы.
Основные работы этапа:
· Изучение объекта;
· Проведение научно-исследовательских работ (НИР);
· Разработка вариантов концепции АС;
· Оформление отчета о выполненной работе.
Так как данный этап хронологически стоит на втором месте, к его началу у Разработчика на руках уже имеется документ, в котором собраны основные требования пользователей.
|
|
|
Работы над концепцией начинаются с обследования объекта автоматизации. Выполняются НИР, направленные на исследование принципиальной реализуемости требований и возможных вариантов реализации.
ГОСТ, в отличие от большинства современных методологий, в общем случае закладывает многоальтернативность вариантов концепции системы и планов их реализации. Каждый из проработанных вариантов оценивается с позиций требуемых ресурсов и функциональности. Для вариантов должны быть представлены оценки преимуществ и недостатков. Полезность проработки нескольких вариантов концепции заключается в том, что Заказчику трудно сформулировать самостоятельно видение системы, в то время, как выбор из набора вариантов, представленных Разработчиком - вполне посильная задача.
Кроме того, концепция должна отражать оценки качества, условия приемки системы, оценку эффекта, ожидаемого от реализации. При оформлении отчета необходимо привести обоснование предлагаемого варианта.
Видение в RUP
Шаги, которые необходимо пройти для формирования документа "Видение":
· Формулировка проблем.
· Идентификация совладельцев
· Определение границ системы
· Идентификация ограничений
· Формулировка постановки задач
· Определение возможностей системы
· Оценка результатов
Для описания проблем предлагается шаблон, показанный в табл. 7.1.
| Таблица 7.1. | |
| Проблема | (описание проблемы) |
| Затрагивает | (совладельцы, затрагиваемые проблемой). |
| Ее следствием является | (каково влияние проблемы). |
| Успешное решение | (список некоторых ключевых преимуществ от успешного решения). |
Идентификация совладельцев предполагает поиск и фиксацию интересантов проекта - представителей Заказчика и Исполнителя, инвесторов, внешних экспертов и пр.
Определение границ системы представляет собой нетривиальный процесс. Для этого используют контекстные диаграммы [7.1] (см. материалы "Расширенный анализ требований. Моделирование" ). RUP в поиске границ предлагает отталкиваться от факторов и вариантов использования.
Среди источников ограничений обычно выделяют:
· Политические,
· Экономические,
· Среды,
· Технические,
· Выполнения,
· Системные.
Описание возможностей системы представляет собой формулировку высокоуровневых требований.
Шаблон документа "Vision" RUP содержит следующие основные разделы:
1. Введение
2. Позиционирование
3. Описания совладельцев и пользователей
4. Краткий обзор изделия
5. Возможности продукта
6. Ограничения
7. Показатели качества
8. Старшинство и приоритеты
9. Другие требования к изделию
10. Требования к документации
11. Приложение.
Во введении описываются цель документа, его контекст (связь и взаимовлияние с различными проектами), определения, акронимы и сокращения, ссылки на другие документы, краткое содержание.
В разделе "позиционирование" помещается определение решаемой проблемы (проблем), указывается целевой заказчик и исследуются деловые преимущества изделия перед аналогичными на рынке.
В описании совладельцев и пользователей, помимо собственно описания этих двух групп, исследуется демография рынка: целевые рыночные сегменты, размер и темпы роста рынка, существующие конкурентные предложения на рынке, репутация Разработчика на рынке.
Краткий обзор изделий содержит резюме изделия, описание его перспектив и ключевых возможностей, предположения и зависимости, указывается стоимость и ее калькуляция, рассматриваются вопросы лицензирования и инсталляции.
В разделе, посвященном возможностям продукта, они описываются более подробно, каждая - в отдельном параграфе.
В раздел "Ограничения" следует выносить существующие технические, технологические и др. обстоятельства, которые необходимо учитывать на данной стадии.
Раздел "Показатели качества" содержит описание наиболее существенных нефункциональных требований к системе (эффективности, надежности, отказоустойчивости и др.).
Раздел "Старшинство и приоритеты" ранжирует сформулированные ранее требования и возможности системы по степени важности, очередности реализации и т.п.
Раздел "Другие требования к изделию" описывает применяемые стандарты, системные требования, эксплуатационные требования, требования к окружающей среде.
В требованиях к документации приводятся ключевые характеристики руководства пользователя, интерактивной справки, руководства по установке и конфигурированию, файла Read Me.
В приложение выносятся атрибуты возможностей. RUP рекомендует следующий набор атрибутов: статус, выгода, объем работ, риск, стабильность, целевой выпуск, назначение, причина.
Видение / рамки в MSF
Согласно белой книге MSF [7.3], на фазе выработки концепции (envisioning phase) закладывается одна из фундаментальных основ успеха проекта - создание и сплочение проектной группы на основе выработки единого видения. Проектная группа должна четко представить себе, что она хочет сделать для заказчика и сформулировать свою цель таким образом, чтобы максимально мотивировать как заказчика, так и саму проектную команду. Выработка высокоуровневого взгляда на цели и условия проекта может рассматриваться как ранняя форма планирования; она подготавливает почву для процессов создания детальных планов, которые будут осуществлены непосредственно во время фазы планирования.
Основными задачами фазы выработки концепции являются создание ядра проектной группы (см. ниже) и подготовка документа общего описания и рамок проекта (vision/scope document). Формирование видения проекта и специфицирование его рамок - не одно и тоже, хотя для успеха проекта необходимо и то, и другое. Видение (vision) - это ничем не ограничиваемое представление о том, каким должно быть решение . Рамки (scope) же дают четкие границы того, что из предложенного этим видением будет реализовано в условиях существующих проектных ограничений.
Управление рисками представляет собой итеративный процесс, осуществляемый на протяжении всего жизненного цикла проекта. Во время фазы выработки концепции проектная группа готовит документ оценки рисков и представляет главные риски проекта вместе с общим описанием и рамками проекта. Для получения дальнейшей информации об управлении рисками, см. "Белую книгу" дисциплины управления рисками MSF.
Также во время фазы выработки концепции производится выявление и анализ бизнес-требований. Более детально эти требования рассматриваются во время фазы планирования.
Ведущим ролевым кластером на фазе выработки концепции является "Управление продуктом".
Шаблон MSF содержит следующие разделы:
Бизнес-преимущества,
· Описание преимуществ
· Формулировка видения
· Анализ выгод
Концепция решения
· Цели, задачи, предположения и ограничения
· Анализ применимости
· Требования
Рамки
· Список характеристик/функций
· Вне рамок
· Стратегия подготовки релизов
· Критерии применимости
· Эксплуатационные критерии
Стратегии проектирования решения
· Стратегия проектирования архитектуры
· Стратегия технического проектирования
Дата добавления: 2021-03-18; просмотров: 107; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!