Автоматизированная проверка качества требований. Ошибки типа «Неопределенность».

Мадорская Ю.М.
к.т.н., доцент СПбГПУ 

Введение

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

  • Качество – свойства (особенности) продукта или услуги, которые отвечают потребностям клиентов и тем самым обеспечивают их удовлетворенность [2].
  • Качество – свобода от дефектов (ошибок) [2].

В рамках данной статьи остановимся на втором определении понятия качества и поговорим об ошибках в требованиях. 

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

Исследование, посвященное обзору литературы по теме классификации ошибок в требованиях, проведенное  Walia и его коллегами в 2007 году, показывает, что большая часть классификаций ошибок чаще всего содержит описание ошибок в реализации системы, но не в требованиях. В то время как данные ошибки являются зачастую лишь симптомами ошибок в требованиях [3], [4].  Ошибки же в самих требованиях детализируются редко, несмотря на признание того, что на их устранение по данным отчета Lientz и Swanson [5]  идет около 21% затрат на сопровождение системы. 

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

  • Требование к системе (требование) – задокументированное, с использованием выбранного метода описания высказывание, определяющее свойства системы и ее окружения, которое должно быть истинно для реализации системы

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

Всего выделено три класса и 11 подклассов ошибок:

Некорректность требования

  • Синтаксическая ошибка
  • Семантическая ошибка
  • Неоднозначность
  • Неопределенность

Ошибка в системе требований 

  • Неполнота
  • Избыточность
  • Противоречивость
  • Дублирование

Ошибка несоответствия внешнему объекту

  • Непроверяемость
  • Недостоверность
  • Неадекватность

Формальную спецификацию классов ошибок можно найти в соответствующей в исходной работе.

Некоторые из приведенных классов ошибок возможно контролировать  автоматизированно или даже автоматически. Часть функций по такому контролю может взять на себя 3SL Cradle (по сравнению с другими системами — большую часть).

Например, за счет стоп-листов и трассировки можно контролировать появление ошибок класса «Неопределенность». Применение MBSE (за счет выбранной модели трассировки или использования встроенного моделирования с проверщиком согласованности) позволяет контролировать ошибки классов Неполнота/Избыточность.

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

Автоматизированный контроль ошибок типа «Неопределенность»

Ошибки типа «Неопределенность» означают, что невозможно построить интерпретацию высказывания, которое заявлено как требование к системе.

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

В последних версиях Cradle появился удобный механизм, который называется «Проверщик согласованности» и который позволяет контролировать появление требований, содержащих слова из заданного стоп-листа. По умолчанию данный список заполнен английскими аналогами слов, означающих неопределенность. Этот список настраивается в установках проекта, в разделе «Проверщик соответствия» на вкладке «Неточности»:

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

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

Примечание: в версии 6.7 работает только для английского языка. Поддержку русского для этих функций планируется реализовать в версии 6.8.2 (июнь-июль 2013)  или 7.0 (осень 2013).

 

Литература

  1.  Мадорская Ю. М., Метод оценки сложности модификации программного обеспечения АСУП: дис. … канд. техн. наук: 05.13.06/ Мадорская Юлия Михайловна; Санкт-Петербургский государственный политехнический университет; науч. рук. Курочкин М. А. — СПб., 2011. — 205с. : ил.- Библиогр.: с. 138-148
  2. Joseph M. Juran. Juran’s quality handbook / Joseph M. Juran, A. Blanton Godf rey. – New York: McGraw-Hill, 1998. – 1730 p. – ISBN 0-07-034003-X.
  3. Walia G., Carver J. Development of Requirement Error Taxonomy as a Quality Improvement Approach: A Systematic Literature Review. / Technical Report, Department of Computer Science and Engineering, Mississippi State University, 2007. –  54 p.
  4. Walia G. S., Carver J. C., Philip T. Requirement Error Abstraction and Classification: A Control Group Replicated Study // Proceedings of the the 18th IEEE international Symposium on Software Reliability.  IEEE Computer Society, Washington, DC, USA, 2007. –  P. 71-80.
  5.  Lientz B.P., Swanson E.B. Software Maintenance Management / B.P. Lientz, E.B. Swanson. –  Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 1980. – 160 p.  
Присоединиться в facebook или linkedin

Комментарии

комментарии

Комментарии закрыты.