Управление проектированием программного изделия
Управление проектированием программного изделия — процесс планирования, мониторинга, контроля и руководства работами по проектированию. План управления проектированием определяет технические и управленческие функции, виды деятельности и задачи, выполнение которых приводит к удовлетворению требований к проекту программного изделия. На протяжении жизненного цикла план постоянно обновляется и совершенствуется, поскольку со временем появляется возможность более точных оценок, а требования или проектные решения могут изменяться.
Во время проектирования необходимо постоянно контролировать выполнение плановых показателей. Все существенные различия плановых оценок и действительных значений должны быть збъяснены и зафиксированы в документе История проекта.
Ключевая проблема управления — организация эффективной деятельности рабочей группы, структура которой определяется после установления всех задач, подлежащих решению в процессе проектирования. Каждый участник разработки должен иметь четко очерченную область полномочий и ответственность, а также опре-теленное местонахождение в иерархии подчинения. Существует ряд практически установленных моделей для организации и распределения работ при проектировании.
Для организации планирования очень важны оценки времени разработки, требуемых трудозатрат, финансовых затрат (стоимости разработки) и необходимых технических и программных ресурсов. Оценки, как правило, делаются на основе предыдущего опыта; любой оценке присущ определенный риск, поскольку все они делаются с определенной степенью достоверности. Величина риска обусловлена степенью неопределенности, которая изменяется по мере разработки программного изделия. Естественно, что наибольшая неопределенность присутствует на первых этапах жизненного цикла, а затем, по мере накопления информации об изделии, точность оценок возрастает.
Основные факторы, оказывающие влияние на степень риска:
1. Сложность проекта обусловливает неопределенность оценок при планировании.
Однако сложность является относительной мерой и в значительной степени зависит от предшествующего опыта разработчиков. При наличии у разработчика опыта создания подобных изделий влияние сложности проекта снижается.
2. Размер проекта также оказывает заметное влияние на точность оценок. При увеличении размеров изделия быстро растет число связей между его элементами, и оптимальная функциональная декомпозиция изделия, которая лежит в основе методологий получения оценок, становится более трудной.
3. Структурность проекта, характеризующая простоту выделения отдельных функций и подфункций изделия, также влияет на точность оценок. Чем более строгая иерархическая схема декомпозиции изделия на функциональные блоки может быть достигнута, тем более точными будут оценки планируемых показателей.
Риск возрастает, если недостаточно полно или плохо поняты масштабы проекта или когда требования к проекту в дальнейшем могут подвергаться изменениям. При этом, как правило, нарушаются сроки выполнения работ, существенно превышаются финансовые затраты. Поэтому планированию работ должно предшествовать тщательное изучение и описание функций и характеристик программного продукта, интерфейсов и ограничений.
При оценке требуемых ресурсов (людских, средств технического и программного обеспечения) для каждого ресурса указывают следующие характеристики:
• описание ресурса;
• информация о наличии ресурса;
• хронологическое время появления потребности в ресурсе;
• продолжительность использования ресурса.
Так, для описания требуемых людских ресурсов необходимо указать, какие требуются профессии (специализации) работников, какие из них имеются в наличии, какова продолжительность работы каждого из них и с какого момента они должны приступить к работе.
При планировании ресурсов технических средств принято рассматривать три категории средств: средства, на которых ведется разработка программного изделия, средства для автоматизации процесса разработки и, наконец, средства, на которых будет реально эксплуатироваться программное изделие.
При планировании средств программного обеспечения необходимо учитывать имеющиеся CASE-средства, позволяющие автоматизировать трудоемкие процессы анализа и проектирования, тестирования и интеграции модулей, имитации прототипов и т.п., а также средства автоматизации процесса управления проектированием.
Планирование требуемых ресурсов программного обеспечения обязательно включает в себя рассмотрение возможности повторного использования прежних разработок, а также существующих библиотек приложений коммерческого назначения. При этом необходимо иметь в виду, что повторное использование накопленных и каталогизированных программных продуктов может приводить к серьезным затруднениям, особенно при дальнейшем сопровождении. Обычно при планировании повторного использования программ придерживаются следующих двух правил:
1. Если существующее программное обеспечение отвечает поставленным требованиям, то стоимость его приобретения почти всегда ниже стоимости разработки эквивалентного Изделия-2, Если существующее программное обеспечение требует некоторой модификации, прежде чем оно может быть объединено в систему, необходима осторожность, так как стоимость модификации может оказаться выше стоимости разработки нового изделия.
