Поддержание прослеживаемости в актуальном состоянии по мере развития проекта [закрыто]

Question

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

Теперь самая большая проблема, с которой я столкнулся, заключалась в поддержании этой отслеживаемости позже, когда ситуация начала меняться (в результате запросов на изменение или в результате изменения варианта использования).

Есть идеи о лучших практиках поддержания прослеживаемости?

(Это может применяться к другим элементам проекта - напримерварианты использования и тестовые примеры, или требования и приемочные тесты)

Последующее редактирование Инструменты могли бы помочь, но они не могут обнаружить пробелы или ошибки в отслеживаемости.Навигация...возможно, но нет гарантии, что отслеживаемость является актуальной или правильной после применения изменений.

Answer 1

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

У меня нет никакой панацеи;просто несколько советов о том, что помогло мне в прошлом.

• Храните документы в центральном месте, где каждый может легко добраться до них.Мне все равно, будь то Sharepoint, wiki или сетевой диск (хотя мне нравится что-то, что обеспечивает контроль версий, если это возможно).Храните это в одном месте и продвигайте на рынок, чтобы все знали, что нужно обращаться туда за ответами, а не использовать старые копии или мешать разработчикам.
• Если у вас есть центральная точка соприкосновения для управления артефактами или их функциональными группировками, это очень помогает.Кто-то, кто понимает их и проблемы, будет знать, куда идти, что обновлять и есть ли зависимости, которые необходимо перенести вперед.
• Хранитель артефактов должен быть предан им и поддерживать их в актуальном состоянии.Спустя год после того, как я разместил некоторые документы с требованиями на сайте, я все еще поддерживал их в актуальном состоянии.Я знаю, что большинство разработчиков боялись бы делать это, но год спустя я ВСЕ еще извлекаю выгоду из того, что оглядываюсь назад, чтобы увидеть, как менялись функциональные требования с течением времени.
• Не обязательно, но полезно быстро выявлять изменения с течением времени:используйте отслеживание версий обработчика документов, если оно у него есть.Если нет, я бы, по крайней мере, включил журнал изменений для документа или просто пометил новый текст ссылкой на номер версии.
• В прошлом я пытался поместить ссылки на зависимости в свои артефакты, такие как ссылки на другие документы или артефакты, но обнаружил, что они либо устарели, либо их было трудно отслеживать, и поэтому они часто не обновлялись.Дисциплина может преодолеть это, но у большинства из нас слишком много дел, не так ли?Поэтому я думаю, что создание перекрестных ссылок между документами / артефактами - это то место, где я хотел бы, чтобы инструмент или какая-то еще не выпущенная бесплатная утилита управления требованиями выполняла эту работу :)

Answer 2

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

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

---

Я предполагаю, что вы не спрашиваете об отслеживаемости вплоть до кода, поэтому я исключаю это из своего ответа.

---

Поскольку вы упомянули уникальные идентификаторы для ваших инструкций и вариантов использования, возможно, вы уже используете инструмент для управления ими.

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

Я бы поискал простой инструмент, который это делает.Если бы только один человек мог изменить его, это мог бы быть просто лист Excel!

---

Обратите внимание, что связывания двух типов документов, вероятно, недостаточно.
Вы упомянули 5 типов:инструкции, варианты использования, тестовые наборы, требования и приемочные тестовые наборы.
Нам постоянно требовалась транзитивность (в мире отношений для ОБЪЕДИНЕНИЯ таблиц), чтобы иметь представление, включающее несколько шагов.

Answer 3

Существует много видов отслеживаемости, которые необходимо поддерживать:системные требования к требованиям подсистемы, требования к дизайну, требования к проверке (наиболее важные), требования к коду, требования к проблемам и т.д.

Word, Excel и хорошая система отслеживания проблем имеют большое значение.Но они могут быть болезненными, когда от вас требуется продемонстрировать прослеживаемость.Ручное поддержание прослеживаемости чревато ошибками и требует больших затрат труда.IBM Doors system - лучший инструмент, который я использовал до сих пор.Но они дорогие.Недавно мы нашли систему Окончательный След это работает довольно хорошо.

Answer 4

Вы хотите добавить версию # к заявлению о требованиях и для каждого варианта использования - самые актуальные из них доводятся до сведения всех и хранятся в какой-либо легкодоступной области (физической и / или компьютерной / веб).Вам нужно будет добавить документ об изменении, который включает в себя то, каким было предыдущее заявление о требовании и / или вариант использования, когда оно было изменено воз и кем одобрено.

Таким образом, при просмотре спецификации требований и вариантов использования у вас / у всех есть последнее представление, и если есть вопросы к изменению, у вас есть документ об изменении, на который можно ссылаться (не перегружайте требования или спецификацию варианта использования исторической информацией, но храните историческую информацию в качестве ссылки в легкодоступной, осмысленной форме)

Answer 5

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

Многие багтрекеры позволяют вам связать несколько ошибок вместе (например, в виде дубликатов), так что это можно использовать для объединения отдельных требований и по-прежнему отдельно для отслеживания по отдельности.

Если вы храните все другие свои артефакты в SCM (т. Е. проектные документы и т.д.), То вы также можете отследить их, связав с требованием.

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