Итеративная природа процесса работы с требованиями (Iterative Nature of the Requirements Process)
В большинстве случаев, понимание и интерпретация требований продолжает эволюционировать в процессе проектирования и разработки программного обеспечения. Кроме того, требования часто меняются в силу изменений бизнес-контекста для которого создается и в котором эксплуатируется программное обеспечение. Необходимо понимать неизбежность изменений и планировать шаги по уменьшению проблем, связанных с изменениями. В то же самое время, современные практики гибкой разработки говорят о том, что необходимо концентрироваться только на том, что требует внимания “прямо сейчас”, не закладываясь на предупреждение всех возможных рисков, в том числе связанных с изменениями, включая изменения требований. Говорить о том, какой подход – предупреждение или реагирование является гарантировано приводит к успеху – сложно сказать. Более того, если кто-то однозначно настаивает только на одной из идей и полностью отвергает другую – это профанация. Восприятие изменений и возможность их своевременной обработки - вопрос способности проектной команды работать в условиях постоянно меняющихся условий, принимаемых архитектурных решений и многих других культурных, технологических и организационных факторов. Так или иначе, понимание меняющейся природы требований – один из факторов адекватного реагирования на сами изменения, а, следовательно, и возможности успешного завершения проекта.
|
|
|
Управление изменениями (Change Management)
Управление изменениями – одна из ключевых тем управления требованиями. Необходимость определения процедур для обработки изменений совсем не то же самое, что и их детальная формализация. Такие процедуры необходимы. Им посвящена тема управления изменениями в приложении к требованиям. В то же время, рассматривать изменение требований в отрыве от других процессов, по меньшей мере, кажется странным. Соответственно, данный вопрос является составной частью управления изменениями и конфигурациями программного обеспечения (Software Configuration and Change Management, SCCM), которое сегодня принято называть просто конфигурационным управлением (Software Configuration Management, SCM), подразумевая, что это не только вопросы контроля версий, но управление всеми активами проекта, включая код, требования, запросы на изменения – change requests (в том числе, отчеты об ошибках – defect или bug reports), задачи (в терминах проектного менеджмента) и т.п.
Общий комплекс вопросов конфигурационного управления рассматривается в области знаний SWEBOK “Управление конфигурациями программного обеспечения” (Software Configuration Management).
Атрибуты требований (Requirements Attributes)
Требования должны состоять не только из описания того, что необходимо сделать, но и содержать информацию, необходимую для интерпретации требований и управления ими. Например, с пользовательскими требованиями часто ассоциируют сценарии Use Case (как в текстовом, так и графическом представлении) и, в то же время, функциональные требования часто трансформируются в задачи в терминах проектного управления, с которыми связаны параметры законченности (например, в процентах), ответственности (например, кто является “владельцем” требования, кто из инженеров назначается исполнителем или принимает на себя обязанности, связанные с реализацией заданной функциональности, как это принято, например, в XP или FDD). Примеров существует множество и, в зависимости от применяемых практик и методов, сложившейся проектной и организационной культуры, спектр атрибутов может меняться достаточно широко, практически, неограниченно.
|
|
|
Необходимо также помнить, что к обсуждаемым атрибутам также относятся параметры, связанные с классификацией требований (см. выше тему 4.1 “Классификация требований”). В свою очередь, принадлежность к тому или иному классу (категории, типу, виду) требований означает не только семантику того, “чему посвящены” требования (функциональности, параметрам качества и т.п.), но и комплекс атрибутов, общий для всех требований данного класса.
В какой-то степени можно провести параллель между требованиями и записями (строками) в реляционной базе данных, где каждая запись обладает набором атрибутов (столбцов). В определенном смысле, можно и необходимо говорить о том или ином уровне атомарности требований (что не исключает связей между требованиями), представляемой такой метафорой.
Дата добавления: 2018-05-12; просмотров: 331; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!