Разработка и стандартизация программ: лекция 3,4

Требования к программному обеспечению:

•Завершение этапа;

•Результаты этапа;

•Риски и управление ими;

•Проектирование: задачи и содержание этапа.

Как понять, что сбор требований завершен

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

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

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

•пользователи повторно описывают уже обсуждавшийся проблемы;

•предлагаемые новые функции, пользовательские или функциональные требования выходят за рамки проекта;

•вновь предлагаемые требования имеют низкий приоритет;

•пользователи предлагают возможности, которые имеет смысл реализовать «когда-то позже», а не включить «в конкретный продукт, который мы сейчас обсуждаем».

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

•регистрация ошибок

•архивация и восстановление

•безопасность доступа

•создание отчетов,

•печать и функции предварительного просмотра

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

РЕЗУЛЬТАТЫ ЭТАПА

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

2.Подписанное заказчиком и исполнителем соглашение о том, какие требования и в каком виде должны реализоваться;

3.Согласованный план приемо-сдаточных испытаний;

4.Процедуры работы с требованиями для конкретных специалистов и случаев (модификация, оценка, анализ и т.д.);

5.Оценки трудоемкости и стоимости разработки;

6.Перечень рисков с учетом их значимости;

7.План управления рисками;

8.План управления проектом.

РИСКИ И УПРАВЛЕНИЕ ИМИ

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

•не уложиться в срок,

•перерасходовать ресурсы,

•разработать не тот продукт, который требуется.

Риск это проблема, которая еще не возникла, а проблема — это риск, который материализовался.

Риск это всегда вероятность и последствия.

Цели управления рисками проекта — снижение вероятности возникновения и/или значимости воздействия неблагоприятных для проекта событий. Адекватное управление рисками в компании — признак зрелости производственных процессов.

Параметры, характеризующие риск:

•Причина или источник. Явление, обстоятельство обусловливающее наступление риска.

•Симптомы риска, указание на то, что событие риска произошло или вот-вот произойдет.

•Последствия риска. Проблема или возможность, которая может реализоваться в проекте в результате произошедшего риска.

•Влияние риска. Влияние реализовавшегося риска на возможность достижения целей проекта.

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

Принято выделять две категории рисков:

•«Известные неизвестные». Это те риски, которые можно идентифицировать и подвергнуть анализу. В отношении таких рисков можно спланировать ответные действия.

•«Неизвестные неизвестные». Риски, которые невозможно идентифицировать и, следовательно, спланировать ответные действия.

Планирование управления рисками

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

•выделить достаточное количество времени и ресурсов для выполнения операций по управлению рисками,

•определить общие основания для оценки рисков,

•повысить вероятность успешного достижения результатов проекта.

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

исходными данными для планирования управления рисками служат:

Отношение к риску и толерантность к риску организаций и лиц,

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

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

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

Планирование управления риском

Список факторов риска — не то же самое, что план управления риском Для малого проекта можно включить план управления риском в план управления проектом разработки ПО. Для

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

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

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

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

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

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