Содержание к диссертации
Введение
Глава 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
Библиографический список 115
- Методы обработки технической документации
- Формальный метод определения полноты проектной документации
- Программная реализация метода
- Результаты экспериментов по выделению терминов предметной области из документов организации
Методы обработки технической документации
Документация является неотъемлемой частью жизненного цикла разработки системы и является обязательной частью системы и требует затрат на ее создание и применение. От качества документации во многом может зависеть успешность и эффективность разрабатываемой системы. При этом документация должна быть адекватной и точно соответствовать продукту, а содержание понятно изложено, с возможностью его освоения и применения квалифицированными специалистами.
Разрабатываемая документация должна соответствовать установленным стандартам и гостам, что упрощает ее разбор. Полнота отображения требований и параметров системы в документах должна полностью определять достоверность информации для взаимодействия заказчиков, пользователей и разработчиков. Разрабатываемая системная документация подвержена постоянным изменениям и должна соответствовать разрабатываемой системе на всех этапах разработки, что требует постоянной поддержки и доработки, которые вносятся всеми участниками разработки при взаимодействии между системой и документами. Неточности документации так же опасны для системы, как и ошибки работы самой системы. Следовательно, во время разработки сложных систем необходима организация работы группы специалистов, обеспечивающих реализацию основных системных работ по документированию процессов проектирования и создания системы. В результате, затраты на разработку документации сложных систем может достигать трети от общей трудоемкости разработки [67].
Наиболее часто применяемым способом проверки технических документов на практике является ручной анализ с привлечением экспертов. Проверка многостраничного документа может занять у опытного эксперта, знающего предметную область и структуру документа, незначительное время. Однако, любое изменение структуры или тематики приведет к увеличению трудозатрат эксперта. Как минимум, при повторной приемке исправленного документа эксперт должен снова ознакомиться со всем документом с тем, чтобы найти все изменения в нем. В случае сложных проектных работ, в процессе которых порождается большой объем документации из различных областей знаний, для проверки выделяется группа совместно работающих экспертов. Однако, увеличение количества экспертов ведет к еще большему увеличению трудозатрат в связи с необходимостью налаживания между ними взаимодействия, а также к возможным проблемам взаимосвязи между конкретными экспертами, работающими с близкими документами. Также стоит заметить, что увеличение количества экспертов не всегда ведет к полному покрытию всех предметных областей и пробелы все также остаются возможны. Набор разработанных методических указаний, применяемых в конкретных случаях [38] помогает при проектировании и сверке документов, но не является решением проблемы, а лишь содержат некий базис полезной информации.
Одним из методов, помогающих экспертам по приемке документации не запутаться в ее содержимом, а разработчикам документации – не упустить ничего важного, является разработка структуры этой документации. Структура разрабатываемой документации должна быть подробно проработана еще на начальных этапах процесса разработки. Один из эффективных способов проработки будущей документации – создание информационных шаблонов. Подобные шаблоны помогают организациям в создании качественной документации, способной полностью раскрыть все характеристики системы в понятной и адекватной форме.
Автоматическая обработка технической документации является одним из развивающихся направлений обработки текстов на естественном языке [104, 120, 134]. Автоматическая обработка технической документации может осуществляться несколькими способами, одним из которых является применение формальных методов представления знаний предметной области, например, онтологий и тезаурусов. Применение онтологий позволяет решить такие проблемы обработки документации, как синонимия, замена понятий сходными, изложение задачи с использованием терминов другого уровня абстракции. К недостаткам данного подхода можно отнести тот факт, что каждая предметная область требует разработки своей собственной онтологии, а создание «общей» единичной онтологии невозможна [18]. В качестве альтернативы следует упомянуть подходы, основанные на извлечении ключевых слов и терминов (в основном без связей между ними) с использованием методов автоматической обработки текстов. Эти методы уступают в эффективности обработки документации, однако выигрывают в трудозатратах к своему применению.
Разработка онтологии – активно развивающаяся область науки. Современные методы стремятся к созданию методов автоматического формирования онтологии предметной области по коллекции документов, но все еще далеки от идеала. При этом логично использовать способы, не завязанные на онтологию в случаях, когда разработка онтологии только начата или невозможна. В этом случае на начальных этапах задача может решаться методами автоматической обработки текстов. В дальнейшем, после того как будет разработана онтология предметной области, достаточная для решения практических задач, можно будет перейти к ее использованию. В связи с этим возможна разработка комбинированного метода, сочетающего в себе все плюсы использования методов автоматической обработки текстов и методов представления знаний.
Кроме того, результаты, получаемые при помощи методов автоматической обработки текстов, впоследствии можно использовать для генерации онтологии. Для этого необходимо провести накопление знаний об использованных терминах, контексте их употребления и, как следствие, связях между ними. Однако, подобный подход является темой для самостоятельного исследования.
Формальный метод определения полноты проектной документации
Значение меры сходства представляет для пользователя лишь цифру, которая может не давать подробной информации о полноте отчета без какой-либо сравнительной характеристики. Данная мера скорее показывает информационную наполненность отчета, чем степень описания требований. Высокая мера сходства может соответствовать отчету, в котором отсутствует половина необходимых требований заказчика или при дублировании текста технического задания. Высокое значение меры может быть получено на отчете, содержащем описание всех требований, но с изложением большого количества лишней информации (это не самый плохой вариант, однако лишний текст в отчете будет препятствовать его пониманию). В связи с этим необходимо разработать способ отображения результатов проверки отчетов в удобном и понятном для пользователя виде. Пользователь должен иметь возможность быстро понять, необходимо ли ему проверять отчетный документ, при этом по возможности до прочтения иметь информацию о всех недостающих требованиях. Таким образом, речь идет о необходимости визуализации результатов в понятной для эксперта форме.
Задачи автоматической интерпретации текстовой информации в визуальной форме активно развиваются уже долгое время и напрямую зависят от развития методов автоматического анализа текстовой информации [106, 124, 141]. В связи с развитием вычислительной техники и увеличением текстовой информации в электронном виде, появляются возможности разработки методов анализа коллекций документов близких тематик.
Визуализация текста активно используется, например, в сети интернет для быстрого представления информации о веб-страницах. Одним из самых распространенных методов является метод создания облака тегов [20, 73]. Облако тегов – визуальное представление текста, созданное из его слов, раскрашенных и расположенных в выбранном пользователе порядке, где размер шрифта каждого слова зависит от его релевантности в тексте или коллекции. Источником информации может также служит метки текста (тэги) в коллекции, что позволяет строить облако тэгов к новостным лентам или библиотекам. Облако тегов показывает, какие основные темы можно найти в библиотеке или какие новости наиболее актуальны на данный момент в новостной ленте. Пример облака тэгов представлен на Рис. 7. Выбор слов, удаляемых из текста, перед занесением в облако зависит от пользователя. Обычно из текста предварительно удаляются стоп-слова, а в результат не включают слова, частота встречаемости которых в тексте мала. Данный метод является наименее информативным способом визуализации и не подходит для комплексного анализа больших текстовых документов. С точки зрения эксперта подобный способ представления текста мало информативен, так как отражает лишь общую направленность документа. Он может использоваться лишь для того, чтобы ввести эксперта в тематику анализируемого документа.
Другим распространённым видом представление текста является граф связей между словами (терминами, словосочетаниями). При обработке текстовой информации применяются различные виды графов (к примеру, суффиксные и префиксные деревья). В визуализации текстов самым распространённым методом является построение концептуальной карты. Концептуальная карта представляет собой ориентированный граф, вершинами которого являются значимые словосочетания, а дуги соответствуют логическим связям. Такими связями, к примеру, могут быть случаи, когда появления исходного словосочетания вершины ведут к появлению словосочетания другой вершины с большей вероятностью, чем с другими. Пример концептуальной карты, составленной при помощи системы [58], части технического задания представлен на Рис. 8.
Рис. 8. Фрагмент концептуальной карты технического задания Концептуальные карты не пригодны для реализации поставленной в диссертации задачи, в связи с большими объемами текста, а также количеством необходимой к отображению информации. Таким образом, появляется необходимость сжатия текста для компактного отображения, не теряя при этом информации о значимости каждого фрагмента.
Принимая во внимание среднее количество символов и слов в предложении (с учетом пробелов) был выбран размер максимальный размер фрагмента, пригодного для поставленной задачи. Размер технического задания может варьироваться от 10 страничного документа с перечисленными требованиями до 80-90 страничных текстов, написанных по всем правилам ГОСТ, следовательно, с учетом размера авторского и печатного листа по ГОСТ Р 7.0.3-2006 [28]. Можно предполагать, что верхняя граница символов, содержащиеся в тексте технического задания будет равна 162 000 (90 страниц) знаков, а нижняя – 18 000 (10 страниц)2. В действительности же, данное значение гораздо меньше, поскольку лист технического задания не целиком занят текстом и в большинстве случаев содержит такую информацию, как иллюстрации и таблицы. При фрагменте в 100 символов (данная цифра примерно соответствует длине нераспространенного предложения) можно подсчитать минимальное и максимальное количество фрагментов: 180-1 620. На основании полученного результата можно делать выводы о размерах, необходимых для представления текста в визуальном виде. Учитывая верхнюю границу количества фрагментов, можно предполагать, что финальное представление должно быть представлено в виде некой диаграммы, где за каждый фрагмент будет отвечать некий объект. Представив каждый фрагмент точкой, чей цвет зависит от содержания фрагмента и его связанности с другими частями проектной документации, можно представить весь документ в виде строки. Для удобства, каждые 100 фрагментов будут располагаться на своей собственной строке. Такое разделение позволит вписывать диаграммы в окно программы или печатного листа. При условии, что каждая точка имеет толщину в 2 пикселя + 1 пиксель рамки, а, следовательно, одна строка из 100 фрагментов занимает 301 (По три пикселя на фрагмент и ее правую рамку и 1 на левую внешнюю рамку) пикселей в ширину. Таким образом, можно просматривать графики одновременно с текстом отчета и технического задания на разрешении 1024 7683 (Наиболее часто встречаемое разрешение для соотношения сторон 4:3). Эксперт будет видеть от 2 до (примерно) 20 строк, отображающих информацию о фрагментах в цветовом коде. Практика показывает, что подобный объем удобен для анализа информации и не позволяет потеряться в ее объемах.
Программная реализация метода
Как видно из рисунков, в числе выделенных терминов содержатся используемые только в области топливно-энергетического комплекса слова и словосочетания (Минэнерго, ТЭК, ТЭС и т.д.), а термины конкретного документа, представленные на Рис. 17 и Рис. 18 – описывающие требования к созданию информационной подсистемы категорированных объектов словосочетания.
Подобный набор терминов подтверждает аккуратность и точность метода выделения терминов предметной области. Использование тематических терминов позволяет выделять дополнительные фрагменты текста технического задания, пропускаемые набором стандартных словосочетаний-маркеров (см. раздел 4.4).
Исходя из результатов экспериментов можно сказать, что предложенный метод выделяет корректную информацию, помогающую ЛПР принимать правильные решения о тематике технического задания, изложенных в нем требованиях и полноте изложений этих требований в отчетных документах.
Точечная диаграмма распределения ключевых фрагментов является основным инструментом ЛПР, используемым для работы с отчетным документом. Ниже приведены примеры полученных в результате экспериментов диаграммы технических заданий и отчетов различного качества оформления. Диаграммы читаются построчно, каждая точка представляет информацию по 100 символам. Каждая строка содержит 100 точек, следовательно, в каждой строке представлено 10000 символов текста. Основным критерием оценки полученных результатов является процентное отношение выделенных фрагментов (точек диаграммы) к общему количеству фрагментов.
Рис. 20. Пример визуализации результатов анализа удачного ТЗ На Рис. 20 представлен документ, в котором все условия аккуратно написаны в начале документа. Заключительная часть ТЗ относится к срокам разработки, требованиям к рабочим местам и к интерфейсу системы. На диаграмме видно скопление точек в начале документа. Хотя число ключевых фрагментов в первом и втором случае почти одинаково, второй вариант выигрывает в точности выделенных n-грамм из-за сжатости текста и точно поставленных требований.
Соответствующие отчеты (годовые отчеты о ходе разработки информационной системы) представлены на Рис. 22 и Рис. 23 [54]. Каждому фрагменту текста ТЗ сопоставлен цвет, отображавшийся и в диаграмме отчета для соответствующих фрагментов. Цвет меняется от синего к зеленому в зависимости от номера фрагмента. Поскольку требования пишутся последовательно и обычно связаны по смыслу, можно предположить, что чем ближе цвет на диаграмме, тем ближе фрагменты текста по значению. Блоки из компактно расположенных 5-10 цветных точек описывают заявленные в ТЗ требования. Отдельно стоящие зеленые квадраты – единичная встреча n-грамм в тексте (например, заголовок).
На Рис. 22 видно, что зеленые точки разбросаны по отчету, практически нет блоков больше 5 точек. На более чем 130 000 знаков отчета было найдено лишь 470 групп, относящихся к ТЗ (считая заголовки). Максимальная связная длина текста, имеющего отношение к одному из значимых фрагментов ТЗ – 700 символов. Такой отчет не содержит ценной информации и должен быть отправлен назад разработчику для дополнения. Проверка текста отчета экспертом подтвердила оценку программы.
На Рис. 23 представлен качественно написанный отчет, в котором ключевые n-граммы встречаются везде, за исключением начала (содержание, авторы, введение). При длине отчета более 130 000 знаков найдено более 3500 групп. Максимальная длина текста, имеющего значимые фрагменты ТЗ – 1500 знаков.
Точечная диаграмма для качественно написанного отчета (Отношение выделенных фрагментов к общему количеству – 66%)
Помимо точечной диаграммы, показывающей наличие или отсутствие n-грамм в тексте, ЛПР получает другой вид диаграммы, отображающей связность фрагментов отчета и ТЗ. Каждому фрагменту текста ТЗ сопоставлен цвет, отображавшийся в диаграмме отчета для соответствующих фрагментов. На Рис. 24 и Рис. 25 показаны новые диаграммы для рассмотренных отчетов [54]. Цвет меняется от синего к зеленому в зависимости от номера фрагмента. Поскольку требования пишутся последовательно и обычно связаны по смыслу, можно предположить, что чем ближе цвет на диаграмме, тем ближе фрагменты текста по значению.
Результаты экспериментов по выделению терминов предметной области из документов организации
Порождаемые при выполнении бизнес-процессов организации документы, содержащие необходимую для работы информацию, нуждаются в структурированном хранении с возможностью быстрого доступа к любой части любого документа, а также возможности обработки этой информации. Количество данной информации, даже в небольших организациях, может оказаться колоссальной, что приводит к необходимости использования методов автоматической обработки текстов. Повсеместная необходимость использования подобных методов ведет к их постоянной модернизации и улучшению, а их использование помогает в организации хранения, поиска и работы с документами.
Существующие методы обработки текста позволяют выделять значимую информацию из документов по пользовательскому запросу. Подобное выделение данных может использоваться на предприятиях, к примеру, для создания словарей сокращений и определений, автоматически раскрывающих и описывающих термины в документе на основе коллекции технических документов, хранящихся в системе электронного документооборота организации. Методы сравнения документов позволяю создавать поисковые системы и находить дубликаты существующих документов и заранее сообщать пользователю о уже имеющихся документах подобной тематики, что позволит пользователю повторно использовать уже имеющиеся в организации наработки. Кроме того, методы сравнения и выделения информации могут использоваться для определения сходства двух документов.
Одним из документов, получаемых в процессе жизнедеятельности организации, является документация на проектирование объекта, предоставляемая организацией-заказчиком разработчику. Такой документ содержит все основные требования, условия и параметры будущей разработки и является основным документом, по которому будет происходить данная разработка. Одна из самых частых форм представления такого документа – техническое задание. Для контроля над работой заказчик нередко требует от разработчика отчетный документ, высылаемый с определенной периодичностью, содержащий основные положения процесса разработки. Ориентируясь на данный документ, заказчик может следить за выполнением требований и вовремя замечать несоответствия с условиями, описанными в техническом задании. Проверка такого документа может занимать длительное время, в связи с чем ставится задача автоматизации процессов приемки документов и создание систем поддержки принятия решений о полноте отчетной документации.
Поскольку требования в техническом задании составляют не весь документ, стандартные методы определения сходства документов в данном случае не помогают. Существующие методы работы с техническими заданиями требуют существенной информационной поддержки для различных предметных областей. В связи с этим возникает необходимость разработки нового метода определения полноты проектной документации, который использовал бы только сам документ технического задания в качестве начальных данных, а также повышал бы эффективность работы эксперта.
Реализация такого метода приводится в главе 2 данной диссертационной работы. Метод определения полноты отчетной документации позволяет выделять значимые фрагменты технического задания, содержащие условия разработки и находить их упоминание в отчете. Кроме расчётной части метод должен представлять информацию в понятном для пользователя виде. Метод визуализации результатов сравнения текстов отчетной документации и технического задания представляет результаты в виде точечной диаграммы, благодаря которой пользователь может оперативно принять решение о дальнейших действиях по проверки проектной документации. Визуализация результатов в связке с индексами вхождений выделенной информации позволяет получить требования оригинального технического задания вне зависимости от размера текста. Предоставляемая пользователю информация позволяет найти описание выполнения каждого из выделенных требований в отчете, найти требования, которые не были упомянуты в отчете и показать взаимосвязь между абзацами отчета и фрагментами технического задания. Как следствие, разработанный метод уменьшает время работы пользователя, заменяя чтение всего документа на изучение значимых фрагментов. Поскольку выделение фрагментов не привязано к правилам русского языка, то метод может работать на европейских языках при правильном подборе словосочетаний-маркеров.
Программная реализация разработанного метода представлена в главе 3. Результаты обработки проектной документации рассчитываются системой автоматически, однако сам процесс проверки проводится автоматизировано, то есть итоговая проверка качества проектной документации проводится ЛПР. Метод реализован в виде программного продукта для операционной системы Windows и позволяет производить проверку полноты документов в основных текстовых форматах. Система не заменяет человека, а лишь помогает ему отбросить заведомо пустые тексты или специально увеличенные в размере тексты, не несущие смысловой и информационной нагрузки, автоматизируя процесс проверки качества проектной документации, за счет автоматического вычисления числовых и визуальных данных о покрытии документации.
Система наиболее эффективна при работе с большими по объему документациями. При малых объемах ТЗ и отчетов применение метода не дает ожидаемого эффекта снижения временных затрат. Полученные на основе программы результаты представлены в главе 4.
Полученные в результате работы данные также можно использовать для развития системы. Поскольку система сохраняет позиции вхождений выделенных требований ТЗ, а также выделенные термины предметной области, то при частой обработке схожих документов одной тематики, возможно выделение стандартизированной конструкции. Такая конструкция будет показывать, как в однотипных текстах документации распределяются требования технического задания, а также какие термины предметной области выделяются и где они располагаются. В перспективе, данную конструкцию можно использовать для создания шаблонов автоматизации документирования в САПР, а выделенные термины и взаимосвязь по положению в тексте, можно использовать как базис для создания онтологии предметной области.
На основании результатов экспериментов, приведенных в главе 4, можно судить о полноте и точности работы метода, о повышении эффективности работы эксперта и уменьшении времени, затрачиваемого на проверку отчетного документа. Метод показал свою эффективность при применении в организациях топливно-энергетического комплекса (ФГБУ «САЦ Минэнерго России»).