страница 1
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Похожие работы
|
Анализ требований к аис 07-Формирование видения - страница №1/1
7.Формирование видения7. Формирование видения 1 Видение продукта и границы проекта 1 Концепция в ГОСТ РФ 3 Видение в RUP 4 Видение / рамки в MSF 7 Литература к лекции 9 Видение продукта и границы проектаРаботы по формированию видения продукта и границ проекта обычно начинаются на самой ранней фазе проекта, до начала широкомасштабных консультаций по выявлению подробных требований, хотя в целом наличие и последовательность данных шагов зависит от выбранной методологии. На практике данные работы зачастую совмещаются. Правила извлечения требований, рассмотренные в лекции 06-Выявление требований, могут быть использованы и при формировании видения. Анализируя литературу по рассматриваемой тематике, можно выделить следующие широко употребимые ключевые слова: с одной стороны – концепция, видение, образ, с другой – рамки, границы, контекст. В первом случае речь идёт о видении того, какой должна быть система. Обсуждаются высокоуровневые требования (возможности, свойства) продукта и наиболее существенные ограничения. Ряд авторов, напротив, настаивает на том, что видение должно быть «ничем не ограниченным». Понятие видения широко употребимо в бизнес-анализе. Если у топ-менежмента компании имеется представление о том, какие ключевые цели, сегменты рынка, товарные позиции, прибыль должны быть достигнуты, допустим, через 5 лет – значит, компания имеет долгосрочное видение себя на рынке. Способ снятия ограничений при выработке видения позволяет выработать новый взгляд на вещи, «подняться над ситуацией», планировать будущее, отталкиваясь не от текущих ресурсов и ограничений, а от стратегических целей, применяя инновации, ноу-хау и т.п. Данный опыт формирования видения во многом переносим и на процесс разработки информационных систем: нужно «увидеть» в горизонте средне- и (или) долгосрочного планирования, как АИС впишется в организационные процессы предприятия, какие ключевые выгоды она даст, какие проблемы позволит разрешить. При поиске новых методов и средств управления предприятием на основе информационных технологий зачастую приходится «перекраивать» существующие бизнес-процессы; по сути внедрение АИС, затрагивающей существенный процент процессов предприятия, неизбежно приводит к перестройке этих процессов с целью оптимизации деятельности предприятия, достижения ключевых факторов эффективности и пр. Во втором случае (рамки, границы, контекст) обсуждаются такие вопросы, как граница системы и среды, требуемые ресурсы на создание системы, сроки. Построив «ничем не ограниченное видение», рано или поздно приходится вернуться к таким прозаическим вещам, как бюджет, календарное планирование, подбор персонала, вехи проекта. Всегда ли нужно создавать документ «Концепция»? Следует ли разделять видение и границы? Зачастую Заказчик осознаёт необходимость автоматизации, как способ решения накопившихся проблем. Сформулировав для себя проблему, Заказчик часто видит и вариант её решения, с которым приходит к Исполнителю («мне нужен сайт», «требуется CRM-система» и т.п.). Квалифицированный Исполнитель не должен, сломя голову, спешить решать задачу в формулировке Заказчика. По образному выражению Г.Калянова1 автоматизировать процессы «как есть» – всё равно, что асфальтировать дорожки, по которым ходят коровы. В нотации RUP присутствует важная метафора: «Увидеть проблему за проблемой». Концепция как раз и служит для того, чтобы помочь Заказчику выявить именно те требования к системе, которые помогут ему оптимизировать работу своего предприятия в долгосрочной перспективе. Поэтому этап формирования концепции важен, но он предъявляет и к Заказчику и к Исполнителю достаточно высокие требования: Заказчик должен выделить ресурсы и быть готовым к трудозатратам на совместный поиск решений; Исполнитель должен обладать достаточной квалификацией как в сфере IT-, так и в сфере управления предприятиями, чтобы разрабатываемое средство автоматизации действительно принесло пользу. Всё вышесказанное ничуть не исключает возможность работы без концепции: либо речь идёт о небольшом проекте, закладывать в бюджет которого этап выработки концепции просто нерентабельно, либо Заказчик сам обладает достаточной квалификацией, чтобы сформулировать требования к АИС, имея «концепцию в голове» и время для консультирования Разработчика. Некоторые аргументы за разделение видения и границ были приведены выше. Провести чёткую границу между этими понятиями предлагает, в частности, процесс MSF. В конечном итоге, вопрос «разделять или не разделять» определяется выбранной методологией. Рассмотрим основные требования к выработке концепции, заложенные в отечественных ГОСТ, методологиях RUP и MSF. Концепция в ГОСТ РФВ соответствии с ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания» [7], после этапа формирования (выявления) требований к системе выполняется этап разработки концепции системы. Основные работы этапа:
Так как данный этап хронологически стоит на втором месте, к его началу у Разработчика на руках уже имеется документ, в котором собраны основные требования пользователей. Работы над концепцией начинаются с обследования объекта автоматизации. Выполняются НИР, направленные на исследование принципиальной реализуемости требований и возможных вариантов реализации. ГОСТ, в отличие от большинства современных методологий, в общем случае закладывает многоальтернативность вариантов концепции системы и планов их реализации. Каждый из проработанных вариантов оценивается с позиций требуемых ресурсов и функциональности. Для вариантов должны быть представлены оценки преимуществ и недостатков. Полезность проработки нескольких вариантов концепции заключается в том, что Заказчику трудно сформулировать самостоятельно видение системы, в то время, как выбор из набора вариантов, представленных Разработчиком – вполне посильная задача. Кроме того, концепция должна отражать оценки качества, условия приёмки системы, оценку эффекта, ожидаемого от реализации. При оформлении отчёта необходимо привести обоснование предлагаемого варианта. Видение в RUPШаги, которые необходимо пройти для формирования документа «Видение»:
Для описания проблем предлагается шаблон, показанный в табл. 7-1. Табл. 7-1.
Идентификация совладельцев предполагает поиск и фиксацию интересантов проекта – представителей Заказчика и Исполнителя, инвесторов, внешних экспертов и пр. Определение границ системы представляет собой нетривиальный процесс. Для этого используют контекстные диаграммы [7] (см. материалы 09-Моделирование требований). RUP в поиске границ предлагает отталкиваться от акторов и вариантов использования. Среди источников ограничений обычно выделяют:
Описание возможностей системы представляет собой формулировку высокоуровневых требований. Шаблон документа «Vision» RUP содержит следующие основные разделы: 1. Введение 2. Позиционирование 3. Описания совладельцев и пользователей 4. Краткий обзор изделия 5. Возможности продукта 6. Ограничения 7. Показатели качества 8. Старшинство и приоритеты 9. Другие требования к изделию 10. Требования к документации 11. Приложение. Во введении описываются цель документа, его контекст (связь и взаимовлияние с различными проектами), определения, акронимы и сокращения, ссылки на другие документы, краткое содержание. В разделе «позиционирование» помещается определение решаемой проблемы (проблем), указывается целевой заказчик и исследуются деловые преимущества изделия перед аналогичными на рынке. В описании совладельцев и пользователей, помимо собственно описания этих двух групп, исследуется демография рынка: целевые рыночные сегменты; размер и темпы роста рынка; существующие конкурентные предложения на рынке; репутация Разработчика на рынке; Краткий обзор изделий содержит резюме изделия, описание его перспектив и ключевых возможностей, предположения и зависимости, указывается стоимость и её калькуляция, рассматриваются вопросы лицензирования и инсталляции. В разделе, посвящённом возможностям продукта, они описываются более подробно, каждая – в отдельном параграфе. В раздел «Ограничения» следует выносить существующие технические, технологические и др. обстоятельства, которые необходимо учитывать на данной стадии. Раздел «Показатели качества» содержит описание наиболее существенных нефункциональных требований к системе (эффективности, надёжности, отказоустойчивости и др.). Раздел «Старшинство и приоритеты» ранжирует сформулированные ранее требования и возможности системы по степени важности, очерёдности реализации и т.п. Раздел «Другие требования к изделию» описывает применяемые стандарты, системные требования, эксплуатационные требования, требования к окружающей среде. В требованиях к документации приводятся ключевые характеристики руководства пользователя, интерактивной справки, руководства по установке и конфигурированию, файла Read Me. В приложение выносятся атрибуты возможностей. RUP рекомендует следующий набор атрибутов: статус, выгода, объём работ, риск, стабильность, целевой выпуск, назначение, причина. Видение / рамки в MSFСогласно белой книге MSF [7], на фазе выработки концепции (envisioning phase) закладывается одна из фундаментальных основ успеха проекта – создание и сплочение проектной группы на основе выработки единого видения. Проектная группа должна четко представить себе, что она хочет сделать для заказчика и сформулировать свою цель таким образом, чтобы максимально мотивировать как заказчика, так и саму проектную команду. Выработка высокоуровневого взгляда на цели и условия проекта может рассматриваться как ранняя форма планирования; она подготавливает почву для процессов создания детальных планов, которые будут осуществлены непосредственно во время фазы планирования. Основными задачами фазы выработки концепции являются создание ядра проектной группы (см. ниже) и подготовка документа общего описания и рамок проекта (vision/scope document). Формирование видения проекта и специфицирование его рамок – не одно и тоже, хотя для успеха проекта необходимо и то, и другое. Видение (vision) – это ничем не ограничиваемое представление о том, каким должно быть решение2. Рамки (scope) же дают четкие границы того, что из предложенного этим видением будет реализовано в условиях существующих проектных ограничений. Управление рисками представляет собой итеративный процесс, осуществляемый на протяжении всего жизненного цикла проекта. Во время фазы выработки концепции проектная группа готовит документ оценки рисков и представляет главные риски проекта вместе с общим описанием и рамками проекта. Для получения дальнейшей информации об управлении рисками, см. “Белую книгу” дисциплины управления рисками MSF. Также во время фазы выработки концепции производится выявление и анализ бизнес-требований. Более детально эти требования рассматриваются во время фазы планирования. Ведущим ролевым кластером на фазе выработки концепции является “Управление продуктом”. Шаблон MSF содержит следующие разделы:
Литература к лекции
2
|
|