Модель качества практичности программного обеспечения документооборота

Доклады БГУИР

2012 № 7

УДК 004.055

МОДЕЛЬ КАЧЕСТВА ПРАКТИЧНОСТИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

ДОКУМЕНТООБОРОТА

В В. БАХТИЗИН, А.А. ВОРВУЛЬ

Белорусский государственный университет информатики и радиоэлектроники П.Бровки, 6, Минск, 220013, Беларусь

Поступила в редакцию 23 мая 2012

Предложена модель оценки качества практичности программного обеспечения документооборота. Приведен пример поиска, расчета и подтверждения атрибутов качества в предложенной модели.

Ключевые слова: программное обеспечение, практичность, модель качества, атрибут качества, мера качества, тестирование.

Введение

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

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

Вопрос оценки качества программного обеспечения на сегодняшний день является одним из наиболее актуальных вопросов в сфере информационных технологий. Качество продукта - это степень с которой продукт удовлетворяет установленные и предполагаемые потребности своих владельцев. Международный стандарт ISO 25010 определяет иерархическую модель качества продукта, на первом уровне которой находятся восемь характеристик качества. На втором уровне модели находятся подхарактеристики качества. На третьем уровне - атрибуты качества. Количественные и качественные значения атрибутов представляются в модели мерами, полученными в результате измерения. Такая иерархическая декомпозиция удобна для представления и анализа качества программного продукта. Однако перечень стандартных под-характеристик был выбран для представления качества типичных программных продуктов и необязательно является исчерпывающим [1].

Для измерения подхарактеристики качества программных продуктов необходимо:

1) выделить совокупность атрибутов качества, относящихся к подхарактеристике;

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

3) получить интегральную оценку результатов измерения, которая будет являться количественным выражением подхарактеристики качества.

Для вычисления характеристики качества необходимо получить интегральную оценку подхарактеристик качества.

Среди восьми характеристик качества практичность является одной из самых сложных для автоматического вычисления характеристикой. Сложность автоматизации вычисления связана с необходимостью принятия во внимание особенностей как пользовательской психологии,

так и пользовательского окружения. Именно этим и отличается вычисление данной характеристики качества от других, измеряющих, как правило, технические аспекты программного проекта.

Наравне со стандартными моделями оценки качества разрабатываются модели для оценки практичности [2-5]. Однако на сегодняшний день в открытой публикации пока нет полного описания таких моделей. В существующих моделях не определены нижние уровни иерархии качества: подхарактеристики и/или атрибуты качества.

Анализ этого вопроса показал, что двумя наиболее вероятными причинами являются: 1) разработка нижних уровней модели качества не завершена; 2) нижние уровни модели хранятся в виде программного кода, и поэтому в открытую публикацию не попадают (например, сайты www.sumi.ucc.ie и www.wammi.com).

Таким образом, отсутствие полной информации о моделях не позволяет произвести измерение практичности. Отсюда следует, что для вычисления значения характеристики «практичность» требуется разработать соответствующую модели качества. От существующих она будет отличаться множеством атрибутов качества:

M = {m.. | i = 1,k; j = 1,mt},

где т.. - значение j-ого атрибута качества, i-ой подхарактеристики практичности; k - количество подхарактеристик практичности; т. - количество атрибутов качества i-ой подхарактеристики практичности.

Соответственно, каждая i-ая подхарактеристика S, практичности будет рассчитываться по формуле

m m

s=f

.=1 .=1

где mi - количество атрибутов качества i-ой подхарактеристики практичности; m. - значение j-ого атрибута качества, i-ой подхарактеристики практичности; V. - весовой коэффициент j-ого атрибута качества, i-ой подхарактеристики практичности.

Тогда значение характеристики «практичность» U рассчитывается по формуле:

U = f

i=1 i=1

где k - число подхарактеристик практичности; Si - значение i-ой подхарактеристики практичности; V, - весовой коэффициент i-ой подхарактеристики практичности.

Для получения интегральной оценки практичности по формулам 1 и 2 необходимы нормированные значения атрибутов качества mij. То есть меры качества должны быть разработаны таким образом, чтобы результативное значение mij находилось в интервале [0, 1], при этом чем ближе mij к 1, тем выше должно быть качество продукта.

