25. Проблемы управления процессом разработки требований. Планирование. Контроль за ходом выполнения работ. Изменения.
Вся информация из книги элизабет халл, если хотите узнать ещё больше обратитесь к главе 8.3
Проблемы управления требованиями
Основные проблемы управления при разработке требований возникают в связи со следующими процессами:
планирование;
контроль за ходом выполнения работ;
отслеживание и контроль изменений. Проблемы могут немного различаться в зависимости от типа организаций.
Планирование
Начальной точкой проекта организации-покупателя должна быть какая-то форма концепции. Наиболее общей формой концепции может являться только основная идея, но обычно она описывается более подробно и тщательно обосновывается. Причина проста: проекты обязательно должны быть санкционированы организацией, а процесс утверждения проекта потребует некоторого документального обоснования расходов времени и средств (ресурсов). Обоснование обычно содержит краткое описание того, что нужно пользователям, чтобы получить возможность выполнить необходимые действия (концепция), и соответствующее доказательство, демонстрирующее преимущества и выгоды, возникающие для организации, которая способна такие возможности предоставить.
Информация, содержащаяся в описании концепции, позволяет руководителю проекта начать планирование. Так как описание концепции содержит «описание того, какие возможности нужны пользователям», мы сразу же получаем исходный список заинтересованных сторон (пользователей) и первую версию одного или нескольких сценариев использования системы (способности делать что-либо).
Первый шаг в составлении плана состоит в формировании более полного списка типов заинтересованных сторон и более полного набора сценариев, охватывающего весь диапазон предполагаемых условий использования системы, включая при необходимости режимы ее работы. После определения всех типов заинтересованных сторон становится возможным детальное планирование действий по выявлению всех требований. Действия, включаемые в план, могут быть следующими:
включаемые в план, могут быть следующими:
1) планирование опросов одного или нескольких представителей каждого типа заинтересованных сторон.
2) планирование времени для конспектирования ответов и составления отчёта об опросах, а также для согласования их с опрашиваемыми представителями;
3) определение стратегии проведения опроса и обмена информацией с опрашиваемыми (которые в любом случае могут быть привлечены к процессу принятия решения).
4) перед опросом иногда полезно (хотя и не всегда осуществимо) собрать вместе всех представителей заинтересованных сторон и объяснить им общую цель опросов.
5) согласование и документирование набора пользовательских сценариев, которые наилучшим образом отображают цель и режим функционирования системы в её контексте.
6) после опросов предложенные требования заинтересованных сторон могут быть извлечены из отчётов об опросах и согласованы с опрошенными представителями заинтересованных сторон;
7) принятие решения о структуре, в которую будет вводиться каждое требование заинтересованных сторон;
8) размещение каждого определённого требования заинтересованных сторон в утверждённой структуре и изменение этой структуры при необходимости;
9) определение и описание каждого ограничения.
10) принятие решения о введении дополнительных атрибутов, сопровождающих текст требований.
11) согласование критериев проверки каждого отдельного требования и всего набора требований как единого целого.
12) описание процесса контроля и установление его связи с состоянием отдельных требований.
13) выполнение операций анализа требований в соответствии с определённой и утверждённой процедурой контроля.
Контроль за ходом выполнения работ
Контроль за ходом выполнения работ можно начинать сразу после утверждения плана. Очевидные контрольные точки – завершение каждого действия, описанного в плане.
На начальных этапах действия в основном связаны с подготовкой опросов, проведением опросов и составлением отчётов о них. Оценить эти действия достаточно легко.
Для успешного контроля оставшейся части процесса удобно использовать три ключевые контрольные точки:
1) определение структуры для спецификации требований;
2) определение атрибутов, необходимых для каждого требования;
3) описание процесса (или процессов) анализа с использованием контрольных таблиц.
Принятие структуры даёт возможность определить, все ли необходимые требования включены в список. «Пробелы» могут быть заполнены с помощью специальных операций.
После определения атрибутов можно полностью контролировать процесс заполнения структуры.
И наконец, процедура проверки соответствия заданным критериям контроля может выполняться посредством определения количества требований, находящихся в некотором конкретно оговоренном состоянии.
Изменения
При разработке требований заинтересованных сторон могут быть периоды, характеризуемые многочисленными и частыми изменениями. На этом этапе нет смысла вводить жёсткое формальное управление процессом внесения изменений, так как положение дел меняется очень быстро, и формализм будет только мешать. Но по прошествии некоторого времени ситуация стабилизируется, и руководитель группы разработки требований может решить, что требования достаточно устойчивы, для того чтобы использовать более формализованную процедуру внесения дальнейших изменений. Как правило, этот этап начинается только после того, как все требования прошли контроль и достигли состояния «Подтверждено».
Управление изменениями является важным процессом в разработке требований. Степень формализации этого процесса на практике зависит от того, на какой стадии находится проект.
Различают следующие важные этапы:
требования заинтересованных сторон, используемые как основа в процессе выбора исполнителей по конкурсу;
заключение договора на разработку системы;
завершение опытно-конструкторских работ и готовность начать производство;
готовность к началу приёмочных испытаний;
ввод системы в эксплуатацию. Этот список определяет ряд пунктов постоянно дополняемой последовательности обязательных действий.
Таким образом, в дальнейшем требуется большая степень формализации процесса управления изменениями: чем больше предполагаемые затраты на внесение каждого изменения, тем выше должен быть уровень формализации.
На любой стадии проекта в процессе управления изменениями необходимы следующие действия:
1) описание предлагаемого изменения;
2) определение влияния предлагаемого изменения;
3) принятие решения о внесении (или отклонении) этого изменения;
4) принятие решения о сроке реализации этого изменения.
Предлагаемое изменение должно содержать обоснование и указывать требования заинтересованных сторон, которые должны быть изменены, добавлены или удалены. Кроме того, необходимо сделать запись, определяющую лицо или организацию, предлагающие данное изменение.
На шаге 2 воздействие будет зависеть от этапа, на котором предлагается данное изменение, при этом потребуется информация о том, как требования, подверженные такому воздействию, будут влиять на информацию на более низких уровнях, например на требования к системе в целом, на проектное решение, на процесс производства, на режимы эксплуатации.
За третье действие отвечает группа по управлению изменениями (Change Control Board). Состав такой группы зависит от конкретной организации, от масштаба системы, от текущего этапа разработки или текущего режима использования системы. Если изменение утверждено, то необходимо выполнить действие 4. Иногда требуется немедленное внесение изменения вне зависимости от связанных с этим затрат. В других случаях внесение изменения может быть отложено до выпуска очередной версии системы. В зависимости от текущих условий, помимо описанных выше четырёх обязательных действий, может быть выполнено любое количество промежуточных вспомогательных действий.
