WikiDer > Прослеживаемость требований - Википедия

Requirements traceability - Wikipedia

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

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

Техническая реализация

Прослеживаемость вручную

Прослеживаемость реализуется путем записи трассировок либо полностью вручную, либо с помощью инструментов, например как электронная таблица в Майкрософт Эксель. Хотя этот процесс широко применяется, он громоздок, подвержен ошибкам и часто приводит к отслеживаемой информации недостаточного качества из-за различных задействованных инструментов разработки и, как правило, очень большого количества отслеживаемых артефактов.[18]

Прослеживаемость с помощью инструментов

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

Гомогенизация инструментальной среды через ALM инструмент – ALM цепочки инструментов охватывают весь жизненный цикл системы и управляют всеми артефактами процесса разработки в рамках целостного подхода. Средства отслеживания проблем, реализующие Volere Шаблон требований успешно использовался в распределенных средах. Преимущество этого подхода состоит в том, что гомогенизация артефактов позволяет легко управлять ими и анализировать их с помощью специальных инструментов ALM инструмент. Недостаток в том, что необходимо реализовать всю ALM инструментальная цепочка. В случае внедрения будет сложно заменить определенные инструменты в цепочке инструментов.

Гомогенизация данных с помощью суррогатных требований – управление требованиями (RM) инструменты позволяют хранить, систематизировать и управлять всеми требованиями спецификаций системы и обычно размещают их в дерево спецификаций который связывает каждое требование с его родительским требованием в более высокой спецификации. Типичными функциями анализа, основанными на записанной информации о прослеживаемости, являются, например, проверки полноты, т.е. все ли требования системного уровня снижаются до уровня оборудования (с модификациями или без них), оценка отклонений требований на всех уровнях и представление статуса квалификации. Чтобы обеспечить прослеживаемость до типов артефактов, выходящих за рамки требований, инструменты RM часто позволяют импортировать другие артефакты в качестве суррогатных требований, которые затем можно отследить с помощью методов отслеживания требований инструмента. Недостатком этого подхода является то, что для разных типов артефактов необходимы разные адаптеры или преобразователи, которые должны иметь согласованную версию и формат данных. В отличие от инструментов ALM, это согласованность необходимо выполнять самостоятельно.

Гомогенизация данных с помощью специального инструмента отслеживания - основная концепция специализированных инструментов отслеживания состоит из трех основных этапов:

  • Определение модели данных, также известной как информационная модель прослеживаемости (TIM). Эта модель определяет, какие типы артефактов (например, требования заинтересованных сторон, требования к программному обеспечению, интеграционные тесты, элементы системной модели) и как они связаны.
  • Определение сопоставлений из всех соответствующих данных всех инструментов, которые являются частью вашей цепочки инструментов разработки, и того, как эти данные отображаются в TIM.
  • Метрики и функции анализа определены на TIM, а не на данных, хранящихся в конкретном инструменте.

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

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

