Метод вопросно-ответного документирования в проектировании автоматизированных систем Текст научной статьи по специальности «Компьютерные и информационные науки»

УДК 621.372

МЕТОД ВОПРОСНО-ОТВЕТНОГО ДОКУМЕНТИРОВАНИЯ В ПРОЕКТИРОВАНИИ АВТОМАТИЗИРОВАННЫХ СИСТЕМ

© 2008 г. С.П. Красовский

Задачи документирования

Разработка автоматизированных систем (АС), интенсивно использующих программное обеспечение, исключительно сложна, носит коллективный характер, осуществляется в корпоративных средах и часто приводит к задачам, для решения которых индивидуальному интеллекту необходима оперативная интеллектуальная помощь. К числу основных источников такой помощи относится документирование процесса разработки и его результатов, эффективность которого можно существенно повысить, если в число требований к формированию и использованию документов включить «обеспечение согласованной работы интегрированного сознания и интегрированного понимания всех лиц, вовлечённых в общую работу». При реализации требования необходимо учитывать, что в документах формируется и регистрируется общий язык проекта, представлены употребления этого языка и результаты контроля понятийной (концептуальной) деятельности разработчиков в формах согласованного общего понимания. Особо важна роль документирования на ранних этапах разработки АС, когда создаются концептуальные формы существования АС, такие как «система требований», «архитектура» и «концептуальный проект».

Типичным способом решения задач документирования в любой существующей технологии разработок АС является использование шаблонов документов [1]. Так в технологии Rational Unified Process (RUP) каждый используемый документ структурирован и включает «подстрочники», комментирующие «что» и «в какой форме» должно быть представлено в соответствующих блоках документа [2]. Предполагается, что лицо, ответственное за документ, или группа лиц заполняют блоки документа, считывая содержание блока «из головы» и редактируя считанное.

Специфика разработки АС такова, что наиболее подходящей формой документов, сопровождающих концептуальное проектирование и регистрирующих его результаты, являются «живые документы» [3], каждый из которых материализован как активный динамический объект с определённым жизненным циклом. В «живой документ» (в дополнение к традиционным тексту, графике и таблицам) включают «сырые» данные и метаданные, раскрывающие различные аспекты документа в их историческом развитии.

Наиболее распространённой формой материализации «живых документов» является Web-сайт с подхо-

дящими характеристиками, например типа Wiqipedia [3] или типа Web-оболочки технологии RUP. Web-сайт не является единственной версией реализации «живых документов». Их представление в виде интеллектуальных агентов, реализованных в форме микросерверов, приведено в [4], а ещё одна форма - в виде Web-сервисов предложена и описана в [5]. Следует отметить, что типы реализации «живых документов» в виде агентов и Web-сервисов созданы без учёта проблем разработки АС и без использования средств моделирования рассуждений. Об использовании средств моделирования рассуждений в публикациях по «живым документам» не упоминается.

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

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

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

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

Предлагается включить в задачи документирования следующие требования:

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

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

Вопросно-ответная среда документирования

Рациональной корпоративной средой, в рамках которой можно обеспечить выполнение требований к документированию, является инструментальная вопросно-ответная среда на базе процессора NetWIQA (Net Working In Questions and Answers) [6]. Среда процессора предоставляет возможности для моделирования технологий разработки АС, а вернее, для вопросно-ответного моделирования дерева задач любой технологии проектирования АС. Фрагмент дерева задач технологии, ориентированной на использование документов ГОСТ 34.602-89 и РД 50-34.698-90, приведён на рис. 1. Если принято решение использовать любую другую технологию, то задачи создания её нормативных документов включаются (из специальной библиотеки) в запланированные или ситуативновыбранные позиции интерактивного дерева задач проекта (подобно тому, как они позиционированы на рис. 1).

QA -шаблоны документирования:

_ Z.0

- < Тактико-технического отчёта >

- < Концепции >

< Технического задания >

< Пояснительной записки проекта >

2 1 1 Первая итерация

_ 21.1.0 ________

_ 21.1.1 ________

!______ 21.1.2 ________

I I

Рис. 1. Фрагмент дерева задач технологии

Процессор открывает возможность для реализации метода концептуального решения системы задач проекта АС, в основу которого положены вопросно-ответное моделирование проектных задач и пошаговая детализация [7, 8].

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

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

