Как внедрить инструмент управления требованиями

Много лет назад я несколько лет работал над очень сложной системой управления оружием. Как вы понимаете, требования были большими, сложными и часто менялись. Мы потратили много времени, просто пытаясь справиться с этими надоедливыми изменениями, которые продолжали поступать как от клиентов, так и от разработчиков. В те первые дни у нас не было никаких инструментов управления требованиями, которые помогли бы нам оценить эти изменения. Мы использовали Interleaf и Excel (сейчас я слышу стоны боли). Все было ручным, включая нашу сложную прослеживаемость. У нас была пара человек, которые только и делали, что поддерживали матрицы прослеживаемости и оценивали влияние изменений. В то время у нас была прослеживаемость только от концепции эксплуатации до системных требований и требований к подсистемам. Я говорю «только», но в то время просто иметь такой уровень прослеживаемости было большим достижением. 

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

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

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

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

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

(4) – Метрики из инструмента требований являются ключом к пониманию полноты действий по тестированию. Мы часто думали, что завершили тестирование на 50%. Ведь 50% испытаний выполнено. Однако мы обнаружили, что мы склонны сначала тестировать самые простые и наиболее понятные части системы. Таким образом, несмотря на то, что мы были готовы на 50%, все, что осталось, было очень рискованным. Мы научились расставлять приоритеты в нашем тестировании, рассматривая приоритеты требований и сложность программного обеспечения, информацию, которую мы не могли определить с помощью ручного отслеживания.

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

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

Какой большой опыт обучения это было для меня. Если вы заинтересованы во внедрении подобных изменений для улучшения процесса обработки требований, свяжитесь с Visure Solutions. Мы будем рады обсудить с вами ваш процесс.