Войти
Прослеживаемость требований - это подраздел управления требованиями в рамках разработки программного обеспечения и системного проектирования. Прослеживаемость как общий термин определяется в словаре IEEE Systems and Software Engineering Vocabulary как (1) степень, в которой могут быть установлены отношения между двумя или более продуктами процесса разработки, особенно продуктами, имеющими отношения предшественник-преемник или главный-подчиненный. для другого; (2) идентификация и документирование путей деривации (вверх) и распределения или вниз (вниз) рабочих продуктов в иерархии рабочих продуктов; (3) степень, в которой каждый элемент продукта разработки программного обеспечения устанавливает причину своего существования; и (4) заметная связь между двумя или более логическими объектами, такими как требования, системные элементы, проверки или задачи.
Прослеживаемость требований, в частности, определяется как «способность описывать и прослеживать жизненный цикл требования как в прямом, так и в обратном направлении (т. Е. От его происхождения, через его разработку и спецификацию, до его последующего развертывания и использования, а также через периоды. текущих доработок и итераций на любом из этих этапов) ". В области разработки требований прослеживаемость - это понимание того, как требования высокого уровня - цели, задачи, задачи, стремления, ожидания, потребности - преобразуются в требования низкого уровня. Поэтому в первую очередь он связан с отношениями удовлетворенности между слоями информации (также известными как артефакты). Однако прослеживаемость может документировать отношения между многими видами артефактов разработки, такими как требования, спецификации, проекты, тесты, модели и разработанные компоненты. Например, обычной практикой является фиксация взаимосвязей проверки, чтобы продемонстрировать, что требование проверяется определенным артефактом тестирования.
Прослеживаемость особенно важна при разработке критически важных для безопасности систем и поэтому предписывается руководящими принципами безопасности, такими как DO178C, ISO 26262 и IEC61508. Общим требованием этих руководств является то, что критические требования должны быть проверены и что эта проверка должна быть продемонстрирована посредством прослеживаемости.
Прослеживаемость предварительных требований. Требования поступают из разных источников, таких как деловой человек, заказывающий продукт, менеджер по маркетингу и фактический пользователь. У всех этих людей разные требования к продукту. Используя прослеживаемость требований, внедренную функцию можно отследить до человека или группы, которые хотели ее во время выявления требований. Это можно использовать в процессе разработки для определения приоритетов требований, определяя, насколько они ценны для конкретного пользователя. Его также можно использовать после развертывания, чтобы понять, почему в первую очередь потребовались определенные неиспользуемые функции, обнаруженные в ходе пользовательских исследований.
Прослеживаемость после требований. Следует отслеживать не только сами требования, но и взаимосвязь требований со всеми связанными с ними артефактами, такими как модели, результаты анализа, тестовые примеры, процедуры тестирования, результаты тестирования и всякого рода документация. Следует отслеживать даже людей и группы пользователей, связанные с требованиями. Требования воплощаются в артефакты проектирования, реализации и, наконец, проверяются. Артефакты, связанные с последними стадиями, также должны быть прослежены до требований. Обычно это делается с помощью матрицы прослеживаемости требований.
Обеспечение прослеживаемости за пределами требований в артефактах проектирования, реализации и проверки может стать трудным. При реализации требований к программному обеспечению, например, требования могут быть в средстве управления требованиями, тогда как артефакты дизайна могут быть в таком средстве, как MagicDraw, Mathworks Simulink, Rational Rhapsody и Microsoft Visio. Кроме того, артефакты реализации, скорее всего, будут в виде исходных файлов, ссылки на которые могут быть установлены различными способами в различных областях. Артефакты проверки, например, созданные внутренними тестами или формальными инструментами проверки (например, набором тестовых стендов LDRA, Parasoft DTP и SCADE )
Интеграция репозитория или стека инструментов может стать серьезной проблемой для поддержания прослеживаемости в динамической системе.
Использование трассируемости, особенно при трассировке сверх требований ко всем артефактам, находящимся в цепочке инструментов, может дать несколько преимуществ:
Более полный обзор разработок, поддерживаемых прослеживаемостью, и их актуальность приведен в.
Обширные исследования подтверждают эффективность, но также и трудности сбора информации о прослеживаемости:
Одна из целей прослеживаемости - визуализировать взаимосвязь между артефактами. Поскольку количество и сложность ссылок трассировки увеличивается, необходимы методы визуализации трассируемости. Визуализация может включать в себя информацию об артефактах (например, тип артефакта, метаданные, атрибуты) и ссылках (например, тип ссылки, метаданные, мощность ссылки).
Распространенными визуализациями информации о прослеживаемости являются матрицы, графики, списки и гиперссылки.
Визуализации можно комбинировать, чтобы преодолеть их специфические ограничения.
Прослеживаемость реализуется путем сбора трассировок либо полностью вручную, либо с помощью инструментов, например, в виде электронной таблицы в Microsoft Excel. Хотя этот процесс широко применяется, он громоздок, подвержен ошибкам и часто приводит к информации о прослеживаемости, которая имеет недостаточное качество из-за различных задействованных инструментов разработки и, как правило, очень большого количества отслеживаемых артефактов.
Прослеживаемость с помощью инструментов требует, чтобы информация о разработке, которая распределяется по всей цепочке инструментов разработки, была гомогенизирована и агрегирована. Для достижения этого состояния существуют следующие подходы:
Гомогенизация инструментальной среды с помощью инструмента ALM - цепочки инструментов ALM охватывают весь жизненный цикл системы и управляют всеми артефактами процесса разработки в рамках целостного подхода. Средства отслеживания проблем, реализующие шаблон требований Volere, успешно используются в распределенных средах. Преимущество этого подхода заключается в том, что гомогенизация артефактов позволяет легко управлять ими и анализировать их с помощью специальных инструментов инструмента ALM. Недостаток в том, что необходимо реализовать всю цепочку инструментов ALM. Если они введены, будет сложно заменить определенные инструменты в цепочке инструментов.
Гомогенизация данных с помощью суррогатных требований - инструменты управления требованиями (RM) позволяют хранить, систематизировать и управлять всеми требованиями спецификаций системы и обычно упорядочивают их в дереве спецификаций, которое связывает каждое требование с его родительским требованием в более высокой спецификации. Типичными функциями анализа, основанными на записанной информации о прослеживаемости, являются, например, проверки полноты, т.е. все ли требования системного уровня снижаются до уровня оборудования (с модификациями или без них), оценка отклонений требований на всех уровнях и представление статуса квалификации. Чтобы обеспечить прослеживаемость до типов артефактов, выходящих за рамки требований, инструменты RM часто позволяют импортировать другие артефакты в качестве суррогатных требований, которые затем можно отслеживать с помощью методов отслеживания требований инструмента. Недостатком этого подхода является то, что для разных типов артефактов необходимы разные адаптеры или преобразователи, которые должны иметь согласованную версию и формат данных. В отличие от инструментов ALM, это согласованность нужно выполнять самостоятельно.
Гомогенизация данных с помощью специального инструмента отслеживания - основная концепция специализированных инструментов отслеживания состоит из трех основных этапов:
Подход объединяет преимущества вышеупомянутых подходов: он охватывает все инструменты и артефакты в целостном подходе, гомогенизирует данные и избегает риска несоответствий, вызванных устаревшими суррогатами. Недостатком является то, что этот подход подразумевает расширение цепочки инструментов другим инструментом (прослеживаемости).
