Ibm Rational SoDa
Формирование проектной документации обычно требует много времени и усилий. Нередко составление документов и отчетов в течение жизненного цикла проектов осуществляется случайным образом, а то и вовсе игнорируется из-за нехватки времени и ресурсов, которые требуются на их разработку и сопровождение.
Специализированное средство IBM Rational SoDA помогает успешно решить эти проблемы, позволяя автоматизировать создание и сопровождение необходимой проектной документации. SoDA значительно облегчает процесс документирования в проекте. Инструмент позволяет более согласованно и оперативно генерировать необходимые документы и отчеты, автоматически извлекая исходную информацию из репозитариев и артефактов проекта, созданных в других инструментальных средствах. Таким образом, SoDA – мощный инструмент для организации обмена жизненно важной информацией проекта между его непосредственными и внешними участниками (заказчиками, конечными пользователями и т. д.).
Рисунок 10 – Работа в Rational SoDA
Использовать IBM Rational SoDA крайне просто. Сначала создаются шаблоны документов, а затем на их основе генерируются сами документы. При этом участники проекта акцентируют внимание только на создании продукта и сопутствующих артефактов. Можно быть абсолютно уверенным, что сгенерированный документ будет всегда включать актуальную информацию, полученную из проектных репозитариев и артефактов. IBM Rational SoDA изначально включает несколько десятков шаблонов.
Основу IBMRationalSoDAсоставляетMicrosoftWord. Любой внешний вид документа, который можно создать в Word, может быть представлен в виде шаблона SoDA Таким образом, IBM Rational SoDA поддерживает возможность стандартизации типов документов в рамках отдельного проекта или всей организации в целом. Эта стандартизация может обеспечить соответствие документов таким стандартам, как ISO, SEI CMM/CMMI и IEEE, повышая качество проектной документации и облегчая взаимодействие занятых в проекте сотрудников.
Шаблоны SoDA содержат информацию о форматировании документа, его структуре и стилях. В них фиксируется расположение источников информации, из которых извлекаются необходимые данные. По желанию пользователя IBM Rational SoDA может автоматически генерировать документы и отчеты в формате HTML. Это значительно упрощает публикацию документов в Интернет. Данный функционал особенно полезен для распределенных проектных команд.
IBM Rational SoDA генерирует документы, извлекая информацию из следующих проектных репозитариев:
- репозитарий требований Rational RequisitePro;
- репозитарий тестирования Rational TestManager;
- базы данных запросов на изменения Rational ClearQuest;
- версионные объектные базы (VOB) Rational ClearCase;
- общий проектный репозитарий Rational Administrator.
Кроме того, IBM Rational SoDA может извлекать данные из следующих отдельных артефактов проекта:
- модели Rational Rose и Rational Rose RealTime;
- планы Microsoft Project;
- документы Microsoft Word.
Документация программного обеспечения для крупных проектов может составлять сотни и тысячи страниц. При этом документы должны быть постоянно актуальными, чтобы отражать текущее состояние дел в проекте. IBM Rational SoDA позволяет обновлять лишь отдельные части документов, что значительно упрощает ведение процесса документирования.
Требования к аппаратно-программным средствам. Процесс управления требованиями, участники процесса управления требованиями.
Программные требования – Software Requirements – свойства программного обеспечени, которые должны быть надлежащим образом представлены в нём для решения конкретных практических задач. Данная область знаний касается вопросов извлечения (сбора), анализа, специфицирования и утверждения требований.
Опыт индустрии информационных технологий однозначно показывает, что вопросы, связанные с управлением требованиями, оказывают критически-важное влияние на программные проекты, в определенной степени - на сам факт возможности успешного завершения проектов. Только систематичная работа с требованиями позволяет корректным образом обеспечить моделирование задач реального мира и формулирование необходимых приемочных тестов для того, чтобы убедиться в соответствии создаваемых программных систем критериям, заданным реальными практическими потребностями.
На практике часто применяется подход, используемый в различных методологиях разработки ПО и базирующийся на определении групп требований к продукту. Такой подход обычно включает группы (типы, категории) требований, например: системные, программные, функциональные, нефункциональные (в частности, атрибуты качества) и т.п. Классический пример (см. рисунок 1) высокоуровневого структурирования групп требований как требований к продукту описан в работах одного из классиков дисциплины управления требованиями – Карла Вигерса.
Рисунок 1. Уровни требований по Вигерсу [Вигерс, 2003, с.8, рис. 1-1]
Рисунок 2. Область знаний “Программные требования”
Сама же структура обсуждаемой области знаний в большой степени совместима со стандартами IEEE 12207.x, ISO/IEC, ГОСТ Р ИСО/МЭК 12207. Такая структура построена исходя из идеи выделения ключевых групп вопросов дисциплины.
Область знаний управления требованиями включает 7 секций, каждая из которых представлена в виде ключевых тем (см. рисунок 2). Кроме того, данная область знаний тесно связана со следующими областями:
Software Design
Software Testing
Software Maintenance
Software Configuration Management
Software Engineering Management
Software Engineering Process
Software Quality