Прослеживаемость требований - это подраздел управления требованиями в рамках разработки программного обеспечения и системного проектирования . Прослеживаемость как общий термин определяется в IEEE Systems and Software Engineering Vocabulary [1] как (1) степень, в которой могут быть установлены отношения между двумя или более продуктами процесса разработки, особенно продуктами, имеющими предшественника-преемника или главного -подчиненное отношение друг к другу; [2] (2) идентификация и документирование путей деривации (вверх) и распределения или вниз (вниз) рабочих продуктов в иерархии рабочих продуктов; [3](3) степень, в которой каждый элемент продукта разработки программного обеспечения устанавливает причину своего существования; и (4) заметная связь между двумя или более логическими объектами, такими как требования, системные элементы, проверки или задачи.
Прослеживаемость требований, в частности, определяется как «способность описывать и прослеживать жизненный цикл требования как в прямом, так и в обратном направлении (т. Е. От его происхождения, через его разработку и спецификацию, до его последующего развертывания и использования, а также через периоды. постоянных доработок и итераций на любом из этих этапов) ". [4] [5] В области разработки требований прослеживаемость - это понимание того, как высокоуровневые требования - цели, задачи, задачи, стремления, ожидания, потребности - преобразуются в требования низкого уровня. Поэтому в первую очередь он связан с отношениями удовлетворенности между слоями информации (также известными как артефакты). [6] Тем не менее, прослеживаемость может документировать отношения между многими видами артефактов разработки, такими как требования, спецификации, проекты, тесты, модели и разработанные компоненты. [7] Например, обычной практикой является фиксация взаимосвязей проверки, чтобы продемонстрировать, что требование проверяется определенным артефактом тестирования.
Прослеживаемость особенно важна при разработке критически важных для безопасности систем и поэтому предписывается руководящими принципами безопасности , такими как DO178C , ISO 26262 и IEC61508 . Общим требованием этих руководств является то, что критические требования должны быть проверены и что эта проверка должна быть продемонстрирована посредством прослеживаемости. [8]
Отслеживание требований и за их пределами
Прослеживаемость предварительных требований . [4] Требования поступают из разных источников, таких как деловой человек, заказывающий продукт, менеджер по маркетингу и фактический пользователь. У всех этих людей разные требования к продукту. Используя прослеживаемость требований, внедренную функцию можно отследить до человека или группы, которые хотели ее во время выявления требований . Это можно использовать в процессе разработки для определения приоритетов требований, определяя, насколько они ценны для конкретного пользователя. Его также можно использовать после развертывания, чтобы понять, почему в первую очередь потребовались определенные неиспользуемые функции, обнаруженные в ходе пользовательских исследований.
Прослеживаемость после требований . [4] Следует отслеживать не только сами требования, но и взаимосвязь требований со всеми артефактами, связанными с ними, такими как модели, результаты анализа, тестовые примеры, процедуры тестирования, результаты тестирования и всякого рода документация. Следует отслеживать даже людей и группы пользователей, связанные с требованиями. Требования воплощаются в артефакты проектирования, реализации и, наконец, проверяются. Артефакты, связанные с последними стадиями, также должны быть прослежены до требований. Обычно это делается с помощью матрицы прослеживаемости требований .
Обеспечение прослеживаемости за пределами требований в артефактах проектирования, реализации и проверки может стать трудным. [9] При реализации требований к программному обеспечению, например, требования могут быть в средстве управления требованиями , тогда как артефакты дизайна могут быть в таком средстве, как MagicDraw , Mathworks Simulink , Rational Rhapsody и Microsoft Visio . Кроме того, артефакты реализации, скорее всего, будут в виде исходных файлов, ссылки на которые могут быть установлены различными способами в различных областях. Артефакты верификации, такие как те, которые генерируются внутренними тестами или формальными инструментами верификации (например, набором тестовых стендов LDRA , Parasoft DTP и SCADE )
Интеграция репозитория или стека инструментов может стать серьезной проблемой для поддержания прослеживаемости в динамической системе.
Использование информации о прослеживаемости
Использование прослеживаемости, особенно при отслеживании сверх требований ко всем артефактам, находящимся в цепочке инструментов, может дать несколько преимуществ: [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 охватывают весь жизненный цикл системы и управляют всеми артефактами процесса разработки в рамках целостного подхода. Средства отслеживания проблем, реализующие шаблон требований Volere , успешно используются в распределенных средах. Преимущество этого подхода заключается в том, что гомогенизация артефактов позволяет легко управлять ими и анализировать их с помощью специальных инструментов инструмента ALM . Недостаток в том, что необходимо реализовать всю цепочку инструментов ALM . Если они введены, будет сложно заменить определенные инструменты в цепочке инструментов.
Гомогенизация данных с помощью суррогатных требований - инструменты управления требованиями (RM) позволяют хранить, систематизировать и управлять всеми требованиями спецификаций системы и обычно упорядочивают их в дереве спецификаций, которое связывает каждое требование с его родительским требованием в более высокой спецификации. Типичными функциями анализа, основанными на записанной информации о прослеживаемости, являются, например, проверки полноты, т.е. все ли требования системного уровня снижаются до уровня оборудования (с модификациями или без них), оценка отклонений требований на всех уровнях и представление статуса квалификации. Чтобы обеспечить прослеживаемость до типов артефактов, выходящих за рамки требований, инструменты RM часто позволяют импортировать другие артефакты в качестве суррогатных требований, которые затем можно отслеживать с помощью методов отслеживания требований инструмента. Недостатком этого подхода является то, что для разных типов артефактов необходимы разные адаптеры или преобразователи, которые должны иметь согласованную версию и формат данных. В отличие от инструментов ALM, это согласованность нужно выполнять самостоятельно.
Гомогенизация данных с помощью специального инструмента отслеживания - основная концепция специализированных инструментов отслеживания состоит из трех основных этапов:
- Определение модели данных, также известной как информационная модель прослеживаемости (TIM). Эта модель определяет, какие типы артефактов (например, требования заинтересованных сторон, требования к программному обеспечению, интеграционные тесты, элементы модели системы) и как они связаны.
- Определение сопоставлений из всех соответствующих данных всех инструментов, которые являются частью вашей цепочки инструментов разработки, и того, как эти данные отображаются в TIM.
- Метрики и функции анализа определены на TIM, а не на данных, хранящихся в конкретном инструменте.
Подход объединяет преимущества вышеупомянутых подходов: он охватывает все инструменты и артефакты в целостном подходе, гомогенизирует данные и избегает риска несоответствий, вызванных устаревшими суррогатами. Недостатком является то, что этот подход подразумевает расширение цепочки инструментов другим инструментом (прослеживаемости).
Смотрите также
- Требования
- Анализ требований
- Управление требованиями
Рекомендации
- ^ Системная и программная инженерия - Словарь . Iso / IEC / IEEE 24765: 2010 (E) . 2010-12-01. С. 1–418. DOI : 10.1109 / IEEESTD.2010.5733835 . ISBN 978-0-7381-6205-8.
- ^ Руководство IEEE по разработке спецификаций системных требований . Издание 1998 г., IEEE STD 1233 . 1998-12-01. С. 1–36. DOI : 10.1109 / IEEESTD.1998.88826 . ISBN 978-0-7381-1723-2.
- ^ IEEE Guide for Information Technology - System Definition - Concept of Operations (ConOps) Document . IEEE STD 1362-1998 . 1998-12-01. С. 1–24. DOI : 10.1109 / IEEESTD.1998.89424 . ISBN 978-0-7381-1407-1.
- ^ а б в Gotel, OCZ; Финкельштейн, 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 .
- ^ Готель, Орлена; Клеланд-Хуанг, Джейн; Хейс, Джейн Хаффман; Зисман, Андреа; Египетский, Александр; Грюнбахер, Пауль; Дехтяр, Алексей; Антониол, Джулиано; Малетик, Джонатан (01.01.2012). Клеланд-Хуанг, Джейн; Готель, Орлена; Зисман, Андреа (ред.). Программное обеспечение и прослеживаемость систем . Springer London. стр. 3 -22. DOI : 10.1007 / 978-1-4471-2239-5_1 . ISBN 9781447122388.
- ^ Халл, Элизабет; Кен Джексон; Джереми Дик (2005). Разработка требований (второе изд.). Springer. С. 9–13, 131–151. ISBN 978-1-85233-879-4.
- ^ Пиньейру КВС и Гоген JA, "Объектно-ориентированный инструмент для отслеживания требований", IEEE программного обеспечения 1996 года, 13 (2), стр. 52-64
- ^ а б Mäder, P .; Джонс, Польша; Zhang, Y .; Клеланд-Хуанг, Дж. (01.05.2013). «Стратегическая прослеживаемость для критически важных для безопасности проектов». Программное обеспечение IEEE . 30 (3): 58–66. DOI : 10.1109 / MS.2013.60 . ISSN 0740-7459 . S2CID 16905456 .
- ^ Ли, Инь; Хуан Ли; Е Ян; Миншу Ли (2008). Прослеживаемость, ориентированная на требования, для анализа воздействия изменений: пример из практики . Springer Berlin / Heidelberg. С. 100–111. ISBN 978-3-540-79587-2.
- ^ Вигерс, Карл (2013). «Прослеживаемость требований: звенья в цепочке требований, часть 1» . джама . Проверено 14 декабря 2016 .
- ^ Wiegers, K .; Битти, Дж. (2013). Требования к программному обеспечению . Microsoft Press.
- ^ Бульон, Эльке; Мэдер, Патрик; Филиппов, Илка (2013-04-08). Дорр, Йорг; Опдаль, Андреас Л. (ред.). Разработка требований: основа качества программного обеспечения . Конспект лекций по информатике. Springer Berlin Heidelberg. стр. 158 -173. CiteSeerX 10.1.1.659.3972 . DOI : 10.1007 / 978-3-642-37422-7_12 . ISBN 9783642374210.
- ^ Мэдер, Патрик; Египтян, Александр (01.04.2015). «Выигрывают ли разработчики от отслеживаемости требований при разработке и сопровождении программной системы?». Эмпирическая программная инженерия . 20 (2): 413–441. DOI : 10.1007 / s10664-014-9314-Z . ISSN 1382-3256 . S2CID 2514618 .
- ^ Ремпель, Патрик; Мэдер, Патрик (01.01.2016). «Предотвращение дефектов: влияние полноты прослеживаемости требований на качество программного обеспечения» . IEEE Transactions по разработке программного обеспечения . ПП (99): 777–797. DOI : 10.1109 / TSE.2016.2622264 . ISSN 0098-5589 . S2CID 1959772 .
- ^ «open-DO | На пути к совместной и открытой платформе для разработки сертифицированного программного обеспечения» . www.open-do.org . Проверено 15 апреля 2017 .
- ^ а б в г д е Li, Y .; Маалей, В. (2012). Какая визуализация прослеживаемости подходит в этом контексте? Сравнительное исследование . Springer. С. 194–210.
- ^ Лерче, Феликс (2019). «5 ПРИЧИН, ПОЧЕМУ ТРЕБОВАНИЯ МАТРИЦЫ СЛЕЖЕНИЯ НЕДОСТАТОЧНО» .
- ^ Канненберг, Эндрю; Сайедян, Хоссейн (2009). «Почему прослеживаемость требований к программному обеспечению остается проблемой» (PDF) . CrossTalk Magazine - журнал оборонной программной инженерии .