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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 13.1. Фазовое измерение модели жизненного цикла при объектно-ориентированном развитии проекта, дополненное обработкой требования в мини-цикле

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

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