уровень разработки вопроса формализации и оценки качества

СБОРНИК НАУЧНЫХ ТРУДОВ НГТУ. – 2008. – № 2(58). – 65–70
УДК 004.414.3
УРОВЕНЬ РАЗРАБОТКИ ВОПРОСА ФОРМАЛИЗАЦИИ
И ОЦЕНКИ КАЧЕСТВА ТРЕБОВАНИЙ
Н.В. ПУСТОВАЛОВА
Проанализирован уровень разработки вопроса формализации и оценки качества требований. Приведено определение ключевых понятий предметной области, перечислены
основные проблемы, присущие процессу разработки требований. Сделаны выводы о
перспективах дальнейшего исследования.
ВВЕДЕНИЕ
По оценкам Д. Леффингуэлла и Д. Уидринга, стоимость исправления
ошибок, «просачивающихся» с одной разработки на другую, возрастает на
порядок [1]. Вместе с тем этап разработки требований представляется самым
проблемным в процессе создания ПО.
«Строжайшее и единственное правило построения систем программного
обеспечения (ПО) – решить точно, что же строить. Никакая другая часть концептуальной работы не является такой трудной, как выяснение деталей технических требований, в том числе и взаимодействие с людьми, с механизмами
и с иными системами ПО. Никакая другая часть работы так не портит результат, если она выполнена плохо. Ошибки никакого другого этапа работы не
исправляются так трудно» [2].
1. ОПРЕДЕЛЕНИЕ КЛЮЧЕВЫХ ПОНЯТИЙ ПРЕДМЕТНОЙ
ОБЛАСТИ
Для начала необходимо более точно определить понятия предметной области, которые будут использоваться в статье.
Определение понятия «требование» возьмем из стандарта IEEE Std. 610 12,
«IEEE Standard Glossary of Software Engineering Terminology».
Требование:
– условие или возможность решения задач или достижения целей;
– условие или возможность, которые должны удовлетворяться системой/компонентом системы, или которыми система/ компонент системы должна обладать для обеспечения условий контракта, стандартов, спецификаций
или других регулирующих документов;

