Файл: Инфрам.pdf

320
Командные кнопки
Списки
Командная кнопка может определять действие добавле- ния, изменения, запроса. Кнопка ОК может вызывать транзакции (различных типов). Кнопка Next может быть входным элементом запроса или вызывать другую тран- закцию. Каждая кнопка считается отдельным элементом данных
Список может быть внешним запросом, но результат запроса может быть элементом данных внешнего ввода
Например, GUI для обслуживания клиентов может иметь поля Имя,
Адрес, Город, Страна, Почтовый Индекс, Телефон, Email. Таким обра- зом, имеется 7 полей или семь элементов данных. Восьмым элементом данных может быть командная кнопка (добавить, изменить, удалить). В этом случае каждый из внешних вводов Добавить, Изменить, Удалить будет состоять из 8 элементов данных (7 полей плюс командная кноп- ка). Обычно одному экрану GUI соответствует несколько транзакций.
Типичный экран включает несколько внешних запросов, сопровождаю- щих внешний ввод.
Обсудим порядок учета сообщений. В приложении с GUI генериру- ются 3 типа сообщений: сообщения об ошибке, сообщения подтвержде- ния и сообщения уведомления. Сообщения об ошибке (например, Тре- буется пароль) и сообщения подтверждения (например, Вы действи- тельно хотите удалить клиента?) указывают, что произошла ошибка или что процесс может быть завершен. Эти сообщения не образуют само- стоятельного процесса, они являются частью другого процесса, то есть считаются элементом данных соответствующей транзакции.
С другой стороны, уведомление является независимым элементар- ным процессом. Например, при попытке получить из банкомата сумму денег, превышающую их количество на счете, генерируется сообщение
Не хватает средств для завершения транзакции. Оно является результа- том чтения информации из файла счета и формирования заключения.
Сообщение уведомления рассматривается как внешний вывод.
Данные для определения ранга и оценки сложности транзакций и файлов приведены в табл. 7.4 - 7.8 (числовая оценка указана в круглых скобках). Использовать их очень просто. Например, внешнему вводу, который ссылается на 2 файла и имеет 7 элементов данных, по табл. 7.4 назначается средний ранг и оценка сложности 4.
Таблица 7.4
Данные (до 15 элементов) для определения ранга и оценки
сложности транзакций и файлов
Ссылки
на
файлы
Элементы данных
1-4 5-15
>15 0-1 2
>2
Низкий (3)
Низкий (3)
Средний (4)
Низкий (3)
Средний (4)
Высокий (6)
Средний (4)
Высокий (6)
Высокий (6)

321
Таблица 7.5
Данные (до 19 элементов) для определения ранга и оценки
сложности транзакций и файлов
Ссылки
на
файлы
Элементы данных
1-4 5-19
>19 0-1 2-3
>3
Низкий (4)
Низкий (4)
Средний (5)
Низкий (4)
Средний (5)
Высокий (7)
Средний (5)
Высокий (7)
Высокий (7)
Таблица 7.6
Данные (до 19 и более элементов) для определения ранга и оценки
сложности транзакций и файлов
Ссылки
на
файлы
Элементы данных
1-4 5-19
>19 0-1 2-3
>3
Низкий (3)
Низкий (3)
Средний (4)
Низкий (3)
Средний (4)
Высокий (6)
Средний (4)
Высокий (6)
Высокий (6)
Таблица 7.7
Данные (до 50 элементов) для определения ранга и оценки
сложности транзакций и файлов
Типы
эле-
ментов-
записей
Элементы данных
1-19 20-50
>50 1
2-5
>5
Низкий (7)
Низкий (7)
Средний (10)
Низкий (7)
Средний (10)
Высокий (15)
Средний (10)
Высокий (15)
Высокий (15)
Таблица 7.8
Данные (до 50 и более элементов) для определения ранга и оценки
сложности транзакций и файлов
Типы
эле-
ментов-
записей
Элементы данных
1-19 20-50
>50 1
2-5
>5
Низкий (5)
Низкий (5)
Средний (7)
Низкий (5)
Средний (7)
Высокий (10)
Средний (7)
Высокий (10)
Высокий (10)

