учебники, программирование, основы, введение в,

 

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

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

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

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

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

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

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

Трассировка требований, поступающих в ходе эксплуатации
Характер работы с требованиями в период, когда релиз изделия передан в эксплуатацию, существенно меняется. Во-первых, это связано с самими требованиями: теперь они начинают отражать не только пожелания инициаторов работ, но и оценку полученных пользователями текущих результатов выполнения проекта. Появляются критика решений, указания на ошибки в коде, обнаруживаются просчеты в архитектуре и интерфейсе. Во-вторых, может измениться организационная структура коллектива разработчиков, по крайней мере — распределение обязанностей. В-третьих, программистские работы над созданием продукта завершились (или законсервировались), и разработчики переходят к следующим этапам реализации проекта. Наконец, в-четвертых, поток поступающих требований увеличивается. Все это должно учитываться при организации трассировки требований.
Завершение выполнения проекта или итерации редко описывают в моделях жизненного цикла структурно. Обычно этот период только обозначается, а все его работы лишь классифицируются. Возможно, что разнообразие вариантов организации эксплуатационной поддержки препятствует их систематическому изучению. Понятно, что не стимулирует изучение этих работ неявное и не соответствующее действительности положение о том, что требования к системе, возникающие в этот период, относятся уже к другому проекту. В то же время промышленная разработка программных систем всегда нуждается в организации как можно более быстрых откликов на пользовательские запросы: рекламации, пожелания и требования развития.
С точки зрения обработки требований задачу моделирования фазы завершения можно описать в стиле предыдущей модели. Не стоит ожидать от этого описания, что оно даст единственно возможный рецепт работы. Цели моделирования иные. Во-первых, это систематизация действий, которые необходимо выполнять в качестве реакции на пользовательские запросы. Во-вторых, это явное разграничение реакций, относящихся к текущему релизу, к одному из следующих релизов, к другому проекту. Для итеративно развиваемых проектов такое разграничение очень важно в силу необходимости осуществлять одновременную поддержку разных версий в сочетании с итеративным наращиванием возможностей системы.
Основой моделирования жизненного цикла после завершения проекта (итерации) является обратная связь с пользователями системы. Это обычные сообщения о ходе эксплуатации: мнения, рекламации, пожелания, нарекания, претензии и т.п. Все подобные сообщения могут быть классифицированы, ранжированы по степени важности для развиваемого (на данном этапе — обслуживаемого) проекта. Но это обстоятельство в предлагаемой ниже модели не учитывается: считается, что из пользовательских сообщений извлекаются   требования к проекту в целом или к его итерации. Сообщения, а значит, и требования могут поступать в ходе эксплуатации в течение всего периода использования системы или ее релиза. И новые требования нуждаются в трассировке.
В представленной намодели описываются операционные маршруты, возникающие в связи с обработкой одного требования в ходе эксплуатации программной системы. Для упрощения предполагается, что операционные маршруты от накапливаемой информации не зависят. Конечно, в действительности принятие решений о требовании выполняется не только на основании первичных установок, но и с использованием знаний о системе, пользователях, текущем представлении, приоритетах и предпочтениях. Можно считать, что подобные сведения используются в точках разветвления операционных маршрутов, но как именно осуществляется такое использование, моделью не описывается.
Аналогично тому, как это было при организации мини-цикла для трассировки требований в модели периода эксплуатации, началом обработки является поступление сообщения, которое можно трактовать как содержащее требования (контрольная точка (a)). Это событие может возникать в любой момент периода сопровождения, т.е. обсуждаемая модель является естественным продолжением модели с обработкой требования в мини-цикле. Так как отобразить весь поток сообщений невозможно, рассматривается операционный маршрут только одного сообщения, при этом постулируется, что все сообщения обрабатываются подобно:

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

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

