Записать формулы, по которым производились расчёты

_________________________________________________________________________

____________________________________________________________________________________________________________________________________________________

Лабораторна робота № 2.

Аналіз чуттєвості програмного проекту.

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

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

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

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

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

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

Фактор

Описание

Значение

Оценка

Множитель

RELY

Номинал.

DATA

20 Кбайт

Низкая

0,93

CPLX

Очень высок.

1,3

RUSE

Номинал.

DOCU

Номинал.

TIME

70%

Высокая

1,11

STOR

45 из 64 Кбайт, 70%

Высокая

1,06

PVOL

каждые 6 месяцев

Номинал.

ACAP

75%

Высокая

0,83

PCAP

75%

Высокая

0,87

AEXP

1 год

Номинал.

PEXP

6 месяцев

Низкая

1,12

LTEX

1 год

Номинал.

PCON

12% в год

Номинал.

TOOL

Высокая

0,86

SITE

телефоны

Низкая

1,1

SCED

Номинал.

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

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

Рассчитаем затраты и стоимость проекта (А=2,5, В=1,16):

ЗАТРАТЫ=А*РАЗМЕР^В*М_Р=______________________________________________

СТОИМОСТЬ=ЗАТРАТЫ*$6000=_________________________________________

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

Сценарий понижения зарплаты

Положим, что заказчик решил сэкономить на зарплате разработчиков. Т.е. понижение квалификации аналитика и программиста. Соответственно, зарплата сотрудников снижается до $5000. Оценки их возможностей становятся номинальными, а соответствующие множители затрат принимают единичные значения: ЕM_ACA_Р=ЕM_PCAP=1.

Следствием такого решения является изменение множителя поправки

М_Р= _____________________________,возрастание/убывание(нужное подчеркнуть),

а также затрат и стоимости:

ЗАТРАТЫ = _________________________________________,

СТОИМОСТЬ = ______________________________________,

проигрыш/выигрыш (нужное подчеркнуть) =___________

Сценарий наращивания памяти

Положим, что разработчик предложил нарастить память — купить за $ 1000 чип ОЗУ емкостью 96 Кбайт (вместо 64 Кбайт). Это меняет ограничение памяти (используется не 70%, а 47%), после чего фактор STOR снижается до номинального: ЕM_STOR=l.

Следствием такого решения является изменение множителя поправки

М_Р= ____________________________, возрастание/убывание (нужное подчеркнуть),

а также затрат и стоимости:

ЗАТРАТЫ = _________________________________________,

СТОИМОСТЬ = ______________________________________,

проигрыш/выигрыш (нужное подчеркнуть) =___________

Сценарий использования нового микропроцессора

Положим, что заказчик предложил использовать новый, более дешевый МП (дешевле на $1000). К чему это приведет? Опыт работы с его языком и утилитами понижается от номинального до очень низкого и ЕM_LTEX=1,22, а разработанные для него утилиты (компиляторы, ассемблеры и отладчики) примитивны и ненадежны (в результате фактор TOOL понижается от высокого до очень низкого и ЕМ_TOOL=1,24).

Следствием такого решения является изменение множителя поправки

М_Р= ____________________________, возрастание/убывание (нужное подчеркнуть),

а также затрат и стоимости:

ЗАТРАТЫ = _________________________________________,

СТОИМОСТЬ = ______________________________________,

проигрыш/выигрыш (нужное подчеркнуть) =___________

Сценарий уменьшения средств на завершение проекта

Положим, что к разработке принят сценарий с наращиванием памяти.

Кроме того, предположим, что завершился этап анализа требований, на который было израсходовано 10% от бюджета. Т.е. осталось $200 000.

Допустим, что в этот момент «коварный» заказчик сообщает об отсутствии у него достаточных денежных средств и о предоставлении на завершение разработки только $170000 (15%-ное уменьшение оплаты).

Для решения этой проблемы надо установить возможные изменения факторов затрат, позволяющие уменьшить оценку затрат на 15%.

Первое решение:уменьшение размера продукта (за счет исключения некоторых функций). Нам надо определить размер минимизированного продукта. Будем исходить из того, что затраты должны уменьшиться с 37 до 31,45 чел.-мес. Решим уравнение:

2,5*(НовыйРазмер)^1,16 = 31,45.

Очевидно, что НовыйРазмер = 12,58^1/1,16 = 8,872 [KLOC].

Другие решения:

ü уменьшить требуемую надежность с номинальной до низкой. Это сокращает стоимость проекта на 12% (ЈM_RELY изменяется с 1 до 0,88). Такое решение приведет к увеличению затрат и трудностей при применении и сопровождении;

ü повысить требования к квалификации аналитикой и программистов (с высоких до очень высоких). При этом стоимость проекта уменьшается на 15-19%. Благодаря программисту стоимость может уменьшиться на (1-0,74/0,87)*100%=15%. Благодаря аналитику стоимость может понизиться на (1-0,67/0,83)*100%=19%. Основная трудность — поиск специалистов такого класса (готовых работать за те же деньги);

ü повысить требования к опыту работы с приложением (с номинальных до очень высоких) или требования к опыту работы с платформой (с низких до высоких). Повышение опыта работы с приложением сокращает стоимость проекта на (1-0,81)*100%=19%; повышение опыта работы с платформой сокращает стоимость проекта на (1-0,88/1,12)*100%=21,4%. Основная трудность — поиск экспертов (специалистов такого класса);

ü повысить уровень мультисетевой разработки с низкого до высокого. При этом стоимость проекта уменьшается на (1 - 0,92/1,1)*100%=16,4%;

ü ослабить требования к режиму работы в реальном времени. Предположим, что 70%-ное ограничение по времени выполнения связано с желанием заказчика обеспечить обработку одного сообщения за 2 мс. Если же заказчик согласится на увеличение среднего времени обработки с 2 до 3 мс, то ограничение по времени станет равно (2 мс/3 мс)*70%=47%, в результате чего фактор TIME уменьшится с высокого до номинального, что приведет к экономии затрат на (1-1/1,11)*100%=10%;

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

Дата добавления: 2018-04-05; просмотров: 252; Мы поможем в написании вашей работы!

Поделиться с друзьями:

⇐ Предыдущая 123 Следующая ⇒

Мы поможем в написании ваших работ!