322
Отметим, что если во внешнем запросе ссылка на файл используется как на этапе ввода, так и на этапе вывода, она учитывается только один раз. Такое же правило распространяется и на элемент данных (одно- кратный учет).
После сбора всей необходимой информации приступают к расчету метрики – количества функциональных указателей FP (Function Points).
Автором этой метрики является А. Албрехт (1979) [2].
Исходные данные для расчета сводятся в табл. 7.9.
Таблица 7.9
Исходные данные для расчета функциональных указателей
Имя характеристики
Ранг, сложность, количество
Низкий
Средний
Высокий
Итого
Внешние вводы
0x3 = __
0x4 = __
0x6 = __
= 0
Внешние выводы
0x4 = __
0x5 = __
0x7 = __
= 0
Внешние запросы
0х3 = __
0x4 = __
0x6 = __
= 0
Внутренние логиче- ские файлы
Внешние интерфейс- ные файлы
0x7 = __
0x5 = __
0x 10= __
0x7 = __
0x15 = __
0x10 = __
= 0
= 0
Общее количество
= 0
В таблицу заносится количественное значение характеристики каж- дого вида (по всем уровням сложности). Места подстановки значений отмечены прямоугольниками (прямоугольник играет роль метки- заполнителя). Количественные значения характеристик умножаются на числовые оценки сложности. Полученные в каждой строке значения суммируются, давая полное значение для данной характеристики. Эти полные значения затем суммируются по вертикали, формируя общее количество. Количество функциональных указателей вычисляется по формуле
FP = Общее количество х (0,65+ 0,01 x
14 1
i
i
F
), (7.1) где F
i
– коэффициенты регулировки сложности.
Каждый коэффициент может принимать следующие значения: 0 – нет влияния, 1 – случайное, 2 – небольшое, 3 – среднее, 4 – важное, 5 – основное. Значения выбираются эмпирически в результате ответа на 14 вопросов, которые характеризуют системные параметры приложения
(табл. 7.10).
Таблица 7.10
Данные для выбора значений
коэффициенты регулировки сложности
№ Системный параметр
Описание

323 1 Передачи данных
Сколько средств связи требуется для передачи или обмена информацией с приложением или системой?
2 Распределенная обра- ботка данных
Как обрабатываются распределенные данные и функции обработки?
3 Производительность
Нуждается ли пользователь в фиксации времени ответа или производительности?
4 Распространенность используемой конфигу- рации
Насколько распространена текущая аппаратная платформа, на которой будет выполняться при- ложение?
5 Скорость транзакций
Как часто выполняются транзакции? (каждый день, каждую неделю, каждый месяц)
6 Оперативный ввод дан- ных
Какой процент информации надо вводить в режиме онлайн?
7 Эффективность работы конечного пользователя
Приложение проектировалось для обеспечения эффективной работы конечного пользователя?
8 Оперативное обновле- ние
Как много внутренних файлов обновляется в онлайновой транзакции?
9 Сложность обработки
Выполняет ли приложение интенсивную логи- ческую или математическую обработку?
10 Повторная используе- мость
Приложение разрабатывалось для удовлетворе- ния требований одного или многих пользовате- лей?
11 Легкость инсталляции
Насколько трудны преобразование и инсталля- ция приложения?
12 Легкость эксплуатации Насколько эффективны и/или автоматизирова- ны процедуры запуска, резервирования и вос- становления?
13 Разнообразные условия размещения
Была ли спроектирована, разработана и под- держана возможность инсталляции приложения в разных местах для различных организаций?
14 Простота изменений
Была ли спроектирована, разработана и под- держана в приложении простота изменений?
После вычисления FP на его основе формируются метрики произво- дительности, качества и т. д.:
Производительность = Функц.Указатель/Затраты [FP/чел.-мес];
Качество = Ошибки/Функц.Указатель [Единиц/ FP];
Удельная стоимость = Стоимость/Функц.Указатель [Тыс.$/ FP];
Документированность
=
СтраницДокумента/Функц.Указатель
[Страниц/FP].
Область применения метода функциональных указателей – коммер- ческие информационные системы. Для продуктов с высокой алгоритми- ческой сложностью используются метрики указателей свойств (Features
Points). Они применимы к системному и инженерному ПО, а также ПО реального времени и встроенному ПО.

324
Для вычисления указателя свойств добавляется одна характеристика
– количество алгоритмов. Алгоритм здесь определяется как ограничен- ная подпрограмма вычислений, которая включается в общую компью- терную программу. Примеры алгоритмов: обработка прерываний, ин- вертирование матрицы, расшифровка битовой строки. Для формирова- ния указателя свойств составляется табл. 7.11.
Таблица 7.11

325
Java
53
Ada 95 49
Visual Basic
32
Visual C++
34
Delphi Pascal
29
Smalltalk
22
Perl
21
HTML3 15
LISP
64
Prolog
64
Miranda
40
Haskell
38
7.4. Выполнение оценки проекта
7.4.1. Оценка на основе LOC- и FP-метрик
Процесс руководства программным проектом начинается с множест- ва действий, объединяемых общим названием планирование проекта.
Первое из этих действий – выполнение оценки. Оно закладывает фун- дамент для других действий по планированию проекта. При оценке про- екта чрезвычайно высока цена ошибок. Очень важно провести оценку с минимальным риском. Цель этой деятельности – сформировать предва- рительные оценки, которые позволят: предъявить заказчику корректные требования по стоимости и затра- там на разработку программного продукта; составить план программного проекта.
При выполнении оценки возможны два варианта использования
LOC- и FP-данных: в качестве оценочных переменных, определяющих размер каждого элемента продукта; в качестве метрик, собранных за прошлые проекты и входящих в метрический базис фирмы.
Рассмотрим шаги процесса оценки.
Шаг 1. Область назначения проектируемого продукта разбивается на ряд функций, каждую из которых можно оценить индивидуально:
f
1
, f
2
,…,f
n
.
Шаг 2. Для каждой функции f
i
, планировщик формирует лучшую
LOC
лучшi
(FР
лучшi
), худшую LOC
худшi
(FР
худшi
) и вероятную оценку
LOC
вероятнi
(FР
вероятнi
). Используются опытные данные (из метрического базиса) или интуиция. Диапазон значения оценок соответствует степени предусмотренной неопределенности.

