Учебное пособие ТОАУ Ч.3 (Учебное пособие по ТАУ), страница 4

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

• Изучение объекта;

• Проведение научно-исследовательских работ (НИР);

• Разработка вариантов концепции АС;

• Оформление отчета о выполненной работе.

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

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

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

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

Видение в RUP.

Шаги, которые необходимо пройти для формирования документа "Видение":

• Формулировка проблем.

• Идентификация совладельцев

• Определение границ системы

• Идентификация ограничений

• Формулировка постановки задач

• Определение возможностей системы

• Оценка результатов

Идентификация совладельцев предполагает поиск и фиксацию интересантов проекта - представителей Заказчика и Исполнителя, инвесторов, внешних экспертов и пр.

Определение границ системы представляет собой нетривиальный процесс. Для этого используют контекстные диаграммы [7.1]. RUP в поиске границ предлагает отталкиваться от факторов и вариантов использования.

Среди источников ограничений обычно выделяют:

• Политические,

• Экономические,

• Среды,

• Технические,

• Выполнения,

• Системные.

Описание возможностей системы представляет собой формулировку высокоуровневых требований.

Шаблон документа "Vision" RUP содержит следующие основные разделы:

• Введение

• Позиционирование

• Описания совладельцев и пользователей

• Краткий обзор изделия

• Возможности продукта

• Ограничения

• Показатели качества

• Старшинство и приоритеты

• Другие требования к изделию

• Требования к документации

• Приложение.

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

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

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

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

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

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

Раздел "Показатели качества" содержит описание наиболее существенных нефункциональных требований к системе (эффективности, надежности, отказоустойчивости и др.).

Раздел "Старшинство и приоритеты" ранжирует сформулированные ранее требования и возможности системы по степени важности, очередности реализации и т.п.

Раздел "Другие требования к изделию" описывает применяемые стандарты, системные требования, эксплуатационные требования, требования к окружающей среде.

Видение / рамки в MSF.

Согласно белой книге MSF [7.3], на фазе выработки концепции (envisioning phase) закладывается одна из фундаментальных основ успеха проекта - создание и сплочение проектной группы на основе выработки единого видения. Проектная группа должна четко представить себе, что она хочет сделать для заказчика и сформулировать свою цель таким образом, чтобы максимально мотивировать как заказчика, так и саму проектную команду. Выработка высокоуровневого взгляда на цели и условия проекта может рассматриваться как ранняя форма планирования; она подготавливает почву для процессов создания детальных планов, которые будут осуществлены непосредственно во время фазы планирования.

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

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

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

Ведущим ролевым кластером на фазе выработки концепции является "Управление продуктом".

Шаблон MSF содержит следующие разделы:

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

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

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

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

1. Концепция решения

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

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

• Требования

1. Рамки

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

• Вне рамок

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

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

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

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

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

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

Классификация и специфицирование требований

Акторы и варианты использования

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

Для того, чтобы повысить уровень информативности требований, устранить взаимные противоречия и добиться выполнения их других основных характеристик, осуществляется переход от полностью неформализованных текстов к частично регламентированным (например, шаблонам MS Word) текстам, классификация, присвоение наборов атрибутов, построение моделей, прототипирование.

Актор (actors) - это некто или нечто, обладающее активностью по отношению к программной системе. Если вы разрабатываете простой текстовый редактор, то, скорее всего, выбор актора не составит особого труда: это будет пользователь, набирающий текст. Однако не всегда все так просто. Помимо пользователя в качестве актора может рассматриваться другая программная система, аппаратное устройство, в ряде случаев - активная компонента самой системы. Поиск акторов корпоративной информационной системы обычно сводится к анализу ролей различных пользователей. Менеджер по продажам, старший менеджер и начальник отдела продаж - один актор, два или три? Это зависит от их функциональных обязанностей, разграничения доступа, способов использования информационной системы. Поиск акторов может осуществляться, например методом мозгового штурма. В дальнейшем при необходимости найденные акторы могут обобщаться, пересматриваться и объединяться.

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

Глоссарий

Помимо формирования требований совладельцев другим результатом начальной фазы выявления требований является концептуальный анализ проблемной области. Самым первым результатом его является формирование глоссария (словаря) основных используемых терминов. Значение глоссария трудно переоценить: он является основой, ключом для единообразного понимания описаний требований Заказчиком и Разработчиком.

Кроме того, глоссарий является отправной точкой для построения более развернутых моделей проблемной области, которые, на стадии реализации информационной системы, ложатся в основу объектной модели (для объектно-ориентированных приложений) и модели данных (для генерации схемы базы данных).

Глоссарий оформляется, как текст, состоящий из абзацев, каждый из которых определяет значение одного из терминов проблемной области. Термин обычно выделяют полужирным кеглем. Иногда проблемную область целесообразно сегментировать на ряд "подобластей" (subject areas). Тогда каждой из них в глоссарии выделяется отдельный параграф.

Спецификация варианта использования

Существуют различные шаблоны описания вариантов использования:

• Свободный формат,

• Полный формат (предложенный А. Коберном),

• Таблица в две колонки,

• Таблица в три колонки,

• Стиль RUP.

Кроме того, иногда целесообразно использовать:

• Псевдокод,

• Диаграмму активности UML (см. лекцию 9),

• Другие графические модели.

• Свободный формат.

Свободный формат предполагает описание действий пользователя и системы в повествовательном стиле, например: "Менеджер запрашивает у Системы список заказов за период. Система отображает на экране найденные заказы данного Менеджера с указанием их основных атрибутов". Свободный стиль допускает использование конструкций "Если то". "Если Менеджер имеет полномочия Начальника Отдела, то Система предоставляет возможность просмотра заказов всех менеджеров этого отдела".

Шаблон полного описания варианта использования по А. Коберну:

Название <краткая фраза в виде глагола в неопределенной форме совершенного вида, отражающая цель>

Контекст использования <уточнение цели, при необходимости - условия ее нормального завершения>.

Область действия <ссылка на рамки проекта>. Например - подсистема бухгалтерского учета.

Уровень <один из трех: обобщенный, цели пользователя, подфункции>. Автор задает предопределенную трехуровневую классификацию требований, в целом соответствующую классификации требований на бизнес-требования, требования пользователей и функциональные требования.

Основное действующее лицо <имя роли основного актора или его описание>.

Участники и интересы <список других акторов-участников прецедента с указанием их интересов>.