Что такое SoDA?
SoDA, по существу, представляет собой макрос, написанный для MS Word и особенно полезный при реализации крупных информационных проектов, в которых на составление документации и ее постоянную переработку обычно тратится очень много времени и сил разработчиков.
По задаваемым пользователем шаблонам SoDA "компилирует" документацию, собирая в один документ текстовые и графические данные из различных источников, например из моделей, созданных в . Далее пользователь может отредактировать полученный документ с помощью Microsoft Word или Adobe FrameMaker. Как и любая система отчетности, SoDA базируется на тех данных, которые получает из сторонних программ.
SoDA поддерживает всю линейку продуктов Rational Software, позволяя создавать сложные комбинированные отчеты на основе выходных данных программ состава Rational Suite. Плюс ко всему SoDA имеет доступ к данным из Microsoft Project.
Основные возможности системы:
- Автоматическое извлечение информации из файлов, созданных различными инструментальными средствами. SoDA "понимает" структуру информации, хранимой теми системами, с которыми она интегрирована, а сама информация доступна ей через API этих систем.
- Сохранение при "перекомпиляции" текста и графики, введенных пользователем вручную в текстовом процессоре. Если пользователь, скажем, в Microsoft Word, добавил какие-нибудь комментарии или иллюстрации в сгенерированный с помощью SoDA документ, то при перестраивании данного документа SoDA его не испортит.
- Настройка шаблонов, по которым генерируется документация. С помощью удобного визуального редактора можно создавать шаблоны, соответствующие всевозможным внешним стандартам (таким как ISO 9000, IEEE, MIL-STD-498 и DOD-STD-2167A) или внутренним стандартам компании.
- Синхронизация с источниками и проверка актуальности документации. Связи между отдельными частями документации и исходными файлами запоминаются. Поэтому, во-первых, SoDA может отслеживать изменения, происходящие с источниками, на основе которых была в последний раз "скомпилирована" документация, а во-вторых, пользователь может из любой секции документа быстро получить доступ к источникам, информация из которых используется в этой секции.
- Частичная "перекомпиляция" больших документов.
Проектная документация к масштабным программным системам может достигать гигантских объемов. Поэтому в SoDA предусмотрена возможность "перекомпилировать" только такие части документации, которые действительно утратили актуальность. - Сбор информации из многочисленных и разнородных источников.
- Документирование всех этапов работы над проектом.
- Проверка соблюдения требований, предъявляемых к разрабатываемой системе. SoDA позволяет сформировать таблицы, из которых можно понять, насколько полученные результаты соответствуют требованиям, определенным на начальных этапах проектирования.
- Поддержка русифицированных шаблонов и отчетов.
Из описания следует, что SoDA может работать в двух режимах. Первый - генерация отчета по данным на основе существующего шаблона, который, в свою очередь, строго следует стандартам RUP и ISO. Второй - генерация отчета на основе собственного шаблона компании, оформленного произвольным образом в соответствии с ее традициями. Давайте немного остановимся на первом режиме, когда за основу берется стандартный шаблон. Известно, что компания Rational не только полностью описала процесс выпуска программного обеспечения, но и создала программные средства для каждого этапа этого процесса. Следовательно, каждый продукт сохраняет данные, а SoDA по ним строит ("компилирует") отчет. Если внимательнее присмотреться к этапам разработки приложений с точки зрения Rational, получится следующий список:
- Бизнес-моделирование.
- Определение требований.
- Анализ и проектирование.
- Тестирование.
- Реализация.
- Внедрение.
Естественно, все этапы детально описаны, и на каждом из них предполагается получение документа строго определенного образца (согласно RUP), после того как соответствующие данные были обработаны той или иной программой из набора средств Rational. Так, на первом этапе при помощи SoDA можно получить документы "Оценка организации заказчика", "Словарь терминов предметной области", "Коммерческое предложение", "Бизнес-правила" и т.д.
На втором этапе можно получить документы "Спецификация на программную систему", "Спецификация на функции системы". Каждый из этих отчетов будет соответствовать RUP, а форма изложения - отражать требования ISO. В дальнейшем такой документ можно согласовать с заказчиком. Обратите внимание: первый этап называется "Бизнес-моделирование", что подразумевает использование на данном этапе средств визуального проектирования. Согласно технологии RUP, этим средством является Rational Rose, позволяющее на основе различных диаграмм получить полную бизнес-модель предприятия и модель проектируемой системы. Соответственно, опять же по технологии RUP, на этапе проектирования аналитик или проектировщик не только рисует модель, создавая определенные связи между диаграммами, но и комментирует каждое свое движение на специальных полях либо подключает уже имеющиеся документы к модели. Разумеется, в результате получается отличная модель, полностью описывающая бизнес-процессы и программную систему. Правда, понятной она будет только узкому кругу лиц, представляющих себе полную картину сделанного. Заказчик же, к сожалению, зачастую плохо ориентируется в мире диаграмм... Вот и настает черед SoDA! Из меню Rose запускается составитель отчетов, пользователь выбирает тип отчета и через 1-5 минут получает готовый документ с разметками, комментариями и фрагментами моделей в формате Word. При этом все элементы документа представляют собой внедренные объекты, а это значит, что изменения, внесенные в модель, автоматически отражаются в документе. В табл. 1 показано, с какими программными продуктами работает SoDA и какие отчеты может создавать. Для тех, кто не знаком с терминологией, в табл. 2 даны расшифровка и описание типов диаграмм в Rose.
Таблица 1
ПродуктОтчетХарактеристика/комментарий
| Version | Отчет по версии одного элемента из репозитария ClearCase |
| Vob | Отчет по состянию всех репозитариев в целом |
| | Element | Отчет по свойствам элементов |
| | Region | Отчет по всем используемым в проекте регионам |
| All Defect in This State | Вывод всех дефектов, находящихся в указанном состоянии |
| DocsReqts.doc | Отчет по требованиям и документам проекта |
| | Reqts.doc | Отчет по требованиям |
| | ReqtsAttrs.doc | Отчет по требованиям с выводом атрибутов требований |
| | ReqtsTraces.doc | Отчет по требованиям с использованием трассирования |
| BuildDetail.doc | Детальный отчет по тестированию с выводом ошибок, состояний и владельцев |
| | Build Summary.doc | Упрощенная версия вышеуказанного отчета |
| | ComputerDetail.doc | Отчет по характеристикам компьютеров, на которых проводилось тестирование, в том числе IP-адрес машины, на которой проигрывались тесты, наименование операционной системы |
| | ScriptDetail.doc | Отчет по скриптам тестирования, в том числе путь к файлу, имя его владельца |
| | TestDocDetail.doc | Отчет по тестовым документам |
| 498idd.doc | Отчет по списку документов, дизайну интерфейса, трассировке требований |
| | 498irs.doc | Список документов, требования к интерфейсу, квалификационный лист, трассировка требований |
| | 498ocd.doc | Список документов, требования к продукту, квалификационный лист, трассировка требований |
| | 498sdd.doc | CSCI-заключение, дизайн, трассировка требований |
| | Classes.doc | Отчет по всем классам в системе. Отчет следует иерархии и показывает связи |
| RUP | Actor Report.doc | Простой и быстрый отчет по характеристикам, отношениям и диаграммам состояний модели |
Таблица 2
АббревиатураРасшифровкаОписание
| IDD | Interface Design Description | Описание интерфейса системы |
| IRS | Interface Requirements Specification | Спецификации на требования интерфейса |
| OCD | Operational Concept Description | Операционное концептуальное описание |
| SDD | Software Design Description | Описание программного дизайна |
| SDP | Software Development Plan | План разработки |
| SRS | Software Requirements Specification | Спецификации на требования |
| SSS | System/Subsystem Specification | Спецификации на систему |
Еще раз внимательно посмотрите на табл. 1. Хотя я не стал описывать все виды стандартных отчетов, представленного списка с лихвой должно хватить для правильной оценки возможностей продукта. К слову сказать, все вышеприведенные форматы отчетов помогут аналитикам и проектировщикам точно договориться с заказчиком о том, какую систему он хочет получить. Тестировщики же смогут генерировать отчеты по всем ошибкам (дефектам) и представлять их в удобной форме. Не остались без внимания и разработчики. Для них будет полезным отчет по классам, когда в наглядном виде можно получить список классов с иерархией и описанием всех атрибутов и методов, не выходя из среды разработки. В качестве одного дополнительного (я бы даже сказал - комплексного) штриха можно с помощью только Rose и SoDA сделать отчет по классам той системы, которая УЖЕ написана и скомпилирована! Rose имеет механизм так называемого обратного проектирования, когда исходный код превращается в модель Rose (преобразуясь в UML-нотацию). При обратном проектировании учитываются все составляющие классов, а также комментарии, которыми они снабжались, вследствие чего на выходе получается полная модель всех классов (с иерархией). После этого достаточно будет просто пропустить модель через систему генерации отчетов - и вы получите полноценный документ, описывающий систему классов программного продукта по всем мыслимым и немыслимым стандартам и правилам! Понятно, что даже с помощью SoDA трудно получить стопроцентно читабельный отчет для заказчика, но свои процентов восемьдесят такого отчета SoDA честно сгенерирует.Остальную правку можно возложить на плечи специалиста, способного придать отчету (на этом этапе уже - документу) литературный вид. Вернувшись к основе ведения проектов - RUP, можно выделить 10 важнейших моментов, когда без системы отчетности невозможно обойтись. Это бывает в тех случаях, когда необходимо:
- Выработать концепцию будущего приложения (документы, роли участников).
- Выработать план.
- Идентифицировать и смягчить риски.
- Устанавливать и отслеживать проблемы.
- Проанализировать прецеденты.
- Разработать компонентную архитектуру.
- Создавать и тестировать продукт.
- Проверять и оценивать результаты.
- Управлять изменениями и контролировать их.
- Обеспечивать ввод в коммерческую эксплуатацию и поддержку пользователей.