Основы программирования

Основы технологии - Анализ чувствительности программного проекта
Индекс материала
Основы технологии
Организация процесса конструирования
Классический жизненный цикл
Макетирование
Быстрая разработка приложений
Спиральная модель
Тяжеловесные и облегченные процессы
Модели качества процессов конструирования
Контрольные вопросы
Руководство программным проектом
Начало проекта
Трассировка и контроль
Достоинства размерно-ориентированных метрик:
Примеры элементов данных
Достоинства функционально-ориентированных метрик:
Конструктивная модель стоимости
Модель композиции приложения
Модель раннего этапа проектирования
Модель этапа постархитектуры
Факторы продукта:
ПРИМЕЧАНИЕ
Предварительная оценка программного проекта
Анализ чувствительности программного проекта
Сценарий понижения зарплаты
Сценарий уменьшения средств на завершение проекта
Выводы.
Классические методы анализа
Все страницы
Анализ чувствительности программного проекта

 

СОСОМО II — авторитетная и многоплановая модель, позволяющая решать самые разнообразные задачи управления программным проектом.

Рассмотрим возможности этой модели в задачах анализа чувствительности — чувствительности программного проекта к изменению условий разработки.

Будем считать, что корпорация «СверхМобильныеСвязи» заказала разработку ПО для встроенной космической системы обработки сообщений. Ожидаемый размер ПО — 10 KLOC, используется серийный микропроцессор. Примем, что масштабные факторы имеют номинальные значения (показатель степени В = 1,16) и что автоматическая генерация кода не предусматривается. К проведению разработки привлекаются главный аналитик и главный программист высокой квалификации, поэтому средняя зарплата в команде составит $ 6000 в месяц. Команда имеет годовой опыт работы с этой проблемной областью и полгода работает с нужной аппаратной платформой.

В терминах СОСОМО II проблемную область (область применения продукта) классифицируют как «операции с приборами» со следующим описанием: встроенная система для высокоскоростного мультиприоритетного обслуживания удаленных линий связи, обеспечивающая возможности диагностики.

Оценку пост-архитектурных факторов затрат для проекта сведем в табл. 2.27.

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

Таблица 2.27. Оценка пост-архитектурных факторов затрат

Фактор

Описание

Оценка

Множитель

RELY

Требуемая надежность ПО

Номинал.

1

DATA

Размер базы данных — 20 Кбайт

Низкая

0,93

CPLX

Сложность продукта

Очень высок.

1,3

RUSE

Требуемая повторная используемость

Номинал.

1

DOCU

Документирование жизненного цикла

Номинал.

1

TIME

Ограничения времени выполнения (70%)

Высокая

1,11

STOR

Ограничения оперативной памяти (45 из 64 Кбайт, 70%)

Высокая

1,06

PVOL

Изменчивость платформы (каждые 6 месяцев)

Номинал.

1

ACAP

Возможности аналитика (75%)

Высокая

0,83

PCAP

Возможности программиста (75%)

Высокая

0,87

AEXP

Опыт работы с приложением (1 год)

Номинал.

1

PEXP

Опыт работы с платформой (6 месяцев)

Низкая

1,12

LTEX

Опыт работы с языком и утилитами (1 год)

Номинал.

1

PCON

Непрерывность персонала ( 1 2% в год)

Номинал.

1

TOOL

Активное использование программных утилит

Высокая

0,86

SITE

Мультисетевая разработка (телефоны)

Низкая

1,1

SCED

Требуемый график разработки

Номинал.

1

Множитель поправки Мр

1,088

 

Рассчитаем затраты и стоимость проекта:

ЗАТРАТЫ = AхРАЗМЕРBхМр=2,5(10)1,16х1,088=36x1,088= 39[чел.-мес],

СТОИМОСТЬ = ЗАТРАТЫ х $6000 = $234 000.

Таковы стартовые условия программного проекта. А теперь обсудим несколько сценариев возможного развития событий.