Анализ требований и управление изменениями программных проектов

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

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

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

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

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

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

Задача бизнес-аналитика состоит в том, чтобы объединить два набора требований в бизнес-модели. Как показано на рисунке 1, бизнес-модель содержит модель бизнес-классов и модель бизнес-прецедентов. Модель бизнес-классов представляет собой диаграмму классов верхнего уровня, которая идентифицирует и связывает между собой бизнес-объекты. Модель бизнес-прецедентов — это диаграмма прецедентов верхнего уровня, которая идентифицирует основные функциональные строительные блоки системы.

В общем случае, классы проблемной области (бизнес-объекты) не должны выводиться из прецедентов [1]. Однако на практике правильность модели бизнес-классов должна подтверждаться посредством сравнения с моделью бизнес-прецедентов. Это сравнение, как правило, приводит к некоторой настройке или расширению модели бизнес-классов.

На этапе установления требований осуществляется выявление требований и их определение, преимущественно в виде формулировок на естественном языке. Формальное моделирование требований с использованием языка UML проводится позже на этапе спецификации требований. Тем не менее, во время установления требований постоянно ведется деятельность по обобщенному визуальному представлению собранных требований, называемая бизнес моделированием требованием. Для установления рамок системы требуется, по меньшей мере, высокоуровневая визуальная модель, позволяющая обозначить ключевые прецеденты и ввести наиболее существенные бизнес-классы [2].

Рисунок 1. Взаимное влияние моделей, характерных для процесса определения требований Для выявления требований по данному проекту использовался метод интервьюирования, за несколько интервью были получены требования заказчика и знания в предметной области. Так же заказчиком были предоставлены значительные материалы по игре (формы, образцы, презентации, наброски), что позволило глубже проникнуть в требования к системе. После этого был создан документ описания требований, в котором были сформулированы все требования к системе в целом и обсуждены смежные вопросы. Требования были сформулированы в виде коротких предложений, четко описывающих свою цель, например: «Так как игра реализована на веб-технологиях, то игроки и мастера должны иметь возможность получить доступ к игре из любого места, где есть компьютер, подключенный к сети Интернет. Поэтому каждый пользователь системы должен иметь имя авторизации и пароль к нему, которые позволят ему авторизоваться и продолжить игру».

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

• · Программы для непосредственного управления и анализа требований;
• · Программы для построения UML диаграмм, в которых можно строить диаграммы бизнес-прецедентов (use case).

Также можно классифицировать их по платформе:

• · Веб-приложения;
• · Приложения уровня операционной системы.

Компании, занимающиеся разработкой таких программ (Rational, Sparx Systems, DOORS), создают возможность обмена данным между такими продуктами. Это позволяет использовать два продукта, так же эффективно как один, хорошим примером являются Rational RequisitePro (обеспечивает поддержку создания, анализа и управления требованиями) и Rational Rose Data Modeler (среда визуального моделирования). Enterprise Architect — это программа компании Sparx System, которая является интегрированным решением, она содержит в себе обе функциональности.

В проекте «Конкуренция» используется Rational RequisitePro для управления требованиями. Требования были созданы и внесены в репозиторий, в процессе добавления они были идентифицированы, классифицированы и структурированы. Затем требования прошли этап согласования и проверки, в ходе которого, были отброшены выходящие за рамки системы требования, требования которые совпадали частично или полностью были объединены, противоречащие были разрешены. Всем требованиям были назначены атрибуты, такие как приоритет и риски. При выставлении атрибутов проводились консультации с заказчиком, особенно мнение заказчика повлияло на приоритеты требований.

