Комплект программных приложений IBM Rational / Telelogic для поддержки управления жизненным циклом предприятия (ELM, Enterprise Lifecycle Management) позволит вам четко сформулировать и обозначить бизнес-цели компании, смоделировать, оптимизировать и привести бизнес-процессы компании в соответствие с ее стратегическими целями, настроить процессы разработки (если таковые имеются), а также идентифицировать и приоритезировать потребности своих клиентов, чтобы выйти на рынок с продуктом, максимально удовлетворяющим нужды клиентов, с минимальными затратами на его реализацию, в рамках планируемого бюджета и сроков.
Настроив и оптимизировав с помощью System Architect [Enterprize Architecture] ваши бизнес-процессы, а с помощью Focal Point [Product Management] определив тот приоритетный список требований, которые вы предполагаете воплотить в новом продукте, вы можете воспользоваться подходом IBM Rational / Telelogic для ALM [Application Lifecycle Management].
Замкнутый цикл производства инженерных систем или программных приложений может быть представлен в виде последовательности этапов:
Активность на каждом из этих этапов поддерживается разными инструментами линейки IBM Rational / Telelogic, которые могут быть позиционированы следующим образом:
Более подробно использование и взаимодействие инструментов IBM Rational / Telelogic в рамках управления жизненным циклом разработки приложений изложено в документе:
Роль "печки", от которой принято плясать, в данном случае, играет инструмент, располагающийся на самом верху приведенной диаграммы. С него и начнем описание функциональных возможностей продуктов, составляющих решение IBM Rational / Telelogic для ALM.
IBM Rational / Telelogic DOORS [Requirements Management].
Общее название IBM Rational / Telelogic DOORS , под которым оно известно во всем мире, принадлежит собственно продукту DOORS и двум его основным опциям, которые предназначены для управления требованиями:
- DWA (DOORS Web Access)
- DOORS/Analyst
IBM Rational / Telelogic DOORS - Инструмент "открывает" линейку инструментов IBM Rational / Telelogic, отвечая, как за первоначальный этап сбора и формулирования требований по проекту (Requirements Management), так и за весь жизненный цикл реализации проекта.
Инструмент хорошо известен во всем мире и заслуженно пользуется высокой репутацией.
Чем же так хорош и чем может быть полезен DOORS...? Здесь лучше пойти от обратного и вспомнить о том, какие проблемы имеет компания, которая не использует каких-либо специальных инструментов для работы с требованиями. Вот хотя бы некоторые из высказываний ваших коллег:
1. Трудно работать с большими объемами информации
В отличие от Word или Excel, которые начинают "тормозить" при работе с документом, имеющим более 3050 страниц, DOORS способен обрабатывать документы, содержащие несколько тысяч страниц. Причем отображать в одном документе текст, таблицы, видео и аудиоинформацию, графики, схемы, рисунки, слайды и т.д. И при этом позволяет работать с несколькими документами одновременно.
2. При работе с документами очень трудно контролировать и отслеживать постоянно вносимые изменения (особенно, если число служебных копий достаточно велико), так что нет уверенности, что каждый из сотрудников работает с последним вариантом документа. Работая в среде DOORS, вы можете быть уверены, что перед глазами пользователя будет всегда самая последняя версия, т.к. все пользователи работают в режиме online (предумотрены и иные возможности). Более того, в базе данных DOORS хранится вся история вносимых изменений - кто, когда, в какую сессию, под каким именем и что именно изменял в тексте требования. Хранится также информация и о baselines и имеется возможность их сравнения. Если потребуется, то всего лишь нажатием пары клавиш, вы можете вернуться к любой из предыдущих редакций конкретного требования или искомой версии baseline.
3. По статистике около 15% проектов "сыпятся" только потому, что на самых ранних стадих работы над проектом сам заказчик недостаточно плотно привлекается исполнителем к работе. DOORS свободен от этого недостатка. Инструмент имеет одну\единую базу данных, которая устанавливается на стороне исполнителя, а доступ к его базе данных - по локальной сети для своих сотрудников, через WEB-интерфейс для заказчика - регулируется системным администратором, используя иерархический принцип (только читать, читать и редактировать, возможность или запрет делегировать права доступа другим пользователям и т.д.).
4. Для согласования документов с заказчиком приходится много времени тратить на различного рода ведомственные совещания, на которых вносятся, обсуждаются, принимаются и отклоняются разного рода дополнения и изменения. В DOORS встроена система (процесс) работы с вносимыми изменениями, не требующая очного присутствия. Каждый из желающих внести изменение заполняет в DOORS специальную электронную форму (указывая новую редакцию, поясняя почему это следует сделать, отмечает приоритет и т.д.) и отправляет ее - по локальной сети или через WEB-интерфейс - в специальный репозиторий. Все эти невидимые для пользователей пока еще только предложения на внесение изменений хранятся в DOORS до тех пор, пока лицо или лица, уполномоченные принимать решения, рассмотрев вносимые предложения, не вынесут свой вердикт. Только после такой процедуры принятия решения это изменение становится доступным для всех пользователей. Система может быть настроена так, что все заинтересованные лица могут по эл.почте получить извещение о статусе их предложения - принято, отложено, отклонено.
5. При работе с большим числом документов, да еще и немалых объемов, бывает трудно увязать между собой различные требования или "блоки" информации, которые так или иначе должны быть связаны и приниматься во внимание при работе - ссылки на ГОСТы, законы или постановления, привязка к нормативным документам или рекомендациям и т.д. Находящийся в DOORS документ, сохраняя стилистику и целостность обычного документа, отображается на экране в виде набора отдельных объектов, которые с помощью встроенного механизма (drag&drop) линкования - могут быть легко связаны между собой как в рамках одного документа, так и в разных и независимых документов. Работая с одним документом, нажатием клавиши на обозначение связи, вы открываете другой соответствующий документ и именно в нужном месте. Это значительно облегчает поиск необходимой информации и ускоряет работу с ней. Механизм трассировки и интеграционные возможности DOORS обеспечивают глубокую связь между требованиями верхнего уровня (пользователя) и всеми последующими документами, задействованными на разных этапах процесса производства ПО, вплоть до привязки требования (через системные требования, функциональные требования, диаграммы, тестовые модули и т.д.) к конкретному коду, обеспечивающему реализацию этого требования, и результатам тестирования.
6. Зачастую некоторые требования не учитываются "теряются" и заказчик не получает качественный продукт. Это общая беда всех проектов. Та же вездесущая статистика говорит, что почти 75% общего числа проектов не реализуют всех поставленных задач. Для борьбы с такого рода ошибками в DOORS встроен механизм проверки неучтенных, непроверенных и не подверженных требований. А также механизм выявления "подозрительных" связей (suspect links). Это значительно облегчает контроль за реализацией всех требований проекта.
7. Мы уже давно работаем так как привыкли, наши текущие проекты находятся на разных стадиях и есть опасения, что при переходе на новые технологии, мы потеряем темпы работ. Представляя из себя как интерфейс пользователя - некий симбиоз Word и Excel, но, обладая значительно большими возможностями, DOORS весьма легок в освоении - достаточно 24 недель самостоятельного изучения, чтобы начать работать с ним, уже на 6080% используя заложенные возможности (при необходимости возможно обучение специалистов у вас в офисе на любой стадии работы с инструментом). Новые проекты могут начинаться непосредственно в среде DOORS, а для текущих предусмотрена простая возможность экспорта-импорта в\из Word или Excel.
8. Плановые сроки окончания проектов зачастую срываются. Вы далеко не одиноки в этом. Давно посчитано, что средний проект "опаздывает" на 220% от плановых показателей. Правильно поставленные и увязанные между собой задачи на самых ранних этапах проекта(DOORS) и последующий контроль их выполнения (Project Management tools) значительно сокращают сроки реализации проектов. А поддержка коллективной и командной работы, которую обеспечивает DOORS, еще и снижает не плановый и не контролируемый расход времени, позволяя руководству компании иметь перед глазами необходимую информацию и контролировать процесс выполнения работ в режиме online.
9. Есть опасения, что все это хорошо выглядит на бумаге, но может не оправдать предполагаемых вложений. Многочисленные отзывы наших пользователей, работающих с DOORS, только лишь подтверждают изложенные (и еще многие другие) преимущества инструмента. По вашему требованию мы готовы предоставить и конкретные ссылки использования DOORS, и отчеты аналитиков, и любую другую информацию. Кроме того, существуют методики расчета (ReturnOnInvestment), которые тоже подтверждают, что вложения в DOORS - за счет значительного повышения эффективности труда окупаются уже через 35 месяцев. DOORS может иметь одну или несколько баз данных с иерархической схемой доступа к ним и несколько опций для работы в офисе по локальной сети и для работы через WEB-интерфейс (удаленные пользователи, заказчики, распределенные команды):
DOORS - инструмент с собственной базой данных, предназначенный для работы пользователей в единой сети, полный функционал;
DWA online работа через WEB-интерфейс (удаленные пользователи, подразделения, заказчики), несколько ограниченный (специально) функционал (функционирует только как опция DOORS, самостоятельно не используется).
Следует заметить, что первоначально DOORS разрабатывался только, как средство для управления требованиями в процессе разработки программного обеспечения.
Однако идеи, заложенные в DOORS, оказались настолько привлекательными, что в настоящее время DOORS широко используется также и в компаниях, которые не имеют никакого отношения к разработке софта, но вынуждены - в соответствии с профилем своей работы - контролировать огромные объемы взаимосвязанной информации, например, при разработке сложных инженерных систем или комплексов.
Основное предназначение и функционал DOORS легко представить, если только задуматься над тем, какие гигантские ресурсы затрачиваются на то, чтобы внести в проект необходимые изменения, отследить документы, в которые они вносятся, проверить вносимые дополнения на непротиворечивость друг другу, а также их соответствие различным нормативным документам (корпоративные правила, стандарт, закон), известить об этих изменениях всех вовлеченных в процесс, "заставить" их рыться в многостраничных документах, выискивая последние изменения, корректировать и приводить в соответствие имеющиеся планы и "утрясать" новые, согласовывать сроки этапов и проектов, тратить время на многочисленные совещания, а для разных департаментов компании тратить время и дополнительные усилия еще и на согласование и взаимоувязку совместных действий.
По данным аналитиков независимой компании The Standish Group:
- в 22% реализуемых проектов не все вносимые изменения принимаются во внимание;
- и, как следствие, 70% проектов не реализуют всех поставленных задач.
- 3050% рабочего времени специалиста тратится на работу, никак не связанную с непосредственным решением его задачи, а уходит на работу с документами, поиском требуемой информации, отслеживанием последних редакций изменений и т.п.;
- из-за неправильной работы с требованиями средний проект опаздывает на 220%;
- и, в конце концов, 3040% всех проектов просто "умирают" до их завершения;
DOORS с легкостью решает все эти проблемы, поскольку в него заложены определенные виды анализа (Impact analyze, Traceability analyze, Coverage analyze, Change Proposal System), позволяющие управлять и контролировать процесс реализации требований и внесения и отработки изменений на всем жизненном цикле проекта.
В любой момент времени DOORS может показать:
- статус выполнения работ как над каждым требованием отдельно, так и над группой требований;
- статус работы над всем проектом;
- кто отвечает за выполнение конкретного требования или группы требований;
- кто, когда и с какой целью вносил изменения, с возможностью вернуть любую из предыдущих формулировок (сохранение истории);
- какие ресурсы потребуются для реализации предлагаемого изменения, но еще до того, как будет принято решение о его внесении;
- связь между требованиями заказчика, пунктами технического задания, программами верификации и тестирования и задачами управления проектом;
- как конкретное требование воплощается в модель, диаграмму, код, чертеж, его реализующие;
- любой промежуточный отчет;
- в одном документе все многообразие информации - текст, таблицы, диаграммы, рисунки, аудио-видео-информация,
а также поможет:
- преодолеть разногласия между многочисленными управлениями и подразделениями и привлечь их к совместной и контролируемой работе над проектом;
- сократить время заседаний и обсуждений, поскольку можно работать с данными, не покидая свое рабочее место;
- дать сотрудникам разных подразделений возможность разговаривать на одном языке (поскольку зачастую системный аналитик с трудом понимает инженера и программиста);
- легко импортировать и экспортировать данные в приемлемом формате;
- обеспечить интеграцию с используемыми или созданными вами инструментами и приложениями;
- выполнять проект в строгом соответствии с принятыми стандартами (государственными, корпоративными, финансовыми и т.д.);
- дать 100% уверенность в том, что по окончании проекта вы получаете именно тот продукт, который имел цель быть созданным.
Подтверждением больших возможностей DOORS могут служить выводы аналитиков различных независимых компаний - Yphise, Standish Group, META Group, Ovum, высоко оценивающих инструмент.
Так, например, последний (август, 2006) отчет компании Yphise "RequirementsDriven Development" позиционирует DOORS во всех номинациях, как бесспорного лидера среди инструментов для управления требованиями:
1. Оптимизация требований для достижения целей бизнеса: a) Возможность структурировать и моделировать требования b) Возможность собирать и поддерживать потребности заказчика
2. Оптимизация масштабирования проектов: a) Возможность формировать базовые версии b) Возможность анализировать и детализировать требования
3. Оптимизация отношений с заказчиками: a) Возможность демонстрировать реализацию требований b) Возможность документировать соглашения и договоренности
4. Поддержка разработки на основе управления требованиями: a) Возможность контролировать разработки b) Возможность контролировать процессы управления требованиями
А компания Standish Group уже несколько лет подряд отводит DOORS лидирующую позицию еще и по степени охвата рынка - более 36% мирового рынка на сегодняшний день.
DOORS/Analyst (AddOn)
Многие компании, работающие с требованиями, представляют их не только в виде текста, но и пытаются отобразить их в графическом виде. Такой подход, с одной стороны, позволяет на самых ранних стадиях избежать двусмысленностей или неточностей при толкования требований, а сдругой стороны, позволяет более наглядно отобразить суть требований ("лучше раз увидеть..").
Использование единой нотации для графической интерпретации требований еще в большей степени способствует взаимодействию и взаимопониманию всех вовлеченных в работу над проектом. В этих целях весьма широкое распространение среди пользователей получил стандарт визуального моделирования - UML 2.1.
Напрашивающееся - на первый взгляд использование самостоятельного (отдельного) инструмента для моделирования требований в UML, разумеется, имеет свои преимущества, но зачастую создает некоторые трудности в его применении (финансовые, интеграционные..).
Предлагаемая пользователям опция DOORS/Analyst , работающая совместно с DOORS, позволяет разрешить эти проблемы поскольку привносит непосредственно в DOORS возможность моделировать требования, использую нотацию языка UML 2.1.
Поскольку DOORS/Analyst ни на шаг не отходит от стандарта UML 2.1, то такой подход позволяет впоследствии "собирать" разные диаграммы в единое целое, используя более мощное средство моделирования IBM Rational / Telelogic Tau (или третьей стороны) для проверки и отработки функционала создаваемогой системы, для симуляции поведения приложения или автогенерации кода.
Книга "Разработка и управление требованиями", написанная английскими специалистами и переведенная на русский язык, находится в свободном доступе.
В книге уделяется особое внимание тому, как писать хорошие требования. Как основа для более глубокого понимания сути процесса разработки требований в книге вводиться понятие общего процесса разработки требований. Применение общего процесса затем рассматривается отдельно для области проблем и для области решений. Книга также описывает основные широко распространенные методы моделирования требований. Одной из важнейших тем, рассмотренных в книге, являются связи и их анализ. В книге подробно рассматриваются связи, их характеристики и методы их анализа.