 |
Функционально-ориентированные метрики
|
|
|
|
Функционально-ориентированные метрики косвенно измеряют программный продукт и процесс его разработки. Вместо подсчета LOC – оценки при этом рассматривается не размер, а функциональность или полезность продукта.
Используется 5 информационных характеристик.
1. Количество внешний вводов. Подсчитываются все вводы пользователя, по которым поступают разные прикладные данные. Вводы должны быть отделены от запросов, которые подсчитываются отдельно.
2. Количество внешних выводов. Подсчитываются все выводы, по которым к пользователю поступают результаты, вычисленные программным приложением. В этом контексте выводы означают отчеты, экраны, распечатки, сообщения об ошибках. Индивидуальные единицы данных отчета отдельно не подсчитываются.
3. Количество внешних запросов. Под запросами понимают диалоговый ввод, который приводит к немедленному программному ответу в форме диалогового вывода. При этом диалоговый ввод в приложении не сохраняется, а диалоговый вывод не требует вычислений. Подсчитываются все запросы – каждый учитывается отдельно.
4. Количество внутренних логических файлов. Подсчитываются все логические файлы (т.е. логические группы данных, которые могут быть частью базы данных или отдельным файлом).
5. Количество внешних интерфейсных файлов. Подсчитываются все логические файлы из других приложений, на которые ссылается данное приложение.
Выводы, вводы, запросы относятся к категории транзакция. Транзакция – это элементарный процесс, различаемый пользователем и перемещающий данные между внешней средой и программным приложением. В своей работе транзакции используют внутренние и внешние файлы. Приняты следующие определения.
|
|
|
Внешний ввод – элементарный процесс, перемещающий данные из внешней среды в приложение. Данные могут поступать с экрана ввода или из другого приложения. Данные могут использоваться для обновления внутренних логических файлов. Данные могут содержать как управляющую, так и деловую информацию. Управляющие данные не должны модифицировать внутренний логический файл.
Внешний вывод - элементарный процесс, перемещающий данные, вычисленные в приложении, во внешнюю среду. Кроме того, в этом процессе могут обновляться внутренние логические файлы. Данные создают отчеты или выходные файлы, посылаемые другим приложениям. Отчеты и файлы создаются на основе внутренних логических файлов и внешних интерфейсных файлов. Дополнительно этот процесс может использовать вводимые данные, их образуюткритерии поиска и параметры, не поддерживаемые внутренними логическими файлами. Вводимые данные поступают извне, но носят временный характер и не сохраняются во внутреннем логическом файле.
Внешний запрос – элементарный процесс, работающий как с вводимыми, так и с выводимыми данными. Его результат – данные, возвращаемые из внутренних логических файлов и внешних интерфейсных файлов. Входная часть процесса не модифицирует внутренние логические файлы, а выходная не несет данных, вычисляемых приложением (в этом и состоит отличие запроса от вывода).
Внутренний логический файл – распознаваемая пользователем группа логически связанных данных, которая размещена внутри приложения и обслуживается через внешние вводы.
Внешний интерфейсный файл – распознаваемая пользователем группа логически связанных данных, которая размещена внутри другого приложения и поддерживается им. Внешний файл данного приложения является внутренним логическим файлом в другом приложении.
Каждой из выявленных характеристик ставится в соответствие сложность. Для этого характеристике назначается низкий, средний или высокий ранг, а затем формируется числовая оценка ранга.
|
|
|
Для транзакций ранжирование основано на количестве ссылок и количестве типов элементов данных. Для файлов ранжирование основано на количестве типов-элементов записей и типов элементов данных, входящих в файл.
Тип элемента-записи – подгруппа элементов данных, распознаваемая пользователем в пределах файла.
Тип элемента данных – уникальное не рекурсивное (неповторяемое) поле, распознаваемое пользователем. Примеры элементов данных для различных характеристик приведены в табл.4, 5 и содержат правила учета элементов из графического интерфейса пользователя (ГИП).
Табл.4. Примеры элементов данных
| Информационная характеристика | Элементы данных |
| Внешние вводы | Поля ввода данных, сообщения об ошибках, вычисляемые значения, кнопки |
| Внешние выводы | Поля данных в отчетах, вычисляемые значения, сообщения об ошибках, заголовки столбцов, которые читаются из внутреннего файла |
| Внешние запросы | Вводимые элементы: поле, используемое для списка, щелчок мыши. Выводимые элементы: отображаемые на экране поля. |
Табл.5. Правила учета элементов данных из ГИП
| Элемент данных | Правило учета |
| Группа радиокнопок | Так как в группе пользователь выбирает только одну радиокнопку, все радиокнопки группы считаются одним элементом данных |
| Группа флажков (переключатели) | Так как в группе пользователь может выбрать несколько флажков, каждый флажок считают элементом данных |
| Командные кнопки | Командная кнопка может определять действия добавления, изменения, запроса. Кнопка ОК может вызвать транзакции (различных типов). Кнопка Next может быть входным элементом запроса или вызвать другую транзакцию. Каждая кнопка считается отдельным элементом данных. |
| Списки | Список может быть внешним запросом, но результат запроса может быть элементом данных внешнего вида. |
Например, ГИП для обслуживания клиентов может иметь поля Имя, Адрес, Город, Страна, Почтовый_Индекс, Телефон, Email. Таким образом, имеется 7 полей или семь элементов данных. Восьмым элементом данных может быть командная кнопка (Добавить, Изменить, Удалить). В этом случае каждый из внешних вводов Добавить, Изменить, Удалить будет состоять из 8 элементов данных (7 полей плюс командная кнопка).
|
|
|
Обычно этому экрану ГИП соответствует несколько транзакций. Типичный экран включает несколько внешний запросов, сопровождающих внешний ввод.
Обсудим порядок учета сообщений. В приложении с ГИП генерируются три типа сообщений: сообщение об ошибке, сообщение подтверждения и сообщение уведомления. Сообщения об ошибке (например, «Требуется пароль») и сообщение подтверждения (например, «Вы действительно хотите удалить запись о клиенте?») указывают, что произошла ошибка или что процесс может быть завершен. Эти сообщения не образуют самостоятельного процесса, они являются частью другого процесса, то есть считаются элементом данных соответствующей транзакции.
С другой стороны, уведомление является независимым элементарным процессом. Например, при попытке получить от банкомата сумму денег, превышающую их количество на счете, генерируется сообщение «Не хватает средств для завершения транзакции». Оно является результатом чтения информации из файла счета и формирования заключения. Сообщение уведомления рассматривается как внешний вывод.
Данные для определения ранга и оценки сложности транзакций и файлов приведены в табл.6-10 (числовая оценка указана в круглых скобках). Использовать их очень просто. Например, внешнему вводу, который ссылается на два файла и имеет 7 элементов данных по табл.6 назначается средний ранг и оценка сложности 4.
Табл.6. Ранг и оценка сложности внешних вводов
| Ссылки на файлы | Элементы данных | ||
| 1-4 | 5-15 | >15 | |
| 0-1 | Низкий (3) | Низкий (3) | Средний (4) |
| 2 | Низкий (3) | Средний (4) | Высокий (6) |
| >2 | Средний (4) | Высокий (6) | Высокий (6) |
Табл.7. Ранг и оценка сложности внешних выводов
| Ссылки на файлы | Элементы данных | ||
| 1-4 | 5-19 | >19 | |
| 0-1 | Низкий (4) | Низкий (4) | Средний (5) |
| 2-3 | Низкий (4) | Средний (5) | Высокий (7) |
| >3 | Средний (5) | Высокий (7) | Высокий (7) |
Табл.8. Ранг и оценка сложности внешних запросов
| Ссылки на файлы
| Элементы данных | ||||
| 1-4 | 5-19 | >19 | |||
| 0-1 | Низкий (3) | Низкий (3) | Средний (4) | ||
| 2-3 | Низкий (3) | Средний (4) | Высокий (6) | ||
| >3 | Средний (4) | Высокий (6) | Высокий (6) | ||
Табл.9. Ранг и оценка сложности внутренних логических файлов
| Ссылки на файлы | Элементы данных | ||
| 1-19 | 20-50 | >50 | |
| 0-1 | Низкий (7) | Низкий (7) | Средний (10) |
| 2-5 | Низкий (7) | Средний (10) | Высокий (15) |
| >5 | Средний (10) | Высокий (15) | Высокий (15) |
Табл.10. Ранг и оценка сложности внешних интерфейсных файлов
| Ссылки на файлы | Элементы данных | ||
| 1-19 | 20-50 | >50 | |
| 0-1 | Низкий (5) | Низкий (5) | Средний (7) |
| 2-5 | Низкий (5) | Средний (7) | Высокий (10) |
| >5 | Средний (7) | Высокий (10) | Высокий (10) |
Отметим, что если во внешнем запросе ссылка на файл используется как на этапе ввода, так и на этапе вывода, она учитывается только один раз. Такое же правило распространяется на элемент данных (однократный учет).
После сбора всей необходимой информации приступают к расчетам метрики – количества функциональных указателей FP (Function Points). Автором этой метрики является А. Альбрехт (1979).
Исходные данные для расчета сводятся в табл. 11. В таблицу заносится количественное значение характеристики каждого вида (по всем уровням сложности). Места подстановки значений отмечены прямоугольником (этот символ играет роль метки - заполнителя). Количественные значения характеристик умножаются на числовые оценки сложности. Полученные в каждой строке значения суммируются, давая полное значение для данной характеристики. Эти полные значения суммируются по вертикали, формируя общее количество.
Табл.11. Исходные данные для расчета FP – метрик
| Имя характеристики | Ранг, сложность, количество | |||
| Низкий | Средний | Высокий | Итого | |
| Внешние вводы | *3=_ | *4=_ | *6=_ | = |
| Внешние выводы | *4=_ | *5=_ | *7=_ | = |
| Внешние запросы | *3=_ | *4=_ | *6=_ | = |
| Внутренние логические файлы | *7=_ | *10=_ | *15=_ | = |
| Внешние интерфейсные файлы | *5=_ | *7=_ | *10=_ | = |
| Общее количество | = | |||
Количество функциональных указателей вычисляется по формуле:
FP= Общее количество*(0,65+0,01*SFi), (1)
Где Fi – коэффициент регулировки сложности (I=1..14).
Каждый коэффициент может принимать следующие значения: 0- нет влияния, 1- случайное, 2- небольшое, 3- среднее, 4 – важное, 5 – основное. Значения выбираются эмпирически в результате ответа на 14 вопросов, которые характеризуют системные параметры приложения (табл.12).
После вычисления FP на его основе формируются метрики производительности, качества и другие оценки.
Производительность = ФункцУказатель / Затраты (FP/чел.-мес.);
Качество = Ошибки / ФункцУказатель (Единиц/FP);
Удельная Стоимость = Стоимость / ФункцУказатель (Тыс.$/FP);
|
|
|
Документированность=СтраницДокумента/ФункцУказатель (Страниц/FP)
Табл.12. Определение системных параметров приложения
| № | Системный параметр | Описание |
| 1 | Передачи данных | Сколько средств данных требуется для пердачи или обмена информацией с приложением или системой? |
| 2 | Распределенная обработка данных | Как обрабатываются распределенные данные и функции обработки? |
| 3 | Производительность | Нуждается ли пользователь в фиксации времени ответа или производительности? |
| 4 | Распространенность используемой конфигурации | Насколько распространена текущая аппаратная платформа, на которой будет выполняться приложение? |
| 5 | Скорость транзакций | Как часто выполняются транзакции? (каждый день, каждую неделю, каждый месяц)? |
| 6 | Оперативный ввод данных | Какой процент информации нужно вводить в режиме онлайн? |
| 7 | Эффективность работы конечного пользователя | Приложение проектировалось для обеспечения эффективной работы конечного пользователя? |
| 8 | Оперативное обновление | Как много внутренних файлов обновляется в онлайновой транзакции? |
| 9 | Сложность обработки | Выполняет ли приложение интенсивную логическую или математическую обработку? |
| 10 | Повторная используемость | Приложение разрабатывалось для удовлетворения требований одного или многих пользователей? |
| 11 | Легкость инсталляции | Насколько трудны преобразования и инсталляция приложения? |
| 12 | Легкость эксплуатации | Насколько эффективны и/или автоматизированы процедуры запуска, резервирования и восстановления? |
| 13 | Разнообразные условия размещения | Была ли спроектирована, разработана и поддержана возможность инсталляции приложения в разных местах для различных организаций? |
| 14 | Простота изменений | Была ли спроектирована, разработана и поддержана в приложении простота изменения? |
Область применения функциональных указателей – коммерческие информационные системы. Для продуктов с высокой алгоритмической сложностью используются метрики свойств (Features Points). Они применимы к системному и инженерному ПО, ПО реального времени и встроенному ПО.
Для вычисления указателя свойств добавляется одна характеристика – количество алгоритмов. Алгоритм здесь определяется как ограниченная программа вычислений, которая включается в общую компьютерную программу. Примеры алгоритмов: обработка прерываний, инвертирование матрицы, расшифровка битовой строки. Для формирования указателя свойств составляется табл. 13.
Табл.13. Исходные данные для расчета указателя свойств
| № | Характеристика | Количество | Сложность | Итого |
| 1 | Вводы | | *4 | = |
| 2 | Выводы | | *5 | = |
| 3 | Запросы | | *4 | = |
| 4 | Логические файлы | | *7 | = |
| 5 | Интерфейсные файлы | | *7 | = |
| 6 | Количество алгоритмов | | *3 | = |
| Общее количество | = | |||
После заполнения таблицы по формуле (1) вычисляется значение указателя свойств. Для сложных систем реального времени это значение на 25-30% больше значения, вычисляемого по таблице для количества функциональных указателей.
Достоинства функционально-ориентированных метрик:
· не зависят от языка программирования;
· Легко вычисляются на любой стадии проекта.
Недостаток функционально-ориентированных метрик: результаты основаны на субъективных данных, используются не прямые, а косвенные измерения.
FP – оценки легко пересчитать в LOC – оценки. Как показано в табл.14, результаты пересчета зависят от языка программирования, используемого для реализации ПО.
Табл.14. Пересчет FP – оценок в LOC – оценки
| Язык программирования | Количество операторов на 1 FP |
| Ассемблер | 320 |
| С | 128 |
| Паскаль | 90 |
| С++ | 64 |
| Java | 53 |
| Visual Basic | 32 |
| Visual С++ | 34 |
| Delphi Pascal | 29 |
| HTML 3 | 15 |
| LISP | 64 |
| Prolog | 64 |
ЗАКЛЮЧЕНИЕ
Полное устранение негативных воздействий и дефектов, отражающихся на качестве функционирования сложных ПС, принципиально невозможно. Проблема состоит в выявлении факторов, от которых они зависят, в создании методов и средств уменьшения их влияния на функциональную пригодность ПС, а также в эффективном распределении ограниченных ресурсов для обеспечения необходимого качества функционирования комплекса программ, равнопрочного при всех реальных негативных воздействиях. Комплексное, скоординированное применение этих методов и средств в процессе создания, развития и применения ПС позволяет исключать проявления ряда негативных факторов или значительно ослаблять их влияние. Тем самым уровень достигаемого качества функционирования ПС может быть предсказуемым и управляемым, непосредственно зависящим от ресурсов, выделяемых на его достижение, а главное, от системы качества и эффективности технологии, используемых на всех этапах жизненного цикла ПС.
БИБЛИОГРАФИЯ
1. А.М. Вендров. Проектирование программного обеспечения экономических информационных систем. Учебник. М.: «Финансы и статистика». 2000. - 339 с.
2. А.М. Вендров. Практикум по проектированию программного обеспечения экомических информационных систем. М.: «Финансы и статистика». 2002. -190 с.
3. Практические аспекты информатизации. Стандартизация, сертификация и лицензирование. Справочная книга руководителя. Под редакцией Л.Д. Реймана. М.: 2000. -259с.
4. В.В. Липаев. Качество программных средств. Методические рекомендации. М.: «Янус-К». 2002. – 298с.
5. Боэм Б.У. Инженерное проектирование программного обеспечения: Пер. с англ./Под ред. А.А. Красилова. М.:Радио и связь, 1985.
6. В.В. Липаев, А.И. Потапов. Оценка затрат на разработку программных средств. М.: Финансы и статистика. 1988.
7. С.А. Орлов. Технологии разработки программного обеспечения. Учебник для вузов. М., Санкт-Петербург: «Питер». 2002.
8. Г. Коллинз, Дж. Блей. Структурные методы разработки систем: от стратегического планирования до тестирования. М.: «Статистика», 1980. 260с.:ил.
9. ГОСТ Р ИСО 9127 – 94 «Системы обработки информации. Документация пользователя и информация на упаковке потребительских программных пакетов».
10. ГОСТ 34601 – 90. «Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания».
11. ГОСТ 34601 – 89. «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы».
12. ГОСТ 34601 – 92. «Информационная технология. Виды испытаний автоматизированных систем».
13. Информационные системы в экономике. Под ред. Проф. В.В. Дика. Учебник для вузов, М., «Финансы и статистика». 1996. – 270 с.
ПРИЛОЖЕНИЕ
|
|
|
