Прослеживаемость, тестирование и управление результатами — не самоцель, и их значение не следует переоценивать. Разработчики должны концентрироваться на разработке, а не отслеживание, тестирование или управление изменениями. С этими проблемами, как правило, связаны значительные проектные расходы. Однако, в долгосрочной перспективе отсутствии управления этими проблема влечет не менее значительные затраты.
Поскольку основу тестирования и управления изменениями составляет прослеживаемость, рамки и глубину прослеживаемости проекта следует определять с помощью анализа затрат и результатов. По меньшей мере прослеживаемость следует поддерживать между требованиями на основе прецедентов и дефектами. В более развитой модели между требованиями-прецедентами и дефектами в маршрут прослеживаемости можно добавить тестовые требования. В еще более сложной модели прослеживаемости рамки прослеживаемости могут включать системные функции, тестовые прецеденты, усовершенствования, точки тестовой верификации и другие артефакты разработки программного обеспечения.
Функциональные возможности системы представляют собой общую часть функций, которые должны быть реализованы в системе. Это бизнес-процесс, представляющий собой существенную часть системы с точки зрения ее эффективности. Обычно системные функциональные возможности соответствуют бизнес-прецедентам модели бизнес-прецедентов. Если модель бизнес-прецедентов формально не разрабатывалась, системные возможности идентифицируются в документе, отражающем стратегическое видение системы.
Каждая системная возможность реализуется с помощью требований-прецедентов, выраженных в виде одного или нескольких прецедентов. Прослеживаемость прецедентов обратно к потребностям заказчиков помогает проверить обоснованность и правильность модели прецедентов. Эта стратегия «очерчивает рамки» фиксации требований и способствует этапу установления требований. Она также помогает осуществлению наращиваемой разработки и предоставлению программного продукта заказчикам.
Таким образом, используя описанные в данной статье методы и программное обеспечение, функциональные требования проекта «Конкуренция» были занесены в репозиторий. Выполнен анализ требований, в соответствии с которым каждому требованию был назначен набор атрибутов, таких как приоритет, риск и состояние. Атрибуты в дальнейшем использовались для построения матрицы зависимости требований.
При помощи 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 с.
Версия для печати
предыдущая
