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

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

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

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

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

Непрерывность поступления требований

к программному продукту в моделях

жизненного цикла

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

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

При построении модели следует указать этапы, когда производятся те или иные шаги, связанные с трассировкой. Нужно различать три вари­анта работы с требованиями в итеративном проекте:

• требование или группа требований обрабатываются до начала ите­рации;

• требование или группа требований поступают, когда работы итера­ции начались;

• требование или группа требований поступают, когда работы итера­ции завершились и релиз системы передан в эксплуатацию.

Первый вариант полностью укладывается в схему модифицирован­ной модели фазы—функции (см. рис. 9.1, 9.2). Если требование (группа требований) принимается для данной итерации и используется при раз­работке сценария, который будет реализовываться (контрольные точки 2, 8), то указанные на схеме трассировки работы включаются в аналитиче­скую и конструкторскую деятельность. В противном случае оно либо от­кладывается до последующих итераций, либо отклоняется.

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

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

трассировки. При этом в модели, как и в первом варианте, следует отра­зить возможные результаты анализа требования:

• требование отклоняется — работа с требованием прекращается;

• требование принимается к реализации на текущей итерации;

• реализация требования откладывается до следующих итераций.

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

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

• поступление требования или совместной группы (контрольная
точка (а), которая может появиться в любой момент этапов конст­руирования, программирования или оценки);

• расщепление, переход к анализу;

• принятие решения (контрольная точка (б) на общем участке этапов
анализа и конструирования);

• планирование срока или будущей итерации реализации.

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

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

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

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

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

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

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

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

• поступление сообщения (контрольная точка (а));

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

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

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

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

— реализация требования в другом проекте — если выясняется, что в
данном проекте требование реализовать невозможно или неце­лесообразно, то, быть может, оно станет одним из аргументов в
пользу организации нового проекта.

• мини-цикл обработки требования начинается с анализа, цели которого
обычны для объектно-ориентированного развития проектов. В част­ности, определяется осуществимость реализации на данной итера­ции или целесообразность переноса ее на другую итерацию; образу­ется группа требований, которые должны быть реализованы совмест­но. Выработка этих решений о стратегии реализации требований приурочивается к контрольной точке (с). Особенностью анализа в данном случае является то, что он проводится как возобновленный
процесс, поскольку основные работы итерации уже выполнены;

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

• распространение изменений (контрольная точка 10) — деятель­ность, направленная на то, чтобы сделанные исправления стали доступны для всех пользователей версии. При массовом примене­нии программного изделия эта работа может потребовать значи­тельных ресурсов.

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

Дата добавления: 2014-01-06