Поиск и формулирование атрибутов качества

Для нахождения множества атрибутов качества одной из наиболее подходящих является парадигма Бейзили [6] (парадигма goal, question, metric). Алгоритм нахождения атрибутов качества состоит из трех основных этапов: формирование целей, формулирование вопросов и нахождение атрибутов качества.

В статье предлагается провести оценку практичности системы автоматизированного документооборота согласно парадигме Бейзили. В соответствии с этой парадигмой, цели должны быть сформированы экспертно. Более того, стандарт ISO 25010 требует заранее учесть контекст использования программного продукта, к которому относятся пользователи, задачи, оборудование, социальное и физическое окружение [1, 7].

В соответствии с требованиями стандарта ISO 25010 приведем краткую характеристику контекста использования. Ожидается, что пользователями программного продукта будут выступать работники всех возрастных категорий, владеющие базовыми навыками работы с оконными приложениями. Подразумевается, что характеристики и состав оборудования удовлетво-

ряет требованиям, изложенным в техническом задании. Набор пользовательских функций должен автоматизировать документооборот. Рабочие места пользователей могут быть территориально разнесены и объединены в единую компьютерную сеть.

Для формулирования целей используется целевой формат в парадигме GQM. Последовательно должны быть определены [8]:

1) причины проведения оценки практичности;

2) направления, на которые следует сфокусировать внимание оценки;

3) оцениваемые аспекты и участники процесса оценки;

4) среда и окружение, в которых производится оценка.

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

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

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

Обучаемость. Интерфейс взаимодействия с программным продуктом должен максимально облегчать процесс обучения и сокращать его продолжительность.

Простота использования. Усилия пользователей по доступу к данным, вызовам функций и осуществлению навигации должны быть минимальными.

Защита пользователей от совершения ошибок. Пользователи могут не иметь опыта работы с системами автоматизированного документооборота. Сообщения об ошибках должны содержать ответы на прогнозируемые вопросы пользователей, это в свою очередь позволяет снизить нагрузку на службу поддержки пользователей программного продукта.

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

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

Таблица 1. Модель оценки практичности документооборота

Подхарактеристики Атрибуты качества

1. Понятность пригодности 1.1. Успешное завершение функций с первой попытки

1.2. Корректность описания функций пользователем

2. Обучаемость 2.1. Простота изучения функций

2.2. Запоминаемость функций

3. Простота использования 3.1. Логичность и последовательность функциональных действий

3.2. Доступность предустановленных значений параметров

4. Защита пользователя от совершения ошибок 4.1. Информативность сообщений об ошибках

4.2. Продуктивное время

5. Эстетичность пользовательского интерфейса 5.1. Адаптируемость пользовательского интерфейса

Все предложенные в статье меры качества приводят результат вычисления mij к нормированному виду в интервале от 0 (фактически это отсутствие качества) до 1 (максимально возможный уровень меры качества).

Атрибуты качества подхарактеристики "понятность пригодности" вычисляются с помощью следующих мер качества.

1.1. Мера качества тц (успешное завершение функций с первой попытки) рассчитывается по формуле:

X ~

т„ = ,

п

где п - количество пользователей, участвовавших в тестировании; / - количество успешно завершенных 7-ым пользователем функций с первой попытки во время первого тестового сеанса; Fu - общее количество вызванных 7-ым пользователем функций во время первого тестового сеанса. (Тестовый сеанс - интервал выделенного пользователю времени для выполнения тестовых заданий).

1.2. Мера качества ти2 (корректность описания функций пользователем) рассчитывается по формуле:

п И п

п

где п - количество пользователей, участвовавших в тестировании; И7 - количество корректно описанных 7-ым пользователем функций; В7 - общее количество функций описанных 7-ым пользователем.

Атрибуты качества подхарактеристики «обучаемость» вычисляется с помощью следующих мер качества.

2.1. Мера качества т2и (простота изучения функций) рассчитывается по формуле:

X-—

т = 7=1 Н7 21 ' п

где п - количество пользователей, участвовавших в тестировании; Н7 - количество успешно завершенных 7-ым пользователем функций после обращения к документации; Н7 - количество обращений к документации 7-ым пользователя.

