2. Планирование программного проекта (Software Project Planning)

Процесс планирования является итеративным* и базируется на содержании, требованиях и оценке осуществимости проекта. Здесь стоит напомнить, что различные фазы проекта перекрываются (что, например, специально отмечает PMBOK) и вместе с определением содержания, детализацией требований и проведением анализа осуществимости, параллельно с этим сам разрабатываемый план проекта в той или иной степени детализируется и формируется определенный комплекс работ, оцениваются необходимые ресурсы и временные границы работ, и т.п. SWEBOK, основываясь на такой позиции, говорит, что при планировании также оцениваются и отбираются соответствующие процессы жизненного цикла. Там где это уместно, проект детализируется в виде структурной декомпозиции работ, для которых отмечены ассоциируемых с их завершением результаты и их характеристики. Такие характеристики, обычно, связаны с вопросами качества и другими установленными атрибутами требований, соблюдением сроков выполнения работ, усилиями, стоимостью и т.д. Ресурсы распределяются по задачам таким образом, чтобы обеспечить оптимальную продуктивность (на персональном, командном и организационном уровне), использование средств (инфраструктуры, инструментов,...) и оборудования, а также строгое соблюдение проектного расписания. Также должно проводится управление рисками и, в частности, необходимо определить “профиль рисков”, принятый соответствующими заинтересованными лицами. Как составная часть планирования, необходимо определить необходимые процессы обеспечения качества в форме соответствующих процедур и обязанностей (responsibilities) по оценке, проверке, аттестации и аудиту качества (см. область знаний “Качество программного обеспечения” – Software Quality). Безусловно, что должны быть определены процессы и обязанности в части управления планом проекта, его оценкой и порядка пересмотра различных аспектов проекта.

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

2.1 Планирование процесса (Process Planning)

С учетом содержания и требований конкретного проекта необходимо выбрать, адаптировать и использовать соответствующую модель процессов жизненного цикла (например, спиральную, с эволюционным прототипированием). Также должны быть выбраны методы и инструменты. На уровне проекта, методы и инструменты используются для декомпозиции проекта в виде набора задач (tasks), с ассоциированными входами, выходами и условиями завершения (completion), например, в форме структуры декомпозиции работ – WBS (work breakdown structure). Это влияет на высокоуровневое (первичное) определение проектного расписания и организационной структуры <проектной команды>.

2.2 Определение результатов (Determine Deliverables)

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

Такие компоненты, обычно, называют “off-the-shelf”, подразумевая в настоящее время не только коммерческое, но и общедоступное программное обеспечения, если его использование обосновано в рамках данного проекта. Анализ и выбор соответствующих компонент может и, в подавляющем большинстве случаев, должен рассматриваться как самостоятельная задача процесса планирования в контексте сформулированных высокоуровневых требований, определенного содержания и базовых ограничений проекта, таких как сроки, ресурсы, стоимость). Это позволяет четко разделить, в том числе, в контексте затрат, что именно будет разрабатываться самостоятельно (может быть как отдельный “подпроект”), что будет использоваться из 3-их источников (3rd party), а что будет являться содержательным (с точки зрения проекта) результатом работ, то есть его непосредственным активом, обладающим, например, функциональной, для данного проекта, нагрузкой.