Модели жизненного цикла программного обеспечения (стр. 7 )

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

  Набор требований чаще всего является компромиссом.

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

  Требования изменяются.

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

  Требования зависят от времени.

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

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

3.2. Трассировка требований

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

Любое предложение по развитию конструируемой системы может быть классифицировано как требование одного их трех видов:

  дополнительное требование , которое отражает ранее не рассмотренный аспект системы;

  модифицирующее требование , которое изменяет одно или несколько уже существующих требований;

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

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

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

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

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

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

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

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

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

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

  Модельные представления уровня анализа — образы элементарных требований как элементы аналитических моделей системы: моделей ситуаций использования и динамики взаимодействий, которые используются для оценки требований.

Если требование принимается на уровне анализа, то трассировка продолжается на следующих уровнях, и можно говорить о продолжении последовательности трансформаций в реализации требования в компонентах программного изделия:

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

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

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

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