Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
Лабораторная работа
Разработка метрик для оценки человеко-машинных интерфейсов программно-технических комплексов
Цель. Получить навыки по разработке метрик для моделей качества интерфейсов пользователя программных систем
Теоретическая часть
1. Метрики качества программных систем
1.1. Метрика как основа измерения
Атрибуты (характеристики) программной системы, характеризующие ее качество, измеряются с использованием метрик качества.
Метрика – это комбинация конкретного метода измерения (способа получения значений) атрибута сущности и шкалы измерения (средства, используемого для структурирования получаемых значений).
Метрика определяет (вычисляет) меру атрибута – переменную, которой присваивается значение в результате измерения.
Мера атрибута может быть непосредственной, если она не зависит от мер других атрибутов, либо косвенной, полученной по мерам других атрибутов.
По определению стандарта ISO/IEC 9126-2 метрика качества программной системы представляет собой «модель измерения атрибута, связываемого с характеристикой качества ПС. Служит индикатором одного или многих атрибутов. Ее можно увидеть, например, в левой части большинства уравнений X = A*B, где X имеет не ту же шкалу, что A или B».
Метрика называется базовой, если в ее основе лежит элементарный метод (примитив) измерения атрибута. По определению того же стандарта «базовая метрика сама по себе не является индикатором характеристики или подхарактеристики качества. Ее можно увидеть, например, в правой части большинства уравнений X =A*B. А и В – базовые метрики». То есть базовые метрики используются только в составе модели измерения атрибута.
Для того чтобы правильно пользоваться результатами измерений, для каждой меры нужно идентифицировать шкалу измерения.
Стандарт ISO/IEC 9126-2 рекомендует применять 5 видов шкалы измерения значений (упорядоченных от менее строгих к более строгим):
· номинальная шкала. Это классификационная шкала, выполняющая категоризацию свойств оцениваемого объекта. Категории не упорядочены. Например, дефекты могут классифицироваться на дефекты интерфейса, логики, объявления данных и др. Языки – Fortran, С++, Java и др.;
· порядковая шкала. Позволяет упорядочивать характеристики по возрастанию или убыванию путем сравнения их с базовыми значениями. Например, для уровня серьезности последствий события шкала может включать значения «низкий», «средний», «высокий», «критический». Для уровней СММ – 1, 2, 3, 4, 5. Расстояние между значениями по шкале не играет роли. Характеристики, имеющие номинальную или порядковую шкалу измерения, называются качественными (или категорийными). Все остальные - количественными.
· интервальная шкала. Отмечает существенные различия свойств объекта, «дистанцию» между ними (например, календарные даты или значения плотности дефектов - 1.5 дефекта/KSLOC, 3.5 дефекта/KSLOC и т.д.). Используется в арифметических операциях и операциях сравнения (в данном примере разница равна 2 дефекта/KSLOC). Нулевое значение не допустимо;
· относительная шкала. Значения по этой шкале различаются по отношению к выбранной единице (например, времени, изменяющемся от 0 до бесконечности, или стоимости). Применяя эту шкалу можно рассчитать, например, время между отказами, размер программного компонента в SLOC и др. Считается наиболее предпочтительной шкалой измерений. Позволяет применять широкий спектр инструментов измерения (гистограмм, диаграмм Парето и др.);
· абсолютная шкала. Это специальный случай относительной шкалы. В
этой шкале указывается абсолютное значение величины. Например: «размер программы равен 2К», «число обнаруженных ошибок равно 20».
Измеренное значение метрики само по себе не несет информации об уровне удовлетворения требований к качеству. Для этих целей шкала должна быть разделена на области (ранги), соответствующие различным степеням удовлетворения требований. Примеры деления шкалы:
· деление значений по двум категориям - удовлетворительные и неудовлетворительные значения;
· деление шкалы по четырем категориям, ограниченным тремя уровнями значений - текущим, худшим и плановым (рисунок 1).
Рис. 1. Уровни ранжирования метрик
По мере накопления практики измерений и знаний об измеряемых атрибутах шкалы их измерения могут эволюционировать от менее информативных (номинальной и порядковой) к более информативным (относительной или абсолютной).
1.2. Классификация мер качества
Для разработки процедур сбора данных, интерпретации мер и их нормализации с целью сравнения, нужно различать следующие типы мер, определяемых метриками.
· меры размера. Представляют размер ПС в разных единицах измерения, например:
– функциональный размер (учет функциональных возможностей ПС. Значение представлено в условных единицах функциональности (глава 8));
– размер программы (учет числа строк исходного кода, количества модулей, количества операторов на языке программирования,);
– объем ресурсов, используемых работающей программой (учет объема оперативной памяти, дисковой памяти или сетевого трафика, загруженности процессора - количества обрабатываемых инструкций в секунду и др.);
· меры времени. Представляют периоды реального времени (в секундах,
минутах или часах), процессорного времени (в секундах, минутах или часах работы процессора) или календарного времени (в рабочих часах, календарных днях, месяцах, годах), например:
– время функционирования системы с непрерывной или дискретной работой компонентов программного обеспечения (учет истекшего времени (при работе программного обеспечения в системе в течение установленного периода времени), учет времени с момента включения (при непрерывном использовании встроенного программного обеспечения системы реального времени), учет нормализованного времени (при совместной работе нескольких компьютеров, обменивающихся данными);
– время выполнения (время, необходимое работающему программному компоненту системы для завершения решения определенной задачи в определенных условиях);
– время использования (время, затрачиваемое определенным пользователем на решение задач с помощью ПС), например: время сеанса работы (от начала до завершения), время решения задачи и др.;
· меры усилий. Представляют полезное (продуктивное) время, связанное с определенной задачей проекта, например:
– производительность труда (при индивидуальной работе);
– трудоемкость (при коллективной работе);
· меры интервалов между событиями. Представляют интервалы времени между наступлением событий, происходящих в определенный период наблюдения, например, время между последовательными отказами. Вместо этой меры может использоваться частота наступления событий;
· счетные меры. Представляют собой статические счетчики (для учета определенных элементов в рабочих продуктах ПС (документах)) или кинетические (динамические) счетчики (для учета событий или действий человека), например:
– количество обнаруженных ошибок (учет ошибок в ходе инспекции, тестирования, функционирования или сопровождения ПС);
– структурная сложность программы (количество путей в программе, цикломатическая сложность и др.);
– число несовместимых элементов (учет ошибок согласования (требований, стандартов, форматов и др.), учет ответов типа «да»/«нет» в вопросниках);
– число изменений (учет элементов конфигурации, в которых произошли изменения):
– число обнаруженных отказов (учет отказов при тестировании, функционировании или сопровождении ПС);
– число попыток (учет попыток корректировки дефектов или ошибок);
– эргономические счетчики – число нажатий клавиш, щелчков на кнопках и др.
– счетчики-оценки (-очки, -баллы) (учет результатов, представленных в вопросниках, контрольных листах и др.).
При выполнении измерений базовые меры размера, времени и счета могут использоваться в различных комбинациях. Они служат основой для нормализации и обеспечивают возможность сопоставления метрик. Примеры стилей композиции мер представлены в таблице 1.
Таблица.1 Стили композиции мер
|
Стиль композиции мер |
Описание |
Примеры |
|
Стиль нормализации по размеру |
||
|
(Время)/ (Размер) |
Подходит для представления временной эффективности или производственных усилий на единицу размера |
· Время выполнения на инст- рукцию исходного кода · Время исправления на инст- рукцию исходного кода |
|
(Количество) / (Размер) |
Подходит для представления плотности |
· Плотность ошибок · Тестовое покрытие |
|
(Размер) / (Размер) |
Подходит для представления отношения размера определен- ного фрагмента к размеру цело- го |
· Цикломатическое число мо- дуля · Процентиль2 объема модулей, предрасположенных к ошибкам, к общему объему |
|
Стиль нормализации по времени |
||
|
(Размер) / (Время) |
Подходит для представления трендов величин во времени |
· Число строк разработанного кода в месяц |
|
(Количество) / (Время) |
Подходит для представления частоты в единицу времени |
· Число транзакций в секунду · Число измененных инструкций исходного кода в месяц |
|
(Время) / (Время) |
Подходит для представления отношения времени наблюдае- мых событий к общему времени наблюдения |
· Отношение полезного времени работы ко времени функ- ционирования системы |
|
Стиль нормализации по количеству |
||
|
(Размер) / (Количество) |
Подходит для представления сферы охвата (диапазона изме- нений) |
· Среднее покрытие тестами выполняемых инструкций про- граммы |
|
(Время) / (Количество) |
Подходит для представления интервала времени |
· Среднее время между отка- зами · Среднее время исправления одной ошибки |
|
(Количество) / (Количество) |
Подходит для представления отношения числа определенных событий к их общему числу |
· Число успешных попыток пользователя выполнить дейст- вие к общему числу попыток |
1.3. Классификация метрик качества
Для удобства применения общих приемов измерений метрики обычно классифицируют как:
· объективные/субъективные. Объективные метрики включают подсчеты элементов, которые могут быть независимо проверены (число строк кода, число ошибок, сложность и др.). Они снижают влияние личного мнения на вычисление и анализ метрик. Субъективные метрики основываются на индивидуальном или коллективном понимании или предпочтении определенных характеристик или условий (уровень сложности проблем, стоимостные коэффициенты и др.);
· примитивные/вычисляемые. Примитивные (базовые) метрики можно непосредственно наблюдать (размер программы в KSLOC, число дефектов, найденных при тестировании и др.). Вычисляемые метрики не могут непосредственно наблюдаться, но могут вычисляться по примитивным метрикам (число дефектов, приходящихся на SLOC, трудоемкость и др.);
· динамические/статические. Динамическим метрикам свойственен компонент времени. Значения изменяются с течением времени, начиная с момента сбора данных (например, число ошибок в месяц). Статические метрики инвариантны ко времени (число обнаруженных дефектов, общая трудоемкость работ и др.);
· предсказывающие/объясняющие. Значения предсказывающих (прогнозирующих метрик) могут быть получены заранее (например, оцениваемая интенсивность отказов). Значения объясняющих метрик появляются постфактум (реальная интенсивность отказов).
По отношению к виду объекта измерения (работающая программа или совокупность документов) меры и соответствующие метрики подразделяются на внешние, внутренние и метрики использования ПС.
Внешние метрики используют меры работающего на компьютере программного продукта, полученные в результате измерения его поведения в ходе тестирования и функционирования.
Внешние метрики разрабатываются с целью:
· демонстрации качества программного продукта, представленного характеристиками и подхарактеристиками качества, на стадии тестирования и эксплуатации;
· использования для подтверждения (валидации) того, что программный продукт удовлетворяет внешним требованиям к качеству;
· предсказания реального эксплуатационного качества;
· определения степени, в которой программный продукт будет удовлетворять установленным и предполагаемым требованиям пользователей в ходе реальной эксплуатации.
Можно сказать, что совокупность внешних метрик предназначена для оценивания внешнего качества - степени, в которой продукт удовлетворяет установленным (заявленным) и подразумеваемым потребностям при использовании в определенных условиях.
Разработка внешних метрик основывается на выполнении следующих измерений:
· поведения программного продукта при тестировании и функционировании в сочетании с другими программными продуктами, аппаратным обеспечением или системой обработки информации в целом;
· поведения пользователя (сценариев использования ПС).
Под измерением (оценкой) поведения понимается оценка масштабов возможных последствий неадекватного поведения, которые угрожают жизни или здоровью людей, природным ресурсам, могут привести к разрушению данных, несогласованности или недостоверности информации, потере безопасности, деградации сервиса (услуг), экономическим потерям и др.
Примерами внешних метрик для такой характеристики качества как надеж-
ность, могут быть среднее время между отказами, число устраненных дефектов при тестировании, интенсивность отказов и др.
Внутренние метрики обеспечивают возможность пользователям, разработчикам, тестировщикам и менеджерам оценивать качество промежуточных и конечных продуктов ПС непосредственно по их свойствам, без выполнения на компьютере.
Внутренние метрики разрабатываются таким образом, чтобы они могли:
· представлять (отражать) качество не выполняющихся на компьютере
промежуточных и конечных программных продуктов по тем характеристикам и подхарактеристикам качества, которые определены в модели качества ПС;
· служить руководством к действию при планировании и улучшении процессов, которые воздействуют на промежуточные и конечные продукты;
· использоваться при верификации того, что промежуточные и конечные продукты удовлетворяют требованиям к внутреннему качеству ПС, предусмотренным планами совершенствования процессов;
· предсказывать внешние метрики качества.
Можно сказать, что совокупность внутренних метрик предназначена для оценивания внутреннего качества - множества атрибутов продукта, которое определяет его способность удовлетворять установленным или реальным потребностям при использовании в определенных условиях.
Разработка внутренних метрик основывается на выполнении измерений статических атрибутов, которые определены и могут быть оценены по тексту исходного кода, графическому или табличному представлению потоков управления и данных, структур перехода состояний или по документам ПС.
Примерами внутренних метрик для надежности могут быть число ошибок,
найденных при инспекции кода, число устраненных дефектов в результате инспекции кода, прогнозируемое число оставшихся ошибок и др.
Метрики качества в использовании (метрики эксплуатационного качества) измеряют степень, в которой программный продукт, установленный и эксплуатируемый в определенной среде, удовлетворяет потребности пользователей в эффективном, продуктивном и безопасном решении задач.
Метрики качества в использовании помогают оценить не свойства самой ПС, а видимые результаты ее эксплуатации - эксплуатационное качество.
Очевидно, что для правильного измерения эксплуатационного качества важно учитывать контекст применения ПС – особенности категорий ее пользователей, специфику решаемых ими задач, а также физические и социальные факторы среды их работы.
Примерами эксплуатационных метрик качества могут быть точность и полнота достижения целей пользователей, производительность труда, ресурсы, потраченные в связи с достижением эффективного решения задач, мнение пользователей относительно свойств ПС и др.
Внутренние, внешние и эксплуатационные метрики качества взаимосвязаны. Достижение эксплуатационного качества зависит от удовлетворения критериев внешнего качества, основанных на внешних мерах и метриках качества, которые, в свою очередь, зависят от удовлетворения соответствующих критериев внутреннего качества, основанных на внутренних мерах и метриках, связанных с внешними.
Обычно требования пользователей к качеству специфицируются с помощью внешних метрик и эксплуатационных метрик качества, а внутренние метрики выбираются таким образом, чтобы они могли использоваться для предсказания значений внешних метрик.
Построить строгую теоретическую модель, устанавливающую взаимосвязь внешних и внутренних метрик, сложно, поэтому, как правило, строится гипотетическая модель, взаимосвязь метрик в которой моделируется статистически в ходе использования метрик.
1.4. Описание метрик
Описание метрик выполнено по единой схеме с указанием следующей информации:
· имя метрики. Соответствующие метрики внутреннего и внешнего качества имеют одинаковые имена;
· назначение метрики. Сформулировано в виде вопроса, на который дает ответ применение метрики;
· метод применения. Содержит правила получения данных и схему их
применения в метрике;
· формула и элементы данных. Указывается формула вычисления (или
формулы) и поясняются участвующие в ней элементы данных;
· интерпретация измеренных данных. Диапазон значений и предпочти-
тельное значение;
· тип шкалы метрики. Один из типов шкалы - номинальная, порядковая, интервальная, относительная или абсолютная;
· тип меры. Один из типов меры – мера размера, времени, счетная мера;
· исходные данные. Источник данных, используемый в измерении;
· процесс ЖЦ. Указывается наименование процесса ЖЦ ПС, в котором рекомендовано применение метрики при проведении измерения;
· получатель. Указываются потребители результатов измерения.
Уровень определения требований к эксплуатационному, внешнему и внутреннему качеству, множество и тип объектов измерения и измеряемых атрибутов, выбор эксплуатационных, внешних и внутренних метрик, а также порядок применения процедур измерения и оценивания качества зависит от стадии ЖЦ ПС.
Таблица 2. Использование метрик на стадиях ЖЦ
|
Использование внутренних метрик |
Использование внешних метрик |
|
Стадии подготовки предложений и определения требований к ПС |
|
|
Используются для: спецификации плана повышения качества проекта и/или промежуточных продуктов описания количественных подцелей внутреннего качества проекта и/или промежуточных продуктов ПС по характеристикам, указанным в модели. Источники данных: потребности пользователей, описания предложений, спецификации требований |
Используются для: спецификации требований к качеству с точки зрения пользователя описания количественных целей внешнего качества по характеристикам, указанным в модели. Источники данных: потребности пользователей, описания предложений, спецификации требований |
|
Стадии проектирования, кодирования и автономного тестирования ПС |
|
|
Используются для: оценивания достигнутого уровня реализации плана повышения качества по характеристикам, указанным в модели выявления отклонений от подцелей внутреннего качества предсказания значений внешних метрик и внешнего качества Источники данных: результаты обзоров, ста- тического анализа и измерений спецификаций, проекта, кода и др. |
Используются для: предсказания качества при использовании (эксплуатационного качества) Источники данных: результаты анализа сценариев использования ПС, исполняемых прототипов приложений в ходе их тестирования, отчеты о результатах тестирования |
|
Стадии интеграции, системного тестирования, инсталляции, приемки ПС |
|
|
Используются для: оценивания достигнутого уровня реали- зации плана повышения качества проекта и/или промежуточных продуктов Источники данных: результаты обзоров, ста- тического анализа и измерений специфика- ций, проекта, программного кода и др. |
Используются для: · представления характеристик каче- ства ПС, определенных в модели · подтверждения того, что достигнутое качество удовлетворяет пользователя · предсказания эксплуатационного качества Источники данных: сценарии использования ПС при тестировании и эксплуатации, а также совместно с другими программными системами |
|
Стадия эксплуатации ПС |
|
|
Используются для: · исследования взаимосвязи внутренних и внешних метрик Источники данных: результаты обзоров, ста- тического анализа и измерений специфика- ций, проекта, программного кода и др. |
Используются для: · представления характеристик эксплуатационного качества ПС, определенных в модели · подтверждения того, что имеющийся уровень качества все еще удовлетворяет реальные потребности пользователя Источники данных: сценарии использования ПС и сценарии ее поведения в ходе эксплуатации, отчеты о претензиях пользователей |
1.5. Проектирование метрик
Процесс, выполняемый при разработке собственных или выборе существующих метрик качества ПС, отвечающих целевым требованиям к качеству ПС (или ее компонента), включает следующие шаги:
Шаг 1. Определение понятий. Определения всех используемых понятий (сущностей и измеряемых атрибутов) должны соответствовать указанным в применяемых стандартах или приводиться в документе, описывающем принятую модель качества ПС. Нельзя допускать неоднозначности толкования терминов различными категориями лиц, использующих метрики (пользователями, заказчиками, разработчиками).
Шаг 2. Определение внутренней структуры (модели) каждой метрики. Значения базовых метрик измеряются непосредственно и модель таких метрик – это наименование соответствующей переменной. Значения сложных метрик представляют собой математические модели, использующие базовые или другие сложные метрики. Предпочтителен прагматический подход к моделированию метрик - метрики должны отражать наиболее важные аспекты измеряемого атрибута и не быть слишком сложными. Модели метрик могут быть заимствованы из стандартов, научной литературы, из опыта других организаций и т.д. и должны накапливаться и
при необходимости адаптироваться к нуждам конкретных измерений.
Для разработки новых (оригинальных) метрик полезно привлекать экспертов в проблемной области проекта и инженерии качества ПС.
Шаг 3. Формулирование метода вычисления метрики (критерия оценивания). Модель каждой метрики декомпозируется до уровня метрик-примитивов (базовых метрик) и далее для этих примитивов определяется механизм получения значения (критерий оценивания). Пример метрики-примитива со сложным механизмом получения значения – SLOC (число строк исходного кода).
Метрики-примитивы и критерии их оценивания образуют первый уровень необходимых собираемых данных.
Методы определения значений метрик, рекомендованные стандартом ДСТУ 2850, таковы:
· измерительный. Метод основан на получении информации о свойствах и характеристиках ПС с использованием измерительных технических и программных средств (размер загрузочного модуля, время выполнения ветви программы и др.);
· регистрационный. Метод основан на получении информации во время
испытаний или при непосредственном использовании ПС по назначению, когда регистрируются и подсчитываются определенные события (моменты времени сбоев, число отказов и др.);
· расчетный. Метод основан на использовании теоретических и эмпирических зависимостей на ранних стадиях разработки, а также статистических данных, накапливаемых при испытаниях, эксплуатации и сопровождении. Этим методом прогнозируются характеристики и подхарактеристики на ранних стадиях разработки (точность, устойчивость, надежность и др.). Расчетный метод используется и для определения фактических значений характеристик по результатам тестирования;
· экспертный. Метод заключается в определении значений характеристик группой специалистов-экспертов. Применяется в том случае, если задача определения значений не может быть решена иными методами. Для проведения экспертизы устанавливаются контролируемые признаки, включаемые в виде вопросов в аналитические опросные анкеты экспертов.
Шаг 4. Определение критерия «хорошего» значения метрики. Когда известно, что измерять и как измерять, нужно определить, как интерпретировать результаты измерений, и какими должны быть пределы их изменений. Критерием истины во многих случаях служит мнение заказчика и пользователя. Могут также использоваться опубликованные сведения о приемлемых значениях тех или иных метрик, полученные в отраслевой производственной практике значения и др. Так, например, известно, что цикломатическая сложность модулей должна быть 10. Наиболее достоверный источник информации – собственные исторические данные об измерении схожих проектов.
Шаг 5. Документирование метрик. На этом шаге нужно принять решение о формате отчета, о цикле извлечения и регистрации данных (частоте измерений), о механизмах учета данных (твердая копия, электронная копия), о порядке их распределения (направления) различным участникам процесса измерения, об ограничениях (определяющих готовность метрики к использованию) и др.
Шаг 6. Определение дополнительных квалификаторов метрик.
Метрика считается хорошо спроектированной, если она является обобщением различных взглядов и уровней измерения и если ее можно применять, например, на уровне класса продуктов, одного продукта или компонентов этого продукта ПС. В качестве дополнительных квалификаторов может указываться контекст применения и другие ограничения.
Примеры характеристик, метрик и мер
Таблица 3 . Модель практичности (IEC 9126)
|
Характеристики |
Метрики |
|
Понятность |
Четкость концепции |
|
Демонстрационные возможности |
|
|
Наглядность и полнота документации |
|
|
Простота использования |
Простота управления функциями |
|
Комфортность эксплуатации |
|
|
Среднее время ввода заданий |
|
|
Среднее время отклика на задание |
|
|
Изучаемость |
Трудоемкость изучения |
|
Продолжительность изучения |
|
|
Объем эксплуатационной документации |
|
|
Объем электронных учебников |
|
|
Привлекательность |
Субъектная оценка |
Таблица 4 Характеристики-метрики-меры
|
Характеристика |
Мера |
Шкала |
|
Понимаемоть: четкость концепции ПС; демонстрационные возможности; наглядность и полнота документации |
Порядковая |
Отличная; хорошая; удовлетворит.; неудовлетворит. |
|
Изучаемость: трудоемкость изучения ПС; продолжительность изучения; объем документации; объем электронных учебников |
Чел.-часы Часы Страницы Кбайты |
1 - 1000. 1 - 1000. 1 - 1000. 1 - 1000. |
|
Привлекательность: субъективные или экспертные оценки. |
Порядковая |
Отлич.; хорошая; удовлет.; нeудовл. |
|
Простота использования: простота управления функциями; комфортность эксплуатации; среднее время ввода заданий; среднее время отклика на задание |
Порядковая
Секунды Секунды |
Отлич.; хорошая; удовлет.;неудовл. 1 - 1000. 1 - 1000. |
Таблица 6. Модель качества в использовании
|
Характеристика |
Метрика |
|
Эффективность |
Какой процент задач пользователя реализуется в продукте |
|
Отношение числа успешных действий к ошибкам |
|
|
Нагрузка пользователя |
|
|
Количество используемых функций и команд |
|
|
Процент пользователей, успешно выполнивших задание |
|
|
Средняя точность завершенных данных |
|
|
Продуктивность |
Время выполнения задания |
|
Время, необходимое для предварительного обучения |
|
|
Время, которое тратится на ошибки и решение проблем |
|
|
Количество совершаемых ошибок |
|
|
Частота использования справки и документации |
|
|
Количество ошибочных и повторных действий |
|
|
Задания, выполненные в единицу времени |
|
|
Оценка затрат на выполнение задания |
|
|
Удовлетворен-ность |
Рейтинговая оценка полезности продукта |
|
Рейтинговая оценка удовлетворенности функционального продукта |
|
|
Количество случаев недовольства пользователя |
|
|
Частота жалоб |
|
|
Степень загрузки по времени |
|
|
Безопасность |
Риск пользователей |
|
Экономический риск |
|
|
Риск повреждения программ и данных |
Полная спецификация метрик
Таблица 7 Метрики эффективности
|
Имя метрики |
Назначение метрики |
Способ применения |
Измерение, формула и элементы данных для вычисления |
Интерпретация измеренного значения |
Тип шкалы метрики |
Тип измерения |
Исходные данные для измерения |
12207 ссылка |
Исполнитель |
|
Эффективность |
Какая доля задачи завершена корректно? |
Пользовательское тестирование |
M1 = A x B A = Количество(полноста) = = доля заданных целей на выходе B = Количество(полноста) = = степень достигнутых заданных целей, которые были представлены на выходе |
0<= M1 <=1 Чем ближе к 1.0, тем лучше |
Абсолютная |
A = число B = число M1=X= =число*число |
Отчет операции (теста) Запись мониторинга пользователя |
6.5 Валидация 5.3 Тестирование квалификации 5.4Эксплуатация |
Пользователь Проектировщик интерфейса |
|
ПРИМЕЧАНИЕ: рекомендуется для оценщика указать несколько модель выходных данных пользователя и ошибку, соответствующую каждому достигнутому уровню заданных целей. Это помогает оценщику оценить качество (полноту) и качество (корректность) задач, которые рассматриваются пользователем. |
|||||||||
|
Завершенность |
Какая доля задачи завершена? |
Пользовательское тестирование |
X = A/B A = номер пробуемых задач B = общее количество задач |
0<= X <=1 Чем ближе к 1.0, тем лучше |
Относительная |
A = число B = число X=число/число |
Отчет операции (теста) Запись мониторинга пользователя |
6.5Валидац 5.3 Тестирование квалификации 5.4Эксплуатация |
Пользователь Проектировщик интерфейса |
|
ПРИМЕЧАНИЕ: эта метрика может быть измерена одним или группой пользователей. Если задача может быть частично завершена, должна быть использована метрика «Эффективность». |
Продолжение таблицы 7
|
Частота ошибки |
Какова частота ошибки? |
Пользовательское тестирование |
X = A A = количество ошибок, произведенных пользователем |
0<= X Чем ближе к 0, тем лучше |
Абсолютная |
A = число |
Отчет операции (теста) Запись мониторинга пользователя |
6.5 Валидация 5.3 Тестирование квалификации 5.4 Эксплуатация |
Пользователь Проектировщик интерфейса |
|
ПРИМЕЧАНИЕ: эта метрика подходит только для сравнений в случае, когда ошибки имеют равную важность или весомость. |
|||||||||
|
Частота помощи |
Какова частота использования помощи? |
Пользовательское тестирование |
X = A A = количество обращений за помощью |
0<= X Чем ближе к 0, тем лучше |
Абсолютная |
A = число |
Отчет операции (теста) Запись мониторинга пользователя |
6.5 Валидация 5.3 Тестирование квалификации 5.4 Эксплуатация |
Пользователь Проектировщик интерфейса |
|
ПРИМЕЧАНИЕ: помощь может включать в себя помощь online, документацию или помощь человека. Они могут быть измерены отдельно или в комбинации. Если измерения производятся во время первого использования, метрика связана с обучаемостью. |
Таблица 8 Метрики производительности
|
Имя метрики |
Назначение метрики |
Способ применения |
Измерение, формула и элементы данных для вычисления |
Интерпретация измеренного значения |
Тип шкалы метрики |
Тип измерения |
Исходные данные для измерения |
12207 ссылка |
Исполнитель |
|
Продуктивность |
Как пользователь продуктивен? |
Пользовательское тестирование |
M2 = M1/T M1 = эффективность T = время |
0<= M2 Чем больше, тем лучше |
Относительная |
T = время M2=(число*число)/время |
Отчет операции (теста) Запись мониторинга пользователя |
6.5 Валидация 5.3 Тестирование квалификации 5.4 Эксплуатация |
Пользователь Проектировщик интерфейса |
|
ПРИМЕЧАНИЕ: Если «Завершенность» была измерена, продуктивность может быть измерена как завершенность деленная на время. |
|||||||||
|
Экономическая продуктивность |
На сколько экономичным является пользователь? |
Пользовательское тестирование |
M2 = M1/C M1 = эффективность C = общая стоимость задачи |
0<= M2 Чем больше, тем лучше |
Относительная |
T = время M2=(число*число)/время |
Отчет операции (теста) Запись мониторинга пользователя |
6.5 Валидаци 5.3Тестирование квалификации 5.4Эксплуатация |
Пользователь Проектировщик интерфейса |
|
ПРИМЕЧАНИЕ: затраты могут включать, например, время пользователя, время оказание помощи другим, стоимость вычислительных ресурсов, телефонные звонки, материалы. |
Продолжение таблицы 8
|
Доля продуктивности |
Какую часть времени пользователь тратит на выполнение продуктивных действий? |
Пользовательское тестирование |
доля продуктивности M3 = Ta / Tb Ta = продуктивное время= = время задачи – время помощи – время ошибки – время поиска Tb = время задачи |
0<= M3 <=1 Чем ближе к 1.0, тем лучше |
Абсолютная |
Ta = время Tb = время M3 = время/время |
Отчет операции (теста) Запись мониторинга пользователя |
6.5 Валидация 5.3 Тестирование квалификации 5.4 Эксплуатация |
Пользователь Проектировщик интерфейса |
|
ПРИМЕЧАНИЕ: эта метрика требует детального анализа видеозаписи взаимодействия (см. Macleod M, Bowden R, Bevan N and Curson I (1997) The MUSiC Performance Measurement method, Behaviour and Information Technology, 16, 279-293.)) |
|||||||||
|
Относителная пользовательская производительность |
Насколько продуктивным является пользователь относительно эксперта? |
Пользовательское тестирование |
Относительная пользовательская продуктивность M4 = A / B A = продуктивность обычного пользователя (M2) B = продуктивность эксперта (M2) |
0<= M4 <=1 Чем ближе к 1.0, тем лучше |
Абсолютная |
M4 = M2/M2 |
Отчет операции (теста) Запись мониторинга пользователя |
6.5Валидаци 5.3 Тестирование квалификации 5.4 Эксплуатация |
Пользователь Проектировщик интерфейса |
|
ПРИМЕЧАНИЕ: если эксперт на 100% продуктивен, это дает аналогичные значения «Доли произвоительности». |
Таблица 9 Метрики безопасности
|
Имя метрики |
Назначение метрики |
Способ применения |
Измерение, формула и элементы данных для вычисления |
Интерпретация измеренного значения |
Тип шкалы метрики |
Тип измерения |
Исходные данные для измерения |
12207 ссылка |
Исполнитель |
|
Здоровье и безопасность пользователя |
Какие заболевания RSI среди пользователей продукта? |
Статистика использования |
X = A/B A = число отзывов пользователей об RSI B = общее количество ползователей |
0<= X <=1 Чем ближе к 0, тем лучше |
Абсолютная |
A = число B = число X=число/число |
Запись мониторинга пользователя |
5.4 Эксплуатация |
Пользователь Проектировщик интерфейса |
|
Безопасность пациента |
Каков риск опасности для пациента? |
Статистика использования |
X = A/B A = количество пациентов, направленных на лечение B = общее количество пациентов |
0<= X <=1 Чем ближе к 0, тем лучше |
Абсолютная |
A = число B = число X=число/число |
Отчет операции (теста) Запись мониторинга пользователя |
6.5 Валидация 5.3 Тестирование квалификации 5.4 Эксплуатация |
Пользователь Проектировщик интерфейса |
Продолжение таблицы 9
|
Экономический риск |
Каков риск экономического ущерба? |
Статистика использования |
X = A/B A = количиство ситуаций, которые могут привести к экономическому ущербу B = общее количество ситуаций использования |
0<= X <=1 Чем ближе к 0, тем лучше |
Абсолютная |
A = число B = число X=число/число |
Запись мониторинга пользователя |
5.4 Эксплуатация |
Пользователь Проектировщик интерфейса |
|
Повреждение программного обеспечения |
Какова частота искажения файла? |
Статистика использования |
X = A/B A = число вхождений файла в повреждение B = количество ситуаций использования |
0<= X <=1 Чем ближе к 0, тем лучше |
Абсолютная |
A = число B = число X=число/число |
Отчет операции (теста) Запись мониторинга пользователя |
6.5 Валидация 5.3 Тестирование квалификации 5.4 Эксплуатация |
Пользователь Проектировщик интерфейса |
Таблица 10 Метрики удовлетворения
|
Имя метрики |
Назначение метрики |
Способ применения |
Измерение, формула и элементы данных для вычисления |
Интерпретация измеренного значения |
Тип шкалы метрики |
Тип измерения |
Исходные данные для измерения |
12207 ссылка |
Исполнитель |
|
Шкала удовлетворения |
Насколько удовлетверен пользователь? |
Пользовательское тестирование |
X = A A = анкетирование по психометрической шкале |
Сравнить с предидущим значением или со средним значением населения |
Ord. |
A = число X= число |
Отчет операции (теста) Запись мониторинга пользователя |
6.5 Валидаци 5.3 Тестировквалификации 5.4Эксплуата |
Пользователь Проектировщик интерфейса |
|
ПРИМЕЧАНИЕ: Примеры психометрических анкет можно найти в разделе F.3. |
|||||||||
|
Анкета удовлетворения |
На сколько удовлетворены пользователи? |
Пользовательское тестирование |
X = A A = ответы анкеты |
Сравнить с предидущим значением или со средним значением населения |
Ord. |
A = число X= число |
Отчет операции (теста) Запись мониторинга пользователя |
6.5 Валидаци 5.3 Тестирование квалифик 5.4 Эксплуата |
Пользователь Проектировщик интерфейса |
|
ПРИМЕЧАНИЕ: если темы анкеты не взвешены, то существует опасность, что различные вопросы могут иметь различное значение, что затрудняет интерпритацию результатов. |
|||||||||
|
Операционная частота использования пользователем |
Нравится ли пользователю часто использовать программное обеспечение? |
Наблюдение использования |
Оперативная частота использования X = A/B A = Количество раз, когда пользователь использует специфические функции ПО B = кол. возможностей для использования спец. функции |
0 < X Чем больше, тем лучше |
Относительная |
A = число B = число X= число/число |
Отчет операции (теста) Запись мониторинга пользователя |
6.5 Валидаци 5.3 Тестирование квалифик 5.4Эксплу |
Пользователь Проектировщик интерфейса |
1.6 Задание на ЛР
1. Познакомьтесь с метриками, которые приведены в примерах теоретической части.
2. Познакомьтесь с характеристиками и требованиями к ним, которые предъявляются к человеко-машинным интерфейсам программно-технических комплексов а атомной энергетике.
3. Выберите вариант задания
4. Определите метрики для оценки заданной характеристики качества. Для этого выберите метрики из моделей 9126, QUIM и т.л. или разработайте собственные оригинальные метрики для следующих характеристик пользовательских программных интерфейсов.
5. Задайте метрику в форме спецификации табл. 7
6. Обоснуйте адекватность выбранных метрик.
7. Составьте отчет
Варианты заданий
Таблица 11 Характеристики и требования к ним
|
№ |
Характеристика |
Описание |
|
1. |
Безопасность персонала (Personnel Safety) |
Дизайн интерфейса должен обеспечивать минимальную возможность травм и воздействия вредных материалов |
|
2. |
Когнитивная совместимость (Cognitive Compatibility) |
Роль оператора должна состоять из целенаправленных и значимых задач, которые позволяют персоналу поддерживать хорошую осведомленность с АЭС и поддерживать уровень нагрузки, который не настолько высокий, чтобы негативно повлиять на производительность, но достаточной для поддержания бдительности |
|
3. |
Физиологическая совместимость (Physiological Compatibility) |
Дизайн интерфейса должен отражать рассмотрение физиологических характеристик человека, включая визуальное / слуховое восприятие, биомеханику (достижения и движения), |
|
4. |
Простота конструкции (Simplicity of Design) |
ЧМИ должны представлять простой дизайн в соответствии с функциональными требованиями и требованиями задачи |
|
5. |
Согласованность (Consistency) |
Должна быть высокая степень согласованности между ЧМИ, процедурами и обучающими системами. В ЧМИ пути системных функций и деятельности бригады всегда должны быть согласованы, отражать высокую степень стандартизации, и быть в полном соответствии с процедурами и подготовкой кадров |
|
6. |
Понимание ситуации (Situation Awareness) |
Информация, представленная пользователям ЧМИ должна быть правильно, быстро и легко понята (например, "непосредственное восприятие" или "определение состояния с одного взгляда" на дисплее) и поддерживаться на высоком уровне с целью осведомленности пользователей о статусе системы |
|
7. |
Целевая совместимость (Task Compatibility) |
Система должна отвечать требованиям пользователей для выполнения своих задач (в том числе, безопасное завершение работы, осмотр, техническое обслуживание и ремонт). Данные должны быть представлены в формах и форматах, соответствующих задач (включая, необходимость доступа к подтверждающим данным или необработанным данным в случае отображения более высокого уровня). Возможность контроля должна охватывать ряд потенциальных действий. Не должно быть ненужной информации или вариантов контроля |
|
8. |
Пользовательская модель совместимости (User Model Compatibility) |
Все аспекты системы должны быть совместимы с ментальными (психическими) моделями пользователей (понимание и ожидание поведения системы осуществляется путем подготовки кадров, использования процедур и опыта). Все аспекты системы должны быть совместимы с установленными допущениями, т.е. должны быть выражены в обычной, привычной, пригодной и функциональной точки зрения, а не абстрактно |
|
9. |
Структура элементов ЧМИ (Organization of HSI Elements) |
Структура всех аспектов ЧМИ (от элементов в отдельных дисплеях до отдельных рабочих станций и всей комнаты управления) должна быть основана на требованиях пользователя и должна отражать общие принципы организации по важности, частоте и порядке использования. Информация критических функций безопасности должна быть доступна всем, работающим в команде, для обеспечения ее распознавания и сведения к минимуму поиска данных и ответных мер |
|
10. |
Логическая/Явная структура (Logical/Explicit Structure) |
Все аспекты системы (форматы, терминология, последовательность, группировка, и поддержка принятия решений оператора) должна отражать очевидную логику, основанную на требованиях задачи или других непроизвольных обоснованиях. Отношения каждого отображения, управления и обработки данных для общей задачи/функции должны быть ясными. Структура интерфейса и связанная с ней навигация должны быть сделаны легкой для пользователей, чтобы было понятно, где они находятся в пространстве данных. Структура интерфейса должна позволить |
|
11. |
Своевременность (Timeliness) |
Проектирование системы должны принимать во внимание когнитивные возможности пользователей, а также связанные с процессом ограничения времени для обеспечения того, чтобы задачи были выполнены в срок. Скорость информационного потока и требования контроля за исполнением, которые являются слишком быстрыми или слишком медленными могут привести к снижению производительности |
|
12. |
Совместимость управления/отображения (Controls/Displays Compatibility) |
Отображения должны быть совместимы с вводимыми данных и требованиями управления |
|
13. |
Обратная связь (Feedback) |
Система должна давать полезную информацию о состоянии системы, допустимых операциях, ошибках и восстановлении после ошибки, опасных операциях, и достоверности данных |
|
14. |
Когнитивная нагрузка (Cognitive Workload) |
Информация, представленная системой должна быстро восприниматься и пониматься. Поэтому система должна минимизировать требования для вычислений или преобразований в уме и использовать напоминания (ссылаясь на длинные списки кодов, сложные команды, информацию с одного экрана на другой, или длительные последовательности действий). Исходные данные должны быть обработаны и представлены в непосредственно удобной форме. Исходные данные должны быть доступны для подтверждения |
|
15. |
Нагрузка ответа (реакции) (Response Workload) |
Система должна требовать минимальное количество действий для получения результата. Например, одну команду ввода вместо нескольких команд, меню выбора вместо многократных команд, один режим ввода (клавиатура, мышь) вместо смешанного режима. Система не должна требовать ввода избыточных данных, повторного ввода информации, имеющейся уже в системе, или информации, которую система может генерировать по уже поступившим данным |
|
16. |
Гибкость (Flexibility) |
Система должна предоставить пользователю несколько способов для совершения действий и проверить автоматические действия. Отображение и контроль должен быть отформатирован в конфигурации наиболее удобной для задачи. Однако, гибкость должна быть ограничена ситуациями, когда она предлагает преимущества в выполнении задачи (например, для приспособления к различным уровням опыта пользователей) |
|
17. |
Руководства и поддержка пользователя (User Guidance and Support) |
Система должна обеспечить эффективную "Помощь". Информативные, легкие в использовании рекомендации должны быть предоставлены в он-лайн и офф-лайн режимах, чтобы помочь пользователю понять, как работать с системой |
|
18. |
Толерантность и управление ошибками (Error Tolerance and Control) |
Отказоустойчивый дизайн должен предоставляться везде, где сбой может привести к повреждению оборудования, травмам персонала, или непреднамеренной работе критически важного оборудования. Таким образом, система должна вообще быть сконструирована таким образом, чтобы ошибки пользователя не имели серьезных последствий. Надо управлять негативными последствиями ошибок, и сводить их к минимуму. Система должна предлагать простые, понятные уведомления об ошибке, и простые, эффективные методы для восстановления |