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

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 2)

Специалист по АТ - постановка задачи, определение рамок проекта;

Представитель заказчика - постановка задачи, определение рамок проекта, контроль работы исполнителя, приемка результатов работы;

Архитектор системы - разработка архитектуры, проектирование подсистем;

Программист - разработка программного кода;

Тестировщик - составление тест-плана, тестовых сценариев;

Менеджер проекта - планирование и контроль исполнения работ.

Организация работы с требованиями на примере MSF

В MSF для обозначения роли участников команды софтверного проекта используется понятие ролевых кластеров [4.9].

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

Шесть ролевых кластеров модели проектной группы - это "Управление продуктом" (product management), "Управление программой" (program management), "Разработка" (development), "Тестирование" (test), "Удовлетворение потребителя" (user experience) и "Управление выпуском" (release management). Они ответственны за различные области компетенции (functional areas) и связанные с ними цели и задачи.

Microsoft Solutions Framework (MSF) — методология разработки программного обеспечения, предложенная корпорацией Microsoft, организованная на базе комбинации каскадной и спиральной моделей. Отдельная стадия работы содержит в себе 5 фаз:

• Envisioning (выработка концепции),

• Planning (планирование),

• Developing (разработка),

• Stabilizing (стабилизация),

• Deploying (внедрение).

В фазе выработки концепции работа с требованиями наиболее интенсивна (см. табл. Т.1).

Таблица Т.1.

Все 6 кластеров работают со своими группами требований.

Продолжается плотная работа с требованиями и на следующей фазе – фазе планирования, см. табл.Т. 2.

Таблица Т.2.

В фазах разработки и внедрения работа с требованиями сосредотачивается в кластерах управления продуктом и программой, см., соответственно, табл. Т.3, Т.4.

Таблица Т.3.

Таблица Т.4.

Контекст задачи анализа требований

Анализ требований, бизнес-анализ, анализ проблемной области

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

Авторы RUP и UML, в этом вопросе дают определенную свободу: можно создавать бизнес-модели при помощи соответствующих расширений UML и рекомендаций RUP, а можно ограничиться выработкой глоссария объектов предметной области. Как и в вопросе выбора глубины проработки артефактов АТ, вопрос - проводить или не проводить бизнес-анализ (или, точнее говоря, анализ проблемной области), решается в зависимости от конкретной задачи.

Несколько утрируя, можно сказать, что Заказчик и Разработчик всегда говорят на разных языках. Общее понимание вырабатывается с трудом, этот процесс занимает время, но важность его трудно переоценить: ведь успешная реализация проекта в области и внедрения АИС во многом зависит от того, удастся ли выработать и документировать их общее представление о предмете разработки. Если же Разработчик идет еще дальше и вникает в особенности ведения дел на предприятии Заказчика - он, во-первых, сможет добиться лучшего понимания требований к АИС и, во-вторых, участвовать наряду с Заказчиком в формулировке этих требований, анализе пропущенных требований и пр. Глоссарий можно рассматривать как документ, удостоверяющий общее понимание основной терминологии Заказчиком и Разработчиком.

Задачу анализа бизнес-процессов (деловое моделирование), столь популярную в последние десятилетия ввиду устойчивой конъюнктуры, следует рассматривать как часть более общей задачи систем для анализа проблемной области.

С позиций моделирования, анализ требований (АТ) и анализ проблемной области (АПО) - принципиально разные процессы.

АПО преследует классические цели создания модели: налицо объект (автоматизируемое предприятие или организационная система, ОС) и задача аналитика - отразить этот объект в создаваемой модели с требуемой степенью точности (рис. 1).

Анализ требований, напротив, направлен на моделирование воображаемого, еще не существующего объекта (АИС) (рис. 2). Т.е. сначала создается модель, а затем, на ее основании, синтезируется объект.

Рис. 1.

Рассмотрим теперь обобщенную "формулу" создания АИС(рис. 1):

ОС->М(ОС)->М(АИС)->М'(АИС)->М''(АИС)->М'''(АИС)->АИС.

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

Анализируя модель проблемной области, в ней можно вычленить,

с одной стороны, задачи и функции, реализуемые внутри ОС и функции коммуникации ОС и среды,

с другой - устройство предметной области (в начале - на уровне концептуальной модели),

с третьей - требования к информации и ее обработке.

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

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

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

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

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

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

• модели, преследующие цель анализа и улучшения организационной системы (например, SWOT , VCM, BPR, CPI/TQM/ISO9000, BSC),

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

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

Методология ARIS

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Метафора архитектуры RUP описывается в виде 4+1 представлений(рис. 2):

• логическое,

• представление процессов,

• представление реализации

• физическое представление

• представлением вариантов использования (use case ) - связывает между собой представление реализации и физическое представление .

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

Рис. 2.

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

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

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

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

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

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

Характеристики

Список файлов книги