Управление проектированием программного изделия

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

Во время проектирования необходимо постоянно контролиро­вать выполнение плановых показателей. Все существенные разли­чия плановых оценок и действительных значений должны быть збъяснены и зафиксированы в документе История проекта.

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

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

Основные факторы, оказывающие влияние на степень риска:

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

2. Размер проекта также оказывает заметное влияние на точ­ность оценок. При увеличении размеров изделия быстро растет число связей между его элементами, и оптимальная функциональ­ная декомпозиция изделия, которая лежит в основе методологий получения оценок, становится более трудной.

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

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

При оценке требуемых ресурсов (людских, средств технического и программного обеспечения) для каждого ресурса указывают сле­дующие характеристики:

• описание ресурса;

• информация о наличии ресурса;

• хронологическое время появления потребности в ресурсе;

• продолжительность использования ресурса.

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

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

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

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

1. Если существующее программное обеспечение отвечает по­ставленным требованиям, то стоимость его приобретения почти всегда ниже стоимости разработки эквивалентного Изделия-2, Если существующее программное обеспечение требует неко­торой модификации, прежде чем оно может быть объединено в сис­тему, необходима осторожность, так как стоимость модификации может оказаться выше стоимости разработки нового изделия.