Приемы оперирования требованиями
Представленные ниже приемы есть не что иное, как конкретные деятельности системы проектных деятельностей, которые можно рассматривать в качестве методических средств проекта. Для разного уровня сложности проекта они имеют различное значение, часто некоторые из них не выделяются явно. Но в действительно полезном проекте соответствующие им процессы должны выполняться всегда. Важно, чтобы менеджер проекта осознавал это и точно указывал, кто, когда, как и в какой форме обеспечивает получение результатов использования приемов оперирования требованиями.
Прием 1. Анализ проблем
Данный вид анализа проводится для понимания проблем прикладной области, чтобы выявить первичные нужды будущих пользователей из конгломерата пожеланий. Его цель — предложить решение на самом высоком уровне.
В ходе анализа выделяются реальные проблемы. Ограничиваются возможные решения, которые определяются как прикладными, так и техническими следствиями принимаемых решений. Иными словами, происходит оценка пожеланий с точки зрения их осуществимости в проекте. Если это необходимо, для анализируемого проекта строятся модели оценки прибыли (убытков) от вложений в разработку данной системы (business-case анализ).
Результат анализа проблем — ранжированный по степени важности список   потребностей пользователей   с перечислением следствий решения данной проблемы.
Из содержания обсуждаемого приема видно, что применение его целесообразно при уточнении заказа на разработку, а значит, он относится к деятельности менеджера, выполняемой на этапах исследования и анализа осуществляемости. Получаемые сведения позволяют эффективно выполнять два следующих приема, первый из которых связывается с предварительным анализом проектного задания, а второй используется в течение всего периода итеративного развития проекта.
В ходе развития проекта анализ проблем уточняется. В этом принимают участие сотрудники, занимающие ключевые роли. Обязательно в процессе анализа проблем является участие заказчика или представителей заказчика, представляющих пользовательскую деятельность достаточно глубоко.
Прием 2. Понимание пользовательских потребностей
Для понимания пользовательских потребностей очень полезно, а зачастую просто необходимо осуществить типизацию   требований (см. лекцию 12). Типы требований определяются их группировкой по тем или иным признакам. Чем более развита система, чем больше функций она реализует, чем шире круг ее пользователей, тем больше типов требований приходится рассматривать в проекте. Идентификация типов требований позволяет разработчикам проекта организованно подходить к решению задачи удовлетворения требований к системе. Использование различных типов требований помогает классифицировать запросы к системе по типам реакции на них. Как следствие, облегчается взаимопонимание в коллективе и между разработчиками и заказчиком.
В обычном проекте всегда представлен ряд типов требований, которые могут быть разложены на составляющие типы, относящиеся к разным аспектам разработки. Так, коммерческие правила или требования к оформлению экрана можно рассматривать как два типа требований высокого уровня (Тэкон и Тинт из лекции 12), из которых извлекаются типы потребности пользователей, требований к пользовательским средствам, требований к изделию с точки зрения его продажи и др.
В свою очередь, требования к проверке программного изделия извлекаются из требований уровня системы и разбиваются на ряд специфичных проверочных процедур. При появлении у проекта значительного числа первичных требований, исходящих из различных источников, без типизации требований проекта просто не обойтись.
Типизация требований — это обычный прием, с помощью которого облегчается работа с большими объемами информации за счет определения структуры. Система типов   требований   для данного проекта — результат применения этого приема.
Первоночальное применение обсуждаемого приема связывается с предпроектной работой менеджера, в результате которой складывается предварительное представление о системе типов требований проекта. В дальнейшем эта система уточняется. Всякий раз, когда разработчики сталкиваются с требованием, следует понять, какие проблемы обусловили его появление и, как следствие, какое место оно занимает в системе типов требований данного проекта и, если это необходимо, как оно влияет на систему в целом. Таким образом, понимание пользовательских проблем как прием оперирования требований не связан с каким бы то ни было конкретным этапом.

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

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

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

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

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