2.2. Мера качества т22 (запоминаемость функций) рассчитывается по формуле:

X /

т22 = , п  F

где п - количество пользователей, участвовавших в тестировании; /7 - количество успешно завершенных 7-ым пользователем функций после определенного периода (более одной недели) неиспользования программного продукта; F - количество доступных пользователям в интерфейсе функций.

Атрибуты качества подхарактеристики «простота использования» вычисляются с помощью следующих мер качества.

3.1. Мера качества т3 (логичность и последовательность функциональных действий) рассчитывается по формуле:

т31 = 1 - ——, 31 п  А

где п - количество пользователей, участвовавших в тестировании; а7 - количество информационных сообщений или функциональных возможностей, которые 7-ый пользователь нашел непоследовательными (нелогичными) в соответствии со своими ожиданиями; А - количество информационных сообщений или функциональных возможностей, которые предложено исследовать пользователям.

3.2. Мера качества т32 (доступность предустановленных значений параметров) рассчитывается по формуле:

п ь

I В

тЪ2 = 1 - ^, п

где п - количество пользователей, участвовавших в тестировании; bi - количество случаев, когда у /-го пользователь возникли затруднения при выборе значения параметра (по причине того, что программное обеспечение не предложило предустановленных значений параметров по умолчанию); В, - общее количество случаев, когда /-ый пользователь пытался задать или выбрать значение параметра.

Атрибуты качества подхарактеристики «защита пользователя от совершения ошибок» вычисляются с помощью следующих мер качества.

4.1. Мера качества т41 (информативность сообщений об ошибках) рассчитывается по формуле:

п

Iе

т = ——

'"41 ^ '

п  Е

где п - количество пользователей, участвовавших в тестировании; е/ - количество сообщений об ошибках, которые были правильно объяснены /-ым пользователем; Е - количество сообщений об ошибках, которые предложено исследовать пользователям.

4.2. Мера качества т42 (продуктивное время) рассчитывается по формуле:

1т

т42 = 1 - Т = п  1

Е Е,

IЦ, если IЦ < Т

м м ,

Е,

Т, если 1^ > т

]=1

где п - количество пользователей, участвовавших в тестировании; Т, - время, затраченное / -ым пользователем на исправление ошибок в течении тестового сеанса; Е - количество сообщений об ошибках, полученных / -ым пользователем; ^ - время, затраченное / -ым пользователем на исправление /-ой ошибки в течении тестового сеанса; Т - продолжительность времени тестового сеанса. (Тестовый сеанс - интервал выделенного пользователю времени для выполнения тестовых заданий).

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

5.1.Мера качества т51 (адаптируемость пользовательского интерфейса) рассчитывается по формуле:

п

I ^

т51 = 1

п  С

где п - количество пользователей, участвовавших в тестировании; с - количество элементов пользовательского интерфейса которые может настраивать / -ый пользователь; С - общее количество элементов пользовательского интерфейса.

Предложенные в статье атрибуты качества используются для повышения уровня качества программного продукта во время разработки и тестирования.

Проверка наличия связи между атрибутами качества и характеристикой «практичность»

Само по себе применение парадигмы Бейзили пока еще не гарантирует достоверности показателей ни атрибутов качества, ни мер качества. Для их опровержения или подтверждения

предлагается использовать метод регрессионного анализа. С помощью регрессионного анализа можно приближенно определить форму связи между результативным и факторными признаками и решить вопрос о том, значима ли эта связь.