В результате всех выше перечисленных операций был создан проект в программе Rational RequisitePro, который содержит в себе все требования к проекту. Эти требования упорядочены, каждое из них имеет уникальный идентификатор и набор атрибутов, который полностью описывает требование. Упорядоченные требования были разбиты по двум так называемым пакетам (package). Пакет — это структурная единица внутри проекта Rational RequisitePro, которая содержит требования и другие артефакты. В проекте «Конкуренция», было создано два пакета: веб-система мастера (Master's Web System) и веб-система игрока. Такое решение было принято, потому что возможности мастера и игрока, принципиально различные, соответственно и требования к реализации их возможностей тоже разные, поэтому удобно их разделить по двум разным пакетам, общие же требования находятся на уровень выше.

Далее приведем самые основные функциональные требования к системе: программный тестирование дефект интерактивный.

• 1. Пользователи должны иметь возможность авторизоваться в системе.
• 2. Пользователи должны иметь возможность восстанавливать пароль по средству электронной почты.
• 3. Пользователи должны иметь возможность сменить электронную почту при наличии пароля.
• 4. Мастер может добавлять, изменять и удалять игроков.
• 5. Мастер может изменить состояние ресурсов игры.
• 6. Мастер может изменять параметры сценария.

Заметим что, игрок и мастер — это частный случай пользователя, то есть то, что справедливо для пользователя, справедливо и для игрока и для мастера. Легко догадаться, что мастер и игрок связаны отношением наследования с пользователем.

После наполнения проекта «Конкуренция» требованиями, созрела необходимость в создание бизнес-прецедентов и их диаграммы, как и документирования.

Поведение системы — это ее реакция в ответ на внешние события. В языке UML внешне наблюдаемое и допускающие тестирование поведение фиксируется в виде прецедентов. Прецедент (use case) выполняет бизнес-функцию, которую может наблюдать внешний субъект и которая может быть впоследствии отдельно протестирована в процессе разработки.

Не смотря на то, что многие функциональные требования совпадают с прецедентами, необходима особая форма документирования прецедентов. Каждый прецедент должен быть описан с помощью документально описанного потока событий (flow of events). Соответствующий текстовый документ определяет, что должна делать система, когда субъект инициирует действие.

Рисунок 2. Диаграмма прецедентов игры «Конкуренция».

Структура документа, описывающего прецедент, может варьироваться, однако, типичное описание должно содержать следующие разделы [3]:

• · Краткое описание;
• · Участвующие субъекты;
• · Предусловия, необходимые для инициирования прецедента;
• · Детализированное описание потока событий, которое включает:
  • o основной поток, который можно разбить, чтобы показать подчиненные потоки событий;
  • o альтернативные потоки для определения исключительных ситуаций.
• · Постусловия, определяющие состояние системы, по достижению, которого прецедент завершается.

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

Тестирование приводит к обнаружению дефектов. Дефекты необходимо исправлять. Чтобы исправить дефекты их необходимо отправить в виде запросов на изменение (change request) и адресовать разработчикам. Некоторые запросы на изменение связаны с усовершенствованием, а не исправлением дефектов. Как дефекты, так и усовершенствования изменяют свой статус, им могут быть присвоены различные приоритеты, за их сопровождение могут отвечать различные лица, их необходимо отслеживать в связи с их источниками в виде документации по прецедентам и тестированию.

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

Запрос на изменение вводится в проектный репозиторий. После ввода в репозиторий разработчики могут отслеживать продвижение запроса на изменение, наблюдать за его статусом и действовать в соответствии с ним. Действия, выполняемые над запросом на изменение, зависят от текущего статуса запроса.

Каждый запрос на изменение назначается определенному разработчику. Разработчик может открыть (Open) запрос на изменение. Если запрос находится в открытом состояние, то никто другой не может модифицировать статус запроса. После разрешение проблемы, связанной с запросом на изменение, разработчик может совершить над ним действие Resolve. Подробности решения можно ввести в форму и отправить по электронной почте руководству проекта и специалистам по тестированию. Последним может потребоваться выполнить действие по верификации разрешенного запроса на изменение.

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

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

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

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

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

При помощи Enterprise Architect были смоделированы диаграммы прецедентов бизнес-игры «Конкуренция», что обозначило поведение будущей системы.

Данная работа была представлена на конференции «День науки» в ЮФУ, методы анализа и управления требованиями, изложенные в ней, позволили эффективно управлять требованиями и их изменениями в проекте «Конкуренция» с помощью выбранного инструментария. Бизнес-игра «Конкуренция» предоставляет возможность для обучения конкурентной стратегии студентов специальности «Менеджмент высоких технологий» в компьютерных классах.

• 1. Rumbaugh, J. Getting Started. Using Use Case to Capture Requirements, J. Object-Oriented Prog., Sept., 1994, pp. 8−10, 12, 23.
• 2. Халл Э., Джексон К. Разработка и управление требованиями. 2005. — 229 c.
• 3. Quatrani, T. Visual Modeling with Rational Rose 2000 and UML, Addison-Wesley, 2000, 256pp.
• 4. Мацяшек Лешек А. Анализ требований и проектирование систем. Разработка информационных систем с использованием UML. — М.: Изд. дом «Вильямс», 2002. — 432 с.