Отслеживаемость требований
Отслеживание требований — это раздел управления требованиями в рамках разработки программного обеспечения и системной инженерии . Прослеживаемость как общий термин определяется словарем системной и программной инженерии IEEE. [1] как (1) степень, в которой может быть установлена взаимосвязь между двумя или более продуктами процесса разработки, особенно продуктами, имеющими отношение предшественник-преемник или первично-подчиненное отношение друг к другу; [2] (2) идентификация и документирование путей вывода (вверх) и путей распределения или спуска (вниз) рабочих продуктов в иерархии рабочих продуктов; [3] (3) степень, в которой каждый элемент продукта разработки программного обеспечения оправдывает свое существование; и (4) заметная связь между двумя или более логическими объектами, такими как требования, элементы системы, проверки или задачи.
В частности, прослеживаемость требований определяется как «способность описывать и отслеживать жизненный цикл требования как в прямом, так и в обратном направлении (т. постоянных доработок и итераций на любом из этих этапов)". [4] [5] В области разработки требований прослеживаемость заключается в понимании того, как требования высокого уровня – задачи, задачи, стремления, ожидания, бизнес-потребности – преобразуются в готовые к разработке низкоуровневые требования. Поэтому в первую очередь речь идет об удовлетворении отношений между слоями информации (так называемыми артефактами). [6] Однако прослеживаемость может документировать взаимосвязи между многими видами артефактов разработки, такими как требования, спецификации, проекты, тесты, модели и разработанные компоненты. [7] Например, общепринятой практикой является запись связей проверки, чтобы продемонстрировать, что требование проверено определенным тестовым артефактом.
Прослеживаемость особенно важна при разработке систем, критически важных для безопасности, и поэтому предписана руководящими принципами безопасности , такими как DO178C , ISO 26262 и IEC61508 . Общим требованием этих руководств является то, что критические требования должны быть проверены и что эта проверка должна быть продемонстрирована посредством прослеживаемости. [8]
Отслеживание в направлении и за пределами требований
[ редактировать ]Прослеживаемость предварительных требований . [4] Требования исходят из разных источников, например, от делового человека, заказывающего продукт, менеджера по маркетингу и фактического пользователя. У всех этих людей разные требования к продукту. Используя прослеживаемость требований, реализованную функцию можно отследить до человека или группы, которые хотели ее во время выявления требований . Это можно использовать в процессе разработки для определения приоритетности требований и определения того, насколько ценно требование для конкретного пользователя. Его также можно использовать после развертывания, чтобы понять, почему в первую очередь потребовались определенные неиспользуемые функции, обнаруженные в ходе исследований пользователей.
Прослеживаемость после выполнения требований . [4] Необходимо отслеживать не только сами требования, но и связь требований со всеми связанными с ними артефактами, такими как модели, результаты анализа, тестовые примеры, процедуры тестирования, результаты тестирования и документация всех видов. Даже люди и группы пользователей, связанные с требованиями, должны быть прослеживаемыми. Требования воплощаются в артефакты проектирования, реализации и, наконец, проверки. Артефакты, связанные с последними этапами, также следует отнести к требованиям. Обычно это делается с помощью матрицы прослеживаемости требований .
Установление прослеживаемости помимо требований к артефактам проектирования, реализации и проверки может оказаться затруднительным. [9] Например, при реализации требований к программному обеспечению требования могут находиться в инструменте управления требованиями , а артефакты проектирования могут находиться в инструменте проектирования.Более того, артефакты реализации, скорее всего, будут иметь форму исходных файлов, ссылки на которые можно устанавливать различными способами в различных областях. Артефакты проверки, например, созданные внутренними тестами или формальными инструментами проверки.
Интеграция репозитория или стека инструментов может представлять собой серьезную проблему для обеспечения прослеживаемости в динамической системе.
Использование информации о отслеживаемости
[ редактировать ]Использование прослеживаемости, особенно при отслеживании требований ко всем артефактам, расположенным в цепочке инструментов, может принести несколько преимуществ: [10] [11]
- Анализ влияния изменений – если требование меняется, ссылки трассировки информируют о связанных и зависимых артефактах. Эти артефакты можно легко проверить и при необходимости откорректировать. Вероятность пропустить связанные артефакты уменьшена.
- Анализ покрытия: прослеживаемость гарантирует, что ни одно требование не будет упущено из виду. Особенно при сертификации продукции, критически важной для безопасности, необходимо продемонстрировать, что все требования реализованы.
- Анализ статуса проекта – возможно отслеживание статуса проекта: анализ данных отслеживания позволяет увидеть статус выполнения требований. Требования без связей или с неполной цепочкой трассировки (например, требования с реализацией, но без тестов) указывают на необходимость дальнейшей работы. Недостающие звенья показывают, каких конкретных артефактов не хватает и которые необходимо реализовать.
- Повторное использование компонентов продукта — можно структурировать требования и связанные с ними артефакты в пакетах. Эти пакеты можно использовать для разных продуктов.
- Постоянные отношения – часто знания о проекте или продукте находятся в голове конкретных людей. Благодаря использованию прослеживаемости эти знания сохраняются за счет визуализации связей между различными артефактами. Эти знания остаются, даже если человек уходит из проекта.
- Оптимизация тестирования — связывая требования, исходный код , тестовые примеры и результаты тестов, можно легко выявить затронутые части исходного кода в случае неудачного теста. Кроме того, можно выявить и устранить избыточные тестовые примеры.
Более полный обзор деятельности по разработке, поддерживаемой прослеживаемостью, и ее значимости дан в. [12]
Практическое использование информации о отслеживаемости
[ редактировать ]Обширные исследования подтверждают эффективность, но также и трудности сбора информации о отслеживаемости:
- Прослеживаемость ускоряет и улучшает деятельность по разработке. Исследование с участием 71 участника, внесшего изменения в исходный код с поддержкой прослеживаемости и без нее, показало преимущества прослеживаемости. Разработчики выполняли задачи с поддержкой отслеживания на 24 % быстрее и на 50 % точнее. [13]
- Более полная отслеживаемость помогает избежать дефектов программного обеспечения. При анализе данных разработки 24 средних и крупных проектов с открытым исходным кодом была обнаружена статистически значимая связь между полнотой собранной отслеживаемой информации и уровнем дефектов разработанного исходного кода. Компоненты с более полной отслеживаемостью показали меньшее количество дефектов (т.н. ошибок). [14]
- Обеспечить прослеживаемость, соответствующую требованиям, сложно. Анализ предпродажного тестирования программного обеспечения для медицинских устройств, проведенного Управлением по контролю за продуктами и лекарствами США (FDA) в 2013 году, выявил значительные пробелы между предписанной и зарегистрированной информацией о прослеживаемости. [8] Стремление к прослеживаемости, соответствующей стандартам, часто приводит к «большому замораживанию». Большая заморозка, поскольку компании стремятся избежать дальнейшего развития, поскольку повторная сертификация связана с огромными усилиями. [15]
Визуализация информации о отслеживаемости
[ редактировать ]Одна из целей прослеживаемости — визуализировать взаимосвязь между артефактами. По мере увеличения количества и сложности трассировочных связей необходимы методы визуализации прослеживаемости. Визуализация может включать информацию об артефактах (например, тип артефакта, метаданные, атрибуты) и ссылках (например, тип ссылки, метаданные, сила связи). [16]
Обычными способами визуализации информации о отслеживаемости являются матрицы , графики , списки и гиперссылки .
- Матрица прослеживаемости . Матрица прослеживаемости представляет собой табличное представление, которое сопоставляет артефакты одного типа (например, требования), изображенные в столбцах, с артефактами другого типа (например, исходный код), изображенными в строках. Ячейки визуализируют трассировку между двумя артефактами, если она заполнена, или отсутствие трассировки, если оставить ее пустой. [16] Преимущество матриц трассируемости состоит в том, что все связи между артефактами видны с первого взгляда. Фильтры помогают уменьшить количество отображаемой информации. Матрицы прослеживаемости подходят для задач управления. [16] Однако в промышленности проекты часто состоят из тысяч артефактов: таблицы могут стать очень большими и запутанными. [17]
- Граф прослеживаемости . В графе прослеживаемости артефакты представлены в виде узлов. Узлы соединяются ребрами, если существует трассировочная связь между артефактами. Графики особенно подходят для задач разработки. Они позволяют получить обзор ссылок в исследовательском режиме и характеризуются высокой степенью восприятия информации. [16] Путем навигации по графику легко найти недостающие ссылки, что является подсказкой для создания необходимых артефактов.
- Список . Списки представляют собой ссылки для отслеживания в одной записи. Эта запись может включать информацию об исходном и целевом артефакте и атрибутах. Они особенно подходят, когда необходимо выполнить массовые операции для нескольких различных артефактов. Фильтры и механизмы сортировки позволяют обрабатывать отображаемую информацию. Однако по сравнению с описанными выше визуализациями списки менее подходят для выполнения задач управления проектами, разработки и тестирования. [16]
- Гиперссылка . Гиперссылки соединяют связанные артефакты и позволяют «перепрыгивать» от исходного артефакта к связанному артефакту. Эта визуализация подходит, если необходима подробная информация об артефакте, поскольку она позволяет переходить к артефактам в их исходной среде. [16] Единственным недостатком использования гиперссылок является то, что для получения обзора состояния ссылки необходимы большие усилия по навигации, поскольку связанные артефакты не визуализируются компактно.
Визуализации можно комбинировать, чтобы преодолеть их специфические ограничения.
Техническая реализация
[ редактировать ]Ручное отслеживание
[ редактировать ]Отслеживаемость реализуется путем сбора следов либо полностью вручную, либо с помощью специальных инструментов, например, в виде электронной таблицы в Microsoft Excel . Несмотря на широкое применение, этот процесс является громоздким, подверженным ошибкам и часто приводит к получению отслеживаемой информации недостаточного качества из-за различных задействованных инструментов разработки и, как правило, очень большого количества отслеживаемых артефактов. [18]
Отслеживаемость с помощью инструмента
[ редактировать ]Отслеживаемость, поддерживаемая инструментами, требует, чтобы информация о разработке, которая распределяется по всей цепочке инструментов разработки, была гомогенизирована и агрегирована. Существуют следующие подходы для достижения этого состояния:
Унификация среды программных инструментов с помощью ALM инструмента . Цепочки инструментов ALM охватывают жизненный цикл разработки программного обеспечения и управляют всеми артефактами процесса разработки программного обеспечения. Многие компании выбрали лучший в своем классе подход с управлением задачами, управлением кодом и многочисленными инструментами автоматизации тестирования. Компании, выбирающие лучший в своем классе подход, решают проблему отслеживания с помощью инструментов управления требованиями (RM), которые обеспечивают полную модель отслеживания и интеграцию лучших в своем классе инструментов. Единый инструмент ALM, охватывающий требования, анализ рисков, проектирование системы, управление задачами, репозитории кода, интеграцию, тестирование и многое другое, представляет собой классический компромисс между лучшими в своем классе возможностями и более ограниченной функциональностью, общей платформой.
Гомогенизация данных с помощью суррогатных требований — инструменты управления требованиями (RM) позволяют хранить, организовывать и управлять всеми требованиями спецификаций системы и обычно упорядочивают их в дереве спецификаций , которое связывает каждое требование с его родительским требованием в более высокой спецификации. Типичными функциями анализа, основанными на записанной информации о прослеживаемости, являются, например, проверки полноты, т.е. все ли требования системного уровня доходят до уровня оборудования (с модификациями или без них), оценка отклонений требований на всех уровнях и представление статуса квалификации. Чтобы обеспечить отслеживаемость типов артефактов помимо требований, инструменты RM часто позволяют импортировать другие артефакты в качестве суррогатных требований, которые затем можно отслеживать с помощью методов отслеживания требований инструмента. Недостаток этого подхода заключается в том, что для разных типов артефактов необходимы разные адаптеры или преобразователи, которые должны иметь согласованную версию и формат данных. В отличие от инструментов ALM, эту согласованность необходимо выполнять самостоятельно.
Гомогенизация данных с помощью специального инструмента отслеживания . Основная концепция специальных инструментов отслеживания состоит из трех основных этапов:
- Определение модели данных, известной как информационная модель прослеживаемости (TIM). Эта модель определяет, какие типы артефактов (например, требования заинтересованных сторон, требования к программному обеспечению, интеграционные тесты, элементы модели системы) и как они связаны.
- Определение сопоставлений всех соответствующих данных всех инструментов, которые являются частью вашей цепочки инструментов разработки, и того, как эти данные сопоставляются с TIM.
- Метрики и функции анализа определяются в TIM, а не в данных, находящихся в конкретном инструменте.
Этот подход объединяет преимущества вышеупомянутых подходов: он охватывает все инструменты и артефакты в рамках целостного подхода, гомогенизирует данные и позволяет избежать риска несогласованности, вызванного устаревшими суррогатными данными. Недостаток заключается в том, что этот подход предполагает расширение цепочки инструментов другим инструментом (отслеживаемости).
Инструменты отслеживания
[ редактировать ]Во многих проектах люди используют офисные инструменты, такие как электронные таблицы, для управления отслеживаемостью. Эти инструменты подвержены ошибкам, если у вас есть сотни требований и несколько пользователей работают над проектом. Вы можете использовать специализированные инструменты отслеживания для эффективного контроля над вашими проектами.
См. также
[ редактировать ]- Анализ требований – Инженерный процесс
- Список инструментов разработки требований
Ссылки
[ редактировать ]- ^ Системная и программная инженерия -- Словарь . ISO/IEC/IEEE 24765:2010(Е). 01 декабря 2010 г. стр. 1–418. дои : 10.1109/IEESTD.2010.5733835 . ISBN 978-0-7381-6205-8 .
- ^ Руководство IEEE по разработке спецификаций системных требований . Издание IEEE STD 1233, 1998 г. 1 декабря 1998 г. стр. 1–36. doi : 10.1109/IEESTD.1998.88826 . ISBN 978-0-7381-1723-2 .
- ^ Руководство IEEE по информационным технологиям. Определение системы. Документ концепции операций (ConOps) . СТД ИИЭР 1362-1998. 1 декабря 1998 г. стр. 1–24. doi : 10.1109/IEESTD.1998.89424 . ISBN 978-0-7381-1407-1 .
- ^ Jump up to: а б с Готель, ОКЗ; Финкельштейн, CW (апрель 1994 г.). «Анализ проблемы прослеживаемости требований». Материалы Международной конференции IEEE по разработке требований . стр. 94–101. CiteSeerX 10.1.1.201.7137 . дои : 10.1109/icre.1994.292398 . ISBN 978-0-8186-5480-0 . S2CID 5870868 .
- ^ Готель, Орлена; Клеланд-Хуанг, Джейн ; Хейс, Джейн Хаффман; Зисман, Андреа; Эгед, Александр; Грюнбахер, Пауль; Дехтяр, Алекс; Антониоль, Джулиано; Малетик, Джонатан (1 января 2012 г.). «Основы отслеживания». В Клеланд-Хуанг, Джейн; Готель, Орлена; Зисман, Андреа (ред.). Отслеживание программного обеспечения и систем . Спрингер Лондон. стр. 3–22 . дои : 10.1007/978-1-4471-2239-5_1 . ISBN 9781447122388 .
- ^ Халл, Элизабет; Кен Джексон; Джереми Дик (2005). Разработка требований (второе изд.). Спрингер. стр. 9–13, 131–151. ISBN 978-1-85233-879-4 .
- ^ Pinheiro FAC и Goguen JA, «Объектно-ориентированный инструмент для отслеживания требований», IEEE Software 1996, 13 (2), стр. 52-64.
- ^ Jump up to: а б Мэдер, П.; Джонс, Польша; Чжан, Ю.; Клеланд-Хуанг, Дж. (01 мая 2013 г.). «Стратегическая прослеживаемость для проектов, критически важных для безопасности». Программное обеспечение IEEE . 30 (3): 58–66. дои : 10.1109/MS.2013.60 . ISSN 0740-7459 . S2CID 16905456 .
- ^ Ли, Инь; Хуан Ли; Е Ян; Миншу Ли (2008). Прослеживаемость, ориентированная на требования, для анализа влияния изменений: практический пример . Шпрингер Берлин/Гейдельберг. стр. 100–111. ISBN 978-3-540-79587-2 .
- ^ Вигерс, Карл (2013). «Прослеживаемость требований: звенья в цепочке требований, часть 1» . Джама . Проверено 14 декабря 2016 г.
- ^ Вигерс, К.; Битти, Дж. (2013). Требования к программному обеспечению . Майкрософт Пресс.
- ^ Бульон, Эльке; Мэдер, Патрик; Филиппов, Илька (08 апреля 2013 г.). «Обзор сценариев использования прослеживаемости требований на практике». Ин Дорр, Йорг; Опдал, Андреас Л. (ред.). Разработка требований: Фонд качества программного обеспечения . Конспекты лекций по информатике. Том. 7830. Шпрингер Берлин Гейдельберг. стр. 158–173 . CiteSeerX 10.1.1.659.3972 . дои : 10.1007/978-3-642-37422-7_12 . ISBN 9783642374210 .
- ^ Мэдер, Патрик; Эгед, Александр (01 апреля 2015 г.). «Получают ли разработчики выгоду от отслеживания требований при разработке и сопровождении программной системы?». Эмпирическая программная инженерия . 20 (2): 413–441. дои : 10.1007/s10664-014-9314-z . ISSN 1382-3256 . S2CID 2514618 .
- ^ Ремпель, Патрик; Мэдер, Патрик (1 января 2016 г.). «Предотвращение дефектов: влияние полноты отслеживания требований на качество программного обеспечения» . Транзакции IEEE по разработке программного обеспечения . ПП (99): 777–797. дои : 10.1109/TSE.2016.2622264 . ISSN 0098-5589 . S2CID 1959772 .
- ^ «open-DO | На пути к совместной и открытой структуре для разработки сертифицированного программного обеспечения» . www.open-do.org . Проверено 15 апреля 2017 г.
- ^ Jump up to: а б с д и ж Ли, Ю.; Маалей, В. (2012). Какая визуализация прослеживаемости подходит в этом контексте? Сравнительное исследование . Спрингер. стр. 194–210.
- ^ Лерш, Феликс (2019). «5 ПРИЧИН, ПОЧЕМУ МАТРИЦЫ ПРОСЛЕЖИВАЕМОСТИ ТРЕБОВАНИЙ НЕДОСТАТОЧНО» .
- ^ Канненберг, Эндрю; Саидиан, Хосейн (2009). «Почему отслеживание требований к программному обеспечению остается проблемой» (PDF) . CrossTalk Magazine — журнал оборонной разработки программного обеспечения .