Инженерное программирование - это планирование и управление проектом, распределения всех видов ресурсов - исполнителей, программных и инструментальных средств и оценивание сроков, стоимости работ для успешного выполнения проекта. С проектом связано также выявление рисков и других обстоятельств, замедляющих изготовления версий (конфигурации) системы [11.1]-[11.6[11.7].

Материал данной темы состоит из трех разделов, связанных с проблемой управления проектом:

1. Методы управления программным проектом.
2. Методы обнаружения и устранения рисков в проекте.
3. Управление конфигурацией системы.

11.1. Методы управления проектами

Согласно мировой статистики, не все реализуемые программные проекты завершаются успешно, 33% из них являются провальными по следующим причинам:

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

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

• планирование проекта и составление графиков работ выполнения проекта,
• управление проектными работами и командой исполнителей,
• управление рисками,- оценивание продукта и процессов в целях их дальнейшего усовершенствования и др.

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

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

Успешное выполнение проекта зависит от знания менеджером методов управления проекта и особенностей программного продукта:

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

Накопленный опыт в создании технических проектов был систематизирован (в Институте управления проектами в США) и разработано ядро знаний - РMBOK (Project Management Body of Knowledge [11.2]. В нем малыми проектами считаются проекты, содержащие 100 работ и 15 исполнителей, средними - 500 работ и 50 исполнителей и большими - 1000 работ и 100 исполнителей.

В ядре РМВОК определены основные аспекты разработки проектов:

• методы управления, планирования и контроля работ;
• эффективная организация проектной команды;
• инструментарий менеджера проекта (например, система Project Management фирмы Microsoft).

11.1.1 Методы управления программным проектом

К настоящему времени сформировалось несколько методов, эффективно применяемых в практике реализации программных проектов [11.5, 11.7]. Рассмотрим их.

Метод критического пути СРМ. Оснополагающий момент в создании этого метода - исследование возможности эффективного использования вычислительной машины Univac на фирме "Dupon" при планировании и создании планов-графиков больших комплексов работ по модернизации заводов этой фирмы. В результате был создан рациональный и простой метод (Уолкера-Келли) управления проектом с использованием ЭВМ, который был назван CPM (Critical Path Method) - метод критического пути.

Критический путь - наиболее полный путь работ в сетевом графике, которые лежат на этом пути. Именно продолжительность критического пути определяет наименьшую общую продолжительность работ в проекте в целом. Время выполнения всего проекта может быть сокращено за счет уменьшения времени выполнения задач, которые лежат на критическом пути. Соответственно любая задержка выполнения задач критического пути приводит к увеличению времени выполнения проекта. Эта концепция обеспечивает концентрацию внимания менеджера на критических работах. Однако основное преимущество метода критического пути - управление сроками выполнения задач, которые не лежат на критическом пути. Этот метод разрешает рассчитать возможные календарные графики выполнения комплекса работ на основе описанной логической структуры сети и оценок времени выполнения каждой работы [11.1-11.7].

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

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

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

Рис. 11.1. Граф задания сроков выполнения работ

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

Метод анализа и оценки PERT. Параллельно с разработкой CPM в военноморских силах США был создан (фирма "Буз, Аллен & Гамильтон") метод анализа и оценки программ PERT (Program Evaluation and Review Technique) для реализации проекта разработки ракетной системы "Polaris", объединяющей около 3800 подрядчиков с числом операций более 60 тыс. [11.6].

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

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

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

Возможное время выполнения операций оценивается с помощью трех оценок:

• оптимистичной ( \[ О \] );
• пессимистической ( \[ П \] );
• вероятностной ( \[ B \] ).

Далее возможное время вычисляется по формуле: \[ \frac{О + 4В + П}{6} \] .

Для уменьшения провалов в проекте используются и другие аналитические методы и усовершенствованные технологические системы разработки. Как показывает опыт, "продвинутые" технологии предлагают следующие постулаты успешного создания проекта [11.3]:

1. Проект начинать с правильного шага;
2. Поддержка темпа работы на проекте;
3. Обеспечение прогресса и принятия правильных решений;
4. Анализ завершенного проекта (преимуществ и недостатков).

1. Проект начинать с правильного шага. К правильному шагу относится формирование команды разработчиков из хороших специалистов, в том числе не более 20% звезд, наиболее приспособленных для хорошей работы над проектом (много звезд - создание конфликтов). В команду входят надежные разработчики с совместимыми характерами и рабочими привычками. Звезды решают сложные вопросы, разрабатывают более ответственные алгоритмы и проводят техническое обучение остальных членов команды. Для уточнения всех особенностей проекта разработчики садятся за стол переговоров с заказчиком и составляют взаимно приемлемый документ.
2. Поддержка темпа работы предполагает:
   • уменьшение текучести кадров;
   • контроль качества выполняемых работ;
   • управление процессом разработки продукта, а не людьми команды.

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

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

   Управление процессом разработки состоит в анализе проектирования элементов системы и критике результатов труда исполнителей, а не режима работы.
3. Поддержка прогресса и правильных решений. Программа отличается от других продуктов тем, что она - неосязаема. Ее разработка начинается с создания концептуальной модели, а результаты ее применения влияют на получение продукта.
4. Анализ проекта. Это изучение своих ошибок при реализации предыдущего проекта, чтобы не повторить их в новом проекте. Так как каждая команда и фирма имеют свои особенности, которые влияют на процесс разработки, то при анализе можно выделить особенности и закономерности, которые влияют на получение качественных результатов.