Принципы и приемы оперирования требованиями

Трассировка требований, поступающих в ходе эксплуатации

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

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

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

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

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

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

Рис. 13.2. Модель обработки требований в период эксплуатации системы

• поступление сообщения (контрольная точка (a));
• первичный анализ, в ходе которого из сообщения извлекаются требования. Этот период должен быть максимально кратким, ибо пользователю необходимо знать о реакции разработчиков на его сообщение. Результатом первичного анализа является принятие решения о каждом   требовании (контрольная точка (б), в которой происходит расщепление линии жизненного цикла ). Возможны следующие не взаимоисключающие варианты такого решения:
  • немедленная реакция — действия, направленные на быстрое устранение замечания, если это возможно, либо указание пользователю сроков, когда и как будут учтены поступившие претензии, либо предложение пути преодоления трудностей (возможно, временные). Немедленная реакция выполняется всегда, в том числе совместно с другими решениями;
  • требование   отклоняется — действия, указывающие пользователю причины отклонения требований и пути преодоления трудностей;
  • реализация   требования   в текущем релизе — если претензии обоснованы, а устранение замечаний, ошибок и т.п. возможно в обслуживаемом релизе, то организуется мини-цикл обработки требований в итерации;
  • реализация   требования   в одном из следующих релизов — если устранение замечаний в рамках обслуживаемого релиза невозможно или нецелесообразно, то требование передается для исполнения на одной из следующих итераций проекта;
  • реализация   требования   в другом проекте — если выясняется, что в данном проекте требование реализовать невозможно или нецелесообразно, то, быть может, оно станет одним из аргументов в пользу организации нового проекта.
• мини-цикл обработки требования начинается с анализа, цели которого обычны для объектно-ориентированного развития проектов. В частности, определяется осуществимость реализации на данной итерации или целесообразность переноса ее на другую итерацию; образуется группа требований, которые должны быть реализованы совместно. Выработка этих решений о стратегии реализации требований приурочивается к контрольной точке (c). Особенностью анализа в данном случае является то, что он проводится как возобновленный процесс, поскольку основные работы итерации уже выполнены;
• реализация отобранных требований на данной итерации осуществляется по обычной схеме, включающей конструирование, программирование и оценку. В качестве специфики следует указать на особую роль проверочных работ — дополнительный этап проверки реализации, который вкладывается в этап оценки. Эти работы обязательно должны включать повторение проверки того, что было отлажено ранее. Таким образом, пополнение базового окружения проекта приобретает дополнительное содержание – накопление тестовой базы;
• распространение изменений (контрольная точка 10) — деятельность, направленная на то, чтобы сделанные исправления стали доступны для всех пользователей версии. При массовом применении программного изделия эта работа может потребовать значительных ресурсов.