Аспирант кафедры экономической информатики
66
Н.В. Пустовалова
– документальная репрезентация условий или возможностей, перечисленных в предыдущих пунктах.
Многие авторы в ходе описания процесса работы с требованиями используют формулировку «система требований» и указывают на важность данного
элемента для достижения качественного результата разработки [7–10]. Однако никто из исследователей не дает точного определения, не приводит полного описания свойств системы требований, не определяет, какие критерии служат для её оценки.
Между тем данное понятие предметной области можно считать ключевым, когда дело касается вопроса обеспечения качества результата процесса
разработки требований. И вот почему.
Во-первых, между многими отдельными требованиями существуют зависимости, обусловленные спецификой предметной области.
Во-вторых, термин «система» подразумевает наличие определенных,
стандартных для проекта, методов и процедур управления и обработки требований.
В-третьих, наличие системы требований подразумевает, что в ходе проекта выработан определенный стандарт документирования требований. Это в
свою очередь влияет на возможность упорядочения и хранения информации,
автоматизации поиска и построения моделей, например с применением UML.
В-четвертых, такое свойство систем, как неаддитивность – принципиальная несводимость свойств системы к сумме свойств составляющих её компонентов – увеличивает ценность конечного продукта для пользователя. Потому
необходимо попытаться спрогнозировать и учесть, какая дополнительная
ценность продукта будет обусловлена именно этим свойством системы требований.
Качество программного продукта – способность реализовать функции,
необходимые и достаточные пользователю для решения его бизнес-задач.
Качественный результат процесса разработки требований – система
требований проекта, обеспечивающая возможность создания качественного
программного продукта за счет определения и документирования однозначных формулировок отдельных требований и управления системой требований
проекта в процессе разработки.
Система требований проекта – совокупность задокументированных отдельных требований, организованных определенным образом, обладающая
следующими свойствами:
1) полнота (охвачена вся область задач всех типов пользователей);
2) непротиворечивость (найдены решения для реализации формулировок
требований, изначально противоречащих друг другу);
3) отслеживаемость и трассируемость (изменения, производимые в процессе разработки требований, должны быть очевидными как для системы в
целом, так и для отдельных требований, а также для их взаимосвязей);
Уровень разработки вопроса формализации…
67
4) понятность (система требований должна иметь единственно возможную интерпретацию, чтобы не возникало разногласий между заказчиком и
разработчиком, а также в коллективе разработчиков в процессе реализации и
приемки ПО);
5) адекватность (в результате реализации описанной системы требований
полученный программный продукт должен предоставлять пользователям
функционал, пригодный для решения их бизнес-задач с учетом оговоренных
ограничений).
Данное определение было сформулировано в качестве гипотезы, и в ходе
исследования оно будет проверено на корректность и адекватность. Предполагается, что определение будет использовано при формировании набора критериев для оценки качества требований.
Обобщая мнения различных специалистов в предметной области, процесс
разработки требований можно определить как выявление требований к системе, их систематизацию, документирование, анализ, выявление противоречий, неполноты и согласование с заказчиком.
Процесс управления требованиями – это систематический подход к выявлению, организации и документированию требований к ПО, а также выработка и обеспечение соглашения между заказчиком и группой разработчиков,
выполняющих проект [2].
Это определение [2] хотелось бы уточнить. Можно предположить, что успешное управление процессом разработки требований к программному обеспечению, цель которого – обеспечение качественного результата, должно
включать, с одной стороны, управление конкретными требованиями, с другой
– управление системой требований проекта. На рисунке изображена взаимосвязь управления системой требований проекта и отдельными требованиями.
Управление требованиями и системой требований проекта
2. ОБЗОР И АНАЛИЗ ПРОБЛЕМ, ВЫДЕЛЯЕМЫХ В ПРОЦЕССЕ
РАЗРАБОТКИ ТРЕБОВАНИЙ К ПО
На основании анализа работ различных исследователей были выявлены
наиболее часто возникающие в процессе разработки требований к ПО проблемы:
68
Н.В. Пустовалова
1) проблемные ситуации процесса формирования и оценки требований [1]:
– пропуск типов пользователей;
– двусмысленность требований;
– добавление разработчиками функций, которых нет в спецификации;
2) проблемные ситуации процесса управления требованиями [4]:
– многочисленность источников, из которых взяты требования;
– неочевидность требований;
– невозможность легко выразить требование словами;
– множество различных типов требований и различных уровней их детализации;
– противоречивость требований;
– уникальность требований;
– компромиссность требований;
– изменяемость требований;
– зависимость требований от времени;
– трудность оценивания требований.
Характеризуя общее состояние разработанности вопросов формализации
и оценки качества требований, можно утверждать, что формализация требований имеет общий характер независимо от специфики производства. Разработан достаточно мощный методологический аппарат, аккумулирующий знания из различных дисциплин – от математики и статистики до психологии и
языкознания.
В вопросах оценки качества требований к ПО необходимо гораздо больше
внимания уделять специфике предметной области. Если требование к какойлибо детали или агрегату можно заранее четко задать в конкретных единицах,
то при разработке ПО это зачастую невозможно. Поэтому одной из первостепенных проблем становится оценка качества требований, тщательный и объективный анализ того, насколько разработанный продукт будет соответствовать потребностям пользователя.
Специфичность процесса разработки отчасти связана с тем, что требования формализуют на искусственных языках. Необходимость автоматизации
порождает дополнительные сложности, так как возникает дополнительное
искажение информации при переводе требований с естественного языка на
искусственный. Рост количества переводов увеличивает вероятность смысловых искажений, тем самым требуя дополнительных методов контроля и проверки.
В вопросах оценки требований много места занимает эмпирический опыт
как отдельно взятых специалистов, так и закрепленный в стандартах. Это связано с тем, что развитие данной области происходит снизу вверх. Пока единой
обобщающей системы взглядов, одной общей теории нет. Эта система только
формируется.
Современные концепции управления ориентированы на качество продукта, на создание ценности для пользователя. В свою очередь вопрос качества
Уровень разработки вопроса формализации…
69
ПО зависит от того, насколько качественно были сформулированы требования.
Анализ литературы, посвященной изучению требований, позволяет рассмотреть процесс разработки требований в свете следующих аспектов [8–10]:
1) модель жизненного цикла продукта, применяемая при разработке;
2) дисциплины, необходимые для разработки требований к ПО;
3) методология разработки;
4) нотация и CASE-средство, используемые при создании ПО;
5) стандарты, регламентирующие процесс разработки;
6) методы, применяемые для проверки качества требований.
Данная структура позволит оценить все нюансы процесса разработки требований и на основе их анализа сформировать рекомендации по использованию тех или иных методов формализации и оценки качества требований для
конкретного проекта. Предполагается, что данная формальная структура может быть положена в основу методики управления системой требований, учитывающей всю её сложность и изменчивость.
ЗАКЛЮЧЕНИЕ
Каждая из названных выше проблем представляет собой комплекс задач, с
которыми сталкивается любая команда разработчиков в процессе создания
ПО. Для решения части из них есть разработанные и опробованные формальные методы. Решение оставшейся части проблем, в основном относящихся к
вопросу оценки качества требований, открывает широкие перспективы для
исследований. В частности, весьма перспективен вопрос оценки возможности
применения методик и алгоритмов, разработанных для решения аналогичных
задач в других предметных областях.
[1] Леффингуэлл Д., Уидринг Д. Принципы работы с требованиями к программному обеспечению. – М., 2002. – C. 5–23.
[2] Маглинец Ю.А. Анализ требований к автоматизированным
информационным системам: курс лекций. Режим доступа: [http://www.intuit.ru
/department/itmngt/analisis/4/].
[3] Скопин И.Н. Основы менеджмента программных проектов: курс лекций. Режим доступа: [http://www.intuit.ru/department/itmngt/manag/1/].
[4] Вигерс К. Разработка требований к программному обеспечению. – М.,
2004.
[5] Орлов. С. Технологии разработки программного обеспечения. – СПб.,
2002.
[6] Баутов А. Оценка факторов, влияющих на качество программных продуктов. Режим доступа: [http://www.osp.ru/cio/2001/11-12/171992/].
70
Н.В. Пустовалова
[7] Коберн A. Современные методы описания функциональных требований к системам. – М., 2002.
[8] Мацяшек Лешек А. Анализ требований и проектирование систем. Разработка информационных систем с использованием UML. – М., 2002.
[9] Трофимов C. Методы сбора требований к программному обеспечению.
Режим доступа: [http://journal.caseclub.ru/articles/trebmethod.html].
[10] Тэйер P. Системная инженерия программного обеспечения: введение.
Режим доступа: [http://www.osp.ru/os/2002/05/181460/_p1.html].
[11] Новичков А. Роль процесса управления требованиями при разработке
сложных программных систем. Практика применения методологии IBM RUP
и инструмента IBM Rational RequisitePro. Режим доступа: [http://cmcons.ru/
requisite_02.htm].
[12] Алфимов P. Управление требованиями на базе стандартов. Режим
доступа: [http://www.osp.ru/os/2006/10/3910108/].