Добавлен: 25.10.2018
Просмотров: 6998
Скачиваний: 27
необходимо тестировать при модификациях структуры и содержания данных
в ИБД, от сложности тестов для проверки их характеристик. Ее атрибуты
зависят от четкости формализации в системном проекте правил структурного
построения компонентов и всего комплекса ИБД, от унификации
межмодульных и внешних интерфейсов, от полноты и корректности
технологической документации. Субхарактеристики изменяемость и
тестируемость данных доступны количественному определению по
величине трудоемкости и длительности реализации этих функций при
типовых операциях с данными при применении различных методов и средств
автоматизации.
Мобильность данных БД, так же как для программ, можно
характеризовать в системном проекте в основном длительностью и
трудоемкостью их инсталляции, адаптации и замещаемости при переносе
ИБД на иные аппаратные и операционные платформы. Информация о
процессах, происходящих во внешней среде, может иметь большие объем и
трудоемкость первичного накопления и актуализации, что определяет
необходимость ее тщательного хранения и регламентированного изменения.
Формирование и заполнение информацией баз данных достаточно сложный и
трудоемкий процесс, технико-экономические показатели которого сильно
зависит от структуры, состава, объема, связности и других характеристик
исходной информации. Особенности и трудоемкость переноса ИБД зависят,
прежде всего, от характеристик совместимости архитектуры и содержания
информации переносимой БД между рассматриваемыми платформами:
форматная совместимость характеризуется степенью соответствия
данных в ИБД анализируемых платформ требованиям стандартов на
форматы представления данных для документальных, фактографических,
словарных и иных БД;
лингвистическая
совместимость
определяется
степенью
использования в рассматриваемых ИБД единых лингвистических
средств (классификаторов, рубрикаторов, словарей), формализованных
соответствующими стандартами этих платформ;
физическая совместимость заключается в степени соответствия
кодировки информации БД одинаковым стандартам на машиночитаемые
носители информации.
Так как перенос БД часто обусловлен необходимостью увеличения
ресурсов ЭВМ, доступных для решения новых перспективных задач, их
системный проект становится естественным расширением функций ИБД
относительно исходной версии проекта. Для оценки качества и определения
требований к мобильности ИБД, так же как для ПС, следует решать задачу
сравнения достигаемого эффекта и затрат для методов переноса или
повторной разработки компонентов и наполнения базы данных в конкретных
условиях с учетом всех перечисленных факторов и затрат. Эти задачи
значительно упрощаются при одновременном сокращении затрат при
применении идеологии и концепции открытых компьютерных систем,
поддержанных
комплексом
международных
стандартов,
а
также
современных версий ОС и СУБД, как стандартов де-факто.
МОДЕЛИ ОЦЕНКИ ХАРАКТЕРИСТИК КАЧЕСТВА И
НАДЕЖНОСТИ ПО
Размерно-ориентированные метрики. Функционально- ориентированные
метрики. Пример применения метрик. Достоинства и недостатки размерно –
ориентированных и функционально-ориентированных метрик.
РАЗМЕРНО-ОРИЕНТИРОВАННЫЕ МЕТРИКИ
Размерно-ориентированные метрики прямо измеряют программный
продукт
и
процесс
его
разработки.
Основываются
размерно-
ориентированные метрики на LOC – оценках (Lines Of Code). LOC - оценка –
это количество строк в программном продукте.
Исходные данные для расчета этих метрик сводятся в таблицу (табл.3).
Исходные данные для расчета LOC- метрик
Табл. 3.
Проект Затраты,
чел.-мес.
Стоимость
тыс. $
КLOC,
тыс.
LOC
Страниц Ошибки Количество
человек
А01
24
168
12,1
365
29
3
В02
62
440
27,2
1224
86
5
С03
43
314
20,2
1050
64
6
Таблица содержит данные о проектах за последние несколько лет.
Например, запись о проекте А01 показывает: 12100 строк программы были
разработаны за 24 чел.-мес. И стоили $168 000. Кроме того, по проекту было
разработано 365 страниц документации, а в течение первого года
эксплуатации было зарегистрировано 29 ошибок. Разрабатывали проект три
человека.
На основе таблицы вычисляются размерно-ориентированные метрики
производительности и качества проекта:
Производительность = Длина / Затраты (тыс.LOC/чел.-мес.);
Качество = Ошибки / Длина (Единиц/тыс. LOC);
Удельная стоимость = Стоимость /Длина (тыс.$/LOC);
Документированность = Страниц_Документа / Длина (Страниц/тыс.LOC)
Достоинства размерно-ориентированных метрик:
широко распространены;
просты и легко вычисляются.
Недостатки размерно-ориентированных метрик:
зависимы от языка программирования;
требуют исходных данных, которые трудно получить на начальной
стадии проекта;
не приспособлены к непроцедурным языкам программирования.
ФУНКЦИОНАЛЬНО-ОРИЕНТИРОВАННЫЕ МЕТРИКИ
Функционально-ориентированные
метрики
косвенно
измеряют
программный продукт и процесс его разработки. Вместо подсчета LOC –
оценки при этом рассматривается не размер, а функциональность или
полезность продукта.
Используется 5 информационных характеристик.
1. Количество
внешний вводов. Подсчитываются все вводы
пользователя, по которым поступают разные прикладные данные. Вводы
должны быть отделены от запросов, которые подсчитываются отдельно.
2. Количество внешних выводов. Подсчитываются все выводы, по
которым к пользователю поступают результаты, вычисленные программным
приложением. В этом контексте выводы означают отчеты, экраны,
распечатки, сообщения об ошибках. Индивидуальные единицы данных
отчета отдельно не подсчитываются.
3. Количество
внешних запросов. Под запросами понимают
диалоговый ввод, который приводит к немедленному программному ответу
в форме диалогового вывода. При этом диалоговый ввод в приложении не
сохраняется, а диалоговый вывод не требует вычислений. Подсчитываются
все запросы – каждый учитывается отдельно.
4. Количество внутренних логических файлов. Подсчитываются все
логические файлы (т.е. логические группы данных, которые могут быть
частью базы данных или отдельным файлом).
5. Количество внешних интерфейсных файлов. Подсчитываются все
логические файлы из других приложений, на которые ссылается данное
приложение.
Выводы, вводы, запросы относятся к категории транзакция. Транзакция
– это элементарный процесс, различаемый пользователем и перемещающий
данные между внешней средой и программным приложением. В своей работе
транзакции используют внутренние и внешние файлы. Приняты следующие
определения.
Внешний ввод – элементарный процесс, перемещающий данные из
внешней среды в приложение. Данные могут поступать с экрана ввода или из
другого приложения. Данные могут использоваться для обновления
внутренних логических файлов. Данные могут содержать как управляющую,
так и деловую информацию. Управляющие данные не должны
модифицировать внутренний логический файл.
Внешний вывод - элементарный процесс, перемещающий данные,
вычисленные в приложении, во внешнюю среду. Кроме того, в этом процессе
могут обновляться внутренние логические файлы. Данные создают отчеты
или выходные файлы, посылаемые другим приложениям. Отчеты и файлы
создаются на основе внутренних логических файлов и внешних
интерфейсных файлов. Дополнительно этот процесс может использовать
вводимые данные, их образуют критерии поиска и параметры, не
поддерживаемые внутренними логическими файлами. Вводимые данные
поступают извне, но носят временный характер и не сохраняются во
внутреннем логическом файле.
Внешний запрос – элементарный процесс, работающий как с
вводимыми, так и с выводимыми данными. Его результат – данные,
возвращаемые из внутренних логических файлов и внешних интерфейсных
файлов. Входная часть процесса не модифицирует внутренние логические
файлы, а выходная не несет данных, вычисляемых приложением (в этом и
состоит отличие запроса от вывода).
Внутренний логический файл – распознаваемая пользователем группа
логически связанных данных, которая размещена внутри приложения и
обслуживается через внешние вводы.
Внешний интерфейсный файл – распознаваемая пользователем группа
логически связанных данных, которая размещена внутри другого
приложения и поддерживается им. Внешний файл данного приложения
является внутренним логическим файлом в другом приложении.
Каждой из выявленных характеристик ставится в соответствие
сложность. Для этого характеристике назначается низкий, средний или
высокий ранг, а затем формируется числовая оценка ранга.
Для транзакций ранжирование основано на количестве ссылок и
количестве типов элементов данных. Для файлов ранжирование основано на
количестве типов-элементов записей и типов элементов данных, входящих в
файл.
Тип элемента-записи – подгруппа элементов данных, распознаваемая
пользователем в пределах файла.
Тип элемента данных – уникальное не рекурсивное (неповторяемое)
поле, распознаваемое пользователем. Примеры элементов данных для
различных характеристик приведены в табл.4, 5 и содержат правила учета
элементов из графического интерфейса пользователя (ГИП).
Примеры элементов данных
Табл.4.
Информационная
характеристика
Элементы данных
Внешние вводы
Поля ввода данных, сообщения об ошибках,
вычисляемые значения, кнопки
Внешние выводы Поля данных в отчетах, вычисляемые значения,
сообщения об ошибках, заголовки столбцов, которые
читаются из внутреннего файла
Внешние
запросы
Вводимые элементы: поле, используемое для списка,
щелчок мыши.
Выводимые элементы: отображаемые на экране поля.
Правила учета элементов данных из ГИП
Табл.5.
Элемент данных
Правило учета
Группа
радиокнопок
Так как в группе пользователь выбирает только одну
радиокнопку, все радиокнопки группы считаются
одним элементом данных
Группа флажков
(переключатели)
Так как в группе пользователь может выбрать
несколько флажков, каждый флажок считают
элементом данных
Командные
кнопки
Командная кнопка может определять действия
добавления, изменения, запроса. Кнопка ОК может
вызвать транзакции (различных типов). Кнопка Next
может быть входным элементом запроса или вызвать
другую транзакцию. Каждая кнопка считается
отдельным элементом данных.
Списки
Список может быть внешним запросом, но результат
запроса может быть элементом данных внешнего вида.
Например, ГИП для обслуживания клиентов может иметь поля Имя,
Адрес, Город, Страна, Почтовый_Индекс, Телефон, Email. Таким образом,
имеется 7 полей или семь элементов данных. Восьмым элементом данных
может быть командная кнопка (Добавить, Изменить, Удалить). В этом случае
каждый из внешних вводов Добавить, Изменить, Удалить будет состоять из 8
элементов данных (7 полей плюс командная кнопка).
Обычно этому экрану ГИП соответствует несколько транзакций.
Типичный экран включает несколько внешний запросов, сопровождающих
внешний ввод.
Обсудим порядок учета сообщений. В приложении с ГИП генерируются
три типа сообщений: сообщение об ошибке, сообщение подтверждения и
сообщение уведомления. Сообщения об ошибке (например, «Требуется
пароль») и сообщение подтверждения (например, «Вы действительно хотите
удалить запись о клиенте?») указывают, что произошла ошибка или что
процесс
может
быть
завершен.
Эти
сообщения
не
образуют
самостоятельного процесса, они являются частью другого процесса, то есть
считаются элементом данных соответствующей транзакции.
С другой стороны, уведомление является независимым элементарным
процессом. Например, при попытке получить от банкомата сумму денег,