Прием 4. Оперирование многомерными требованиями
Этот прием носит служебный характер, так как не связывается с конкретными этапами. Его назначение — организация помощи при отборе требований для различных целей. Задача состоит в том, чтобы отбирать требования быстро, а главное — точно, чтобы ни при каких обстоятельствах ни одно из нужных требований не было упущено. Типизация требований — одно из средств, облегчающих решение задачи отбора, но его явно недостаточно, поскольку параметры отбора не сводятся к одному измерению, фиксированному типизацией. Другим примером параметра отбора служит приоритетность требований, отбираемых для реализации в рамках итерации. Единственного значения параметра для этого не хватает: разные инициаторы работ могут выставлять разные приоритеты одним и тем же требованиям. Следовательно, и здесь нужно уметь одновременно оперировать разными параметрами отбора.
Тип требований характеризуется своими атрибутами, и каждое требование имеет различные значения этих атрибутов. К примеру, с требованием могут быть связаны его приоритет или причина появления, оно может быть соотнесено с теми, кто должен заниматься его реализацией (рабочие группы, ответственные за сетевые взаимодействия, управление поведением системы, интерфейс и др.). Характеризует требование уровень трудоемкости реализации, наконец, срок или итерация, когда планируется реализация. Анализ требований зависит от подобных характеристик, которые называются измерениями   атрибутного набора требования.
При выполнении анализа полезно иметь следующие возможности:

  • Отбор требований, которые обладают заданными значениями некоторых атрибутов или значениями, попадающими в определенный диапазон. В частности, сюда попадает отбор требований заданного типа.
  • Сортировка требований по основным измерениям, указывающим на те или иные атрибуты.
  • Ручная корректировка набора требований, отобранных в соответствии с заданным критерием.
  • Объединение, пересечение и дополнение отобранных наборов требований.
  • Проверка свойств требования (набора требований), формулируемых как предикаты над значениями атрибутов.

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

