Вопрос 5. Управление проектом

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

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

Подробнее о способах управления проектом, касающихся создания требований — в следующих главах:

1 в главе 17 — о планах, связанных с проектом, о их реализации на основе требований;

1 в главе 18 — о контроле объема работ по созданию требований;

I в главе 23 — о документировании и управлении рисками, связанными с требований.

Управление проектом включает:

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

1. Управление процессом;

2. Идентификация программных конфигураций;

3. Контроль программных конфигураций;

4. Учет статусов конфигураций;

5. Аудит конфигураций;

6. Управление выпуском и поставками.

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

Пересмотр обязательств по проекту при изменении требований.

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

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

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

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

Управление процессом нашло свое отражение в SCM (Software Configuration Management)

ТЕМА: SCM (Software Configuration Management)