Организация бизнеса на рынке программных продуктов

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

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

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

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

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

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

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

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

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

Оптимальная реализация программного проекта должна обеспечить достижение конкретной бизнес-цели при соблюдении ограничений «железного треугольника» (рис. 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 процессов (областей знаний) по управлению проектами, каждый из которых состоит из определенного набора работ, и пять этапов (фаз) жизненного цикла проекта: инициация, планирование, исполнение, мониторинг

Продолжение табл. 2.1

Окончание табл. 2.1

Планирование программного проекта относится к работам,

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

метод критического пути — CPM (Critical Path Method) и ме-

тод анализа и оценки программPERT (Program Evaluation and Review Technique).

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

Анализ состояния разработки проекта предлагается проводить на основе анкетирования, отражающего состояние направлений аудита [26]. Направлениями аудита являются:

1) четкость постановки целей проекта:

·концепция определяет ясные недвусмысленные цели;

·все члены команды считают концепцию реалистичной;

·у проекта имеется обоснование экономической эффективности;

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

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

·с конечными пользователями продукта налажена двухсторонняя связь;

2) конкретизированность способов достижения целей:

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

·в список задач проекта включены«второстепенные» задачи

(управление конфигурациями, конвертация данных, интеграция

сдругими системами);

·после каждой фазы проекта обновляется расписание и бюджет;

·архитектура и проектные решения документированы;

·имеется план обеспечения качества, определяющий тестирование и рецензирование;

·определен план многоэтапной поставки продукта;

·в плане учтены обучение, выходные, отпуска, больничные;

·план проекта и расписание одобрены всеми участниками команды;

3) наличие определенной формы организации контроля и управления реализацией проекта:

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

·у проекта есть менеджер, причем только один;

·в плане проекта определены «бинарные» контрольные точки;

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

·между руководством и разработчиками установлены доверительные отношения;

·установлена процедура управления изменениями в проекте;

·определены лица, ответственные за решение о принятии изменений в проекте;

·план, расписание и статусная информация по проекту доступны каждому участнику;

·код системы проходит автоматическое рецензирование;

·применяется система управления дефектами;

4) проведение периодического анализа угроз и рисков:

·имеется список рисков проекта. Осуществляется его регулярный анализ и обновление;

·руководитель проекта отслеживает возникновение новых рисков;

·для каждого подрядчика определено лицо, ответственное за работу с ним.

5) организация командной работы над проектом:

·опыт команды достаточен для выполнения проекта;

·у команды достаточная компетенция в прикладной области;

·в проекте имеется технический лидер;

·численность персонала достаточна;

·у команды имеется достаточная сплоченность;

·все участники привержены проекту.

Каждый вопрос предлагается оценить по следующей схеме: оценка 0 проставляется, если руководитель даже не знает об этом; 1 — знает, но пока не реагирует на это; 2 — знает, но реагирует периодически; 3 — реагирует постоянно. В зависимости от численности команды при расчете итогового балла предлагается учитывать следующие поправочные коэффициенты: для малых проектов (до 5 человек) — 1,5; для средних (от 5 до 20 человек) — 1,25. Результаты самооценки: если итоговый балл меньше40 — завершение проекта сомнительно; 40–59 — в ходе реализации проекта следует ожидать серьезные проблемы; 60–79 — проект, скорее всего, будет успешным; 80–89 — вероятность успеха высока; больше 90 — 100 % шансов на успех.

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