ПРИМЕНЕНИЕ ДИАГРАММ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ ПРИ СБОРЕ ТРЕБОВАНИЙ К ИТ ПРОЕКТАМ

Дождев Д.В. (СЭИК, г.Южно-Сахалинск, РФ),

Куперман В.Г. (ТГПУ, г.Тула, РФ)

Authors investigate reason of failed projects. They highlight two fundamental route causes: poor project communication and gathering requirements. Authors proposed apply Use Case Diagram as a tool addressed to enhance gathering requirements process. Authors provide brief description of this approach.

Исследования, проведенные Standish group, выявили, что 88% проектов отстают от графика, выходят за рамки бюджета, или и то и другое одновременно. Прямые издержки неудач этих проектов составляют 145 млрд. долларов ежегодно.[1] Исследования, направленные на выяснения причин, в частности выявили, что основные причины неудач проектов связаны с недостаточно ясно определенным содержанием проекта, при этом они выделяю следующие факторы, ведущие к неудаче проекта[2]:

- Неполные требования;

- Недостаточное вовлечение конечных пользователей результата проекта;

- Недостаток ресурсов;

- Нереалистичные ожидания;

- Недостаток поддержки со стороны высшего руководства;

- Изменение требований/спецификаций;

- Недостаточное планирование;

- Результат проекта более не нужен.

Перечисленные выше факторы в той или иной мере связаны с двумя фундаментальными причинами:

1. Качество коммуникаций в проектной среде;

2. Качество требований к проекту и продукту проекта, собранных на ранних стадиях проекта.

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

Сформулируем требования к данной методике:

- Методика должна быть эффективным средством коммуникации между проектной командой и заказчиком;

- Методика должна быть формальной, чтобы избежать разночтения вовлеченными сторонами;

- Методика должна быть достаточно высокоуровневой, чтобы описывать поведение и характеристики продукта проекта, а не детали реализации.

На наш взгляд, для удовлетворения перечисленных выше требований следует рассмотреть применение языка UML – Unified Modeling Language. Язык UML это средство моделирования, применяемое при разработке программного обеспечения. Однако, раздел данного языка, называемый Варианты Использования (Use Case) может быть с успехом применен и для решения задач сбора требований к продукту проекта в значительно более широком контексте.

Варианты Использования удовлетворяет приведенным выше требованиям, по следующим причинам:

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

- В качестве средства коммуникации заказчика и исполнителя данный подход содержит в себе Диаграммы Вариантов Использования (Use Case Diagram)

- Являются частью общепринятого стандарта, описывая поведение продукта проекта.

Основными составными частями метода являются Диаграммы Вариантов Использования (Use Case Diagram) и Сценарии Вариантов использования. Рассмотрим далее Диаграммы Вариантов использования, оставив за рамками данной работы Сценарии Вариантов Использования, применяемых для описания последовательности действий, которая описывает действия актеров и поведение моделируемой системы в форме обычного текста, в контексте языка UML сценарий используется для дополнительной иллюстрации взаимодействия актеров и вариантов использования. Разработка Диаграммы Вариантов Использования преследует цели:

- Определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы;

- Сформулировать общие требования к функциональному поведению проектируемой системы;

- Разработать исходную концептуальную модель системы для ее последующей детализации в форме логических и физических моделей;

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

Основными двумя компонентами Диаграммы Вариантов Использования являются: вариант использования и актеры. Каждый отдельный вариант использования определяет последовательность действий, которые должны быть выполнены проектируемой системой при взаимодействии ее с соответствующим актером. Отдельный вариант использования обозначается на диаграмме эллипсом, внутри которого содержится его краткое название или имя в форме глагола с пояснительными словами (рис. 1)[3]

Рисунок 1 - Графическое обозначение варианта использования

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

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

Рисунок 2 - Графическое обозначение актера

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

Рисунок 3 - Графическое обозначение актера

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

Литература

1. Andrew Longman and Jim Mullins. The Rational Project Manager: A Thinking Team's Guide to Getting Work Done. John Wiley & Sons 2005

3. Леоненков А.В. Самоучитель UML - СПб.: "БХВ - Петербург", 2001. - 304 с.

4. Леоненков А.В. Формализация функциональных требований к системе с помощью диаграммы вариантов использования. http://www.intuit.ru/department/pl/umlbasics/4/umlbasics_4.html