Библиотека – Давыденко Дарина Павловна – Разработка и исследование обучающих систем с повышенной возможностью адаптации по форме изложения материала на основе использования ментальных карт.
Назад в библиотеку  

МЕТРИКИ ОЦЕНКИ КАЧЕСТВА WEB–СИСТЕМ

  • Авторы: Д.П. Давыденко, Н.Е. Губенко

    Описание: В статье проведен краткий анализ основных метрик оценки качества web-систем. Определены ключевые параметры метрик и методы оценки web-проектов по их параметрам.

    Источник: Информатика, управляющие системы, математическое и компьютерное моделирование в рамках II форума Инновационные перспективы Донбасса (ИУСМКМ – 2016): VII Международная научно-техническая конференция, 26 мая 2016, г. Донецк: / Донец. национал. техн. ун-т; редкол. А.Ю. Харитонов и др. – Донецк: ДонНТУ, 2016. – 260–265с. // URL: http://iuskm.donntu.ru/electronic/iusmkm2016.pdf

    • Постановка проблемы. Известно, что существует достаточно большое количество способов тестирования web-проектов[1]. Качество web-проекта определяется качеством самого продукта по степени соответствия требованиям пользователей и качеством процесса разработки. Одним из эффективных инструментов контроля качества является тестирование с помощью метрик. Согласно международному стандарту ISO 14598 метрика – это количественный масштаб и метод, который может использоваться для измерения. Измерения помогают оценить как продукт, так и сам процесс его разработки. В результате измерений определяется количественная характеристика какого-либо свойства объекта.

    Цель работы – обзор и классификация метрик оценки качества web-систем. Кроме того, существует целый ряд классификаций, ранжирующих метрики по разным критериям. В виду сложности и трудоемкости процесса тестирования предполагается разработать специальное программное обеспечение для этих целей.

    Метрики web-проектов – это количественные показатели, отражающие их отдельные характеристики. При правильном применении метрики являются полезным инструментом оценки работы web-системы. По ним можно отследить целый ряд важных параметров:

    • снижения качества разработки;
    • определить причины снижения качества;
    • выявить самые сложные участки в системе и т.п.

    Кроме того, числовые показатели способны помочь в планировании затрат ресурсов на дальнейшее развитие разрабатываемого продукта. Поэтому введение и использование метрик полезно для улучшения контроля над процессом разработки и тестирования web-систем. Необходимую для контроля информацию собирают (как вручную, так и автоматически) и используют для оценки прогресса выполнения запланированных работ и освоения бюджета.

    Метрики количества – это те характеристики, которые можно измерить. Примеры таких метрик: количество дефектов, покрытие требований, количество дефектов, найденных пользователями, отношение количества открытых дефектов к закрытым и т.д.

    Метрики качества отражают качество работы по проекту. Например, качество отчетов об ошибках, качество разработанных тест кейсов. Метрики качества называют еще субъективными оценками. Как правило, метрики качества должны подтверждаться метриками количества. Например, часто определятся оценка качества заносимых дефектов. Это субъективная оценка участников проекта. Для ее подтверждения необходимо проанализировать количество дефектов с резолюцией Не является дефектом или количество запросов программистов на уточнение шагов для воспроизведения инцидента. Субъективные метрики собирают в виде опросников в Wiki или Word, там же можно хранить обобщённые результаты опросов[2]. Для большей наглядности сгруппируем метрики по типам в таблицу 1.

    Таблица 1 – Классификация метрик
    Метрики по тест кейсам
    Passed/Failed Test Cases Метрика показывает результаты прохождения тест кейсов – отношение количества удачно пройденных к завершившимся с ошибками. К концу проекта количество провальных тестов должно стремиться к нулю.
    Not Run Test Cases Метрика показывает количество тест кейсов, которые еще необходимо выполнить в данной фазе тестирования. Из полученной информации путем анализа можно выявить причины, по которым тесты не были проведены.
    Метрики по багам
    Open/Closed Bugs Метрика показывает отношение количества открытых багов к закрытым (исправленным и перепроверенным)
    Reopened/Closed Bugs Метрика показывает отношение количества переоткрытых багов к закрытым (исправленным и перепроверенным)
    Rejected/Opened Bugs Метрика показывает отношение количества отклоненных багов к открытым
    Bugs by Severity Количество багов по серьезности
    Bugs by Priority Количество багов по приоритету
    Метрики по задачам
    Deployment tasks Метрика показывает количество и результаты установок приложения. Если количество отклоненных командой тестирования версий будет критически высоким, рекомендуется срочно проанализировать и выявить причины, а также в кротчайшие сроки решить имеющуюся проблему.
    Still Opened Tasks Метрика показывает количество все еще открытых задач. К окончанию проекта все задачи должны быть закрыты. Задачи – это такие виды работ: написание документации (архитектура, требования, планы), введение новых модулей или изменение существующих по запросам на изменения, работы по настройке стендов, различные исследования и т.д.
    Метрики по сложности
    Цикломатическая сложность Метрика предназначена для оценивания сложности потока управления программы (control flow graph), вычисляется на основе ориентированного графа, где вычислительные операторы или выражения представляются в виде узлов, а передача управления между узлами – в виде дуг. Формула вычисления цикломатической сложности: C = e - n + p, где e – число ребер, n – число узлов, p – число соединенных компонент графа управляющей логики. Упрощенно формулу можно рассматривать как количество ветвлений, которые может проходить программа, увеличенное на единицу.
    Метрики по назначению
    Прогнозирующие Метрики нужны, чтобы спрогнозировать те проблемы, с которыми может столкнуться проект.
    Диагностические Метрики служат для мониторинга текущего состояния проекта.
    Ретроспективные Метрики помогают избежать в будущем тех ошибок, с которыми команда разработчиков сталкивалась в текущих или уже завершенных проектах.

    В начале таблицы рассмотрены метрики по типам сущностей, участвующих в обеспечении качества и тестировании программного обеспечения, а именно: метрики по тест кейсам (Test Cases), метрики по багам / дефектам, метрики по задачам. Метрики Open/Closed Bugs, Bugs by Severity и Bugs by Priority хорошо визуализируют степень приближения продукта к достижению критериев качества по багам. После каждой итерации тестирования количество открытых багов сравнивает их с реальными данными. Метрики Reopened/Closed Bugs и Rejected/Opened Bugs направлены на отслеживание работы отдельных участников групп разработки и тестирования.Также интересна метрика по времени выполнения задач и многие другие.

    Далее в таблице приведена еще одна распространенная группа метрик оценки сложности. программных проектов. Эти метрики могут применяться и на ранних стадиях работы при осуществлении проектирования. Основное их предназначение – выявить наиболее критичные участки программного проекта, которые являются потенциальными источниками ошибок и повышенных рисков на всех стадиях его жизненного цикла. Вычисление метрик в ходе пошаговой реализации проекта позволяет своевременно определить наиболее сложные, сопровождающиеся высокими рисками, структурные единицы и принять меры по устранению рисков за счет внесения коррективов.

    Более-менее универсальной классификацией метрик может считаться их разделение на: метрики оценки программного обеспечения и метрики оценки условий разработки программного обеспечения [3].

    В каждой из этих категорий могут использоваться метрики с разными шкалами оценки свойств программного обеспечения: номинальной, порядковой, интервальной и относительной. Номинальная шкала показывают наличие либо отсутствие у программного обеспечения какого-либо свойства. Порядковой шкале соответствуют метрики, служащие для ранжирования определенных характеристик с помощью сравнения с некоторыми опорными значениями. Измерения по этой шкале по факту показывают взаиморасположением конкретных программ. Интервальная шкала показывает уже не только взаиморасположение программ, но и то, насколько далеко они отстоят друг от друга. Относительная шкала позволяет не только разместить программы определенным образом и оценить их размещение относительно друг друга, но также может показать, насколько далеко оценки отстоят от точки, начиная с которой характеристика вообще может быть измерена.

    Таким образом, использование метрик позволяет эффективно управлять проектом: своевременно обнаруживать недостатки, устранять их и при этом видеть, насколько хорошо работают найденные методы решения проблем.

    Выводы. Завершая обзор метрик оценки качества web-систем, можно утверждать, что в настоящий момент существует весьма большое количество отдельных показателей, с помощью которых можно эффективно тестировать разработку web-проекта. Использование целого комплекса необходимых метрик и графиков на всех этапах жизненного цикла проекта позволяет улучшить не только процесс тестирования, но и разработку проекта в целом. Исходя из проделанного анализа метрик качества web-систем, можно утверждать, что ни один из рассмотренных методов не является совершенным и для разработки программного обеспечения оценки качества web-систем целесообразно разработать интегрированное программное обеспечение, объединяющее большинство из рассмотренных методов.

    Список литературы

    1. Foundations of Software Testing: ISTQB Certification / D. Graham, E. van Veenendaal, I. Evans et al. // CENGAGE Lrng Business Press. – 2006. – 258 р.
    2. Зачем использовать метрики в тестировании [электронный ресурс] URL:http://bugscatcher.net/archives/3560
    3. Метрики в управлении проектами [электронный ресурс] // URL:http://www.issoft.by/metriki-v-upravlenii-proektami/