Второй уровень. Избранные практики - 2

Записаться

Планирование разработки ПО: основные операции

1. Участие группы разработки в планировании

Группа разработки участвует в следующих действиях:

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

2. Обязательства проекта

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

Группа разработки должна решить:

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

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

3. Планирование на протяжении жизненного цикла

Планирование проекта идёт на протяжении всего жизненного цикла. В ходе проекта в план могут вноситься изменения и уточнения. Группа разработки обязана рассматривать все такие планы.

4. Выбор модели жизненного цикла

Модель жизненного цикла должна быть выбрана. Примеры: водопад, водопад с перекрытием, спираль. Это только примеры и подсказка, а не обязательные схемы. Если внедряется СМ (CMM, Capability Maturity Model), они помогают понять, о чём идёт речь.

5. Подготовка плана разработки ПО

План разработки ПО создаётся на основании документов и стандартов заказчика. Например, если заказчик применяет ГОСТ 34, нужно работать с ним. Если используется UML (Unified Modeling Language), этапы UML нужно распределить по выбранной модели, например по водопадной модели ГОСТа.

Уже есть утверждённое ТЗ (техническое задание). Значит, состав работ фактически определён. Нужно разложить работы по времени. Также учитываются установленные требования, не вошедшие в ТЗ.

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

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

6. Документирование плана разработки

План разработки раскрывает:

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

7. Оценка объёма промежуточных программных продуктов

В момент разработки СМ были популярны методы оценки объёма работ программистов. Возник метод функциональных точек (function points). Сейчас он используется редко, но тогда был актуален. Также применялись оценки:

• по реализованным возможностям (частично прослеживается в UML);
• по количеству строк кода;
• по количеству пунктов требований;
• по количеству страниц документации.

Вывод: нужна процедура оценки объёма будущих работ. СМ требует, чтобы такая процедура была. Конкретный метод можно выбрать.

8. Оценка трудозатрат и стоимости

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

9. Учёт компьютерных ресурсов

Раньше компьютерные ресурсы были дорогими. В организациях существовал учёт использования компьютерных ресурсов, особенно там, где работали мейнфреймы (mainframe) в режиме разделяемого доступа. Сейчас это не всегда актуально, но зависит от задачи. Если задача большая, сложная и требует большого объёма ресурсов, использование которых может повлиять на другие работы, учёт нужно вести.

10. Календарный график, риски, инструменты и документирование данных

Далее в планировании учитываются:

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

Краткие итоги

Планирование разработки ПО — это не единичный акт, а непрерывный процесс согласования технических, организационных и экономических ограничений. Его практический смысл в том, чтобы превратить расплывчатую цель «сделать клиенту хорошо» в проверяемые обязательства: технические цели, решения, бюджет, график, ресурсы и процедуры. Логика изложения строится от участия группы разработки в предложении и обсуждении обязательств к выбору жизненного цикла и документированию плана. Это отражает реальную последовательность: сначала фиксируются рамки и взаимные ожидания, затем выбирается способ организации работ, после чего план наполняется оценками, ресурсами и управленческими механизмами.

Ключевой практический вывод: план должен быть управляемым и контролируемым. Это означает версионность, обоснование выбора модели жизненного цикла, методов и стандартов, а также прозрачность промежуточных продуктов. Без такого обоснования план превращается в формальный документ, который невозможно корректировать при изменениях. Особое внимание уделяется оценке объёма и трудозатрат. Любая оценка требует процедуры и источника данных: исторических проектов, производительности, аналогий. Это снижает риск волюнтаризма и делает бюджет и сроки защищаемыми.

Вспомогательные работы — обучение, загрузка данных, интеграция — должны попадать в бюджет, иначе реальная стоимость проекта окажется заниженной. Учёт компьютерных ресурсов и рисков показывает, что планирование не сводится к календарю: нужно учитывать ограничения среды и неопределённость. Документирование данных по завершении и в ходе проекта создаёт основу для улучшения будущих оценок. Таким образом, практическая ценность темы в том, что она даёт набор взаимосвязанных решений: как выбрать жизненный цикл, что включить в план, как оценить объём и затраты, какие работы не забыть и как сделать план живым инструментом управления, а не статичным перечнем задач.