Рекомендации

  1. ^ Системная и программная инженерия - Словарь. Iso / IEC / IEEE 24765: 2010 (E). 2010-12-01. С. 1–418. Дои:10.1109 / IEEESTD.2010.5733835. ISBN 978-0-7381-6205-8.
  2. ^ Руководство IEEE по разработке спецификаций системных требований. Издание 1998 г., IEEE STD 1233. 1998-12-01. С. 1–36. Дои:10.1109 / IEEESTD.1998.88826. ISBN 978-0-7381-1723-2.
  3. ^ IEEE Guide for Information Technology - System Definition - Concept of Operations (ConOps) Document. IEEE STD 1362-1998. 1998-12-01. С. 1–24. Дои:10.1109 / IEEESTD.1998.89424. ISBN 978-0-7381-1407-1.
  4. ^ а б c Gotel, O.C.Z .; Финкельштейн, К.В. (апрель 1994 г.). Анализ проблемы прослеживаемости требований. Труды Международной конференции IEEE по разработке требований. С. 94–101. CiteSeerX 10.1.1.201.7137. Дои:10.1109 / icre.1994.292398. ISBN 978-0-8186-5480-0.
  5. ^ Готель, Орлена; Клеланд-Хуанг, Джейн; Хейс, Джейн Хаффман; Зисман, Андреа; Египетский, Александр; Грюнбахер, Пауль; Дехтяр, Алексей; Антониол, Джулиано; Малетик, Джонатан (01.01.2012). Клеланд-Хуанг, Джейн; Готель, Орлена; Зисман, Андреа (ред.). Программное обеспечение и отслеживание систем. Springer London. стр.3–22. Дои:10.1007/978-1-4471-2239-5_1. ISBN 9781447122388.
  6. ^ Халл, Элизабет; Кен Джексон; Джереми Дик (2005). Разработка требований (второе издание). Springer. С. 9–13, 131–151. ISBN 978-1-85233-879-4.
  7. ^ Пинейро F.A.C. и Гогуэн Дж. А. «Объектно-ориентированный инструмент для отслеживания требований», IEEE Software 1996, 13 (2), стр. 52-64.
  8. ^ а б Mäder, P .; Jones, P. L .; Zhang, Y .; Клеланд-Хуанг, Дж. (01.05.2013). «Стратегическая прослеживаемость для критически важных для безопасности проектов». Программное обеспечение IEEE. 30 (3): 58–66. Дои:10.1109 / MS.2013.60. ISSN 0740-7459.
  9. ^ Ли, Инь; Хуан Ли; Е Ян; Миншу Ли (2008). Прослеживаемость, ориентированная на требования, для анализа воздействия изменений: пример из практики. Springer Berlin / Heidelberg. С. 100–111. ISBN 978-3-540-79587-2.
  10. ^ Вигерс, Карл (2013). «Прослеживаемость требований: звенья в цепочке требований, часть 1». джама. Получено 2016-12-14.
  11. ^ Wiegers, K .; Битти, Дж. (2013). Требования к программному обеспечению. Microsoft Press.
  12. ^ Бульон, Эльке; Мэдер, Патрик; Филиппов, Илка (2013-04-08). Doerr, Joerg; Опдаль, Андреас Л. (ред.). Разработка требований: основа качества программного обеспечения. Конспект лекций по информатике. Springer Berlin Heidelberg. стр.158–173. CiteSeerX 10.1.1.659.3972. Дои:10.1007/978-3-642-37422-7_12. ISBN 9783642374210.
  13. ^ Мэдер, Патрик; Египтян, Александр (01.04.2015). «Выигрывают ли разработчики от отслеживания требований при разработке и сопровождении программной системы?». Эмпирическая разработка программного обеспечения. 20 (2): 413–441. Дои:10.1007 / s10664-014-9314-z. ISSN 1382-3256.
  14. ^ Ремпель, Патрик; Мэдер, Патрик (01.01.2016). «Предотвращение дефектов: влияние полноты прослеживаемости требований на качество программного обеспечения». IEEE Transactions по разработке программного обеспечения. PP (99): 777–797. Дои:10.1109 / TSE.2016.2622264. ISSN 0098-5589.
  15. ^ "open-DO | К совместной и открытой структуре для разработки сертифицированного программного обеспечения". www.open-do.org. Получено 2017-04-15.
  16. ^ а б c d е ж Li, Y .; Маалей, В. (2012). Какая визуализация прослеживаемости подходит в этом контексте? Сравнительное исследование. Springer. С. 194–210.
  17. ^ Лерче, Феликс (2019). «5 ПРИЧИН, ПОЧЕМУ ТРЕБОВАНИЯ МАТРИЦЫ СЛЕЖЕНИЯ НЕ ДОСТАТОЧНО».
  18. ^ Канненберг, Эндрю; Сайедян, Хоссейн (2009). «Почему прослеживаемость требований к программному обеспечению остается проблемой» (PDF). CrossTalk Magazine - журнал оборонной программной инженерии.