Более того, если определённая задача документирования 2Di будет сформулирована и включена в дерево проекта, то все перечисленные возможности анализа и оценивания можно будет применять к соответствующему документу и его фрагментам. Это предложение автора приводит к вопросно-ответным моделям задач документирования, типовая структура которых приведена на рис. 2, состоит из взаимосвязанной совокупности архитектурных видов, раскрывающих документирование с определённых позиций. Каждый вид в его текущем состоянии материализуется в виде интерактивного динамического объекта, представление которого регистрируется в общей для всех видов базе данных (около 80 отношений, 500 атрибутов и 90 функций доступа).

Модель задачи документирования построена в результате адаптации вопросно-ответной модели задачи проекта [8]. Адаптация состоит в том, что часть видов, представляющих задачу проекта, из модели задачи документирования исключена (пустые бланки на рисунке), а для «Проблемно-ориентированного вида» и «Документного вида» введена специализация - «группа образцов документа» и «модель твёрдой копии документа» соответственно.

Z1

Z1.0

Служебные задачи формирования

< Постановки основной задачи > ПРОЕКТА

< Прототипа основной задачи > ПРОЕКТА

< Мотивационно-целевой структуры > Другие служебные задачи

Интеллектуально-организационный

Коммуникативный

Онтологический

Задачный вид

I_M_

Проблемно-ориентированный

Документный

Диаграммный

te

Логико-лингвистический

Обучающий

Событийный

Деятельностный

Стандартов

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

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

Рис. 2. Архитектурное представление вопросно-ответной модели документа

Результат адаптации, как модель задачи документирования, включает в себя модель документа и модель процесса его построения (через состояния документа, регистрирующие его историю). Спецификации модели документа таковы, что позволяют отнести её к классу моделей «живых документов», а средства документирования к классу систем документирования с «Управлением корпоративным содержанием» (Enterprise Content Management) [9].

В QA-модели только «Проблемно-ориентированный вид» и «Модель твёрдой копии» отражают традиционную документную форму, а в остальные виды введены полезные метапредставления, например: в «Деятельностном виде» формируются модифицированная диаграмма Ганта и ПЕРТ-диаграмма, фиксирующие деятельностную динамику построения документа; «Интеллектуально-организационный вид» и «Коммуникативный вид» представляют коллективный характер работ в проектировании АС, причём, первый из них моделирует круг лиц, вовлечённых в разработку, а второй - коммуникативное взаимодействие между ними. За каждым из видов стоит его формализация, приводящая при её программировании к визуальному представлению вида на экране монитора.

К числу основных отличий вопросно-ответной модели документа от родственных моделей «живых документов» относятся:

- её построение и использование в контексте вопросно-ответной модели задачи проекта, которой задача документирования подчинена, что и обеспечивает выполнение сформулированных выше требований;

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

вую структуру, включая типовой набор атрибутов. Более того, атрибутика элементов включает индикаторы рекурсивной структуризации, справедливой для любых XML-документов с вопросно-ответной разметкой. Этот факт существенно упрощает программирование средств преобразования и отображения XML-документов за счёт использования единообразных программных механизмов в работах с атрибутикой и приёмов рекурсивного программирования.

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

Метод вопросно-ответного документирования

Сущность метода вопросно-ответного документирования представим на примере создания документа «Техническое задание» в версии, узаконенной стандартом ГОСТ 34.602-89.

В разработанной системе вопросно-ответных средств документирования с созданием документа «Техническое задание на АС» связана служебная задача (сохраним для этой задачи обозначение ZDh использованное выше). Служебные задачи разделены на два класса. Задачи первого класса встроены (вместе с их вопросно-ответными моделями) в исходное дерево технологии, которое загружается в базу проекта по команде «Создать» для каждого нового проекта, разрабатываемого в среде процессора NetWIQA. Служебная задача, обеспечивающая создание технического задания Z ь относится к первому классу.

Второй класс служебных задач состоит из задач, которые загружаются в дерево задач проекта, как только в этом появляется необходимость. К такому типу задач документирования относится, например, документ «Постановка задачи» в версии, соответствующей нормам РД 50-34.698-90. Загрузка заключается в том, что в соответствующем «месте» дерева задач создаётся подчинённая задача 2 к, к которой присоединяется шаблон типовой вопросно-ответной модели QA(2DTk) для очередного документа. Шаблоны типовых моделей QA(2DTk) документов хранятся в специальной библиотеке шаблонов.

