Задачи управления рисками

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

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

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

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

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

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

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

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

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

Анализ требований включает три типа деятельности:

• Сбор требований: общение с клиентами и пользователями, чтобы определить, каковы их требования.

• Анализ требований: определение, являются ли собранные требования неясными, неполными, неоднозначными, или противоречащими, и затем решение этих проблем.

• Документирование требований: Требования могут быть задокументированы в различных формах, таких как простое описание, сценарии использования, пользовательские истории, или спецификации процессов.

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