2.5 Управление рисками (Risk Management)

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

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

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

• смягчение рисков (risk mitigation) и планируемость непредвиденных обстоятельств (contingency planning) – формирование стратегии, касающейся рисков и управление профилями рисков.

Для идентификации и оценки рисков необходимо применять соответствующие методы и техники (например, построение дерева решений – decision tree или моделирование процессов – process simulation). Кроме того, со всеми заинтересованными лицами необходимо определить правила и политики прекращения проекта.

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

2.6 Управление качеством (Quality Management)

Качество определяется в терминах атрибутов, значимых для данного конкретного проекта и/или ассоциированного с ним продукта. Атрибуты могут выражаться как качественно, так и количественно. Эти характеристики качества определяются в спецификации требований к программному обеспечению (см. область знаний “Требования к программному обеспечению” – Software Requirements).

Отправной точкой для соблюдения качества является набор индикаторов, соответствующих ожиданиям заинтересованных лиц. На этой стадии (как мы помним, речь идет о планировании проекта) также специфицируются процедуры, связанные с проведением SQA-деятельности (деятельности по обеспечению качества – software quality assurance) на протяжении всех процессов жизненного цикла и для проверки и аттестации (V&V – verification and validation) для получаемого продукта и всех активов (артефактов) проекта (см. область знаний “Качество программного обеспечения” – Software Quality).

2.7 Управление планом проекта (Plan Management)

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