326
Шаг 3. Для каждой функции в соответствии с ß - распределением вычисляется ожидаемое значение LOC- (или FP-) оценки:
LOC
ожi
=(LOC
лучшi
+ LOC
худшi
+ 4 x LOC
вероятнi
)/ 6.
Шаг 4. Определяется значение LOC- или FP-производительности разработки функции.
Используется один из трех подходов:
1) для всех функций принимается одна и та же метрика средней про- изводительности ПРОИЗВ
ср
, взятая из метрического базиса;
2) для i-й функции на основе метрики средней производительности вычисляется настраиваемая величина производительности:
ПРОИЗВ
i
=ПРОИЗВ
ср х (LOC
ср
/LOC
ожi
), где LOC
cp
– средняя LOC-оценка, взятая из метрического базиса (со- ответствует средней производительности);
3) для i-й функции настраиваемая величина производительности вы- числяется по аналогу, взятому из метрического базиса:
ПРОИЗВ
i
=ПРОИЗВ
анi х(LOC
анi
/LOC
ожi
).
Первый подход обеспечивает минимальную точность (при макси- мальной простоте вычислений), а третий подход – максимальную точ- ность (при максимальной сложности вычислений).
Шаг 5. Вычисляется общая оценка затрат на проект: для первого подхода
;
мес
- чел.
ПРОИЗВ
/
)
LOC
(
ЗАТРАТЫ
1
ср ож
n
i
i
для второго и третьего подходов мес
- чел.
)
ПРОИЗВ
/
(LOC
ЗАТРАТЫ
1
ож
n
i
i
i
Шаг 6. Вычисляется общая оценка стоимости проекта: для первого и второго подходов ср
1
ож
ТЬ
УД_СТОИМОС
)
LOC
(
СТОИМОСТЬ
n
i
i
где УД_СТОИМОСТЬ
ср
— метрика средней стоимости одной стро- ки, взятая из метрического базиса. для третьего подхода
),
ТЬ
УД_СТОИМОС
(LOC
СТОИМОСТЬ
ан
1
ож
i
n
i
i
где УД_СТОИМОСТЬ
анi
– метрика стоимости одной строки аналога, взятая из метрического базиса. Пример применения данного процесса оценки приведем ниже.
7.4.2. Оценка по конструктивной модели стоимости
В данной модели для вывода формул использовался статистический подход – учитывались реальные результаты огромного количества про-

327 ектов. Автор оригинальной модели – Барри Боэм (1981) – дал ей назва- ние СОСОМО 81 (Constructive Cost Model) и ввел в ее состав три разные по сложности статистические подмодели [8].
Иерархию подмоделей Боэма (версии 1981 года) образуют: базисная СОСОМО – статическая модель, вычисляет затраты разра- ботки и ее стоимость как функцию размера программы; промежуточная СОСОМО – дополнительно учитывает атрибуты стоимости, включающие основные оценки продукта, аппаратуры, персонала и проектной среды; усовершенствованная СОСОМО – объединяет все характеристики промежуточной модели, дополнительно учитывает влияние всех ат- рибутов стоимости на каждый этап процесса разработки ПО (анализ, проектирование, кодирование, тестирование и т. д.).
Подмодели СОСОМО 81 могут применяться к трем типам про- граммных проектов. По терминологии Боэма, их образуют: распространенный тип – небольшие программные проекты, над ко- торыми работает небольшая группа разработчиков с хорошим ста- жем работы, устанавливаются мягкие требования к проекту; полунезависимый тип – средний по размеру проект, выполняется группой разработчиков с разным опытом, устанавливаются как мяг- кие, так и жесткие требования к проекту; встроенный тип – программный проект разрабатывается в условиях жестких аппаратных, программных и вычислительных ограничений.
Уравнения базовой подмодели имеют вид
Е=а
b
x (KLOC)
b
b
[чел-мес];
D = c
b
x (E)
b
d
[мес], где Е – затраты в человеко-месяцах, D – время разработки, KLOC — количество строк в программном продукте.
Коэффициенты а
b
, b
b
, с
b
, d
b
берутся из табл. 7.13.
Таблица 7.13
Значения коэффициентов в
подмодели
СОСОМО 81
Тип проекта
а
b
b
b
с
b
d
b
Распространенный
2,4 1,05 2,5 0,38
Полунезависимый
3,0 1,12 2,5 0,35
Встроенный
3,6 1,20 2,5 0,32
В 1995 году Боэм ввел более совершенную модель СОСОМО II, ори- ентированную на применение в программной инженерии XXI века [19].
В состав СОСОМО II входят: модель композиции приложения; модель раннего этапа проектирования;