Управління ІТ-проектами / Література / Элизабет Халл. Разработка и управление требованиями

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

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

2.3.2 Стратегия проверки и критерии приемки

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

Это информация, связанная с проверкой реализации требований.

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

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

Как обобщение вышесказанного на рис. 2.4 показан полный контекст процесса разработки требований.

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

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

Рис. 2.4 Значение стратегии проверки

2.4 Введение в основной процесс разработки требований

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

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

2.4.1 Идеальный мир

На рис. 2.5 показан процесс разработки требований для идеального мира.

Процесс начинается с необходимости согласования входящей информации (требований) с заказчиками, находящимися на уровень выше.

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

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

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

Рис. 2.5 Процесс разработки требований для идеального мира

2.4.2Разработка требований в контексте изменений

Ксожалению или к счастью, но жизнь никогда не стоит на месте. Это особенно сильно заметно в области разработки систем. Создается такое впечатление, что все только и делают, что постоянно меняют свое мнение, утверждая, что-то, что было согласовано ранее, теперь просто категорически неприемлемо.

Араз так, то, следовательно, и процесс разработки требований необходимо адаптировать к изменениям, так как показано на рис. 2.6.

Степень формальности отношения к изменениям зависит от характера проекта и от стадии, на которой он находится.

На ранних стадиях проекта, чтобы проект быстрее двигался вперед, изменения должны предлагаться чаще и приниматься легче.

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

не вносятся), а затем рассматриваются в контексте их возможного влияния, которые они могут оказать на весь проект в целом.

Запрос на изменение

Запрос на изменение

Запрос на изменение

Рис. 2.6 Процесс разработки требований в контексте изменений

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

Тема контроля изменений, как часть процесса управления проектом, будет рассмотрена более подробно в Главе 8.

Как следует из рис. 2.6, практически любое действие в рамках процесса разработки требований может привести к изменениям, и эти изменения обычно распространяются вверх. Это не означает, что заказчик никогда ничего не меняет, что все проблемы находятся на нижних уровнях, и «вытекают» из того, что разработка ведется «сверху вниз». Просто

движение сверху вниз уже учтено в рамках основного процесса и теперь необходимо также учесть и обратную связь.

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

Запрос на изменение (или предложение изменения) (change request) может предусматривать не только изменение модели\-ей, но и\или проведение дополнительного анализа для более полного исследования проблемы. Также на этапе анализа и моделирования могут быть найдены проблемы, связанные с входящими требованиями, и поэтому создан запрос на внесение изменения в процесс согласования требований.

2.5 Информационная модель общего процесса разработки требований

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

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

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

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

2.5.1Классы информации

Вконтексте общего процесса нами уже рассмотрены следующие типы информации:

∙входящие требования;

∙производные требования;

∙стратегия проверки для входящих требований;

∙стратегия проверки для производных требований;

∙запрос на изменение.

На рис. 2.7 эти пять типов информации представлены в виде диаграммы классов UML- модели.

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

Линии, соединяющие классы, обозначают связи между ними. В UML эти связи также называют «ассоциациями». Как следует из диаграммы, входящее требование может быть связано с производным требованием связью «удовлетворяется». Аналогично производное требование может быть связано с входящим требованием связью «удовлетворяет». (Обозначение связи в UML также называют «ролью».)

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

Следовательно, в модели на рис. 2.7 ноль или более входящих требований могут быть удовлетворены одним производным требованием, и входящее требование может быть удовлетворено нулем или более производных требований.

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

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

производные требования удовлетворяют входящие требования, и, наоборот, что все вхоящие требования удовлетворяются производными требованиями.

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

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

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

Как уже упоминалось выше, средняя часть символа класса служит для отражения имеющихся атрибутов класса. Классы требований имеют три атрибута:

∙статус согласования;

∙статус проверки;

∙статус удовлетворения.

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

-согласованно

-несогласованно.

2.5.2 Статус согласования

Диаграмма состояний для статуса согласования представлена на рис. 2.8.

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

Прямоугольник, помеченный заголовком Оценка, называется «супер-состоянием» (superstate) поскольку содержит внутри себя другие состояния. Стрелки, связывающие между собой разные состояния, обозначают переходы, вызывающие изменение состояния.

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

После согласования стратегии проверки требования, статус проверки переходит в состояние Стратегия проверки определена.

Рис. 2.9 Статус проверки

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

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

Стратегия проверки не определена.

2.5.4 Статус удовлетворения

Диаграмма состояний для статуса удовлетворения требования представлена на рис. 2.10. Диаграмма очень похожа на диаграмму состояний статуса проверки.

Начальной точкой является состояние Неудовлетворенно, что означает отсутствие производных требований связанных с данным требованием. После того, как входящее требование удовлетворено одним или несколькими производными требованиями, и при этом «поставщик» с более низкого уровня согласовал требования, а «заказчик» с более высокого уровня согласился с тем, что производные требования удовлетворяют входящее