Ibm doors что это

Обновлено: 19.05.2024

Рис. 1. Общий вид интерфейса программы IBM DOORS

Года два назад мы начинали работать с одним из наших европейских партнеров, вместе с которым выбирали систему для управления требованиями к электронике и электрическим компонентам автомобиля. Партнер использовал технологии IBM Rational, в частности IBM DOORS, для управления требованиями и, учитывая положительный опыт, мы тоже решили попробовать использовать это решение. Европейский партнер вел базу требований, а мы со своей стороны участвовали в их согласовании и необходимой корректировке. После этого был успешно осуществлен перенос базы требований, и все дальнейшее управление велось уже на нашей стороне.

Качество требований зависит не только от инструментов, но и от того как простроен процесс управления требованиями. Определение процессов взял на себя наш европейский партнер. Мы имели доступ только к той части процессов, которая касалась нас. Но процессы взаимодействия, структура проекта и структура требований определялись нами совместно.

Если говорить про этапность проекта, надо сказать, что процесс согласования требований в рамках нашего взаимодействия занял чуть больше времени, чем мы ожидали, так как они затрагивали реальную ответственность НАМИ перед партнером и партнера перед НАМИ в части количества и качества предоставляемой информации и тайминга. Но, как только мы согласовали эту часть, мы достаточно быстро начали работать с инструментом. Обучение как таковое нам не требовалось – наш партнер оказывал консультации там, где это было необходимо.

Рис. 2. Пример скрипта на языке DXL.

Когда назрела необходимость расширения возможностей DOORS с помощью скриптов DXL (DOORS eXtension Language), мы обратились за помощью к службе технической поддержки IBM. Нам достаточно быстро предоставили похожие примеры использования языка, а далее наши программисты самостоятельно адаптировали их под наши требования.

Хотел бы также отметить, что в НАМИ над проектом работал в основном молодой коллектив, который не был скован привычками делать все на бумаге. Поэтому работа с требованиями изначально велась в системе DOORS.

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

Однако надо признать тот факт, что многие наши партнеры, в основном западные, присылают требования именно в формате DOORS. Это позволяет нам сразу загрузить их в базу и начать работать с ними. Таким же, образом западные партнеры получают их от нас. Подобный подход позволяет значительно сэкономить время.

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

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

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

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

Государственный научный центр Российской Федерации ФГУП «НАМИ» основан 16 октября 1918 года как первый научно-исследовательский институт в области автомобильной теории и технологии. «НАМИ» является современным научно- исследовательским экспериментальным центром развития производства для проектирования, конструирования и испытаний автомобильных платформ. ГНЦ РФ ФГУП «НАМИ» также является представителем Российской Федерации в Техническом комитете 22 «Дорожный транспорт» Международной организации по стандартизации.

Техническая информация

Требования к программному обеспечению

Требования к программному обеспечению для IBM Engineering Requirements Management DOORS приведены по следующей ссылке:

Требования к аппаратному обеспечению

Требования к аппаратному обеспечению для IBM Engineering Requirements Management DOORS Family приведены по следующей ссылке:

Управление требованиями к IT-проектам

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

Введение

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

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

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

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

Разработка большой и сложной системы не может быть завершена за один подход — итерацию. Это может быть связано как с большой сложностью самой системы, так и со сложностью ее адаптации. Тем не менее, возможно уменьшить объем работы для разработчиков за счет повторного использования кода из одного проекта в другом. Для того, чтобы выявить возможность повторного использования кода необходимо найти требования, которые данный код реализуют. Такие требования очень часто встречаются в продуктах, автоматизирующих одну и ту же предметную область на разных организациях, например, бухгалтерский учет или документооборот. Задача повторного использования требований является одной из задач решаемых управлением требований.

Управление требованиями, выработка требований и определение требований — краеугольные камни успеха любого IT-проекта.

По данным исследования, проведенного IBM в области IT, 60% затрат времени организации-разработчики программного обеспечения несут в результате неэффективного подхода к управлению требованиями. В организациях, не располагающих достаточными возможностями бизнес-анализа, проекты в три раза чаще заканчиваются неудачей, чем успехом. При правильном определении требований и управлении ими перерасходы по проекту можно снизить на 20% благодаря сокращению числа неточных, неполных и упущенных требований.

