8.3.2 Организация разработки программного изделия в фазе анализа осуществимости
Анализ осуществимости проводится одновременно всеми функциональными группами на основе изучения соглашения о требованиях. На этом этапе исследуется каждое предложение соглашения о требованиях. Руководитель проекта поясняет и защищает свой сетевой график. В процессе обсуждения вносятся изменения в эти документы и вновь представляются на утверждение. Может быть предусмотрено несколько неформальных процедур пересмотра плана, однако все они должны быть успешно закончены официальным рассмотрением — фазовым обзором II. В результате фиксируется согласие или несогласие каждой функциональной группы с предложениями соглашения о требованиях.
Полученные в ходе фазового обзора II предложения относительно внесения изменений в соглашение о требованиях дают возможность оценить недостатки проекта. Оценку проводят по трем переменным: технические характеристики, календарные сроки и стоимость (рис. 8.7).
Рис. 8.7 — Границы изменяемости проекта:
Cc — увеличение стоимости; Sc — изменение времени; Fc — изменение технических характеристик
То есть внутри проекта выделяется некоторый диапазон изменения переменных; фактически это соответствует заданию небольшого запаса финансовых ресурсов, времени и свободы выбора технических характеристик системы.
На рассмотрение, переработку и утверждение соглашения о требованиях может уйти много времени, поэтому обычно эта работа совмещается с продолжением разработки в тех масштабах, которые позволяют ресурсы.
Параллельно с процессом рассмотрения соглашения о требованиях составляются индивидуальные рабочие планы и сводка трудозатрат, которые будут основой для определения будущих финансовых затрат.
8.3.3 Организация разработки программного изделия в фазе конструирования (проектирования)
Основная цель проектирования заключается в выработке и анализе требований к программному изделию. Процесс декомпозиции проекта, начатый при составлении соглашения о требованиях, продолжается путем разработки спецификаций и разбивки их на две части — внутренний и внешний проект. Внешний проект — это совокупность характеристик программного изделия, которые видит пользователь. Внутренний проект — совокупность характеристик программного изделия, скрытых от пользователя. Это делается, в первую очередь, для того, чтобы пользователи могли критически рассматривать те характеристики программного изделия, которые имеют к ним непосредственное отношение, не вдаваясь в критику внутренних характеристик изделия. То есть внешний проект описывает, что делает программное изделие, а внутренние спецификации указывают, каким образом изделие сконструировано для достижения внешних спецификаций. Внешние спецификации передаются для открытого и широкого обсуждения, в котором предпочтения отдаются предложениям пользователей.
Для того чтобы провести границу между внутренним и внешним проектом, схему декомпозиции упорядочивают. Схема декомпозиции называется хорошо упорядоченной, если на ней отмечен каждый случай вызова одной функции другой, вплоть до некоторого уровня абстракции, удобного с точки зрения управления проектом. Далее, каждый функциональный модуль рассматривается как черный ящик, для которого можно определить внешнее поведение, однако ничего нельзя сказать относительно его внутреннего устройства. Свойства черного ящика определяются полным описанием его характеристик, видимых извне, включая описание условий, при которых к нему можно обратиться, чтобы инициировать его функционирование. Те атрибуты модулей, которые играют существенную роль при составлении описания программного изделия как единого целого, составляют внешний проект. Все остальные параметры модулей, полностью или частично скрытые внутри программного изделия, составляют внутренний проект.
С учетом четкого различия между внешним и внутренним проектом, следует составлять внешние и внутренние спецификации программного изделия. При этом необходимо избегать общих мест в разных документах. Формы спецификаций обычно строго стандартизированы (SADT, PDL, и др.).
После того, как внешние спецификации приобретают сравнительно стабильный характер, в рамках функции разработки производится их рассылка функциональным группам (с пометкой «проект»). Все замечания суммирует специальный орган — технический комитет, который после анализа передает их в группу разработки. Обязанность группы разработки — максимально учесть все замечания.
Во время создания внутренних и внешних спецификаций другие функциональные группы готовят планы выпуска документации, планы испытаний и др. Эти документы рассылаются на рассмотрение в конце фазы проектирования. Руководитель проекта изучает и утверждает их. Фаза проектирования обычно заканчивается утверждением внешних спецификаций.