Табл.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 | Простота изменений | Была ли спроектирована, разработана и поддержана в приложении простота изменения? |
Область применения функциональных указателей – коммерческие информационные системы. Для продуктов с высокой алгоритмической сложностью используются метрики свойств (FeaturesPoints). Они применимы к системному и инженерному ПО, ПО реального времени и встроенному ПО.
Для вычисления указателя свойств добавляется одна характеристика – количество алгоритмов. Алгоритм здесь определяется как ограниченная программа вычислений, которая включается в общую компьютерную программу. Примеры алгоритмов: обработка прерываний, инвертирование матрицы, расшифровка битовой строки. Для формирования указателя свойств составляется табл. 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 с.
Стандарт фирмы IBM. Проектирование пользовательского интерфейса на персональном компьютере.- Вильнюс, 1992
Стандартизация и согласованность интерфейса экономят время пользователя и разработчика.
Пользовательский интерфейс включает в себя три понятия: общение приложения с пользователем, общение пользователя с приложением, язык общения. Язык общение определяется разработчиком программного приложения. Свойствами интерфейса являются наглядность и конкретность. Наиболее распространенный ранее командный интерфейс имел ряд недостатков (многочисленность команд, отсутствие стандарта для приложения), что ограничивало круг его применения. Для преодоления этих недостатков были предприняты попытки его упростить (например, NC). Однако настоящим решением проблемы стало создание графической оболочки для ОС. В настоящее время практически все распространенные ОС используют для своей работы графический интерфейс. Примером здесь может служить интерфейс, разработанный в исследовательском центре Пало Альто фирмы Xerox для компьютеров Macintosh фирмы Apple. Немного позже была разработана графическая оболочка под названием MicrosoftWindows, реализующая технологию WIMP и удовлетворяющая стандарту CUA. Новшеством были применение мыши, выбор команд из меню, предоставление программам отдельных окон, использование для обозначения программ образов в виде пиктограмм.