Содержание к диссертации
Введение
Глава 1. Обзор методов обработки текстов технической документации 15
1.1. Особенности приемки проектной документации в топливно-энергетическом комплексе 15
1.2. Методы обработки технической документации 19
1.3. Методы определения тематического сходства документов 29
1.4. Методы выделения терминов из документации 39
Выводы к главе 1 45
Глава 2. Метод определения полноты проектной документации 46
2.1. Основные положения метода определения полноты проектной документации 46
2.2. Формальный метод определения полноты проектной документации 51
2.3. Метод визуализации результатов для эксперта 58
2.4. Метод принятия решения экспертом 63
Выводы к главе 2 69
Глава 3. Особенности практической реализации метода для предприятий топливно энергетического комплекса 70
3.1. Учет особенностей структуры технического задания 70
3.2. Программная реализация метода 78
3.3. Особенности внедрения в системы электронного документооборота предприятий топливно-энергетического комплекса 85
Выводы к главе 3 89
Глава 4. Анализ эффективности применения метода 90
4.1. Оценка точности работы метода 90
4.2. Результаты экспериментов по выделению терминов предметной области из документов организации 98
4.3. Визуальное представление результатов 102
4.4. Использование терминов предметной области 107
Выводы к главе 4 110
Заключение 111
Библиографический список 1
- Методы обработки технической документации
- Метод визуализации результатов для эксперта
- Особенности внедрения в системы электронного документооборота предприятий топливно-энергетического комплекса
- Результаты экспериментов по выделению терминов предметной области из документов организации
Методы обработки технической документации
Документация является неотъемлемой частью жизненного цикла разработки системы и является обязательной частью системы и требует затрат на ее создание и применение. От качества документации во многом может зависеть успешность и эффективность разрабатываемой системы. При этом документация должна быть адекватной и точно соответствовать продукту, а содержание понятно изложено, с возможностью его освоения и применения квалифицированными специалистами. Разрабатываемая документация должна соответствовать установленным стандартам и гостам, что упрощает ее разбор. Полнота отображения требований и параметров системы в документах должна полностью определять достоверность информации для взаимодействия заказчиков, пользователей и разработчиков. Разрабатываемая системная документация подвержена постоянным изменениям и должна соответствовать разрабатываемой системе на всех этапах разработки, что требует постоянной поддержки и доработки, которые вносятся всеми участниками разработки при взаимодействии между системой и документами. Неточности документации так же опасны для системы, как и ошибки работы самой системы. Следовательно, во время разработки сложных систем необходима организация работы группы специалистов, обеспечивающих реализацию основных системных работ по документированию процессов проектирования и создания системы. В результате, затраты на разработку документации сложных систем может достигать трети от общей трудоемкости разработки [67].
Наиболее часто применяемым способом проверки технических документов на практике является ручной анализ с привлечением экспертов. Проверка многостраничного документа может занять у опытного эксперта, знающего предметную область и структуру документа, незначительное время. Однако, любое изменение структуры или тематики приведет к увеличению трудозатрат эксперта. Как минимум, при повторной приемке исправленного документа эксперт должен снова ознакомиться со всем документом с тем, чтобы найти все изменения в нем. В случае сложных проектных работ, в процессе которых порождается большой объем документации из различных областей знаний, для проверки выделяется группа совместно работающих экспертов. Однако, увеличение количества экспертов ведет к еще большему увеличению трудозатрат в связи с необходимостью налаживания между ними взаимодействия, а также к возможным проблемам взаимосвязи между конкретными экспертами, работающими с близкими документами. Также стоит заметить, что увеличение количества экспертов не всегда ведет к полному покрытию всех предметных областей и пробелы все также остаются возможны. Набор разработанных методических указаний, применяемых в конкретных случаях [38] помогает при проектировании и сверке документов, но не является решением проблемы, а лишь содержат некий базис полезной информации.
Одним из методов, помогающих экспертам по приемке документации не запутаться в ее содержимом, а разработчикам документации - не упустить ничего важного, является разработка структуры этой документации. Структура разрабатываемой документации должна быть подробно проработана еще на начальных этапах процесса разработки. Один из эффективных способов проработки будущей документации - создание информационных шаблонов. Подобные шаблоны помогают организациям в создании качественной документации, способной полностью раскрыть все характеристики системы в понятной и адекватной форме.
Автоматическая обработка технической документации является одним из развивающихся направлений обработки текстов на естественном языке [104, 120, 134]. Автоматическая обработка технической документации может осуществляться несколькими способами, одним из которых является применение формальных методов представления знаний предметной области, например, онтологии и тезаурусов. Применение онтологии позволяет решить такие проблемы обработки документации, как синонимия, замена понятий сходными, изложение задачи с использованием терминов другого уровня абстракции. К недостаткам данного подхода можно отнести тот факт, что каждая предметная область требует разработки своей собственной онтологии, а создание «общей» единичной онтологии невозможна [18]. В качестве альтернативы следует упомянуть подходы, основанные на извлечении ключевых слов и терминов (в основном без связей между ними) с использованием методов автоматической обработки текстов. Эти методы уступают в эффективности обработки документации, однако выигрывают в трудозатратах к своему применению.
Разработка онтологии - активно развивающаяся область науки. Современные методы стремятся к созданию методов автоматического формирования онтологии предметной области по коллекции документов, но все еще далеки от идеала. При этом логично использовать способы, не завязанные на онтологию в случаях, когда разработка онтологии только начата или невозможна. В этом случае на начальных этапах задача может решаться методами автоматической обработки текстов. В дальнейшем, после того как будет разработана онтология предметной области, достаточная для решения практических задач, можно будет перейти к ее использованию. В связи с этим возможна разработка комбинированного метода, сочетающего в себе все плюсы использования методов автоматической обработки текстов и методов представления знаний.
Кроме того, результаты, получаемые при помощи методов автоматической обработки текстов, впоследствии можно использовать для генерации онтологии. Для этого необходимо провести накопление знаний об использованных терминах, контексте их употребления и, как следствие, связях между ними. Однако, подобный подход является темой для самостоятельного исследования.
Одной из задач в этой области является выделение значимой информации из документов, например выделение информационной структуры и требований к наполнению. На основе выделенной информации становится возможным создание шаблонов документов, используемых для упрощения процесса проектирования новой технической документации. Поскольку разные фрагменты документов сильно взаимосвязаны между собой и зачастую повторяются, существует возможность автоматизации процессов создания документации по шаблонам, которая будет рассмотрена в Главе 3. Качественно выполненная автоматизация разработки документации позволяет сократить расходы по созданию документации и избежать фактора человеческих ошибок. Разбор документов позволяет определить и выделить установленные требования [52], а также проверить текст на соответствие требованиям технической документации [94].
В общем случае можно сказать, что системы автоматизации создания документации и работы с документооборотом основаны на идее определенной внутритекстовой разметки, содержащей метаинформацию о структуре, иерархии и взаимосвязи объектов и документов между собой. Системы автоматизации используется на этапе проектирования с целью сбора результатов работы разработчиков и преобразования их в установленную форму. После проверки и утверждения, данные используются в процессах производства и эксплуатации системы [109]. Необходимо заметить, что документация, разрабатываемая в ходе внутреннего и внешнего проектирования, строго регламентирована стандартами. В связи с этим и системы автоматизации проектирования генерируют ее в строго заданной стандартами форме.
Автоматизированные системы поддержки электронных моделей изделия обозначаются термином PDM - системы управления данными о продукте. Информационное описание системы осуществляется по стандарту ISO 10303 STEP или ГОСТ Р ИСО 10303 [40] (Действует в Российской Федерации). Подобные системы должны соблюдать регламент процесса проектирования, в ходе которого документация изделия многократно изменяется, вплоть до последних этапов разработки, на которых разработанная документация переходит из разрабатываемого состояния в использование. Для корректной работы системы должны обрабатывать и хранить информацию, получаемую из различных источников в стандартизированную электронную форму. Кроме того, средства поддержки должны обеспечивать возможность параллельного проектирования, и, следовательно, полученная на новом этапе проектирования информация должна быть сразу же доступна к применению на других этапах [101, 102].
Метод визуализации результатов для эксперта
Исследование особенностей ТЗ и отчетных документов показало, что требования к результатам работы обычно описываются с использованием особых синтаксических конструкций. При этом для поиска требований обычно нужен далеко не весь текст ТЗ, так как часть текста может относиться, например, к условиям выполнения проекта. Помимо требований, описываемых в различных предметных областях примерно одними и теми же фразами (хотя и с наличием различий, определяемых предметной областью), ТЗ может содержать специфичные термины, используемые для описания сути проекта. Список терминов при этом определяется как объектом, так и областью проектирования.
Определение полноты документа основывается на использовании значимых n-грамм и специализированных терминов, которые характеризовали бы текст технического задания и показывали бы установленные требования, представленные в документе.
Будем говорить, что словосочетание входит в /-е предложение (с a s,), если в s, существует контактное подмножество, эквивалентное с. Введем список словосочетаний или слов-маркеров, вводящих требования к изделию, поставленные заказчиком: М={с}. (8) Маркеры выбираются экспертом с учетом тематики конкретного технического задания. Также введем множество Ms, содержащее базовые маркеры, пригодные для любой тематики (Ms а М):
Ms={c}. (9) Предложения, в которых встречается словосочетание-маркер, расценивается как значимое. Т.е. предложение s, входящее в текст ТЗ, называется значимым, если 3ceM:ccs. Значимое предложение входит в значимый фрагмент. Значимый фрагмент - несколько предложений, где одно или несколько являются значимыми: где t - текст, в который входит фрагмент, s - номер начального предложения фрагмента, е - номер последнего предложения фрагмента.
Эксперименты показали, что качество работы метода с документами топливно-энергетического комплекса возрастает, если во фрагмент включается одно предложение до и после значимого предложения [54]. Предыдущее предложение часто вводит определения или определяет общее направление и отрасль ТЭК, последующие расшифровывают требования и содержат значения конкретных атрибутов (к примеру, напряжение или мощность). Параметры rl и г2 алгоритма показывают размер значимого фрагмента вправо и влево от значимого предложения. Однако, если ключевая фраза встречается в предложении, после которого идет перечисление, то выделяется это предложение и весь текст до конца перечисления. В результате анализа были разработаны правила определения границ значимых фрагментов ТЗ: 1. Если маркер встречается в предложении связанного текста, то в значимый фрагмент включается это предложение, Гі предложений влево и г2 предложения вправо; 2. Если ключевая фраза встречается в предложении, после которого идет перечисление, то выделяется это предложение и весь текст до конца перечисления; 3. Если фраза встречается отдельно (например, заголовок «требуется»), то выделяется весь следующий абзац.
Термины предметной области обычно описывают в ТЗ особенности проекта, и также могут использоваться для поиска значимых фрагментов. Заметим, что если синтаксические конструкции, определяющие требования, примерно одинаковы для различных предметных областей (хотя и зависят от них), то список терминов уникален при переходе от одной предметной области к другой. Более того, список терминов может существенно меняться и при переходе от одного проекта к другому в рамках одной предметной области. Кроме того, количество терминов, употребляемых в тексте ТЗ сопоставимо (а чаще всего превосходит) с количеством требований. В связи с этим список терминов не может быть зафиксирован в системе, более того, настройка этого списка вручную представляется сложным и затратным мероприятием. Как показывает практика, при извлечении списка вручную специалист пропускает значительную часть терминов или включает в их список словосочетания, не являющиеся терминами. Всё это существенно влияет на качество работы системы.
В связи с этим выделение терминов должно производиться непосредственно из текста ТЗ. Для этого используем меру странности. Данная мера считается исходя из следующих положений. Пусть у нас имеется набор текстов общей лексики (например, беллетристика). Назовем такой набор контрастной коллекцией текстов. Пусть также имеется набор текстов в заданной предметной области, называемый коллекцией предметной области. Тогда слова, редко встречающиеся в контрастной коллекции, но часто в коллекции предметной области, могут считаться терминами данной предметной области. Такое различие может быть определено количественно в отношении частоты встречи слова в специализированном тексте и контрастном корпусе. Такое отношение мерой странности. Мера странность слов рассчитывается по формуле (3). Терминами будем считать слова, для которых мера странности значительно больше единицы. Для вычисления специализированных терминов документа производится двойная выборка кандидатов в термины, предложенная в работе [55]. Текст документа разбивается на слова, которые приводятся к нормальной форме. Идущие подряд слова образуют кандидатов в термины, при этом кандидаты в термины могут состоять только из существительных, прилагательных, причастий, порядковых числительных, предлогов и союза «и», а наречия и местоимения опускаются. Вычисление производится в два шага. На первом шаге в список lcoi выделяются кандидаты в термины коллекции специализированных текстов tcob а в список lcoi выделяются кандидаты в термины контрастного корпуса текстов tmos. Списки представлены в виде:
Список терминов ltmp коллекции создается путем вычисления меры странности списка коллекции документов1соі по списку контрастного корпуса текстов lmos. Вторая выборка выделяет термины конкретного документа ti. Из текста документа выделяются кандидаты в термины, которые заносятся в список її. Финальный набор терминов 1 выделяется вычислением меры странности списка її по уже посчитанному на первом шаге списку странности коллекции документов ltmp. Таким образом, 1 содержит уникальные термины для конкретного документа входящие в его предметную область. Выделенные в итоге термины включаются во множество словосочетаний-маркеров М, и по ним также ведется поиск значимых фрагментов. Схема вычисления специализированных терминов представлена на Рис. 4.
Особенности внедрения в системы электронного документооборота предприятий топливно-энергетического комплекса
Для обработки и хранения документов на данный момент разработаны системы электронного документооборота- автоматизированные системы, сопровождающие процессы управления работой иерархической организации. При этом предполагается, что процесс управления опирается на человекочитаемые документы. Системы документооборота показывают положительные результаты в оптимизации работ даже в небольших организациях [127].
Развитием разработанного программного обеспечения является возможность интеграции системы в системы документооборота организации, для автоматической обработки документов при получении новой информации и последующей передачи ее пользователю.
Системы электронного документооборота [88, 90] в нашем случае используется как база хранения документов, при этом разработанная программа должна встраиваться в систему. При поступлении в СЭД отчетного документа, разработанный модуль отыщет исходное ТЗ и проверит отчет на полноту. При этом все результаты обработки ТЗ извлекаются лишь один раз и хранятся в БД СЭД. Ответственный за приемку эксперт получит уведомление с предварительными результатами, что позволит ему оперативно дать свою оценку.
Единицей информации в СЭД является документ. СЭД осуществляет хранение документа и его истории изменений. СЭД должна обладать следующим основным функционалом: хранение документов, поиск документов, управление документами, администрирование системы. Кроме того, в СЭД должны быть продуманы элементы пользовательского взаимодействия и обеспечение работы жизнедеятельности документа между пользователями.
В целом, СЭД не сильно отличаются от других информационных систем распределения документов. Для сокращения затрат на специализированные рабочие места стала популярна концепция открытой среды с тонким клиентом. Такая среда удобна в крупных организациях, поскольку может быть установлена на любую рабочую машину в организации, не зависимо от платформы. Кроме того, подобная модель работы позволяет подключать внешние модули работы с документами. Развитые методы распознавания текстов позволяют перевести бумажный документооборот к безбумажному формату на этапе появления документа в организации. [91].
В ходе разработки программной системы рассматривалась возможность ее встраивания в такие СЭД, как LotusNotes и EMC Documentum. В ходе консультации со специалистами по данным СЭД был сделан вывод, что предложенная система может быть встроена в качестве одного из модулей СЭД предприятия. Единственной сложностью на этом пути является привлечение специалиста, знакомого с проектированием и разработкой подобных модулей, так как система LotusNotes требует полного знания своей архитектуры.
Внедрение разрабатываемой системы в СЭД позволит реализовать процесс автоматизации версионирования документации. Получаемый в системе СЭД документ проектной документации будет автоматически сохранятся в базе данных, с проверкой на наличие более старой версии. Если в базе данных будет найдено относящиеся к проектной документации техническое задание, то система документооборота будет автоматически запускать встроенную систему проверки качества документации (разрабатываемую в диссертационной работе) и отправлять ответственному за проверку пользователю результаты новой обработки, а также архивные данные результатов обработок прошлых версий текста. ЛПР сразу получает данные о том, что было изменено в документации, упоминание о каких требованиях ТЗ были добавлены или удалены и насколько изменились процентные результаты работы метода.
Как уже было замечено во Введении данной диссертационной работы, применение СЭД возможно для автоматизации процесса поиска и перемещения документации в организации, но не помогает в автоматизации процессов проектирования и разработки документации, поскольку при проектирования комплексной системы, создается документация, относящаяся к нескольким предметным областям. Тогда в ходе производства обычно пишется несколько технических заданий, каждое из которых описывает свою предметную область и требует отдельной предварительной автоматической обработки. Таким образом, интеграция разработанного метода в СЭД возможна лишь с целью организации удобного поиска и хранения документов.
Одним из вопросов, которые необходимо решить при встраивании метода в СЭД, это формирование настроек системы по умолчанию. В качестве параметров настроек выступает размер значимого фрагмента, список слов, определяющих лексико-синтаксические шаблоны, описывающие требования к ТЗ, проценты отсечки слишком частотных или слишком редких терминов и словосочетаний. Для уточнения данных параметров был проведен ряд экспериментов с документами, имеющими отношение к ТЭК. В результате анализа технических документов были выбраны параметры метода (приведены в таблице 2.) и список слово сочетаний-маркеров:
В качестве контрастной коллекции текстов была выбрана библиотека Мошкова (http://www.lib.ru/, 680 млн. словоупотреблений). Данная библиотека имеет целый ряд достоинств по сравнению с другими коллекциями. Во-первых, она является свободно распространяемой, то есть может быть использована в любом проекте без получения дополнительных разрешений. Во-вторых, библиотека содержит в себе тексты, в большинстве своем написанные хорошим литературным языком. Наконец, библиотека содержит в себе тексты различных авторов. Всё это позволяет выделить практически все возможные авторские стили и исключить из рассмотрения проектной документации особенности беллетристики, то есть стиля, ей не присущего и лишнего.
Представленный выше набор параметров и словосочетаний-маркеров предназначен для работы с документами ТЭК любой тематики, однако, в случае наличия однотипных документов или документов установленной тематики, пользователь может изменить данные параметры для более точной работы. Введенные дополнительные словосочетания-маркеры помогают, если заранее известно, что, необходимая в коллекции технических заданий, информация выделяется определенным вводным словом, уникальным именно для этой коллекции. Пользователи могут сохранять отдельные списки словосочетаний-маркеров для различных тематик и перед проверкой документации выбирать один из заранее подготовленных списков. Таким образом, разработанный метод может работать любым текстом ТЭК как без дополнительных доработок со стороны пользователя, так и с более повышенной точностью выделения, при предварительной обработке со стороны пользователя.
Результаты экспериментов по выделению терминов предметной области из документов организации
Порождаемые при выполнении бизнес-процессов организации документы, содержащие необходимую для работы информацию, нуждаются в структурированном хранении с возможностью быстрого доступа к любой части любого документа, а также возможности обработки этой информации. Количество данной информации, даже в небольших организациях, может оказаться колоссальной, что приводит к необходимости использования методов автоматической обработки текстов. Повсеместная необходимость использования подобных методов ведет к их постоянной модернизации и улучшению, а их использование помогает в организации хранения, поиска и работы с документами.
Существующие методы обработки текста позволяют выделять значимую информацию из документов по пользовательскому запросу. Подобное выделение данных может использоваться на предприятиях, к примеру, для создания словарей сокращений и определений, автоматически раскрывающих и описывающих термины в документе на основе коллекции технических документов, хранящихся в системе электронного документооборота организации. Методы сравнения документов позволяю создавать поисковые системы и находить дубликаты существующих документов и заранее сообщать пользователю о уже имеющихся документах подобной тематики, что позволит пользователю повторно использовать уже имеющиеся в организации наработки. Кроме того, методы сравнения и выделения информации могут использоваться для определения сходства двух документов.
Одним из документов, получаемых в процессе жизнедеятельности организации, является документация на проектирование объекта, предоставляемая организацией-заказчиком разработчику. Такой документ содержит все основные требования, условия и параметры будущей разработки и является основным документом, по которому будет происходить данная разработка. Одна из самых частых форм представления такого документа -техническое задание. Для контроля над работой заказчик нередко требует от разработчика отчетный документ, высылаемый с определенной периодичностью, содержащий основные положения процесса разработки. Ориентируясь на данный документ, заказчик может следить за выполнением требований и вовремя замечать несоответствия с условиями, описанными в техническом задании. Проверка такого документа может занимать длительное время, в связи с чем ставится задача автоматизации процессов приемки документов и создание систем поддержки принятия решений о полноте отчетной документации.
Поскольку требования в техническом задании составляют не весь документ, стандартные методы определения сходства документов в данном случае не помогают. Существующие методы работы с техническими заданиями требуют существенной информационной поддержки для различных предметных областей. В связи с этим возникает необходимость разработки нового метода определения полноты проектной документации, который использовал бы только сам документ технического задания в качестве начальных данных, а также повышал бы эффективность работы эксперта.
Реализация такого метода приводится в главе 2 данной диссертационной работы. Метод определения полноты отчетной документации позволяет выделять значимые фрагменты технического задания, содержащие условия разработки и находить их упоминание в отчете. Кроме расчётной части метод должен представлять информацию в понятном для пользователя виде. Метод визуализации результатов сравнения текстов отчетной документации и технического задания представляет результаты в виде точечной диаграммы, благодаря которой пользователь может оперативно принять решение о дальнейших действиях по проверки проектной документации. Визуализация результатов в связке с индексами вхождений выделенной информации позволяет получить требования оригинального технического задания вне зависимости от размера текста. Предоставляемая пользователю информация позволяет найти описание выполнения каждого из выделенных требований в отчете, найти требования, которые не были упомянуты в отчете и показать взаимосвязь между абзацами отчета и фрагментами технического задания. Как следствие, разработанный метод уменьшает время работы пользователя, заменяя чтение всего документа на изучение значимых фрагментов. Поскольку выделение фрагментов не привязано к правилам русского языка, то метод может работать на европейских языках при правильном подборе словосочетаний-маркеров.
Программная реализация разработанного метода представлена в главе 3. Результаты обработки проектной документации рассчитываются системой автоматически, однако сам процесс проверки проводится автоматизировано, то есть итоговая проверка качества проектной документации проводится ЛПР. Метод реализован в виде программного продукта для операционной системы Windows и позволяет производить проверку полноты документов в основных текстовых форматах. Система не заменяет человека, а лишь помогает ему отбросить заведомо пустые тексты или специально увеличенные в размере тексты, не несущие смысловой и информационной нагрузки, автоматизируя процесс проверки качества проектной документации, за счет автоматического вычисления числовых и визуальных данных о покрытии документации.
Система наиболее эффективна при работе с большими по объему документациями. При малых объемах ТЗ и отчетов применение метода не дает ожидаемого эффекта снижения временных затрат. Полученные на основе программы результаты представлены в главе 4.
Полученные в результате работы данные также можно использовать для развития системы. Поскольку система сохраняет позиции вхождений выделенных требований ТЗ, а также выделенные термины предметной области, то при частой обработке схожих документов одной тематики, возможно выделение стандартизированной конструкции. Такая конструкция будет показывать, как в однотипных текстах документации распределяются требования технического задания, а также какие термины предметной области выделяются и где они располагаются. В перспективе, данную конструкцию можно использовать для создания шаблонов автоматизации документирования в САПР, а выделенные термины и взаимосвязь по положению в тексте, можно использовать как базис для создания онтологии предметной области.
На основании результатов экспериментов, приведенных в главе 4, можно судить о полноте и точности работы метода, о повышении эффективности работы эксперта и уменьшении времени, затрачиваемого на проверку отчетного документа. Метод показал свою эффективность при применении в организациях топливно-энергетического комплекса (ФГБУ «САЦ Минэнерго России»).