Опубликован: 18.06.2007 | Уровень: для всех | Доступ: платный | ВУЗ: Сибирский федеральный университет (г. Красноярск)
Лекция 5:

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

< Лекция 4 || Лекция 5: 12 || Лекция 6 >

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

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

  • модели, преследующие цель анализа и улучшения организационной системы (например, SWOT , VCM, BPR, CPI/TQM/ISO9000, BSC),
  • модели общего назначения, такие, как SADT, DFD, IDEF1, IDEF3, IDEF5 и другие,
  • модели, специально разработанные для использования при автоматизации (например, ISA, BSP, ARIS, RUP).

CPI (Continuous Process Improvement) - непрерывный процесс усовершенствования [41]. Относится ко всем аспектам деятельности компании; предусматривает постоянный поиск способов улучшения работы организации и использование этих способов для совершенствования продукции компании, создания более благоприятного рабочего климата на предприятии и т. п.

ISO (International Organization for Standardization) - Международная организация по стандартизации, ИСО, http://www.iso.org/iso/ru.  Является одной из самых крупных и значимых организаций, занимающейся разработкой международных стандартов.  Членами ИСО являются национальные органы по стандартизации (в том числе – российский), которые представляют интересы своей страны в ИСО, а также представляют ИСО в своей стране.

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

ARIS (Architecture of Integrated Information Systems) [24] — архитектура интегрированных информационных систем. Методология и CASE-средство для моделирования бизнес-процессов организаций c целью их автоматизации от компании Softwareag http://www.softwareag.com/corporate/products/aris. Основные черты методологии - поддержка 5 различных, но взаимосвязанных между собой точек зрения на предприятие; наличие сверхмощного, не имеющего аналогов графического языка, насчитывающего десятки различных диаграмм и сотни специальных символов для всевозможных аспектов деятельности предприятий и его автоматизации. Сюда вошли многие наработки из мирового арсенала бизнес-моделирования, инкапсулирован также и UML. Наиболее известная диаграмма ARIS – EPC.

CASE (Computer Aided Software Engineering) – набор инструментов и методов, позволяющих автоматизировать отдельные этапы жизненного цикла программной инженерии. Согласно IEEE STD.620.12-1990, CASE – это "использование компьютеров, способствующее процессу программной инженерии; может включать приложения программных средств для проектирования, трассировки требований, генерации кода, тестирования, генерации документации и других действий программной инженерии".

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

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

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

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

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

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

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

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


Рис. 5.2.

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

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

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

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

XP eXtreme Programming, экстремальное программирование. Одна из гибких (гиперссылка на agile) методологий разработки программного обеспечения, развитая в трудах Кента Бека, Уорда Каннингема, Мартина Фаулера и др., ориентированная на использование группами от 2 до 10 программистов. Согласно [44], Экстремальное программирование – это дисциплина разработки программного обеспечения и ведения бизнеса в области создания программных продуктов, которая фокусирует усилия обеих сторон (программистов и бизнесменов) на общих, вполне достижимых целях. Автор [44] выделяет следующие основные черты XP: Разработка через опережающее тестирование; "Игра в планирование"; "Заказчик всегда рядом"; Парное программирование; Непрерывная интеграция; Рефакторинг; Частые небольшие релизы (Small releases); Простота; Метафора системы; Коллективное владение кодом; Стандарт кодирования; 40-часовая рабочая неделя.

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

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


Рис. 5.3.

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

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

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

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

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

Для потока работ "реализация" связь с требованиями не указана. Между тем автор считает, что требования должны анализироваться и учитываться во ВСЕХ рабочих потоках проекта, даже если это формально не предусмотрено выбранным группой процессом. Людям свойственно ошибаться и ошибки, совершенные на ранних стадиях проекта, при движении от этапа к этапу нарастают, как снежный ком. Поэтому любому участнику команды, заинтересованному в успехе проекта, нелишне заглянуть в спецификацию требований и убедиться в том, что та работа, которая ему поручена, соответствует тому или иному требованию. Это позволяет организовать обратную связь, позволяющую отследить ошибки в спецификациях. Многие проекты зашли в тупик именно из-за оторванности группы, отвечающей за реализацию от группы сбора и анализа требований.

< Лекция 4 || Лекция 5: 12 || Лекция 6 >
Ринат Гатауллин
Ринат Гатауллин

Здравствуйте. Интересует возможность получения диплома( https://intuit.ru/sites/default/files/diploma/examples/P/955/Nekommerch-2-1-PRF-example.jpg ). Курс пройден. Сертификат не подходит. В сертификате ошибка, указано по датам время прохождения около 14 дней, хотя написано 576 часов.

Аминат Албакова
Аминат Албакова

Здравствуйте, я прошла весь курс, но нигде не указано, что курс завершился удачно или что-то в этом роде, не знаю что делать, как получть диплом в электронном виде?

Анатолий Федоров
Анатолий Федоров
Россия, Москва, Московский государственный университет им. М. В. Ломоносова, 1989
Алексей Махонин
Алексей Махонин
Россия, Волжский, Средняя школа №12, 1990