Прием 5. Определение системы
Определить систему означает трансформировать потребности пользователей и перечень требований в описание разрабатываемой системы. Сначала достигаются общие соглашения о том, как понимаются требования и их приоритетность, оценка затрат на разработку и потребностей в ресурсах, какие рисковые ситуации вероятны и стратегия управления рисками. Оцениваются границы применения будущей системы. Определяются соглашения о разработке: виды рабочих продуктов, правила их построения, проверки и т.д. Фиксируются внешние рабочие продукты и способы их использования в проекте: применение ранее полученных результатов, использование их как прототипов и др.
Форма представления определения системы может быть различной: тексты, схемы, гипертекстовая структура и др. Важно, чтобы она была понятной для непосредственного восприятия без привлечения дополнительных материалов.
Важный принцип определения системы: перед составлением формализованного модельного описания следует сначала представить его на естественном языке. Если сначала строится формальная модель, то появляется тенденция подмены описания системных решений описанием самой модели, и потому комментарий на естественном языке не достигает цели.
Точное и согласованное   определение системы рассматривается в качестве результата обсуждаемого приема. Наиболее интенсивно он используется при подготовке проекта. Однако в ходе его развития первоначальное определение, скорее всего, будет модифицироваться, так что к данному приему придется возвращаться для корректировок после каждой итерации. Эти возвраты приурочиваются к этапам оценки предыдущей и анализа последующей итераций и выполняются в период их перекрытия.
Главными действующими лицами при определении системы являются менеджер и архитектор проекта. В их обязанности входит выпуск соответствующих документов, для подготовки которых при необходимости привлекаются другие сотрудники проекта.
Прием 6. Управление областью применимости системы
Управление областью применимости — это решение следующей задачи: выбрать приоритетное с точки зрения инициаторов работ направление развития проекта в условиях имеющихся на данный момент ресурсов (время, кадры, финансы). Это ключевая задача, определяющая успешность проекта в целом. Она решается непрерывно в течение всего итеративного наращивания, которое разбивает область применимости системы на небольшие, доступные для управления части (стоит сопоставить это положение с обсуждением мотивации методологических стратегий в лекции 5).
Среди разработчиков основным действующим лицом, определяющим выработку целесообразных вариантов области применимости системы, является эксперт предметной области. В его компетенции находится решение вопросов, не требующих согласования с руководством компании и с заказчиком. Подготовленные варианты предъявляются менеджеру, который определяет оптимальный вариант развития проекта из числа предложенных с учетом всех обстоятельств, в частности ресурсных потребностей и ограничений, допустимого уровня риска и приоритетности задач для пользователя. Такое разделение функций позволяет охватить все возможные пути развития проекта и на этой основе выбирать направление.
Методы определения области применимости сводятся к достижению соглашений посредством обсуждения атрибутов требований с целью выявления реальных возможностей проекта.
В качестве основного критерия эффективности расширения области в том или ином направлении выступает приоритетность задач. Очень много неудач выполнения заказов связано именно с тем, что разработчики в первую очередь пытаются решать интересные исследовательские задачи, игнорируя текущие потребности заказчика, пользователей, задачи, которые смягчают риски и т.д. В то же время хорошим стилем ведения проекта является противоположная позиция разработчиков: удовлетворение ожиданий заказчика на всех этапах, причем не в качестве ответов на настойчивые запросы, а с упреждением, предсказанием того, что действительно требуется.
Результатом деятельности по управлению областью применимости системы является список   требований, которые планируется удовлетворить в ходе выполнения текущей и последующих итераций и для проекта в целом. Этот список должен быть согласован с проектным техническим заданием, как по составу, так и по срокам. Если выясняется расхождение целесообразного направления развития проекта с тем, что зафиксировано в техническом задании, то это повод для организации переговоров с целью корректировки задания.
Прием 7. Детализированное определение системы
Детализированное определение системы нужно для того, чтобы инициаторы работ могли понять, какое изделие предлагается, и решить, соглашаться с этим предложением или нет. Оно нужно не только по отношению к функциональности, но также для выработки соглашений о порядке реализации требований, о практичности и надежности системы, о ее производительности, о поддержке и удобствах применения.
Распространенная ошибка — уверенность в том, что сложное для разработки нуждается в сложном описании. Это приводит к запутанным объяснениям целей проекта и системы, которые, возможно, и производят впечатление, но не помогают потенциальным пользователям. Необходимо приложить значительные усилия, чтобы добиться понятности детализированного определения системы в описывающем ее документе. Быть может, потребуется несколько такого рода документов, предназначенных для различных пользователей.
Другая составляющая детализированного определения системы — это описание того, как система должна тестироваться. План тестирования и определение того, что тестируется, дают представление том, как верифицируются заявленные возможности системы.
Детализированное определение системы должно быть представлено в такой форме, которая одинаково понятна как заказчикам, так и разработчикам. Практика показывает, что использование языка заказчика для описания требований к системе в виде ее детализированного определения наиболее эффективно для взаимопонимания. Такое представление используется разработчиками в качестве исходной информации при составлении спецификаций конструируемой системы.
Детализированное определение постоянно развивается по мере продвижения проекта. В начале каждой итерации, во время ее этапа текущего анализа в рамках детализированного определения фиксируются требования, которые планируется реализовать в течение ближайших этапов. Таким образом, детализированное определение   рассматривается в качестве постановки задач итерации.
В ходе выполнения этапа оценки итерации детализированное определение уточняется — описывается, что удалось предложить в качестве очередного релиза. Таким образом, детализированное определение   становится документом для пользователей. Именно в это время возможно появление различных вариантов детализированного определения для разных пользователей.
На этапе оценки появляется дополнительная информация о том, как, по мнению инициатора работ, должна быть дополнена система. Она используется как для управления областью применимости (см. предыдущий пункт), так и в качестве исходного материала для модификации (расширения) текущей версии детализированного определения в ходе этапа анализа следующей итерации.
Таким образом, в качестве результата обсуждаемого приема рассматривается определение системы  в виде описаний ее возможностей, пригодных для предоставления пользователям очередного релиза.
Составление детализированного определения системы — задача, которую решают проектировщики системы. Подготавливаемые на этапе анализа и уточняемые в ходе оценки материалы согласовываются с заказчиком.

 

 
На главную | Содержание | < Назад....Вперёд >
С вопросами и предложениями можно обращаться по nicivas@bk.ru. 2013 г.Яндекс.Метрика