Главная » UML » Технологический процесс управления    требованиями

0

 

На рис. 9.2 представлены виды деятельности, составляющие технологический процесс управления требованиями. Разберем эту диаграмму подробнее.

•       Анализ проблемы. Выработка приемлемой формулировки проблемы, которую мы
пытаемся   решить;   определение   заинтересованных   сторон;   установление
пределов и ограничений системы.

•       Понимание   щжд   заинтересованных   сторон.   С   помощью   различных   методов
собираются запросы заинтересованных сторон, позволяющие отчетливо понять
действительные нужды заинтересованных сторон и пользователей системы.

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

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

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

 

Управление меняющимися требованиями. Используйте атрибуты требований и возможность оперативного контроля для оценки влияния меняющихся требований; применяйте центральный управляющий отдел, такой как орган контроля над изменениями (Change Control Board— CCB), для контроля над изменениями в требованиях. Не забывайте о том, что с заказчиками нужно постоянно согласовывать, какие требования являются реалистичными и должны реализовываться в конечном продукте.

Исполнители

Как все сказанное выше реализуется в терминах исполнителей, артефактов и видов деятельности? Рассмотрим основных исполнителей и представим артефакты технологического процесса управления требованиями (рис. 9.3).

•     Системный аналитик

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

•     Спецификатор прецедентов

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

 

•   Разработчик пользовательского интерфейса

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

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

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

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

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

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

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

Артефакты

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

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

 

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

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

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

•       заказчикам и пользователям — проверить соответствие готовой системы их
ожиданиям;

•       разработчикам системы — создать эту ожидаемую систему.

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

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

Полное определение программных требований (описанное в форме прецедентов и дополнительных спецификаций) может формировать полную спецификацию программных требований (Software Requirement Specification — SRS) готового продукта, отдельного "свойства" или другой подгруппы системы.

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

•       Словарь

•       Архив прецедентов

•       Прототип пользовательского интерфейса

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

 

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

Инструментальная поддержка

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

Для визуального моделирования артефактов процесса управления требованиями можно использовать средство Rational Rose, обеспечивающее автоматическую поддержку исполнителей и прецедентов модели прецедентов (с возможностью интеграции с RequisitePro для поддержки текстовых свойств, атрибутов требований и возможности связи), а также архива прецедентов и классов границ. Использование этого приложения также облегчает поддержание связи с элементами модели проектирования.

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

Резюме

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

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

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

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

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

•        

По теме:

  • Комментарии