Новосибирский Государственный Университет
Опубликован: 20.08.2004 | Доступ: свободный | Студентов: 4839 / 473 | Оценка: 4.01 / 3.23 | Длительность: 18:07:00
ISBN: 978-5-9556-0013-0
Лекция 13:

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

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

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

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

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

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

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

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

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

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

В рамках проф. переподготовки по программе "Программирование"

Есть курсы, которые я уже прошел. Но войдя в курс я вижу, что они не зачтены (Язык Ассемблера и архитектура ЭВМ, Программирование на С++ для профессионалов). Это как?

Сергей Прошута
Сергей Прошута
Россия
Sergey Ostr
Sergey Ostr
Россия, Энгельс