Управление требованиями

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

Управление требованиями — процесс, включающий идентификацию, выявление, документацию, анализ, отслеживание, приоретизацию требований, достижение соглашений по требованиям и затем управление изменениями и уведомление заинтересованных лиц. Управление требованиями — непрерывный процесс на протяжении всего жизненного цикла продукта.

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

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

Единичность — требование описывает одну и только одну вещь.
Завершенность — требование полностью определено в одном месте и вся необходимая информация присутствует.
Последовательность — требование не противоречит другим требованиям и полностью соответствует документации.
Атомарность — требование нельзя разделить на более мелкие.
Отслеживаемость — требование полностью или частично соответствует деловым нуждам как заявлено заинтересованными лицами и задокументировано.
Актуальность — требование не стало устаревшим с течением времени.
Выполнимость — требование может быть реализовано в рамках проекта.
Недвусмысленность — требование определено без обращения к техническому жаргону, акронимам и другим скрытым формулировкам. Оно выражает объекты и факты, а не субъективные мнения. Возможна одна и только одна его интерпретация. Определение не содержит нечетких фраз, использование отрицательных и составных утверждений запрещено.
Обязательность — требование представляет собой определенную заинтересованным лицом характеристику, отсутствие которой ведет к неполноценности решения, которая не может быть проигнорирована. Необязательное требование — противоречие самому понятия требования.
Проверяемость — реализованность требования может быть проверена.

Функциональные (Functional) — реализуют саму бизнес-функцию.
Управленческие (Manageability) — требования к доступным и безопасным сервисам; относятся к размещению системы, администрированию и безопасности.
Эргономические (Usability) — к удобству работы конечных пользователей.
Архитектурные (Architectural) — требования к архитектуре системы.
Взаимодействия (Interface) — к взаимосвязям между существующими приложениями и программным средствами и новым приложением.
Сервисного уровня (Service Level) — описывают поведение сервиса, качество его выходных данных и другие качественные аспекты, измеряемые заказчиком.

Распространенное программное обеспечение для управления требованиями

В настоящее время широкое распространение получили такие системы управления требованиями как IBM Rational RequisitePro, Telelogic DOORS, Sybase PowerDesigner и Borland Caliber RM.

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

IBM Rational Requisite Pro

Сокращение объема доработок и ускорение выхода на рынок благодаря совместной работе с заинтересованными лицами.
Повышение производительности труда за счет контроля над изменениями в требованиях и управлении ими.
Минимизация расходов и рисков за счет оценки влияния происходящих изменений.
Демонстрация соответствия требований благодаря полному отслеживанию требований.

Снижает сложность благодаря подробным представлениям с возможностью трассировки, в которых показаны отношения между родительскими и дочерними элементами.
Снижает связанные с проектом риски, показывая требования, которые могут быть затронуты изменениями требований более низкого или более высокого уровня.
Обеспечивает совместную работу географически распределенных рабочих групп благодаря применению полнофункционального, масштабируемого Web-интерфейса и цепочек обсуждения.
Обеспечивает сбор и анализ сведений о требованиях с возможностью точной настройки атрибутов и фильтрации.
Повышает производительность труда, позволяя отслеживать изменения путем сравнения версий проекта с начальными характеристиками, описанными с помощью XML.
Обеспечивает соответствие результатов проекта поставленным задачам и бизнес-целям благодаря интеграции со средствами IBM Rational для разработки и выпуска ПО.

IBM Rational/Telelogic DOORS

IBM Rational/Telelogic DOORS — семейство решений для управления требованиями и создания сложных наукоемких изделий (авиа, судостроение, поезда, ракеты, автомобили т.п.).

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

