Обзор методологий SQFD и GQM

В статье автор рассматривает на примерах подходы SQFD и GQM для определения качества программного обеспечения. Дано описание методов SQFD и GQM. Проанализированы методологии оценки качества программного обеспечения. Предоставлен краткий сравнительный анализ двух подходов.

Ключевые слова: качество программного обеспечения, показатели качества, SQFD, GQM, внешнее качество программного обеспечения, внутреннее качество программного обеспечения.

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

Качество программного обеспечения — это способность программного продукта при заданных условиях удовлетворять установленным или предполагаемым потребностям [1]. Внешнее качество программного обеспечения — это функциональные возможности. Внутреннее качество — это качество кода и внутренней архитектуры [1]. Эффективный подход к оценке качества программного обеспечения может внести свой вклад в улучшения конкурентоспособности компании.

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

– ориентироваться на конкретные цели;

– применяться ко всем продуктам, процессам и ресурсам жизненного цикла;

– учитывать нюансы для конкретной организации.

Это означает, что измерение должно определяться сверху вниз. Оно должно быть сосредоточено, на основе целей и моделей. Подход снизу-вверх не сработает, потому что существует много показателей качества программного обеспечения (например, время, количество дефектов, сложность, строки кода, серьезность сбоев, производительность, плотность дефектов), но какие метрики использовать и как их интерпретировать, непонятно без соответствующих моделей и целей. К настоящему времени известны различные подходы к определению измеримых целей: подход к развертыванию функции качества [2], подход «цель, вопрос, метрика» [3, 4, 5, 6] и подход с метрикой качества программного обеспечения [7, 8].

Рассмотрим методологию GQM (Goal Question Metric) на примерах его применения. Подход GQM основан на предположении, что для измерения своего продукта организация должна сначала определить цели для себя и своих проектов, а затем отслеживать эти цели с использованием определённых данных. Таким образом, важно прояснить, какие информационные потребности имеет организация, чтобы эти потребности можно было количественно оценить, а затем эту оценку можно было проанализировать, чтобы определить, достигнуты ли цели. Результатом применения подхода GQM является спецификация системы, нацеленная на определенный набор проблем, и набор правил для интерпретации данных измерений.

Концептуальный уровень (ЦЕЛЬ): цель определяется для объекта по ряду причин, в отношении различных моделей качества, с различных точек зрения, относящихся к конкретной среде. Объектами измерения являются:

– продукты: результаты и документы, которые создаются в течение жизненного цикла системы; например, спецификации, макеты, программы и тестовые наборы.

– процессы: действия, связанные с программным обеспечением, обычно имеющие отношения к времени; например, описание спецификаций, дизайн, проектирование, тестирование, интервьюирование.

– ресурсы: элементы, используемые процессами для получения результатов; например, персонал, оборудование, программное обеспечение, офисные помещения.

Операционный уровень (ВОПРОС): набор вопросов, который используется для того, чтобы охарактеризовать каким образом определённая цель будет оцениваться или достигаться. Данная характеристика производится на основе моделей характеризации. Вопросы описывают объект исследования (продукт, процесс, ресурс) относительно какого-то выбранного качества и также определяют это качества с некой точки зрения.

Количественный уровень (METRIC): Набор данных ассоциируется с каждым вопросом, позволяющий дать на них количественный ответ. Данные могут быть:

– объективные: если они зависят только от объекта, который измеряется, а не чей-то точки зрения; например, количество версий документа, часы персонала, потраченные на задачу, размер программы.

– субъективные: если они зависят как от объекта измерения, так и от чей-то точки зрения; например, читаемость текста, уровень удовлетворенности пользователей.

Модель GQM — это иерархическая структура, представленная на рис. 1, начинающаяся с цели (с указанием цели измерения: объекта, который необходимо измерить: проблемы, которую необходимо измерить, и точки зрения, с которой принимается измерение). Цель уточняется в нескольких вопросах, таких как вопрос в примере выше, которые обычно разбивают проблему на ее основные компоненты. Затем каждый вопрос превращается в метрики. Некоторые из них объективны, некоторые из них субъективны. Один и тот же показатель можно использовать для ответа на разные вопросы по одной и той же цели. Несколько моделей GQM также могут иметь общие вопросы и метрики, чтобы гарантировать, что, когда мера действительно принята, разные точки зрения учитываются правильно (то есть метрика может иметь разные значения, когда берется с разных точек зрения). Чтобы дать наглядный пример подхода GQM, предположим, что мы хотим улучшить своевременность обработки запросов изменения на этапе обслуживания жизненного цикла системы. Итоговая цель будет определять намерение (улучшить), процесс (обработка запроса на изменение), точку зрения (менеджера проекта) и аспект качества (своевременность). Эту цель можно уточнить с помощью ряда вопросов, например, о времени выполнения и количества ресурсов, требуемых для выполнения запросов. На эти вопросы можно ответить с помощью показателей, сравнивающих конкретное время обработки запроса со средними показателями. Полная модель GQM показана в таблице 1.