Для проведения регрессионного анализа в первую очередь необходимо получить экспертное значение характеристики «практичность» для каждой версии продукта и сопоставить его со значением атрибута качества (например, т42 (продуктивное время; формула (3)) и характеристикой практичности и, которая представляет собой интегральную оценку практичности, полученную на основании всех предложенных атрибутов качества (формула (2)).

Проект выполнялся по инкрементной модели и включал в себя в общей сложности 9 версий. В табл. 2 представлен пример результатов вычисления т42 по формуле (3) и характеристики качества «практичность» и по формуле (2) начиная с версии №2. После выхода всех версий была проведена экспертная оценка, в ходе которой четыре пользователя оценивали практичность каждой из версий. Усредненные результаты экспертной оценки практичности приведены в табл. 2 в строке «Экспертное значение практичности».

Таблица 2. Пример результатов оценки практичности

Экспертное значение практичности 0,59 0,59 0,62 0,68 0,70 0,70 0,82 0,88

Продуктивное время т42 0,710 0,724 0,793 0,811 0,820 0,823 0,893 0,911

Практичность и 0,583 0,595 0,604 0,630 0,643 0,650 0,704 0,730

Версии ПО 2 3 4 5 6 7 8 9

В данном примере процесс оценки практичности фактически представляет собой ранжирование версий. Наиболее подходящим методом проверки атрибута качества является метод ранговой корреляции, основанный на ранговом коэффициенте Кендалла, представленном формулой

2 • 5"

Т = ——¡7,5 = р - Q,

п

где 5 - фактическая сумма рангов; п - число сопоставляемых рангов двух величин: т42 и экспертного значения практичности, при этом ранги величины т42 упорядочены так, что представляют собой натуральный ряд; Р - величина, отражающая прямой порядок расположения последующих рангов сопоставимой величины (экспертное значение практичности); Q - величина, отражающая обратный порядок расположения последующих рангов сопоставимой величины (экспертное значение практичности).

Для приведенного выше примера значение т = 0,929 одинаково в обоих случаях связи экспертного значения практичности как с величиной т42 (продуктивное время), так и с величиной и (характеристика "практичность").

Проанализируем значимость полученного коэффициента т. При небольшом объеме выборки (4 < п < 10) проверка статистической гипотезы независимости производится с помощью специальных таблиц [9]. При п=8 по таблице [9] находим, что 26 - верхнее критическое значение для 5, соответствующее уровню значимости 0,0002, и по формуле (4) т = 2-26/56 = 0,929 -верхнее критическое значение для т. Нижним критическим значением является т = -0,929. Следовательно, критической области |т| > 0,929 отвечает вероятность ошибки первого рода, равная 0,0004.

Таким образом, анализ показал значимость полученного коэффициента т. Следовательно, подтверждена положительная связь между полученными с помощью парадигмы Бейзили атрибутами качества и экспертной оценкой характеристики качества практичность.

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

Заключение

Следует отметить, что использование предложенной модели качества характеристики «практичность» предоставляет разработчикам программного обеспечения недорогой и эффек-

тивный способ оценки и обеспечения качества разрабатываемого ПО документооборота.

USABILITY QUALITY MODEL OF DOCUMENTS CIRCULATION SOFTWARE

V.V. BAKHTIZIN, A.A. VORVUL Abstract

Usability model of documents circulation software is suggested. This model is being applied for the usability quality estimation. The example of search, calculation and quality properties confirmation of the suggested usability model is shown.

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

1. ISO 25010-2011 Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - System and software quality models.

2. Winter S. A Comprehensive Model of Usability // Institut für Informatik Technische Universität München, [Electronic resource]. - 2007. - Mode of access: https://wwwbroy.in.tum.de/~wagnerst/publ/ eis07.pdf. - Date of access: 26.03.2012.

3. Abran A. Consolidating the ISO Usability Models // The Pennsylvania State University, [Electronic resource]. - 2005. - Mode of access: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.9 3.3969&rep=rep 1 &type=pdf. - Date of access: 26.03.2012.

4. Navalkar A. Usability Engineering - Quality Approach (ISO 13407) // Human Factors International, [Electronic resource]. - 2004. - Mode of access: http://www.humanfactors.com/downloads/ docu-ments/UsabilityISO.pdf. - Date of access: 26.03.2012.

5. Nacke L. From Playability to a Hierarchical Game Usability Model // Human Factors International, [Electronic resource]. - 2009. - Mode of access: http://arxiv.org/pdf/1004.0256. - Date of access: 26.03.2012.

6. Фатрелл Р. Управление программными проектами. Достижение оптимального качества при минимуме затрат. СПб., 2003.

7. СТБ ISO/IEC 25000-2009 Разработка программного обеспечения. Требования к качеству и оценка программного продукта (SQuaRE). Руководство по SQuaRE.

8. Уодтоке К. Информационная архитектура: Чертежи для сайта. СПб., 2004.

9. Большев K.K, Смирнов Н.В. Таблицы математической статистики. М., 1983.