Управление проектом связано с вопросами:

- планирования и организации работ;

- создания коллективов разработчиков;

- планирования и управления ресурсами, персоналом, аппаратурой, программными средствами и инструментарием;

- контроля за сроками и качеством выполняемых работ и с вопросами конфигурационного управления.

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

Определив размеры проекта, руководителю компании-разработчика надо уметь согласовать собственные интересы с интересами заказчика.

Следующая задача руководителя — это следить за общим ходом проекта на основе правильных показателей и управлять ходом выполнения проекта.

А самая главная задача — это стараться предвидеть проблемы, которые могут возникнуть в процессе работы.

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

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

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

В качестве критерия объема проделанных работ некоторые компании используют процент от выделенных на проект средств (можно истратить весь бюджет, но не выполнить проект), число строк кода (можно написать миллиарды строк кода, и при этом проект останется недоделанным), качество работы.

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

Единственным "хорошим" методом является личный опыт руководителя, так как всегда:

- трудно сказать, насколько велика данная работа;

- нельзя точно сказать, какой будет (или даже была) производительность труда людей;

- нельзя указать процент выполненной работы;

- трудно сказать, насколько быстро движется работа;

- трудно сказать, насколько далеко продвинулась разработка.

Для примера рассмотрим опыт оценивания объема разрабатываемой системы корпорации Cutter.

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

Заказчик оплачивает работы только после завершения очередного этапа.

Руководитель проекта должен получить письменное согласие заказчика на переход к следующей стадии проекта.

Заказчик должен одобрить работы на текущей стадии до перехода к следующей стадии.

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

- детальный план следующего этапа;

- отчет по результатам текущего этапа;

- запрос на принятие текущего этапа;

- запрос на переход к следующему этапу.

Существует метод инженерно-технической оценки затрат:

1) Формулируются общие требования к системе, исходя из существующих требований заказчика.

2) Собирается аналогичная информация, например, данные о подобных системах.

3) Отбираются основные общие данные.

4) Производится предварительная оценка:

- сравнение проектируемой системы с подобными, уже разработанными;

- разбиение системы на части и сравнение каждой из этих частей с подобными ей частями других систем;

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

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

5) Производится окончательная оценка системы.

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

Один из методов — метод экспертных оценок.

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

Может использоваться метрика генерации модулей.

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

Модули делят по группам: генерируется автоматически, простой, средней сложности, сложный, очень сложный.

Учитываются как минимум следующие факторы:

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

- стабильность модели функций и степень ее изменения в течение разработки;

- уровень квалификации персонала;

- пригодность выбранных средств разработки;

- использование автоматических генераторов кода (например, экранных форм и отчетов);

- соответствие среды требованиям средств разработки (станции разработчиков, серверы, сеть, операционные системы и т.п.);

- зависимости модулей и возможности накопления отставания от графика.

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

- менее 1 тыс. функциональных точек — один человек;

- от 1 до 4 тыс. функциональных точек — одна бригада разработ­чиков;

- более 4 тыс. функциональных точек — одна бригада разработчи­ков на 4 тыс. функциональных точек.

Под функциональной точкой понимается любой из следующих элемен­тов разрабатываемой системы:

- входной элемент приложения (входной документ или экранная форма);

- выходной элемент приложения (отчет, документ, экранная форма);

- запрос (пара "вопрос/ответ");

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

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

Для определения численности специалистов, занятых в проекте, может быть использован (отраслевой стандарт) ОСТ 4.071.030 — Автоматизированная система управления предприятием. Создание системы. Нормативы трудоёмкости.

Стандарт устанавливает нормативы трудоёмкости на работы по созданию и дальнейшему развитию АС управления предприятием (АСУП).

Нормативы трудоёмкости на проектирование АСУП дифференцированы в зависимости:

- от технологии обработки информации;

- от степени новизны создания АСУП;

- от сложности задач.

Технология обработки информации зависит от использования:

- локальных массивов;

- банка данных (БД).

Степень новизны определяется характером разработки АСУП:

1-я степень — индивидуальная разработка задач с целью развития АСУП, реализуемой на ЭВМ; разработка типовых (головных) проектов АСУП, реализуемых на ЕС ЭВМ;

2-я степень — создание АСУП на базе ЕС ЭВМ на основе внедрения типовых проектов АСУП при условии их частичной доработки; развитие АСУП за счет заимствования проектных решений в случае неполного соответствия их условиям предприятия;

3-я степень — привязка решений типовых проектов АСУП.

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

Причинами возможных неудач проекта являются:

- нечеткая и не­полная формулировка требований к ПО,

- недостаточное вовлечение пользователей в работу над проектом,

- частое изменение тре­бований и спецификаций,

- новизна используемой технологии для организации,

- неудовлетворительное планирование,

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

- недоста­точная поддержка со стороны высшего руководства,

- отсутствие необходимых ре­сурсов.

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

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

Для этого необходимо использовать современные инструментальные средства управления проектами.

Они, как правило, предоставляют следующие базовые возможности:

- календарное планирование;

- планирование ресурсов;

- алгоритмы расчета критических путей плана;

- графические средства наглядного представления планов;

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

- генераторы отчетов;

- поддержку рабочих групп.

Компания Computer Associates Inc. предлагает средство CA-SuperProject.

Компания Microsoft Inc. предлагает средство Microsoft Project 2002. Оно хотя и не предназначено специально для проектов разработки ПО, но по цене, легкости освоения и гибкости (возможность использования встроенного языка программирования VBA) является очень полезным для организации разработки программ.

Microsoft Project 2002 включает в себя:

- Microsoft Project Standart — для управления проектами;

- Microsoft Project Professional — средство анализа и управления ресурсами в масштабах всего предприятия;

- и другие компоненты.

Компания Platinum Technology Inc. предлагает комплекс программ поддержки ЖЦ разработки ADvantage, включающее в себя средство управления проектами и процессами разработки ПО PLATINUM Process Continuum, которое состоит из следующих основных компонентов:

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

- Estimator производит оценку сложности, трудоемкости и стоимости проекта, выполняет анализ сложности и рисков запланированных работ. Результаты, полученные в данном приложении, необходимы для детального календарного планирования проектов разработки ПО;

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

- Decision Support Monitor — средство поддержки принятия решений руководителем проекта;

- Status & Time — инструмент контроля и управления. Позволяет перераспределять задачи, контролировать состояние работ по проекту, управлять расписанием исполнителей проекта и регистрировать внесенные изменения. При внесении изменений автоматически корректируется распределение ресурсов в других проектах. Метрики, собранные здесь, хранятся в репозитории и могут быть использованы в дальнейших проектах, что позволяет постоянно увеличивать качество работ и эффективность выполнения проектов;

- и других компонентов.

Средство KnowledgePLAN фирмы Software Productivity Research (SPR, США) является лидером по точности и корректности планирования проектов разработки ПО.

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

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

В KnowledgePLAN в качестве метрик для оценки размеров ПО используются:

- function points (функциональные точки) — наиболее стандартизированная в настоящее время метрика оценки размеров ПО;

- feature points — собственная разработка фирмы SPR, позволяющая учесть алгоритмическую сложность разрабатываемых программ.

Планирование ведется на основе предопределенных шаблонов планов. Ряд таких шаблонов поставляется фирмой SPR в комплекте с самой программой. Для учета особенностей собственной технологии разработки фирма может разработать сама или заказать новые шаблоны планирования.