Концептуальная база проекта как основа его развития

Концепции развития проекта

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

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

Концепции развития проекта естественным образом разбиваются на две части:

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

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

Общие принципы и положения

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

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

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

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

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

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

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

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

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

В качестве примера приведем очень часто популяризируемый метод декомпозиции проекта на работы, получивший название построения пооперационного перечня работ [52]( WBS — work breakdown structure). Часто WBS переводится как иерархическая система работ — этим переводом мы будем пользоваться, когда требуется подчеркнуть способ построения WBS . Есть и другие переводы термина. Этот метод считается чуть ли не единственной основой любого проекта. Однако это не так! Он вполне подходит проектам, для которых достаточно хорошо известно, что надо получить в результате, или, по крайней мере, существуют способы точно выяснить это. Если проект можно рассматривать как детерминированно развивающийся (см. лекцию 5), то с помощью метода WBS достаточно технологично строится перечень работ, который позволит разумно оценивать затраты на разработку, распределять ресурсы, осуществлять другие менеджерские обязанности. Но как только это условие нарушается, возможности качественного применения метода резко падают. С точностью до этого ограничения методику WBS можно рекомендовать для применения в предпроектной деятельности менеджера проектов самых разнообразных областей, в том числе за пределами разработки программного обеспечения. Одно из главных ее достоинств в том, что она позволяет выделить в иерархически выстроенных работах проекта, необходимых для его успешного выполнения, уровень операций как частей проекта, допускающих непосредственное (в наших терминах — обозримое) управление и контроль выполнения заказчиком. Сумма операций проекта — это тот объем работ, о выполнении которого договариваются при составлении контракта.

Методика WBS применительно к концепции развития проекта рассматривается в следующем соотношении между общими и специальными принципами и положениями. Факт использования методики и обоснование адекватности ее применения — предмет рассмотрения общих положений концепции, а конкретизация использования, т.е. декомпозиция задач подготавливаемого к реализации проекта, относится к специальной части. Учитывая важность методики WBS для реальных проектов и достаточно широкую ее распространенность, в следующем разделе мы более детально обсудим ее содержание.