О проблеме образования в области инженерии программного обеспечения

Мадорская Ю.М., Тимофеев А.Н.

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

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

Чаще всего за основу изложения той или иной темы, связанной с управлением требованиями к программному обеспечению, берется определение из международного стандарта IEEE Standard Glossary of Software Engineering Terminology, которое  нельзя назвать ни однозначным, ни формальным. В переводе с английского данное определение приводится следующим образом [1]:

1. Условия или возможности, необходимые пользователю для решения проблем или достижения целей.

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

3. Документированное представление условий или возможностей для пунктов 1 и 2.

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

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

Соммервиль И., в известной и часто цитируемой книге  «Инженерия программного обеспечения», определяет требования, как описание функциональных возможностей и ограничений, накладываемых на программную систему [6]. Очевидно, что такое определение понятия требования не включает ни требований к структуре системы, ни к ее интерфейсу, а также многих других, так называемых нефункциональных требований.

Многие авторы [3], [9], в книгах и публикациях по темам управление требованиями к ПО, выявление ошибок в требованиях, вообще избегают определения данного понятия. Так,  например, Алистер Коберн в книге «Современные методы описания функциональных требований к системам» не дает определения ни понятия требования, ни функционального требования [3].

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

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

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

Необходимо отметить, что многие исследователи в своих работах, посвященных решению проблемы трассировки требований, пошли по такому же пути, как и Gotel  с соавторами  – определение связей между требованиями и другой проектной информацией без четкого определения того, что же стоит за понятием «требование» [10]. Действительно, это один из экономных, (но не полноценных) путей решения задачи – выделить все то, что не является, по мнению разработчиков метода, требованием и показать, как нечто, именуемое требованием, связано с этими категориями. Результаты исследования, проведенного Bala Ramesh [10], говорят о том, что именно такой подход отражает  практику разработки и управления требованиями. Неудивительно,  что при таком подходе проблема ошибок в требованиях остается основной в индустрии разработки ПО, а задача трассируемости требований остается нерешенной – невозможно бороться с ошибками в неопределенном наборе информации,  связи внутри которого невозможно определить из-за той же неопределенности состава данной информации.

Ошибки в интерпретации понятия «требование» тиражируются впоследствие и в инструментарии. Так, например, методы трассировки требований, поддерживаемые инструментами, строятся исходя из предположения, что все множество требований и соответствующие им проектные решения, а также другие проектные артефакты можно разделить на непересекающиеся множества, между которыми связей нет.  Иначе нельзя интерпретировать то, что в таком популярном инструментарии как Requisite Pro невозможно задать уровень оценки распространения изменений. Это в корне неверно, так как ключевое свойство системы — это связанность всех ее компонентов, и при правильном описании множества требований и проектных решений, при изменении одного требования, в результате (без применения специальных эвристик, ручного отбора или выставления ограничений по уровню поиска) инструментарий должен выдать все множество проектных артефактов заложенных в систему, то есть функция определения связанных артефактов без дополнительных ограничительных настроек не имеет смысла для правильно спроектированной системы. Таким образом, ошибки связанные с неполнотой описания требований фактически зафиксированы и поощряются на уровне основного инструментария проектировщиков.

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

В рамках задачи  по разработке метода формирования оценки изменений программного обеспечения [4] была разработана система определений, обеспечивающая согласованный терминологический базис для формализации данной задачи. Система определений основывается на понятиях  математической логики [2]  и глоссарии руководства по разработке спецификаций требований к системе [8], определяющем понятие системы. Структура системы определений представлена на рисунке справа. Ниже приведена часть разработанной системы определений.

  • Высказывание – правильно построенная формула языка, взятая вместе с ее интерпретацией, в отношении которой имеет смысл утверждать, что она истинна или ложна.
  • Описание – совокупность высказываний.
  • Правила описания —  совокупность истинных высказываний, определяющих  правила построения описания с учетом интерпретаций входящих в него высказываний.
  • Метод описания – формальная система, предназначенная для формирования описаний с целью решения задачи моделирования, включающая язык и  правила описания сформулированные с использованием данного языка.
  • Метод решения задачи моделирования – формальная система, предназначенная для решения задачи моделирования,  включающая метод описания и правила вывода решения задачи моделирования, сформулированные с использованием языка метода описания.
  • Предметная константа – набор символов, обозначающий понятие рассматриваемой предметной области.
  • Предикат – функция, значениями которой служат высказывания, при подстановке в аргументы предметных констант.
  • Взаимосвязанные высказывания – высказывания, для которых соответствующие им предикаты содержат хотя бы одну одинаковую предметную константу.
  • Система – взаимосвязанная группа людей, объектов и процедур организованных для достижения заданных целей, посредством выполнения заданных функций. [8].
  • Окружение системы (окружение) —  среда, в которой должна функционировать разрабатываемая система.
  • Требование к системе (требование) – задокументированное, с использованием выбранного метода описания, высказывание, определяющее свойства системы и ее окружения, которое должно быть истинно для реализации системы.
  • Взаимосвязанные требования к системе (взаимосвязанные требования) – требования к системе, построенные с использованием взаимосвязанных высказываний.
  • Эквивалентные требования – требования, имеющие одинаковую интерпретацию.
  • Частная проектная модель системы/компонента системы (ЧПМ) – описание состоящее из взаимосвязанных требований к системе, ограниченное набором таких свойств системы и ее окружения, который необходим и достаточен для решения задачи моделирования.
  • Проектная модель системы/компонента системы – множество взаимосвязанных частных проектных моделей ограниченное набором таким набором частных проектных моделей, который необходим и достаточен для реализации системы или ее компонента, соответствующей(его) целям создания системы.

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

  • необходимость определения целей системы и соответствие требований данным целям;
  • тестируемость требований — возможность установить истинность или ложность требования для реализации системы;
  • необходимость описания условий функционирования системы – требований к ее окружению;
  • взаимосвязанность требований.

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

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

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

Разработанная согласованная система определений успешно применена при разработке формального метода формирования оценки изменений программного обеспечения АСУП [4]. Использование предложенного подхода к формализации понятия «требование» позволило разработать методы контроля ошибок в требованиях, позволяющие повысить точность и сократить время формирования оценки изменений.

Литература

  1. Вигерс К.И. Разработка требований к программному обеспечению.// Москва,2004.
  2. Горский Д.П., Ивин А.А., Никифоров АЛ. Краткий словарь по логике – М.: Просвещение, 1991.
  3. Коберн А.. Современные методы описания функциональных требований к системам. //Изд-во: Лори, Москва:2002.
  4. Мадорская Ю.М, Формирование оценки изменений программного обеспечения АСУП // Научно-технические ведомости СПбГПУ, №I (115) .- 2011 С.- 65-72
  5. Лаврищева Е.М., Петрухин В.А. Методы и средства инженерии программного обеспечения: Учебник. — М.: МФТИ (ГУ), 2006. — 304 с.
  6. Соммервиль И., Инженерия программного обеспечения.// Изд. дом «Вильямс»:2002.
  7. Gotel O., Finkelstein A.. An Analysis of the Requirements Traceability Problem. In Proc. 1st IEEE Int. Conf. on Requirements Engineering, pages 94-101, Colorado Springs, April 1994.
  8. IEEE Standard 1233 -1998 Guide for Developing System Requirements Specifications.
  9. Kimberly S. Hanks, John C. Knight, Elisabeth A. Strunk. Erroneous Requirements: A Linguistic Basis for Their Occurence and an Approach to Their Reduction (2001)
  10. Ramesh, B. and Jarke, M. 2001. Toward Reference Models for Requirements Traceability. IEEE Trans. Softw. Eng. 27, 1 (Jan. 2001), 58-93.

Мадорская Ю.М., Тимофеев А.Н. О проблеме образования в области инженерии программного обеспечения. //Практика проектирования систем.-2013. [электронный ресурс] — Режим доступа: http://reqcenter.pro/on-a-problem-in-seedu/ , свободный. — Загл. с экрана

Опубликовано в: