8.3 Организация разработки программного изделия
Под управлением проектом мы будем понимать управление достижением требований, предъявляемых к программному изделию на основании использования матричной структуры связи функций и проектов. В этой матрице каждой функции соответствует группа руководителей, несущих ответственность за ее выполнение наилучшим образом, каждому программному изделию соответствует, в свою очередь, группа руководителей, внимание которых сосредоточено только на данном программном изделии (рис. 8.6).
Администратор проекта (руководитель) занят одним-единственным проектом, каждая функция которого охватывает несколько индивидуальных разработок.
Администратор изделия регулирует степень участия каждой функциональной группы в разработке программного изделия, успешность которой определяется, прежде всего, степенью соблюдения ранее установленных технических требований и целей, допустимых границ затрат. Обычно он начинает выполнять свою роль, начиная с фазы анализа осуществимости и до окончания фазы оценки. Администратор — это, обычно, сотрудник подразделения разработки, хорошо понимающий работы, выполняемые другими людьми и подразделениями (часто бывает, что он несет ответственность за все, не имея полномочий).
Рис. 8.6 — Схема матричного управления проектом
В матричной структуре каждый разработчик имеет двух начальников. Однако именно матричная структура наиболее эффективна для управления такими непредсказуемыми процессами, как разработка программ.
8.3.1 Организация разработки программного изделия в фазе исследований
Затраты труда при реализации функций разработки отдельного программного изделия, согласно кривой Релея, имеют максимальное значение в фазах проектирования и программирования. Осуществление функций разработки начинается в фазе исследований с того момента, когда будет признана необходимость создания конкретного программного изделия. В этом случае план — это план завоевания рынков сбыта, план выпуска серии программных изделий и бюджет. Основной параметр этих планов — срок, к которому возникает необходимость в данном программном изделии. Первая задача, выполняемая в рамках разработки, состоит в том, чтобы определить, когда следует начать разработку изделия, чтобы обеспечить его готовность к моменту, когда в нем возникнет необходимость. Функция разработки предусматривает согласование момента начала проектирования с возможностью выполнения других функций, чтобы гарантировать их совместное обеспечение в процессе проектирования. В рамках функции разработки фиксируются предлагаемые сроки начала и завершения всех видов работ, среди которых выделяют основные этапы проектирования, и запрашиваются ресурсы, необходимые для анализа осуществимости проекта, — кадры, машинное время, командировки, фонды для проведения консультаций. Это достигается путем составления сметы затрат, в которой обязательно указывается, кто несет ответственность за выполнение проекта в каждой функциональной группе, здесь же предлагается кандидатура руководителя проекта в целом. Руководитель проекта (администратор) дает указание выполнить анализ результатов работ, выполненных в фазе I (фазовый обзор), и ходатайствует о соответствующем финансировании. Обычно администратор ограничивается выделением средств на работы, связанные с составлением соглашения о требованиях. Такая мера ограничит трату ресурсов, в которых нет необходимости во время фазы анализа осуществимости.
Для правильного принятия решения на основе результатов фазы I оценивается не только стоимость, но и календарные сроки проектирования. Поэтому один из участников проекта, ответственный за подготовку соглашения о требованиях, представляет формально законченный план — график работ. Этот первоначальный вариант плана должен обязательно фиксировать точный срок представления соглашения о требованиях и предполагаемый срок окончания разработки программного изделия.
Если на основании фазового обзора I руководство разрешает начать анализ осуществимости, выделяя для этого соответствующие ресурсы, то предпринимается попытка составить соглашение о требованиях. Формальное составление соглашения о требованиях облегчается, если придерживаться строго формализованной формы. Требования должны быть выражены в ясной форме и не допускать противоречивых толкований. В соглашениях о требованиях следует избегать пунктов, объясняющих, как надо решать поставленную задачу. Рассматривая соглашения о требованиях, функциональные группы обычно накладывают жесткие ограничения на эксплуатационные качества и другие характеристики программного изделия. Для обоснования этих ограничений (принять или нет) обязательно должен быть проведен достаточно глубокий анализ осуществимости.
Соглашение о требованиях — это договор между руководителем проекта и заказчиком, который также включает субподряды, заключенные между группой разработки и другими функциональными группами. Договорный характер соглашения о требованиях подчеркивается тем, что привязываются индивидуальные рабочие планы к конкретным положениям данного документа. И так как соглашение о требованиях связывает воедино усилия многих подразделений, его необходимо согласовывать на всех уровнях (вплоть до конкретного исполнителя).
На базе соглашения о требованиях составляется общий план для всего проекта. В нем указываются взаимодействия между функциональными группами и вклад каждой из них в проект, а также очерчиваются границы обязанностей каждой группы. В этом плане также дается основа описания всех задач, решаемых группой разработки. Обычно этот план составляется в виде сетевого графика.