Фрагмент шаблона типовой модели QA(2DTi) для документа «Техническое задание» приведён на рис. 3. В шаблоне, как и в его фрагменте, с каждой нумерованной позицией текста стандарта ГОСТ 34.602-89 связан вопрос, требующий содержательного заполнения позиции, которое интерпретируется как ответ. После загрузки шаблона в дерево задач образуется задача документирования, и становится активной её вопросно-ответная модель, в «Логико-лингвистическом виде» которой будут активизирована совокупность интерактивных объектов типа «вопрос», соответствующих перечню вопросов в шаблоне, в том числе и перечню, представленному на рис. 3. С этого исходного состояния начинается построение «живого документа» «Техническое задание». В результате построений шаг за шагом формируется и оперативно используется его модель, структура которой приведена на рис. 2.

Шаблон, фрагмент которого приведён на рис. 3, связан с образцами «Технического задания», наиболее подходящий из которых может быть загружен в дерево задач вместо шаблона.

Q1.3.Характеристика объектов автоматизации? Q1.3.1.Краткие сведения об объекте автоматизации или ссылки на документы, содержащие такую информацию?

Q1.3.2.Сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды?

Q1.3.3.Основные параметры и характеристики объектов проектирования? Q1.4.Требования к системе? Q1.4.1.Требования к системе в целом? Q1.4.1.1.Требования к структуре и функционированию системы?

Q1.4.1.1.1.Перечень подсистем, их назначение и основные характеристики, требования к числу уровней иерархии и степени централизации системы?

Q1.4.1.1.2.Требования к способам и средствам связи для информационного обмена между компонентами системы?

Рис. 3. Фрагмент типовой модели документа «Техническое задание»

Информация из любого образца, включённого в «Проблемно-ориентированный вид» модели документа, переносима в его вопросно-ответное представление, а затем и в «модель твёрдой копии». При необходимости, а это обычно и происходит, в экземпляр вопросно-ответной модели «Технического задания» вводятся дополнительные интерактивные объекты, представляющие дополнительные вопросы и ответы.

По сути дела по образцу типовой модели «Технического задания» создаётся её конкретный экземпляр, в котором вопросы типового шаблона адаптируются к содержанию разработки АС, редактируются (при необходимости) и уточняются за счёт подчиненных вопросов на любую глубину подчинения. Для каждого из вопросов экземпляра формируются адекватные ответы.