Статус выполнения работ по каждому требованию отдельно, а также по группе требований.
Статус работы над всем проектом.
Ответственное лицо для каждого требования или группы требований.
Историю изменений требования.
Ресурсы, которые потребуются для реализации требования еще до его внедрения в проект.
Связь между требованиями заказчика, пунктами технического задания, программами верификации, тестирования и задачами управления проектом.
Класс, модель или чертеж, в котором конкретное требование реализовано.

Borland Caliber RM

Borland Caliber RM – это корпоративная система управления требованиями, которая облегчает совместную работу, что позволяет группам разработчикам подходить к вехам проекта вовремя и с запланированными затратами. Borland Caliber RM также помогает командам разработчиков удостовериться, что разрабатываемое приложение удовлетворяет пожеланиям конечных пользователей за счет непрерывного сбора пожеланий на всех этапах жизненного цикла от аналитиков, разработчиков, тестировщиков и других заинтересованных в проекте лиц.

Централизованное хранилище требований для всех проектов, разрабатываемых IT-компанией.
Адаптируемость — Caliber RM можно сконфигурировать для использования в любом проекте, что повышает эффективность процесса управления требованиями.
Трассируемость требований — открытая архитектура Caliber RM позволяет связать требования с другими артефактами на всех стадиях жизненного цикла программного продукта.
Поддержка большого числа клиентов — Caliber RM прекрасно интегрируется с такими системами разработки, как Microsoft Visual Studio, Eclipse на платформе Windows.
Интеграция с другими продуктами Borland для поддержки полного жизненного цикла программного продукта.

Другое ПО

Sybase PowerDesigner
OpenSource Requirements Management Tool
RequirementsWin и другие

Новый подход к управления требованиями

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

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

Предположим, что следующие требования описывают маршруты документов соответственно на предприятиях А и Б:
А —
Б —

Здесь видно, что под F и А имеются в виду документы, а B, C, D, E — их маршруты.

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

О практике использования системы управления требованиями IBM DOORS в «НАМИ»

Рис. 1. Общий вид интерфейса программы IBM DOORS

Рис. 2. Пример скрипта на языке DXL.

Семейство IBM Engineering Requirements Management DOORS

Принцип работы Requirements Management DOORS Family

Централизованное управление требованиями

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

Трассируемость для связывания требований с элементами проекта

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

Масштабируемость в соответствии с меняющимися потребностями

Иерархическое представление папок и проектов в IBM DOORS Family упрощает навигацию вне зависимости от размера базы данных. Настраиваемые представления и общий доступ к файлам позволяют пользователям одновременно работать над одним документом. Данное решение поддерживает возможность масштабирования вплоть до сложных глобальных проектов.

Дополнение и инструменты отслеживания тестов

С помощью этого комплекта инструментов IBM Engineering Requirements Management DOORS Family можно создавать связи между требованиями и тестовыми сценариями. Можно определять тестовые сценарии, записи и сравнивать результаты тестов. Данное решение позволяет удостовериться в том, что тестовые сценарии охватывают все требования. Дополнение DOORS Family Web Access предоставляет расширенный веб-интерфейс для создания, проверки, редактирования и обсуждения требований, хранящихся в базе данных DOORS Family.

Интегрированные инструменты для управления изменениями требований

Данное решение предусматривает два варианта управления изменениями требований: простая готовая система предложений изменений либо более детальный настраиваемый процесс контроля изменений с решениями IBM для управления изменениями, в частности IBM Engineering Test Management и IBM Engineering Systems Design Rhapsody. Решение также интегрируется с HP QualityCenter для наглядного представления требований с возможностью создания тестовых сценариев для обеспечения трассируемости на основе Microsoft Team Foundation Server (TFS).

Усовершенствуйте проекты с новейшим решением IBM DOORS Family

IBM Engineering Requirements Management DOORS Next — масштабируемое решение для оптимизации обсуждения требований, совместной работы над ними и их проверки в масштабе организации и цепочки поставок. Решение также улучшает управление проектами и затратами. С помощью платформы управления IBM Jazz™ можно собирать, отслеживать и анализировать изменения требований и управлять ими, а также обеспечивать непрерывное соответствие требованиям и стандартам. Это решение доступно как локально, так и в облаке.

Читайте также: