Требования к прослеживаемости

Прослеживаемость требований — это подраздел управления требованиями в рамках разработки программного обеспечения и системной инженерии . Прослеживаемость как общий термин определяется Словарем системной и программной инженерии 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, а не данных, хранящихся в конкретном инструменте.

Подход объединяет преимущества вышеупомянутых подходов: он охватывает все инструменты и артефакты в целостном подходе, гомогенизирует данные и избегает риска несоответствий, вызванных устаревшими суррогатами. Недостатком является то, что этот подход подразумевает расширение цепочки инструментов другим инструментом (прослеживаемости).

Инструменты прослеживаемости

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

Смотрите также

• Анализ требований  – Процесс проектирования
• Список требований к инструментам проектирования

Ссылки

1. Системная и программная инженерия -- Словарь . Iso/Iec/IEEE 24765:2010(E). 2010-12-01. стр. 1–418. doi :10.1109/IEEESTD.2010.5733835. ISBN 978-0-7381-6205-8.
2. Руководство IEEE по разработке спецификаций системных требований . Издание 1998 г. IEEE STD 1233. 1 декабря 1998 г. С. 1–36. doi :10.1109/IEEESTD.1998.88826. ISBN 978-0-7381-1723-2.
3. Руководство IEEE по информационным технологиям - Определение системы - Концепция операций (ConOps) Документ . IEEE STD 1362-1998. 1 декабря 1998 г. стр. 1–24. doi :10.1109/IEEESTD.1998.89424. ISBN 978-0-7381-1407-1.
4. Gotel, OCZ; Finkelstein, CW (апрель 1994). "Анализ проблемы прослеживаемости требований". Труды Международной конференции IEEE по разработке требований . стр. 94–101. CiteSeerX 10.1.1.201.7137 . doi :10.1109/icre.1994.292398. ISBN  978-0-8186-5480-0. S2CID  5870868.
5. Готель, Орлена; Клеланд-Хуан, Джейн ; Хейс, Джейн Хаффман; Зисман, Андреа; Эгиед, Александр; Грюнбахер, Пол; Дехтьяр, Алекс; Антониол, Джулиано; Малетич, Джонатан (2012-01-01). "Основы прослеживаемости". В Клеланд-Хуан, Джейн; Готель, Орлена; Зисман, Андреа (ред.). Прослеживаемость программного обеспечения и систем . Springer London. стр. 3–22. doi :10.1007/978-1-4471-2239-5_1. ISBN 9781447122388.
6. Халл, Элизабет; Кен Джексон; Джереми Дик (2005). Требования к проектированию (второе издание). Springer. стр. 9–13, 131–151. ISBN 978-1-85233-879-4.
7. Пинейро Ф.А.К. и Гоген Дж.А., «Объектно-ориентированный инструмент для трассировки требований», IEEE Software 1996, 13(2), стр. 52-64
8. Mäder, P.; Jones, PL; Zhang, Y.; Cleland-Huang, J. (2013-05-01). «Стратегическая прослеживаемость для проектов, критически важных для безопасности». IEEE Software . 30 (3): 58–66. doi :10.1109/MS.2013.60. ISSN  0740-7459. S2CID  16905456.
9. Ли, Инь; Хуан Ли; Йе Ян; Миншу Ли (2008). Требуемая прослеживаемость для анализа влияния изменений: пример . Springer Berlin/Heidelberg. С. 100–111. ISBN 978-3-540-79587-2.
10. Вигерс, Карл (2013). «Прослеживаемость требований: звенья в цепочке требований, часть 1». jama . Получено 14.12.2016 .
11. Вигерс, К.; Битти, Дж. (2013). Требования к программному обеспечению . Microsoft Press.
12. Буйон, Эльке; Медер, Патрик; Филиппов, Илка (2013-04-08). «Обзор сценариев использования для отслеживания требований на практике». В Doerr, Joerg; Opdahl, Andreas L. (ред.). Инженерия требований: основа качества программного обеспечения . Конспект лекций по информатике. Том 7830. Springer Berlin Heidelberg. стр. 158–173. CiteSeerX 10.1.1.659.3972 . doi :10.1007/978-3-642-37422-7_12. ISBN  9783642374210.
13. Mäder, Patrick; Egyed, Alexander (2015-04-01). «Выигрывают ли разработчики от прослеживаемости требований при разработке и поддержке программной системы?». Empirical Software Engineering . 20 (2): 413–441. doi :10.1007/s10664-014-9314-z. ISSN  1382-3256. S2CID  2514618.
14. Ремпель, Патрик; Медер, Патрик (01.01.2016). «Предотвращение дефектов: влияние полноты прослеживаемости требований на качество программного обеспечения». Труды IEEE по программной инженерии . PP (99): 777–797. doi :10.1109/TSE.2016.2622264. ISSN  0098-5589. S2CID  1959772.
15. "open-DO | На пути к кооперативной и открытой структуре для разработки сертифицируемого программного обеспечения". www.open-do.org . Получено 15.04.2017 .
16. Li, Y.; Maalej, W. (2012). Какая визуализация прослеживаемости подходит в этом контексте? Сравнительное исследование . Springer. С. 194–210.
17. Лерче, Феликс (2019). «5 ПРИЧИН, ПОЧЕМУ МАТРИЦЫ ПРОСЛЕЖИВАЕМОСТИ ТРЕБОВАНИЙ НЕДОСТАТОЧНО».
18. Канненберг, Эндрю; Саидиан, Хоссейн (2009). «Почему прослеживаемость требований к программному обеспечению остается проблемой» (PDF) . CrossTalk Magazine — журнал по оборонной программной инженерии .