Материал: u_lectures

Если моделирующий субъект обладает неявными знаниями об ОС в достаточном объёме – значит, АПО можно исключить. На практике это возможно в следующих случаях: а) Разработчик является частью (структурным подразделением, дочерним предприятием и т.д.) ОС, в коллектив Разработчика входят эксперты, хорошо знающие предметную область; б) Заказчик наравне и Разработчиком участвует в создании документа АТ и разделяет с ним ответственность за принятие решений. Это – путь «agile методологий» (см. материалы заключительной лекции).

Рассмотрим теперь обобщённую «формулу» создания АИС.

ОС  М(ОС)  М(АИС) М’(АИС)  М’’(АИС)  М’’’(АИС)  АИС

(рис. 5-1).

Анализ организационной системы позволяет создать модель её модель М(ОС). Это

– модель бизнес-анализа (проблемной области).

Анализируя модель проблемной области, в ней можно вычленить, с одной стороны, задачи и функции, реализуемые внутри ОС и функции коммуникации ОС и среды, с другой – устройство предметной области (в начале – на уровне концептуальной модели), с третьей – требования к информации и её обработке. Выделив среди функций те, которые подлежат автоматизации, мы получаем основу для выявления функциональных требований к системе. Остальная, собранная на этапе АПО, информация служит для поиска нефункциональных требований. В результате получаем модель АТ, как первое приближение модели АИС, М(АИС).

Затем, путём углублённого анализа и проектирования, формируются, соответственно, аналитическая модель М’(АИС), проектная модель М’’(АИС) и модель реализации М’’’(АИС).

Модель уровня реализации позволяет синтезировать собственно АИС, как совокупность программных, информационных, организационных и др. артефактов.

АИС в свою очередь представляет собой модель организационной системы М’(ОС), замыкая цикл моделирования.

Методологии бизнес-анализа

Методологии бизнес анализа можно разделить на три категории по типам моделей:

модели, преследующие цель анализа и улучшения организационной системы

(например, SWOT , VCM, BPR, CPI/TQM/ISO9000, BSC),

модели общего назначения, такие, как SADT, DFD, IDEF1, IDEF3, IDEF5 и другие.

модели, специально разработанные для использования при автоматизации (например, ISA, BSP, ARIS, RUP).

Наиболее развитая модель описания проблемной области предлагается в

методологии ARIS.

Архитектура ARIS [5] выделяет в организации следующие подсистемы.

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

Функциональная. Определяет функции, выполняемые в организации.

Подсистемы входов/выходов. Определяют потоки используемых и производимых продуктов и услуг.

Информационная (подсистема данных). Описывает получение, распространение и доступ к информации (данным).

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

Подсистема целей организации. Описывает иерархию целей, достигаемых в ходе выполнения того или иного процесса.

Подсистема средств производства. Описывает жизненный цикл основных и вспомогательных средств производства.

Подсистема человеческих ресурсов. Описывает прием на работу, обучение и продвижение по службе персонала организации.

Подсистема расположения организационных структур. Описывает

территориальное расположение организационных единиц (конец цитаты). Данное разделение является в определённой мере условным; выделенные

«подсистемы» не являются подсистемами в смысле системного анализа, т.к. взаимопроникают и пересекаются. Они представляют скорее совокупность предметов исследования, разных взглядов на исследуемый объект.

Слушателю курса предлагается самостоятельно проанализировать, какие группы и категории требований к системе позволяет прояснить та или иная компонента принятой в ARIS структуризации объекта исследования.

Требования и архитектура АИС

Говоря об архитектуре АИС, обычно подчёркивают деление на аппаратные, программные, информационные, организационные компоненты, их связность и детализацию.

Метафора архитектуры RUP описывается в виде 4+1 представлений: логическое, представление процессов, представление реализации и физическое представление связываются между собой представлением вариантов использования (use case), которое играет центральную роль в выработке архитектуры системы (рис. 5-2).

Требования первичны по отношению к архитектуре. Но это не значит, что требования и архитектура должны разрабатываться последовательно.

Представление

прецедентов

Рис. 5-2

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

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

требований. Если наступил момент, при котором появление новой информации о требованиях перестала оказывать влияние на архитектуру – значит, архитектура стабилизировалась.

Это – нормальный, естественный путь развития требований и архитектуры. Но что делать, если требования изменились настолько, что архитектура перестала им соответствовать? Причин тому могут быть разные, например: неопытная архитектурная группа не проявила достаточно дальновидности; группа по сбору требований пропустила на ранних стадиях критичные, архитектурно значимые требования; в бизнес-сфере Заказчика произошли большие перемены, вызвавшие коренное изменение требований к системе. Следствия также могут быть различными: договорённость об увеличении сроков и сумм по контракту; исправление ситуации за счёт Разработчика; разрыв контракта.

Альтернативный выход предлагается в методологии XP: архитектура – не догма, а всего лишь метафора. Если требования вошли вразрез с существующей архитектурой – значит, архитектуру нужно просто изменить. Следует понимать, что путь и рецепты XP при кажущейся простоте ориентированы далеко не на любой коллектив. Команда XP состоит их профессионалов, имеющих позитивный опыт работы в этой методологии.

Анализ требований и другие рабочие потоки программной инженерии

Рассмотрим краткий обзор рабочих потоков RUP и их связь с потоком работ АТ

(рис. 5-3).

Анализ

требований

Рис. 5-3

Поток работ «деловое моделирование» служит основой для анализа и формирования требований к АИС, позволяет избежать ошибок.

Поток работ «управление средой» предоставляет исходную информацию для рабочей группы АТ, регламентирующую форматы оформления, CASE-средства, регламенты работы.

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

Поток работ «анализ и проектирование» осуществляется на основе исходных данных, предоставленных АТ. В определённой мере эти потоки работ проводятся параллельно. При обнаружении проблем, связанных с требованиями, возникает обратная связь от этого потока работ к потоку работ АТ.

принятые на предприятии. Одной из немногих методологий, в которых специально выделяются рабочий поток делового моделирования, является Rational Unified Process.

Ещё одна альтернатива, используемая при выявлении требований – так называемые «лучшие практики», широко используемые в настоящее время в бизнес-консалтинге и при внедрении корпоративных информационных систем. Лучшие практики представляют собой описания моделей деятельности успешных компаний отрасли, используемые длительное время в сотнях и тысячах компаний по всему миру.

Подытоживая сказанное, отметим, что основными источниками, образующими «вход» процесса выявления требований, являются требования, высказанные совладельцами, как таковые или (и) артефакты, описывающие объект исследования. Однако, это – достаточно упрощённый взгляд: чтобы данные поступили «на вход», аналитики требований должны проделать немалую работу, связанную с подбором респондентов и информационных материалов, организацией интервью и т.д.

Стратегии выявления требований

Интервью

Ключевой стратегией выявления требований было и остаётся интервью с экспертами.

В ставшей уже классической, но ничуть не утерявшей актуальность монографии Д.Марко [3] в процессе проведения интервью предлагается выделить три подчинённых процесса: подготовку, проведение интервью (опроса) и завершение. Ниже приводится краткий обзор рекомендаций Д.Марко с акцентом на выявление требований (в монографии даны рекомендации по интервьюированию с целью формирования модели объекта исследования).

1. Подготовка

Подготовка позволяет спланировать процесс опроса и выработать стратегию управления этим процессом. Важность подготовительного этапа вырастает, если респондент является «дефицитным» полезным ресурсом, например – президентом крупной компании.

При подготовке Д.Марко рекомендует следующие шаги:

выберите нужного собеседника;

договоритесь о встрече;

установите предварительную программу встречи;

изучите сопутствующую информацию;

согласуйте свои действия с группой проектирования8.

При выборе собеседника для целей сбора требований определяющими являются две вещи:

Он действительно является экспертом по данному вопросу;

Его мнение действительно является ценным при формировании целевого набора требований9.

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

8В нашем случае – группой аналитиков требований

9На практике возможны ситуации, когда требование, сформулированное одним из представителей Заказчика, не подтверждается другим представителем, имеющим большие властные полномочия. Надо отчётливо понимать, что каждое требование в конечном итоге транслируется, с одной стороны, в компоненту информационной системы, а с другой – может быть выражено в определённом количестве денежных знаков, которые Заказчик должен будет выплатить Исполнителю по приёмке работы. Поэтому право формулировать требования и область компетенции того или иного эксперта должны быть формально оговорены внутренним документом Заказчика, с которым следует ознакомится до начала проведения интервью.