Таблица 1

Пример полной модели GQM

Подход к развертыванию функции качества (QFD — Quality Function Deployment) — это процесс или набор инструментов, используемых для определения требований заказчика к продукту и преобразования этих требований в технические спецификации и планы таким образом, чтобы требования заказчика к этому продукту были удовлетворены.

QFD был разработан в конце 1960-х годов японским специалистом по планированию Йоджи Акао.

QFD стремится преобразовать пожелания клиента в измеримые и детализированные проектные цели.

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

Метод всеобщего управления качеством (TQM — Total Quality Management) во многих организациях стал важным аспектом методик общего повышения качества. В частности, QFD, являющимся средством реализации TQM, был предложен как эффективный подход для реализации методик повышения качества в различных средах продуктов и услуг. Адаптированный QFD для разработки программного обеспечения — SQFD.

Развертывание функции качества (SQFD — Software Quality Function Deployment). SQFD представляет собой перенос технологии QFD из традиционной производственной среды в среду разработки программного обеспечения. SQFD — это метод запроса требований внешнего интерфейса, который можно адаптировать к любой методологии разработки программного обеспечения, которая количественно запрашивает и определяет критически важные требования клиентов. Будучи методологией для внешнего интерфейса, SQFD представляет собой адаптацию матрицы «Дом качества», наиболее часто используемой в традиционной методологии QFD. На рис. 2 представлен обзор процесса SQFD со следующими шагами.

Рис. 2. Структура процессов SQFD

Шаг 1. Требования клиентов запрашиваются и записываются слева от оси y. В число клиентов входят конечные пользователи, менеджеры, персонал по разработке системы и любые люди, которым будет выгодно использование предлагаемого программного продукта. Требования обычно представляют собой короткие заявления, записанные специально в терминологии клиентов (например, «легкий в освоении»), и сопровождаются подробным определением, словарем данных версии SQFD.

Шаг 2: В сотрудничестве с клиентами требования затем преобразуются в технические и измеримые формулировки программного продукта и записываются сверху оси x. Например, «легкий в освоении» можно преобразовать во «время, необходимое для завершения обучения», «количество иконок» и «количество средств справки онлайн». Здесь важно отметить, что некоторые требования клиентов могут быть преобразованы в различные технические характеристики продукта, что делает крайне важным активное участие пользователя. Кроме того, технические характеристики продукта должны быть измеримыми в той или иной форме. Используемые метрики обычно основаны на числах, но также могут быть логического типа. Например, требование клиента «предоставляет несколько форматов печати» может быть преобразовано в «количество форматов печати» (с использованием числовой метрики) и «выполняет альбомную печать» (измеряется через «Да» или «Нет»).

Шаг 3: Затем клиентов просят заполнить матрицу корреляции, определив силу взаимосвязей между различными требованиями клиентов и техническими характеристиками продукта. Например, «легкий в освоении» сильно коррелирует с «время, необходимое для завершения обучения» (высокая корреляция может получить оценку 9 в матрице корреляции), но не коррелирует с «выполняет альбомную печать» (которая получит оценку 0 в матрице корреляции). Поскольку в этот процесс вовлечено множество клиентов, важно достичь соглашения относительно силы взаимосвязей.

Шаг 4: На основе данных опроса клиентов определяются приоритеты для указанных требований клиентов. Эти приоритеты перечисляются на правой оси y. На этом этапе у клиентов может быть получена дополнительная информация об оценке программных продуктов конкурентов. Данные также могут быть получены от команды разработчиков относительно показателей продаж и улучшений.

Шаг 5: Этот процесс включает в себя разработку приоритетов технических характеристик продукта (нижняя ось x) путем суммирования результатов умножения приоритетов требований клиентов на корреляцию значения между требованиями клиента и техническими характеристиками продукта. Эти исходные веса приоритета для технических спецификаций продукта затем обычно конвертируются в процент от общих необработанных весов приоритета. У команды разработчиков могут быть запрошены дополнительные данные, касающиеся целевых показателей технических характеристик продукта, а также оценки стоимости, сложности и выполнимости графика. Конечный результат процесса SQFD будет, как минимум, содержать измеримые технические характеристики продукта, процент их важности и целевые измерения. Затем эта информация передается в качестве входных данных в жизненный цикл разработки ПО (SDLC — Software development lifecycle). Полная модель SQFD показана в таблице 2.

Таблица 2

Пример полной модели SQFD

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

