Анализ требований к аис 07-Формирование видения - umotnas.ru o_O
Главная
Поиск по ключевым словам:
страница 1
Похожие работы
Название работы Кол-во страниц Размер
Анализ требований к аис 09-Моделирование 1 98.9kb.
Интервью 2 Анкетирование 6 Наблюдение 7 Самостоятельное описание... 1 108.54kb.
Содержание: Раздел I 1 308.17kb.
Анализ требований к ис 05-Контекст задачи анализа требований 1 92.7kb.
Литература к лекции 8 Рабочий поток анализа требований 1 89.95kb.
4 Назначение детали, описание ее конструкции, анализ технических... 1 171.63kb.
Анализ внедрения Федеральных государственных требований к структуре... 1 48.59kb.
Анализ требований и управление изменениями программных проектов 1 108.74kb.
Вопросы к экзамену по дисциплине «Эксплуатация комплексной системы... 1 18.5kb.
Сведения о проверяемом лице 1 93.1kb.
Обновления аис башфин 1 13.88kb.
Методология Rational Unified Process (rup) 1 100.26kb.
Викторина для любознательных: «Занимательная биология» 1 9.92kb.

Анализ требований к аис 07-Формирование видения - страница №1/1


Анализ требований к АИС

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



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 содержит следующие разделы:



  • Бизнес-преимущества,

    • Описание преимуществ

    • Формулировка видения

    • Анализ выгод

  • Концепция решения

    • Цели, задачи, предположения и ограничения

    • Анализ применимости

    • Требования

  • Рамки

    • Список характеристик/функций

    • Вне рамок

    • Стратегия подготовки релизов

    • Критерии применимости

    • Эксплуатационные критерии

  • Стратегии проектирования решения

    • Стратегия проектирования архитектуры

    • Стратегия технического проектирования

Литература к лекции


  1. Марка Д., МакГоуэн К. Методология структурного анализа и проектирования. — М.: МетаТехнология, 1993.

  2. ГОСТ 34.601-90. Информационная технология. Автоматизированные системы. Стадии создания.

  3. Белые страницы MSF. http://www.microsoft.com/rus/msdn/msf



  1. 1 Калянов Г. Н. Консалтинг при автоматизации предприятий: Научно-практическое издание. Серия «Информатизация России на пороге XXI века». — М.: СИН-ТЕГ, 1997.

2





Ю.А. Маглинец

КГТУ, 2006