Ещё раз отметим, что формирование вопросно-ответной модели документа в среде процессора NetWIQA осуществляется так, что образуется специфический интерактивный объект QA(2Dj, состоящий из связной совокупности интерактивных объектов типа «вопрос» и «ответ». Названные интерактивные объекты персонифицированы (известен член группы, отвечающий за каждый объект), представлены через богатую табличную атрибутику, позволяющую показать каждый из объектов и их совокупности с помощью ряда визуальных форм на каждом из рабочих мест корпоративной сети.

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

Как было отмечено выше, для управляемого построения документов разработан метод вопросно-ответного документирования, специализирующий метод концептуального решения задач проекта [7] к его применению в задачах документирования. Динамика метода, в его приложении к документу «Техническое задание», частично представлена выше. Специализация включает разработку дополнительного набора методик документирования, их сценарную реализацию (по образцу «мастеров», используемых при установке программного обеспечения) и разработку набора процедур, обеспечивающих преобразование вопросно-ответных представлений документов в «модель твёрдой копии». В число этих процедур входят и те, которые обеспечивают формирование Ыт1-версии документов.

Базовой деятельностной единицей как метода концептуального решения, так и вопросно-ответного метода документирования является «акт интерактивного взаимодействия» разработчика с вопросно-ответной моделью. Такой акт в работе с задачами

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

Совокупность связанных интерактивных актов интерпретируется как «ОА-программа» или фрагмент «QA -программы» на базе команд, макрокоманд и других средств процессора NetWIQA. Система методик, обслуживающая метод концептуального решения (и метод вопросно-ответного документирования), выполняет функции типового набора «ОА-процедур». Решение конкретной задачи документирования «программируется» (планируется и исполняется) в среде процессора NetWIQA. Ответственность за конкретное решение и его «программную версию» несёт разработчик, на которого возложена ответственность за задачу. Потенциальное различие версий решения обусловлено тем, что исполнение любой методики может быть прервано в любой момент времени, если для этого есть причина. Отработка прерываний включена в состав метода.

Перейдём к вопросам реализации системы вопросно-ответных средств документирования. В процессор NetWIQA вложена система средств интерактивного взаимодействия с моделями «задач», «вопросов» и «ответов», построенных на базе протоколирования рассуждений в текущем и предшествующих проектах, а также рассуждений, вложенных в стандарты, нормативы и шаблоны, используемые в проекти-

ровании АС. Система средств интерактивного взаимодействия открыта для компонентного развития и использования в клиент-серверной корпоративной среде.

Система средств документирования реализована с помощью специальной компоненты «Документирование», включённой в состав приложения комплекса, обслуживающего концептуальное проектирование АС. Для подключения компоненты «Документирование» к приложению «Концептуальное проектирование» использован общий механизм плагинов. В компоненте «Документирование» реализована только часть функций «Системы вопросно-ответных средств документирования». Одной из таких функций является перевод вопросно-ответной формы документа в его нормативную форму в формате Word. Остальные функции, необходимые для интерактивного документирования, «заимствуются» из приложения «Концептуальное проектирование», а значит, и из базового набора средств процессора NetWIQA.

Приложение «Концептуальное проектирование», вложенное в процессор NetWIQA, разработано с ориентацией на использование российских стандартов разработки АС, в условиях модернизации потоков работ и документов за счёт средств технологии RUP. По этой причине процессор NetWIQA использован, в том числе и для моделирования технологии RUP. Для осуществления поэтапной модернизации технологии разработана упрощенная версия приложения «Концептуальное проектирование», в которой поддерживаются функции только комплекса вопросно-ответных средств документирования в разработках АС.

QA -модель (ZD,)

/ 1 1 1

1 1

Ответственный за задачу — та ■ 5 лиц ы

Задача Z

Интерактивное взаимодействие

£ % f

Лица, заинтересованные в решении задачи документирования

Решение

Обоснование

Оценивание

Ревизия

Освоение

Документ в формате Word

Рис. 4. Схема интерактивного взаимодействия

В этой версии, получившей название DocWIQA, обслуживается работа с 30 российскими типовыми проектными документами (включая план-проспект пояснительной записки эскизного проекта, ведомость эксплуатационных документов, отчёт о выполнении научно-исследовательских работ (концепция), программу обеспечения надёжности, описание применения, руководство оператора, руководство системного программиста) и 30 документами технологии RUP (включая документ-концепция Vision, план управления требованиями, документ «архитектура ПО», план управления рисками, план обеспечения качества, план измерений). Для каждого из документов, задача построения которого включена в состав средств DocWIQA, разработаны «мастер построения документа» и процедура перевода в «модель твёрдой копии».

Выводы

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

расширяемая и модифицируемая по составу документов, что позволяет адаптировать её к специфике проектной организации.

Литература

1. Леффингуэлл Д., Уидриг Д. Принципы работы с требованиями к программному обеспечению: унифицированный подход. М., 2002.

2. Крачтен Ф. Введение в Rational Unified Process. M., 2002.

3. Living_document http://en.wikipedia.org/wiki/Living_document.

4. SchimkatR.-D., Kuchlin W. Living Documents - Micro Servers for Documents //XML-Based Data Management and Multimedia Engineering - EDBT 2002, Czech Republic. 2002. P. 764-767.

5. Ghandeharizadeh Sh. at all. Document as a Web Service: Two Complementary Frameworks // XML-Based Data Management and Multimedia Engineering - EDBT 2002, Czech Republic. 2002. P. 809-813.

6. Соснин П.И. Инструментарий вопросно-ответных рассуждений в корпоративной среде автоматизированного проектирования // Программные продукты и системы. 2004. № 3. С.7-12.

7. Sosnin P. Question-Answer Means for Collaborative Development of Software Intensive Systems // Collection of scientific paper "Complex Systems Concurrent Engineering". Part 3. L. 2007. P. 151-158.

8. Sosnin P. Conceptual Decision Of Tasks In Development Of

Software Intensive Systems // Interactive Systems: Problems of Human-Computer Interactions - IS 2007. Russia. 2007, P. 8-20.

9. Технологии документирования. http://www.d0c.ru/

10. Новак Л.Г., Кузнецов С.Д. Свойства данных XML. Тр. ИСП РАН. Т. 4. (2003).

ТИ ЮФУ;

ОАО НПО «Марс» 29 сентября 2007 г.