Рассмотрим сравнение двух методологий, представленных в таблице 2 и 3. Чтобы следовать как требованиям интерфейса, так и техническими требованиями, необходимо исследовать пути достижения этих спецификаций. GQM обладает такой методологией — это более детальный подход к рассмотрению необходимых требований. Постановка целей и их декомпозиция в виде вопросов, помогает ускорить процесс обозначения потребностей и пути их достижения, выраженных в метриках. Что позволяет контролировать процесс разработки программного обеспечения, поставляя на выход программный продукт с необходимыми, проверенными характеристиками. Также для предоставления качественной системы необходимо более явные, согласованные и критически важные потребности, которые в SQFD выясняются с помощью матрицы корреляции мнений пользователей.

Достоинства и недостатки SQFD и GQM

Таблица 3

Сравнения SQFD и GQM

Для оценки влияния методологий SQFD и GQM на время выполнения задачи для программиста, используется метод PERT — Program Evaluation and Review Technique [9]. Например, если поставлена задача — улучшить производительность обработки запроса на изменение, тогда время выполнения рассчитывается по формуле

, (1)

где O — оптимистическая оценка длительности задачи, M — наиболее вероятная оценка длительности задачи, P — пессимистическая оценка длительности задачи.

Предположим, что программист оценивает наиболее вероятное время, необходимое для завершения задачи в 3 дня, при условии возникновения стандартных задержек и сдвигов сроков, оцененных на основании предыдущего опыта. Оптимистичная оценка составляет 1 день — при условии, что задача будет выполняться без каких-либо задержек и ни один из рисков не реализуется. Пессимистичный прогноз выполнения задачи составляет 7 дней, если произойдут все возможные задержки и реализуются риски. Оценка длительности задачи, рассчитанная по методу PERT равна ((1 + 4*3 + 7))/6 = 3.3 дня.

Применяя методологии GQM, программист будет уже знать, по какой метрике оценивать производительность процесса, значит определение внесенных изменений будет точнее. Возможно, метрика будет включена в тесты и проверена на нескольких процессах. За счет этого риск ошибочного суждение о возможном улучшении производительности не появится. На основе экспертного мнения специалистов одной из компаний по разработке программных продуктов в г. Красноярск предположим, что предотвращение одного риска сокращает на 1 день длительность работы на задачу при пессимистическом прогнозе, соответственно ((1 + 4*3 + 6))/6= 3.1 дня.

Исходя из того, что в SQFD учитывается потребности пользователя, будут задокументированы важные технические требования к продукту. Относительно задачи производительности процесса в документации будет указано конкретное время ожидания на запрос, что поможет во время выполнения задачи остановиться на необходимых значениях улучшенного времени выполнения. В данном случае будет учитываться задокументированное время выполнения запроса на изменения от клиента, а не субъективная оценка руководителя. Что поможет предотвратить риск неудовлетворенности клиента и не повлечь дополнительных доработок. В итоге пессимистичный прогноз выполнения задачи можно сократить на 2 дня ((1 + 4*3 + 5))/6 = 3 дня.

Литература:

1. Управление качеством программного обеспечения: учебник / Б. В. Черников. — М.: ИД «ФОРУМ»: ИНФРА-М, 2012. — 240 с.

2. M. Kogure, Y. Akao, «Quality Function Deployment and CWQC in Japan»,Quality Progress, October 1983, pp.25–29.

3. V. R. Basili, «Software Modeling and Measurement: The Goal Question Metric Paradigm», Computer Science Technical Report Series, CS-TR-2956 (UMIACS-TR-92–96), University of Maryland, College Park, MD, September 1992.

4. V. R. Basili, H. D. Rombach, «The TAME Project: Towards ImprovementOriented Software Environments», IEEE Transactions on Software Engineering, vol.SE-14, no.6, June 1988, pp.758–773.

5. V. R. Basili, R. W. Selby, «Data Collection and Analysis in Software Research and Management», Proceedings of the American Statistical Association and Biomeasure Society, Joint Statistical Meetings, Philadelphia, PA, August 1984.

6. R. Basili, D. M. Weiss, «A Methodology for Collecting Valid Software Engineering Data», IEEE Transactions on Software Engineering, vol. SE-10, no.6, November 1984, pp. 728–738.

7. W. Boehm, J. R. Brown, and M. Lipow, «Quantitative Evaluation of Software Quality», Proceedings of the Second International Conference on Software Engineering, 1976, pp.592–605.

8. J. A. McCall, P. K. Richards, G. F. Walters, «Factors in Software Quality, «Rome Air Development Center, RADC TR-77–369, 1977.

9. Boushaala, Amer (2014). An approach for project scheduling using PERT/CPM and Petri Nets (PNs) Tools, Industrial engineering and operations management, Vol 5, No 85, PP 939–947.