Материал: 970

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

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

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

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

Вчастности, ограничения могут содержать:

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

·требования на использование конкретной заданной про- граммно-аппаратной платформы;

·специфические требования к защите информации.

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

Оптимальная реализация программного проекта должна обеспечить достижение конкретной бизнес-цели при соблюдении ограничений «железного треугольника» (рис. 2.7) [26].

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

Содержание

Рис. 2.7. «Железный треугольник» ограничений проекта

В приложении к индустрии программного обеспечения к трем основным ограничениям «железного треугольника» добавляют четвертое ограничение — приемлемое качество [26]. В этом случае система ограничений должна строиться на основе приоритетов проекта и учитывать требования потребителей к создаваемому продукту или услуге. В случае необходимости жесткого предопределенного набора функциональности«плавающими» характеристиками проекта будут требуемое время и необходимый бюд-

жет (рис. 2.8).

Рис. 2.8. Возможные варианты системы ограничений проекта по имеющимся характеристикам: а — отсутствует ограничение на качество; б — отсутствует ограничение на бюджет;

в — отсутствует ограничение на время реализации

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

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

Согласно стандарту PMBOK (A Guide to the Project Management Body of Knowledge — Руководство к своду знаний по управлению проектами) проект считается успешным, если он выполнен в срок в соответствии со спецификациями и в пределах запланированного бюджета.

Общепринято, что не существует единственного правильного процесса разработки программного обеспечения. В каждом новом проекте в соответствии с«Законом 4-х П» (рис. 2.9) процесс должен определяться каждый раз заново, в зависимости от проекта, продукта и персонала [26].

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

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

В стандарте PMBOK приведены 9 процессов (областей знаний) по управлению проектами, каждый из которых состоит из определенного набора работ, и пять этапов (фаз) жизненного цикла проекта: инициация, планирование, исполнение, мониторинг