Управление изменениями (Change Management).

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

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

Соответственно, данный вопрос является составной частью управления изменениями и конфигурациями программного обеспечения (Software Configuration and Change Management, SCCM), которое сегодня принято называть просто конфигурационным управлением (Software Configuration Management, SCM). Это не только вопросы контроля версий, но управление, всеми активами проекта, включая код, требования, запросы на изменения (в том числе, отчеты об ошибках), задачи (в терминах проектного менеджмента) и т.п.

Общий комплекс вопросов конфигурационного управления рассмотрим позже в  разделе «Управление конфигурациями программного обеспечения».

 

 

7.3. Атрибуты требований (Requirements Attributes).

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

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

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

7.4. Трассировка требований (Requirements Tracing).

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

Трассировка предполагает направленную связь (представляется в виде сложного направленного ациклического графа) между требованиями.

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

  Требования (B) обладают обратной зависимостью (то есть вторичны) по отношению к требованиям (A) и заинтересованным лицам, которые являются источником появления рассматриваемых требований (B). То же относится к С, D,E (см. рисунок).

И, наоборот, требования (A) трассируются напрямую к тем требованиям (B) и элементам дизайна (например, модели или, в общем случае, кода, запросов на изменения и т.п.), которые порождаются или удовлетворяют требованиям (A).

7.5. Измерение требований (Measuring Requirements).

С практической точки зрения, полезно иметь некое число, позволяющее определить «объем» требований для создаваемого программного продукта.

Это число полезно для исследования «масштабов» изменений в требованиях, оценки стоимостных характеристик разработки и поддержки программной системы.

Опосредовано – оценки продуктивности разработки и эффективности поддержки на этапах реализации требований и внесения изменений и т.п. 

Измерение объема функциональности (Functional Size Measurement, FSM), как техника численной оценки, определена на концептуальном уровне в стандарте IEEE 14143.1.    

Стандарты ISO/IEC описывают частные методы FSM (например, модель COCOMO II для оценки стоимости).

COnstructive COst MOdel (COCOMO – модель издержек разработки) – это алгоритмическая модель оценки стоимости разработки программного обеспечения, разработанная Барри Боэмом.

Модель использует простую формулу регрессии (простая линейная регрессия — статистический метод, позволяющий предсказывать значения зависимой переменной Y по значениям независимой переменной X) с параметрами, определенными из данных, собранных по ряду проектов. Более подробно рассмотрим ее позднее, в следующих лекциях.

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

Дополнительная информация по стандартам и подходам в оценке масштабов рассмотрим позже в области знаний «Процесс программной инженерии» (Software Engineering Process).