Автоматизированный контроль качества текстов проектной документации на предприятиях топливно-энергетического комплекса тема диссертации и автореферата по ВАК РФ 05.13.12, кандидат наук Калачёв, Ярослав Борисович

• Калачёв, Ярослав Борисович
• кандидат наук
• 2015

Оглавление диссертации кандидат наук Калачёв, Ярослав Борисович

Содержание

Список условных обозначений

Введение

Глава 1. Обзор методов обработки текстов технической документации

1.1. Особенности приемки проектной документации в топливно-энергетическом комплексе

1.2. Методы обработки технической документации

1.3. Методы определения тематического сходства документов

1.4. Методы выделения терминов из документации

Выводы к главе 1

Глава 2. Метод определения полноты проектной документации

2.1. Основные положения метода определения полноты проекшой документации

2.2. Формальный метод определения полноты проектной докумешации

2.3. Метод визуализации результатов для эксперш

2.4. Метод принятия решения экспертом

Выводы к главе 2

Глава 3. Особенности практической реализации метода для предприятий топливно-энер1е1Ического комплекса

3.1. Уче1 особенности сфукгуры 1ехнического задания

3.2. Про1раммная реализация метода

3.3. Особенносш внедрения в сис1емы элекфонною документооборота предприятий топливно-энерге1ического комплекса

Выводы к главе 3

Глава 4. Анализ эффективности применения метода

4.1. Оценка точности работы метода

4.2. Результаты экспериментов по выделению терминов предметной области из докумешов организации

4.3. Визуальное представление результатов

4.4. Использование терминов предметной области

Выводы к главе 4

Заключение

Библиографический список

Список условных обозначений

ТЭК Топливно-энергетический комплекс

тз Техническое задание

НИР Научно-исследовательская работа

ОКР Опытно-конструкторская работа

JI1IP Лицо, принимающее решение

сэд Система электронного документооборота

гост Государственный стандарт

ост Отраслевой стандарт

спдс Система проектной документации для строительства

ЕСКД Единая система конструкторской документации

ЕСПД Единая система программной документации

НИОКР Научно-исследовательские и опытно-конструкторские разработки

ISO International Organization for Standardization (пер. Международная

организация по стандартизации)

Введение диссертации (часть автореферата) на тему «Автоматизированный контроль качества текстов проектной документации на предприятиях топливно-энергетического комплекса»

Введение

В ходе своего существования предприятия топливно-энергетического комплекса России формируют огромные архивы документации. В этих архивах содержатся не только результаты официального документооборота (приказы, распоряжения и пр.), но и техническая документаг^ия по текущим и выполненным проектам: технические отчеты, проектная документация, планы и т.д. Значительная часть этих документов оформляется в виде текстового описания. Анализу этих документов и посвящена данная диссертация.

Россия является крупной энергетической державой, энергетика которой играет важную роль в поддержании надежной экономической ситуации и укреплении на международной арене. Топливно-энергетический комплекс (ТЭК) России отвечает за добычу и переработку топлива, производство и распределение электроэнергии. ТЭК России занимает лидирующие места в мировой добыче полезных ископаемых и выработке электроэнергии, обладает 13% мировых запасов нефти, 14% природного урана, 45% газа и почти 25% запасов угля. При этом ТЭК целиком базируется на отечественных ресурсах, по запасам которых страна занимает одно из первых мест в мире. Особенностью российского топливно-энергетического комплекса является его прямая взаимосвязь с государственными структурами, сложная структура отраслей промышленности и колоссальный географический разброс предприятий [7, 71]. Всё это требует постоянной разработки новых методов и систем автоматизации и взаимосвязи различных отраслей.

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

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

Проектирование объекта или системы начинается с документа, описывающего назначение, условия эксплуатации и требования к выходным параметрам, называемым техническим заданием (ТЗ). Развивающийся во времени процесс проектирования представляется в виде стадий проектирования, таких как стадии научно-исследовательских работ (НИР), эскизного проекта, опытно-конструкторских работ (ОКР), технического и рабочего проектов, и испытаний системы. С каждой новой стадией степень точности проработки проекта растет до уровня, достаточного для изготовления опытных или серийных образцов [75].

Точное обозначение функций системы и составление задания также может быть представлено в виде плана-проспекта, технических условий или других документов, передаваемых исполнителю [27]. Для обозначения всех видов документации начального уровня в работе будет использоваться термин «техническое задание». Техническое задание описывает стадии разработки, специальные требования разработки и исходные данные, необходимые для разработки [2, 32, 98]. В соответствии с [75, с. 19], "разработку ТЗ на проектирование называют внешним проектированием, а реализацию ТЗ -внутренним проектированием". Внешнее проектирование системы представляет собой описание предметной области, формирования основного назначения системы, а также определения требований к системе и разработке ТЗ. Процесс внешнего проектирования делится на четыре этапа: определение цели проектирования, определение объекта проектирования, синтез математической модели объекта проектирования и формализация задачи проектирования. На предварительной стадии рассматриваются возможные изменения параметров и необходимость взаимодействия с действующими системами. Требования к системе на стадии внешнего проектирования выбираются неопределенно, поскольку желания и требования заказчика еще недостаточно выверены. Кроме того, цели и задачи еще качественно не структурированы, а количество вариантов решений велико.

В ходе проектирования степень неопределенности уменьшается, требования уточняются, что ведет к более точному решению поставленной задачи. На этапах НИР и ОКР появляется определенное количество стратегий производства и использования системы. Тогда все допустимые стратегии при проектировании можно представить в виде произведения множеств стратегий ОКР и НИР. На каждом новом этапе проектирования число итоговых стратегий сокращается. Изменяемые факторы прошлого этапа становятся на следующем этапе определенными факторами, формирующими условия нового этапа обобщенной операции. На завершающей фазе внешнего проектирования становится известным перечень требований к системе.

Проектирование разработанных элементов системы называется внутренним проектированием. Стадиями внутреннего проектирования являются предварительное, эскизное и рабочее проектирование, а также изготовление и доработка опытного образца. Результатом внутреннего проектирования является набор проектной документации, отвечающей требованиям технического задания. Этап внутреннего проектирования заканчивается при принятии решения о внедрении системы [69, 75].

При этом, как утверждает автор [75, с. 31], "одна и та же конструкторская документация может быть использована многократно в разных проектах, а одна и та же технологическая документация - адаптирована к разным производственным условиям". То есть, заказчик или исполнитель должны иметь возможность повторить или развить полученный результат. Оформление полной и понятной документации в соответствии с развитыми стандартами разработки проектов может быть достигнуто при помощи внедрения САЬБ-технологий. Разработка по принципам САЬБ-технологии [108] должна заканчиваться оформлением технической документации, описывающей основные положения и стадии разработки. Информационная система в данном случае рассматривается как основа сложных действий по проектированию, созданию, вводу в эксплуатацию, тестированию и обеспечению готового продукта [35]. Заказчик или исполнитель должны иметь возможность без привлечения дополнительных исследований

повторить или улучшить полученный результат. Одной из главных задач САЬ8-технологий является интеграция набора автоматизированных систем в единую многофункциональную систему [75, 76]. Основной целью подобной интеграции является улучшение качества работы с системами и техникой за все время их жизненного цикла.

Применение САЬ8-технологий в разработках систем повышает надежность ее последующей работы. Внедренные автоматизированные системы должны обрабатывать не только данные, вводимые пользователем, но и информацию, получаемую от других систем. Подобная взаимосвязь систем отличается простой интерпретацией данных, как пользователями, так и автоматизированными системами. Благодаря описанию уже проделанной работы можно избежать повторного проектирования сходной продукции за счет использования документации на имеющуюся систему, так как процесс ее разработки уже испробован и отлажен [132].

При наличии полной, доступной и понятной технической документации, описывающей все этапы жизненного цикла системы, значительно снижается сложность работ по изменению или починке системы, адаптации ее к новым задачам, типам входных данных, условиям, и последующей интеграции в рабочие комплексы систем [21, 66]. Однако достижение полноты документации зачастую связано с объективными трудностями. Вообще, требования полноты, доступности и понятности оказываются связанными друг с другом. Полная, но недоступная документация также вредна с точки зрения выполнения проекта, как и неполная или непонятная документация. Таким образом, системы документооборота и их содержимое начинают играть важную роль с точки зрения выполнения и поддержки проекта.

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

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

Таким образом, главной стратегией использования СЛЬБ-технологий является создание единого информационного пространства для всех участников жизненного цикла продукции [57]. Получаемое информационное пространство будет содержать не только основную информацию о разработке объектов, системах и их взаимодействии, но и данные всех пройденных этапов разработки системы. Такая накопленная информация используется для последующего сокращения затрат на разработку новых систем.

Заметим, что ситуация при анализе проектной документации, разрабатываемой в ходе проектирования, может отличаться от ситуации, складывающейся при анализе текущего документооборота, например, при производстве. В ходе проектирования на предприятиях ТЭК в ТЗ, как это уже было отмечено, может ставиться задача проектирования комплексной системы, относящейся к нескольким предметным областям. При этом в ходе производства обычно пишется несколько технических заданий, каждое из которых описывает свою предметную область. В связи с этим актуальность разрабатываемого метода в области САПР, применяемых на предприятиях ТЭК, значительно выше, чем в области систем электронного документооборота (СЭД) или анализа технической документации при производстве. В целом, системы электронного документооборота позволяют организовать работу с документами в организации (поиск, создание, визирование, передача приказов), но не участвуют в процессах проектирования, рассматриваемых в данной работе. Применение СЭД возможно для автоматизации процесса поиска и перемещения документации в организации. Возможность подобной доработки рассматривается в Главе 3.

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

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

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

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

Поскольку процесс проектирования может повторяться несколько раз, неоднократно проходя через этапы внешнего и внутреннего проектирования, до тех пор, пока не будет достаточным для изготовления опытных или серийных образцов [75], возникает проблема повторного просмотра документации. В связи с этим возникают задачи разработки новых методов автоматизации приемки отчетной документации и автоматизированной системы поддержки процессов их приемки, позволяющая на основе анализа ТЗ проверить покрытие списка требований ТЗ в отчетной документации. Такая система выявляет блоки итоговой документации, тематически сходные с ТЗ, выполняет визуализацию данных, необходимых для принятия решения, является дополнительным инструментом первоначальной проверки, выявляющим грубые ошибки и нарушения в тексте и содержании. Результаты обработки проектной документации рассчитываются системой автоматически, однако сам процесс проверки проводится автоматизировано, то есть итоговая проверка качества проектной документации проводится лицом, принимающим решения (ЛПР). При этом использование подобной системы возможно как на стороне заказчика, так и на стороне исполнителя, в случае если исполнитель проводит внутренний аудит качества разрабатываемой документации.

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

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

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

Цель диссертационной работы

Целью диссертационной работы является снижение временных затрат на проверку текстовой проектной документации на завершающих этапах внутреннего проектирования за счет автоматизации оценки степени ее соответствия техническому заданию. Для реализации поставленной цели необходимо решить следующую общую задачу: необходимо разработать автоматизированный метод определения степени покрытия списка требований технического задания в текстах проектных документов

Для этого необходимо решить следующие частные научные и практические задачи:

1. Разработка алгоритма выделения требований из текстов технического задания с использованием лексико-синтаксических шаблонов;

2. Разработка метода поиска описаний выделенных требований в тексте проектного документа и метода определения степени покрытия списка требований технического задания;

3. Разработка метода визуализации полученных результатов;

4. Проектирование и разработка программного комплекса для анализа отчетных документов на полноту описания;

5. Проведение вычислительных экспериментов по тестированию разработанного метода и определения границ применимости метода.

Одной из задач экспертов, принимающих текстовую документацию, подготовленную в ходе внешнего проектирования системы, является проверка ее соответствия поданному на вход этапа проектирования техническому заданию. Увеличения числа и объема отчетов приводит к нелинейному росту сложности приемки и вероятности пропуска ошибок. Существующие автоматические методы работы с текстовой документацией не позволяют быстро перестраиваться на новые предметные области, характерные для ТЭК. В связи с этим возникает необходимость разработки новых методов определения полноты текстовой проектной документации.

Из разрешения полученного противоречия вытекает научная новизна диссертационной работы: в диссертационной работе разработан новый метод определения степени покрытия списка требований из ТЗ в текстах проектной документации на завершающих этапах внутреннего проектирования, учитывающий особенности документов ТЭК. В отличие от существующих, предложенный метод использует в качестве входных данных только тексты технического задания и проектной документации и не нуждается в предоставлении дополнительных словарей и баз данных. Разработанный метод визуализации результатов проверки проектной документации позволяет сэкономить время лица, принимающего решения, на поиск и проверку выделенных требований в ходе рассмотрения и утверждения эскизного или технического проекта.

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

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

помогает эксперту в принятии решений при проверке отчетных документов. Работоспособность метода была проверена для основных европейских языков.

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

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

На защиту выносятся следующие основные положения:

1. Метод автоматического поиска в тексте технического задания описания требований, относящихся к различным предметным областям.

2. Метод автоматического поиска и визуального отображения найденных требований в текстах проектной документации, снижающий временные затраты на принятие решения экспертами предприятий ТЭК в ходе приемки текстов проектной документации.

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

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

Глава 1. Обзор методов обработки текстов технической

документации

1.1. Особенности приемки проектной документации в топливно-энергетическом

комплексе

Россия является крупной энергетической державой. Ее энергетика играет важную роль в поддержании надежной экономической ситуации в стране и укреплении позиций на международной арене [71]. Топливно-энергетический комплекс России отвечает за добычу и переработку топлива, производство и распределение электроэнергии. ТЭК России занимает лидирующие места в мировой добыче полезных ископаемых и выработке электроэнергии, обладающей 13% мировых запасов нефти. 14% природного урана. 45% газа и почти 25% запасов угля. При этом ТЭК целиком базируется на отечественных ресурсах, по запасам которых страна занимает одно из первых мест в мире. ТЭК представляет собой совокупность тесно связанных отраслей энергетики, тепло обеспечения и нефтегазовой промышленности, а также специализированных видов транспорта -трубопроводного и магистральных высоковольтных линий. Общая схема ТЭК России представлена на Рис.1. Отрасли ТЭК тесно связаны с экономикой Российской Федерации и создают предпосылки для развития топливных производств и формирования промышленных комплексов (нефтегазовые, нефтехимические, углехимические и электроэнергетические комплексы).

Размеры ТЭК России, тесная взаимосвязь как внутренних, так и внешних отраслей ТЭК - всё это ведет к постоянному развитию комплекса или появлению новых проектов по межотраслевому взаимодействию. В связи с этим процесс функционирования практически любой организации ТЭК России связан с созданием и обработкой документов, в том числе и рабочей документации, написанной в виде текста в свободной форме. С ростом количества получаемой и накапливаемой текстовой информации растет и необходимость ее автоматической обработки и хранения. Особенностью подобной документации часто является сочетание нескольких предметных областей, смежных для ТЭК. Особенно это проявляется в документации для межотраслевых проектов ТЭК.

Топливно знер! етический комплекс России

1 опливная промышленность

Электро ¿нерг етика

Отрагли доставки

Нефтя-ая

1

Iорфяиая

Г идраэнгргсгина

Теппоэнеогетикз -

Атомная эмгрт'ика *

Дууие ь^дь

Трубопроводный транспорт

ГЛЛН^РВЛЯ

А

Рис.]. ТЭК Российской Федерации

Стандарты разработки проектов требуют оформления полной и понятной документации, при помощи которой заказчик или исполнитель должны иметь возможность повторить или развить полученный результат. Наличие полной документации на проект и удобные способы ее хранения и поиска позволяют заранее сообщать пользователю о уже имеющихся документах подобной тематики, что позволит пользователю повторно использовать уже имеющиеся в организации наработки. Принимая во внимание тесную взаимосвязь ТЭК с государст вом, необходимо заметить, что большинство проектных работ пишутся с использованием государственных стандартов (ГОСТ) [23-26] и отраслевых стандартов (ОСТ). При этом отраслевые стандарты различаются в оформлении и структуре даже внутри одной отрасли и, в основном, пишутся для конкретного случая проектирования (к примеру, ОСТ 153-00.0-002-98). Единые системы документации устанавливают стадии разработки и этапы работ, производимых на каждой стадии. При этом каждый этап сопровождается созданием определенной документациии, список и состав которой оговорены стандартами.

На этапах утверждения эскизного проекта, утверждения технического проекта, разработки документации и приемочного испытания опытного образца

(или испытаний программы) разрабатываются документы, описывающие процесс приемки и проектирования. Подобные документы позволяют понять общий процесс выполнения работ. Текстовые документы проектной документации, такие как пояснительная записка, инструкция и программа и методика испытаний, могут использоваться для контроля над сроками выполнения процесса и отслеживания общего прогресса. Проверка описания всех требований ТЗ в данных текстовых документах помогает вовремя определять несоответствия в процессе разработки.

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

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

Список литературы диссертационного исследования кандидат наук Калачёв, Ярослав Борисович, 2015 год

Список мер ту,

•Найденые в отчете требования из ключевого фрагмента 1

^ «Найденые в отчете требования из ключевого фрагмента 2

Мера сходства абзацев уо,

•максимальное значение меры уо для абзаца 1 •максимальное значение меры чо для абзаца 2

•Абзац 1 •Вхождение ключевого п-грама 1 •Вхождение ключевого п-грама 2 •Абзац 2 •Вхождение ключевого п-грама 3

Точечная диаграмма технического задания и отчета

Рис. 10. Взаимосвязь результатов работы метода

Руководствуясь данными результатами, пользователь принимает решение о пригодности данного отчета. Общий алгоритм работы пользователя состоит из следующих шагов:

• На вход алгоритма подается документ технического задания и отчетный документ.

• Пользователь выбирает набор параметров работы метода, пригодного для конкретного случая (или оставляет стандартные параметры, пригодные для работы с документами ТЭК).

• По желанию пользователя производится выбор дополнительных словосочетаний маркеров.

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

• Пользователь получает меру сходства документов. Полученная мера является одним из параметров, влияющих на финальное решение пользователя.

Значение мера сходства документа должны лежать в пределах от 0,3 до 0,9 у близких по смыслу текстов и в пределах от 0,4 до 0,8 между документами технического задания и принадлежащим им отчетам. Значение меры меньше 0,1 говорит о не связанности текстов по предметной области, а больше 0,9 о возможном копировании текста технического задания в отчётный документ. Подобные значения должны насторожить пользователя и выявляют ошибки в написании отчета.

• Пользователь получает и просматривает точечные диаграммы технического задания и отчетного документа. Качественным показателем пригодности текста по точечной диаграмме является отношение выделенных фрагментов к общему количеству фрагментов и общая кучность выделения. По точечной диаграмме выделенных значимых частей технического задания пользователь может установить качество самого технического задания. Отношение выделенных фрагментов к общему количеству меньше 1% считается границей, при которой техническое задание считается непригодным для работы метода. Хорошим процентным показателем выделения предложений со словосочетаниями-маркерами из документов, написанных по ГОСТ, является 817%. Данный показатель достигает значения в 70-80% на коротких технических записках, в которых перечислены только требования к разработке.

• Основным показателем полноты отчетного документа является процентное отношение фрагментов с найденными ключевыми словосочетаниями к общему количеству фрагментов точечной диаграммы отчета. По итогам исследований нижней границей, при которой отчет является некачественным, считается показатель в 15%, а верхней границей - 85%. Превышение верхней границей показывает пользователю, что отчет, скорее всего, списан с текста технического задания.

• При большом проценте выделения значимых частей технического задания (15% и более), но маленьком значении процентного отношения найденных ключевых словосочетаний в тексте отчета (15-20%) пользователь может просмотреть список мер ту, показывающий какие требования ТЗ не были

представлены в отчете. Значение меры ту варьируется в пределах от 0 до 1, со средним показателем 0,6 для описанных в отчете требований, 0,2 и меньше для плохо описанных и 0 значением, если упоминание требования не найдено.

• На основе данных результатов пользователь принимает решение о насыщенности отчетного документа.

Выводы к главе 2

В главе описан предлагаемый автором метод определения полноты проектной документации и визуализация полученных результатов. Метод основан на выделении синтаксических шаблонов с использованием маркеров и выделение п-граммов из текста технического задания. Предварительные эксперименты показали, что при работе с документами ТЭК (которые могут относиться к любой из четырех основных отраслей), требований, выделяемых из технического задания синтаксическими шаблонами, не достаточно. Каждая из отраслей содержит огромное количество направлений, характеризующихся специализированными словами, различаются даже для смежных видов конкретной отрасли. Для решения данной проблемы набор словосочетаний-маркеров может быть дополнен терминами предметной области, выделяемыми при помощи меры странности. Полнота отчетного документа определяется путем нахождения всех вхождений выделенных п-граммов, которые в методе считаются значимыми.

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

Предложенный метод позволяет:

• выделять требования их текста ТЗ с использованием лексико-синтаксических шаблонов;

• выделять фрагменты отчетной документации, описывающие выделенные требования, определять степень тематической близости фрагментов;

• выбирать фрагмент ТЗ, наиболее полно подходящий по описанию под текст текущего фрагмента отчета;

• визуально представлять информацию эксперту.

Глава 3. Особенности практической реализации метода для предприятий топливно-энергетического комплекса

3.1. Учет особенностей структуры технического задания

На основании выводов Главы 2 и предварительных экспериментов с текстами технического задания, было установлено, что точность выделения требований методом повышается, если в обрабатываемом тексте представлены только специализированные термины. Следовательно, на этапе первоначальной обработки текста технического задания необходимо отделить значимые части документа от юридической и экономической составляющей. Поскольку разработка систем и объектов в топливно-энергетическом комплексе Российской Федерации напрямую связана с взаимодействием с государственными структурами (так как большая часть ТЭК является государственной собственностью или находится под ее контролем), то основными стандартами, использующимся на предприятиях ТЭК при создании технических заданий являются ГОСТ 19.201-78 - «Техническое задание. Требования к содержанию и оформлению» [24] и ГОСТ 34.602.89 - "Техническое задание на создание автоматизированной системы" [28]. Как будет показано ниже, заведомо заданная ГОСТом структура ТЗ позволяет выделять из документации ТЭК только те части, которые описывают технические требования проектирования. Следовательно, разрабатываемый метод должен уметь обрабатывать документацию, написанную по структуре ГОСТ, включая (но не ограничиваясь) ГОСТами [23-29]. Список и описание разделов, которые должно содержать техническое задание согласно ГОСТам, встречается и в написанных не по ГОСТу документах, что также дает возможность использовать данную структуру [97]. Помимо ТЗ, необходимо уметь разбирать следующие типы документов: документы единой системы конструкторской документации (ЕСКД), документы системы проектной документации для строительства (СПДС) и документы единой системы программной документации (ЕСПД). ЕСКД - это комплекс ГОСТ, который устанавливает основные взаимосвязанные требования и правила по разработке и оформлению конструкторской документации на всех этапах жизненного цикла

изделия (проектировании, разработке, изготовлении, контроле, приёмке, эксплуатации, ремонте, утилизации) [25, 26]. СПДС - комплекс нормативных организационно-методических документов, устанавливающих общетехнические требования, необходимые для разработки, учёта, хранения и применения проектной документации для строительства объектов различного назначения. Единая система программной документации ЕСПД - комплекс государственных стандартов Российской Федерации, устанавливающих взаимосвязанные правила разработки, оформления и обращения программ и программной документации. Все три приведенных в пример комплекса содержат набор документов ГОСТ, отвечающих различным целям, включая «правила выполнения документации», описывающие требования к разработке проектной документации различного производства, разбор структуры которых необходимо реализовать. В таблице 1 приведено сравнение разделов двух ГОСТов, а также обобщение разделов.

Таблица 1. Структура технического задания согласно ГОСТ

Назначение раздела ГОСТ 19.201-78 ГОСТ 34.602.89

Общие сведения о разработке 1. Введение 1. Общие сведения

2. Основания для разработки

Общее назначение разработки 3. Назначение разработки 2. Назначение и цели создания системы

3. Характеристика объекта автоматизации

Общие требования 4. Требования к программе или программному изделию 4. Требования к системе

Общие функциональные требования 4.1. Требования к функциональным характеристикам 4.2. Требования к функциям (задачам), выполняемым системой

4.1. Требования к системе в целом

4.1.1. Требования к структуре и функционированию системы

4.1.3. Показатели назначения

Общие требования к надежности и безопасности разработки 4.2. Требования к надежности 4.1.4. Требования к надежности

4. 1.5. Требования к безопасности

4. 1.6. Требования к эргономике и технической эстетике

Таблица 1. (продолэ/сение)

Назначение раздела ГОСТ 19.201-78 ГОСТ 34.602.89

Общие требования к эксплуатации 4 3. Условия эксплуатации 4.1.2. Требования к численности и квалификации персонала системы и режиму его работы

4. 1.9. Требования к защите информации от несанкционированного доступа

4. 1.10. Требования по сохранности информации при авариях

4. 1.11. Требования к защите от влияния внешних воздействий

4. 1.12. Требования к патентной чистоте

4. 1.13. Требования по стандартизации и унификации

4.4. Требования к составу и параметрам технических средств 4. 1.8. Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы

4.5. Требования к информационной и программной совместимости

4.6. Требования к маркировке и упаковке

Общие требования транспортабельности 4.7. Требования к транспортированию и хранению 4.1.7. Требования к транспортабельности для подвижных систем

Дополнительные требования 4.8. Специальные требования 4.1 14. Дополнительные требования

4.3. Требования к видам обеспечения

Общие требования к документированию 5. Требования к программной документации 8. Требования к документированию

6. Технико-экономические показатели

Общие стадии разработки 7. Стадии и этапы разработки 5. Состав и содержание работ по созданию системы

Общие сведения по приемки разработки 8 Порядок контроля и приемки 6. Порядок контроля и приемки системы

7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие

9.Источники разработки

Из таблицы видно, что несмотря на различие названий и количества разделов, разделы можно разделить на основные группы. Текст технического задания должен содержать все требования к проектируемому продукту, выделенные на этапе внешнего проектирования [97]. На основании анализа ГОСТ 19.201-78 «Техническое задание. Требования к содержанию и оформлению» [24] и ГОСТ 34.602.89 - «Техническое задание на создание автоматизированной системы» [28], приведенного в таблице 1, можно утверждать, что различные типы ТЗ обладают общими фрагментами:

• Общие сведения о разработке;

• Назначение разработки;

• Общие требования;

• Функциональные требования;

• Требования к надежности и безопасности разработки;

• Требования к эксплуатации;

• Требования транспортабельности;

• Дополнительные требования;

• Требования к документированию;

• Стадии разработки;

• Сведения по приемке разработки.

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

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

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

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

Общие сведения о разработке. Данный раздел содержит полное наименование системы, термины и сокращения, используемые при разработке документации, а также реквизиты организаций, участвующих в разработке (Заказчик и Исполнитель). То есть данный пункт содержит в основном юридическую (то есть не относящиеся к работе разрабатываемой системы) информацию и должен быть опущен при разборе. Исключение составляет подпункт «Сокращения и определения», из которого необходимо выделить таблицу сокращений и терминов, использующихся в тексте. С помощью списка сокращений можно заранее раскрыть все сокращения, встречающиеся в тексте, что исключит возможность несовпадения слов в техническом задании и отчете в виду полной и сокращенной формы/аббревиатуры. Основные документы, на основании которых выполняются данные работы, приведены в подразделе «Основания для разработки». Эта часть также может быть пропущена, так как включает в себя документацию более высокого уровня.

Структурные пункты «Назначение и цели создания», «Характеристика объектов» и «Требования» являются основными для работы алгоритма и должны разбираться полностью.

Назначение разработки. Данный раздел документа должен содержать основные назначение и цели создания системы. Сформулированные здесь

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

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

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

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

• Техническое задание;

• Ведомость эскизного (технического) проекта;

• Пояснительная записка к Техническому проекту;

• Описание организации информационной базы;

• Руководство пользователя/администратора;

• Программа и методика испытаний;

• Протокол приемочных испытаний;

• Акт выполненных работ.

Поскольку подпункт «Требования к документированию» содержит в себе перечень всех необходимых документов, которые необходимо создать в процессе

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

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

Сведения по приемке разработки. В данном разделе указываются условия приемо-сдаточные испытаний, которые необходимо произвести, а также степень точности проработки проекта. Этап приемки осуществляется посредством

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

Текст ТЗ может быть дополнен новыми разделами, или сокращен путем удаления пунктов (при предварительном согласии заказчика и разработчика) [97]. Вопрос удаления пункта ТЗ является тривиальным - система не найдет его в тексте, и его результаты обработки не будут представлены. Все дополнительные пункты ТЗ обязаны быть подвергнуты анализу, так как априори не известно, какую именно информацию они содержат.

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

3.2. Программная реализация метода

Для проведения экспериментов и проверки аккуратности метода было разработано программное обеспечение проверки проектных документов на полноту. При реализации программного обеспечения были использованы разработанные в процессе предварительных экспериментов библиотеки выделения терминов предметной области, разделения текста на слова и анализа п-граммов. Поскольку при создании данных библиотек важным требованием являлось их повторное использование, выбор языка был обусловлен следующими требованиями: наличие доступных библиотек работы с текстом, платформенная независимость и широкая популярность (для возможности поддержки программы сторонними специалистами). Подходящими под требования языками программирования являлись: С++, Java, Python. Принимая во внимание объемы обрабатываемой текстовой информации, еще одним важным требованием являлась скорость вычислений, следовательно, был необходим низкоуровневый язык (или язык сочетающий свойства низкоуровневых и высокоуровневых языков). В силу особенности архитектуры, вычисления на языке С++ производятся быстрее, чем на высокоуровневых Java и Python. Принимая во внимание все представленные требования, языком разработки был выбран С++. Выбор среды разработки производился между наиболее распространёнными: Microsoft Visual Studio и Embarcadero С++ Builder (ранее Borland С++ Builder). Обе среды являются коммерческими и обладают схожим функционалом. Финальным выбором стала доступная на момент разработки среда Embarcadero С++ Builder ХЕ2 [119]. Язык и среда разработки для программного обеспечения для проведения экспериментов и проверки аккуратности метода были унаследованы от разработанных библиотек. Программное обеспечение ориентировано на работу в среде Microsoft Windows и использует некоторые из ее компонентов и приложений. Программа выполнена в простом и понятном интерфейсе на русском языке. Общий вид программы представлен на Рис. 11.

Входные данные Нэг'рой» Выборка Гег'Льтз'ы Cono-rr.se"»мнебгокое

Те»мческое задание

Готово к расчету

Загрузить дрдои файл

Загрузить др/гсн1 файл

начать проверку

, _ кол^-«вст»о символов в TJ

Техническое задание T-mpV^.M.rererg^TO.NiOi-R.l t-t 10g?9.

Отчетный документ remp\r«f2iMireferg$_R«port_NIOI<.P t.

Текст тонического задания Текст отчета Клюеве:: е фрагмента

2 1 необходимость классифи>атора 36 4 2

'* 3 3 требования г электронным карточкам докумен-ов мформациомного обмена 53 •»

4 4 6 функционалы

'.тура системы 74

- 5 3 технические требования ма--етз 79 требования обеспечению 7

техническое задание требования к содержанию и оформлению

автоматизированные системы требования к содержанию документов

автоматизированные системы управления общие требования

автоматизированные системы требования к содержанию документов 1

защита от несанкционированно'© доел,-па к информации общие технические требования. 1

защита от несанкционированно'о доступа к информации классификация автоматизированные систем и требования по защите информации 2

в системе применяется конечный список классификаторов список классификаторов рассмотрен в п 3 6 категория узел древовидного классификатора определяющий существенную характеристику блока информации историчность данных .»эрактеристикэ. определяющая

Рис. 11. Интерфейс основного окна программы

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

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

Также для проектирования системы, построенной на основе представленного метода, необходимо установить требования к входным форматам текстовых документов. В настоящее время активно используются несколько форматов, которые позволяют предоставлять информацию в электронном виде. Это форматы файлов TXT, HTML, XML, DOC, RTF, PDF, DJVU, OTD. [9].

Формат .txt представляет из себя прямой текст, без каких-либо специальных символов. Формат .rtf отличается от ЛхШаличием специальных команд, которые

определяют свойства текста в редакторе. Формат MicrosoftWord (.doc, .docx) [49] содержат информацию о форматировании текста. Считается самым распространённым форматом представления документов. Формат OpenTextDocument (.otd) -некоммерческий аналог (.doc). Portable Document Format (-pdf) - межплатформенный формат электронных документов, разработанный фирмой Adobe Systems. В первую очередь предназначен для представления полиграфической продукции в электронном виде.

Несмотря на установленный в декабре 2010 года стандарт формата данных документов ГОСТ Р ИСО/МЭК 26300 - 2010 «Информационная технология. Формат Open Document для офисных приложений (OpenDocument) v.1.0» [31], который должен был устранить многообразие форматов оформления документов за счет использования открытого формата OpenDocument [4, 95], принято считать, что основным форматом электронных документов в электронном документообороте Российской Федерации является Microsoft Word Document (.doc). Кроме того активно используются форматы pdf в полиграфии и djvu при обмене конструкторской документацией. Однако последние два формата обычно содержат в себе графическую документацию: чертежи, схемы, рисунки и проч. Принимая во внимание вышеизложенное, и учитывая специфику предметной области, в качестве основных форматов, воспринимаемых разрабатываемой программой, были выбраны: .txt, .rtf, .doc (.docx) и .otd. Обработка формата pdf и djvu может быть добавлена путем использования коммерческих библиотек.

В качестве источника информации разработанная система использует документы Microsoft Word, ОрепОоситеШили текстовые файлы, выбираемые пользователем. Подключение готовых компонент Microsoft Word позволяет преобразовывать выбранные форматы в PlainText. Именно в этом формате полученный текст технического задания и проектного документа подается на вход программы для дальнейшей обработки. При конвертации документа в текст теряется информация об оформлении документа, однако использование модели «мешка слов» приводит к тому, что она становится неважна, за исключением

случаев предварительного определения структуры документа (которая при необходимости может быть восстановлена и из формата Р1атТех1:).

Одной из подсистем является модуль выделения терминов предметной области. Реализовано два варианта выделения терминов: в два этапа и в один. Пользователь загружает коллекцию документов интересующей его тематики и конкретный документ в систему, которая производит выделение кандидатов в термины из коллекции и документа и на основе значения меры странности и хранящегося в памяти системы списка кандидатов в термины библиотеки Мошкова вычисляет термины предметной области.

Проверка качества документации производится в несколько этапов:

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

• В тексте документа ищутся все вхождения словосочетаний-маркеров и терминов. Предложения объединяются во фрагменты.

• Фрагменты преобразовываются в п-граммы и отправляются на хранение. При этом знаки препинания разделяют словосочетания.

• Индексы вхождения словосочетания-маркера, а также начала и конца значимого фрагмента заносятся в список. В тексте технического задания производится выделение фрагмента.

• Ключевые п-граммы ищутся в отчетном документе. Индексы сохраняются, вхождения в текст отмечаются цветом.

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

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

¡ход ные данные Настроил Выборка' Рез/льтать Сопоставление блоков

Кл>оче»ь>« кологации (по блокам)

фср..-в-говдчс■

фС— вТИ-«вС<ОЙ ТрЭ-;-ргТ141

XÍSí-» прскс^о

трэ*:н.-терэ аии олрвдв-ч«-

Индексы Индексы Ключеаь.«

кпм>чеаы« ключевы« кол локации

слое коллокацкй (по блокам)

15 ЭЗ > хБло- U ,

1SSS3 136Э&

252'' i?:si ^эло:-

-355 i?4:: вблг- я»

:iS35 -£лсв- 5 =

гг i4i is:75

ът>г голо- 5=

10.Í4S 1&ПС- 7г

11243 12Э13

13S23 1413Э

Текст те«мич€о <

т отчета К,гю-..?еtrie фрагменты

| •.рм.сз имеютбольшое значение Некоторые исследователи дэволы:тв\ются корпусами созданными вручную другие и.-пплвзуют двуязычные словари имен и терминов [22 32 42] получают параллельные примерь из двуязычны» корп-, сов [33]. изпписгоеьк запросов [41] сравнивают терминь из разных языков в фонетическом пространстве [14 ?3] В работе [31] описано обучение статистического конечного автомата на одноязычном корпусе Если обойти от теоретической проблема обнаружения с&отве'ств>-й пэдгтро»- или фонем ра ни» я».м»ов и п осмотреть на зад ач*, пра-тической транскрипции с тэч- и прения конечного ползЗоеа*еля воз ■ икает еш" од~э ребующая решения задача определение «ч чэ происхождения имени Пои порождении модели трансгрип-ы.т п о-. 1тен яаык-игтпчни- и делееой язы- а при преобразование некоторой произвольней стро?.- требуется не только наличие модели ран.'крипцИи но и знан.-е того •акую ил имеющиеся моде л е-" следуем

Методь распознавания языка происчожденич имени делятся нз две беляши* группы основанные на правила« и основанные на п-граммэ* [28]

Метод* основанные на правила», могут бы<ь разделены -а две группы методь с автоматическим построением дерева приня-ил решений к1 методы с ручным вводам характеристически» правил В случае руч »и» о ввода г пециалне' должен сделать вывод и тг.м ка-ие конструкции не могут встре-отьсз в данном пзь ье а иак.-е наоборо' будут для него »арактеристичне I "а« например, »арак'ерит-чкыми для арабского язь >.-з или язы-а кинди г. даются сочетания НЬ и ЬН юирые не встречаются в романски» и германски* языка*, тогда «а-характерное для романс ки» и гетман 1-й* языков сочетание "г н* встречается в н-орейс-ом япо- сюм и китайском В связи с тем что подоб I I иааипа не пхялтывают все* имен дз J■ и ты-л. мят-д

Рис. 12. Пример отображения выделенных ключевых терминов и словосочетаний

и связанных с ними фрагментов документа

Общая структура модулей разработанной программы и их взаимосвязи представлена на Рис. 13.

1.Л и дахмыа ДСЖумгмШ

Паяет дому***и1о« со стороны р j |р*ба1чик i

•тнкя ДО« IWK-

Лицо, принимающие решение

КОЛЛ*М|(ИИ Д|нуМГ|11|)|

Контрастный корпус текстов

J

liJU^iniUI lrpfc*n.4>«

l>aia настрой* АЯРЮДЛ

• с-рт* «.<•

т t

Модуль luAfWHXi 1грмиио« пр»дмт1ном

области

♦ Техническое задание

♦ Коллекция документов единой тематики

»Обобщенный корпус текстов

♦ Выделение терминов предме1ной

области

♦ Выделение терминов документа

▼ Г '

Модуль ГУЩ! я» . Л «>•«»» WI» фрагментов

♦ Словосочетания маркеры

♦ Термины предметной области

♦ Параметры метода

♦ Текст технического задания

♦ Выделение ключевых фрагментов технического задания

♦ Выделение ключевых п граммов

♦ Поиск индексов вхождений словосочетаний маркеров

Модуль ра*6ора отчетного документа

• Отчетный документ

• Ключевые п граммы

• Поиск индексов вхождений о граммов

• Расчег общей меры сходства

• Расчет сходства частей отчета с фрагментами техническою задания

• Расчет покрытия отчета фрагментами технического задания

• вычислемие мер ту

í:

Пользовательским интерфейс

Точечная диаграмма местонахождения словосочетаний маркеров в тексте технического задания Точечная диаграмма ключевых N Граммов в тексте отчета го всему документу Точечная диаграмма ключевых N Граммов в тексте отчета го фрагментам Список Фрагментов текста упоминания которых в отчете не было найдены Мера сходства документов целиком и по абзацам

Позиции найденных в отчете упоминаний требований технического задания

Рис. 13. Общая структура программы

Работа метода осуществляется работой основных модулей: 1. Модуль выделения терминов предметной области - загружает уже выделенные термины из хранилища или производит выделение новых терминов на основе полученного на вход документа и контрастного корпуса текстов.

2. Модуль поиска ключевых фрагментов — выделяет фрагменты технического задания, содержащие термины предметной области и выбранные из хранилища настроек словосочетания-маркеры. На выход модуль подает список выделенных ключевых п-грамм.

3. Модуль разбора отчетного документа - производит поиск п-грамм в тексте отчета.

4. Модуль визуализации результатов (пользовательский интерфейс) -выводит результаты работы метода пользователю. Производит построение графиков.

Хранение выделяемой информации производится в виде текстовых списков, хранящихся в памяти программы. Кроме того, пользователь может сохранять и загружать настройки системы и создавать профили обработки определенных типов документов. Всего создано 4 хранилища документов:

5. База данных документов - хранит технические задания и проработанные отчетные документы организации за все время ее существования. При введении нового отчетного документа из данного хранилища выделяется принадлежащее ему техническое задание.

6. Хранилище коллекции документов - содержит контрастные корпуса текстов, применяемые для выделения терминов предметной области. Выбор конкретного корпуса производится в настройках программы

7. База данных терминов - хранит уже выделенные в результате работы программы термины предметной области. По желанию пользователя могут быть использованы при работе, пропуская модуль выделения новых терминов.

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

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

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

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

3.3. Особенности внедрения в системы электронного документооборота предприятий топливно-энергетического комплекса

Для обработки и хранения документов на данный момент разработаны системы электронного документооборота- автоматизированные системы, сопровождающие процессы управления работой иерархической организации. При этом предполагается, что процесс управления опирается на человекочитаемые документы. Системы документооборота показывают положительные результаты в оптимизации работ даже в небольших организациях [127].

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

Системы электронного документооборота [88, 90] в нашем случае используется как база хранения документов, при этом разработанная программа должна встраиваться в систему. При поступлении в СЭД отчетного документа, разработанный модуль отыщет исходное ТЗ и проверит отчет на полноту. При этом все результаты обработки ТЗ извлекаются лишь один раз и хранятся в БД СЭД. Ответственный за приемку эксперт получит уведомление с предварительными результатами, что позволит ему оперативно дать свою оценку.

Единицей информации в СЭД является документ. СЭД осуществляет хранение документа и его истории изменений. СЭД должна обладать следующим основным функционалом: хранение документов, поиск документов, управление документами, администрирование системы. Кроме того, в СЭД должны быть продуманы элементы пользовательского взаимодействия и обеспечение работы жизнедеятельности документа между пользователями.

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

того, подобная модель работы позволяет подключать внешние модули работы с документами. Развитые методы распознавания текстов позволяют перевести бумажный документооборот к безбумажному формату на этапе появления документа в организации. [91].

В ходе разработки программной системы рассматривалась возможность ее встраивания в такие СЭД, как LotusNotes и EMC Documentum. В ходе консультации со специалистами по данным СЭД был сделан вывод, что предложенная система может быть встроена в качестве одного из модулей СЭД предприятия. Единственной сложностью на этом пути является привлечение специалиста, знакомого с проектированием и разработкой подобных модулей, так как система LotusNotes требует полного знания своей архитектуры.

Внедрение разрабатываемой системы в СЭД позволит реализовать процесс автоматизации версионирования документации. Получаемый в системе СЭД документ проектной документации будет автоматически сохранятся в базе данных, с проверкой на наличие более старой версии. Если в базе данных будет найдено относящиеся к проектной документации техническое задание, то система документооборота будет автоматически запускать встроенную систему проверки качества документации (разрабатываемую в диссертационной работе) и отправлять ответственному за проверку пользователю результаты новой обработки, а также архивные данные результатов обработок прошлых версий текста. ЛПР сразу получает данные о том, что было изменено в документации, упоминание о каких требованиях ТЗ были добавлены или удалены и насколько изменились процентные результаты работы метода.

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

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

Одним из вопросов, которые необходимо решить при встраивании метода в СЭД, это формирование настроек системы по умолчанию. В качестве параметров настроек выступает размер значимого фрагмента, список слов, определяющих лексико-синтаксические шаблоны, описывающие требования к ТЗ, проценты отсечки слишком частотных или слишком редких терминов и словосочетаний. Для уточнения данных параметров был проведен ряд экспериментов с документами, имеющими отношение к ТЭК. В результате анализа технических документов были выбраны параметры метода (приведены в таблице 2.) и список словосочетаний-маркеров:

• возможность;

• должен;

• назначение;

• необходимо;

• имеет следующую структуру;

• обеспечивает;

• основной целью;

• осуществляемой;

• требуется;

• обеспечит следующие возможности;

• предназначен для;

• реализовать;

• состоит из;

• требования;

• обусловливает необходимость.

В качестве контрастной коллекции текстов была выбрана библиотека Мошкова (http://www.lib.ru/, 680 млн. словоупотреблений). Данная библиотека имеет целый ряд достоинств по сравнению с другими коллекциями. Во-первых, она является свободно распространяемой, то есть может быть использована в любом проекте без получения дополнительных разрешений. Во-вторых, библиотека содержит в себе тексты, в большинстве своем написанные хорошим литературным языком. Наконец, библиотека содержит в себе тексты различных

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

Таблица 2. Параметры работы метода

Проценты отсечки (рх и р2) Количество слов (п) Размер фрагмента (Г] и гг)

85% 15% 2 1 1

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

Выводы к главе 3

Применение разработанного метода на предприятиях ТЭК предполагает учет структуры документации, которая пишется в соответствии с системой ГОСТов. В главе разобрана структура ГОСТ на Техническое Задание и произведен анализ основных глав документа.

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

В ходе экспериментов с разработанной программной системой экспертом были подобраны параметры ее работы: размер значимого фрагмента, список слов, определяющих лексико-синтаксические шаблоны, описывающие требования к ТЗ, проценты отсечки слишком частотных или слишком редких терминов и словосочетаний.

Разработанный программный комплекс позволил провести серию экспериментов с целью определения значений критериев качества его работы. Результаты экспериментов приведены в главе 4.

Глава 4. Анализ эффективности применения метода 4.1. Оценка точности работы метода

Проверка работоспособности разработанного метода проводилась в два этапа. На первом этапе эксперты читали тексты технического задания и отчета и высказывались об их содержании. Был подготовлен комплект технических заданий и отчетов по научно-исследовательским и опытно-конструкторским разработкам (НИОКР) в области топливно-энергетического комплекса. Каждому ТЗ соответствует один или несколько отчетных документов. Тематика данных работ варьируется и включает такие работы как создание и разработка геоинформационной системы объектов топливно-энергетического комплекса Российской Федерации, разработка программного комплекса для выполнения расчетных работ по паводковой обстановке, разработка научно-обоснованных подходов к созданию в государственной информационной системе топливно-энергетического комплекса сегмента о технологических нарушениях.

На втором этапе множество документов перекрестно проверялось при помощи разработанного метода. Все ТЗ проверялись по всем отчетами чтобы проверить гипотезу о том, что максимум совпадения для качественно написанных отчетов должен находиться на соответствующих им техническим заданиям. Для получения данных результатов были использованы 6 технических заданий и 9 отчетов. При этом:

• ТЗ 1, 2, 3 имеют близкую тематику, связанную с ТЭК.

• ТЗ 5 и 6 имеют близкую тематику, не связанную с ТЭК.

• Отчет 0 не имеет ничего общего ни с одной из тематик 1-6 и не принадлежит к общей тематике ТЭК.

• Отчет 3+ является исправленной по требованию заказчика версией отчета 3, отчет 6+ - исправленной версией отчета 6.

Результаты кросс-проверки приведены в таблицеЗ. В ячейках таблицы приведено значение меры гмежду техническим заданием и отчетным документом

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

Таблица 3. Результаты кросс-проверки для предложенного метода

Технические задания

1 2 3 4 5 6

1 0,521 0,157 0,192 0,032 0,025 0,072

2 0,394 0,592 0,543 0,056 0,054 0,062

3 0,37 0,39 0,158 0,05 0,049 0,05

3 {_ 3+ 0,494 0,45 0,535 0,045 0,051 0,054

4» Т 4 0,032 0,032 0,066 0,032 0,002 0,03 1

н О 5 0,032 0,009 0,02 0,307 0,057 0,095

6 0,006 0,011 0,007 0,002 0,031 0,638

6+ 0,006 0,009 0,006 0,002 0,016 0,725

0 0,01 1 0,043 0,035 0,006 0,006 0,017

Как видно из таблицы 3, разработанный метод и программное обеспечение определило высокое качество отчетов, написанных для технических заданий 1-3 и 6. Блок документов 1-3, имеющих близкую тематику показывает хорошие результаты друг с другом, но максимум меры у находится у корректных пар. Отчет 3+, являющийся переписанным по требованию заказчика отчетом 3, действительно показывает лучшее совпадение с третьим техническим заданием, чем отчет 3. Отчет 6+ также показывает заметное улучшение в значении меры по сравнению с отчетом 6. Результат работы системы для отчетов 3 и 3+, 6 и 6+ совпал с мнением заказчика. Принимая во внимание факт того, что отчеты были переписаны, по мнению заказчика, и эксперты, проверявшие отчеты на первом шаге, согласны с общими улучшениями в структуре, можно предполагать, что метод сработал верно.

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

Основные трудности возникли с документами 4 и 5. Технические задания 4 и 5 не предполагали подробного описания результатов работы и требований к ним. В задачи отчетного документа 5 входила выдача рекомендаций по улучшению существующих бизнес-процессов, что усложнило поиск соответствия. Фактически ТЗ 4 и 5 не содержали конкретных требований к тексту отчета, а указывали на те направления, в которых должно проводиться исследование, и параметры, подлежащие улучшению. Несмотря на различие тематики технических заданий 4 и 5, отчет 4 содержал информацию по предметной области технического задания 5, поэтому их мера сходства высока. Данный пример показывает ограничения, которые накладываются на применимость метода. Рассматриваемая пара ТЗ-отчет должна быть связана наличием общих требований, ставящихся в ТЗ и раскрываемых в отчете. Если ТЗ не содержит в себе подобных требований, метод допустит ложный пропуск и покажет низкое соответствие текстов. В этом случае эксперту придется самостоятельно изучать текст отчета без каких-либо подсказок со стороны системы.

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

Таблица 4. Результаты кросс-проверки без выделения значимых фрагментов

Технические задания

1 2 3 4 5 6

1 0,533 0,546 0,546 0,198 0,263 0,292

2 0,532 0,554 0,880 0,151 0,169 0,162

3 0,554 0,779 0,579 0,183 0,205 0,191

3 3+ 0,534 0,763 0,612 0,191 0,204 0,192

о •х 4 0,331 0,238 0,326 0,189 0,212 0,167

н О 5 0,418 0,302 0,331 0,182 0,317 0,243

6 0,161 0,091 0,116 0,089 0,091 0,443

6+ 0,163 0,091 0,117 0,089 0,091 0,443

0 0,257 0,174 0,207 0,139 0,175 0,185

Как видно из таблицы, косинусная мера успешно определяет тексты с общей тематикой, но не показывает качество отчетной документации: максимальные значения достигаются на ТЗ, не соответствующих данному отчету; разделимость качественных и не качественных отчетов отсутствует.

Блок документов 1-3 практически не различен, техническое задание 2 получило большое значение сходства с отчетом 3. В таблице не различается диагональ корректных пар. Переписывание отчета 6+ не сильно повлияло на изменение меры, отчеты 4-5 приближаются к значениям сходства документов 1-3, хотя не близки по конкретной тематике. Отчет 0 показывает меру сравнимую с мерой документов 1-6, хотя не принадлежит к общей тематики разработок в сфере ТЭК.

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

словосочетаний-маркеров и дополнительной работе с выделением терминов документа.

На основании анализа документов 4 и 5 и их отчетов выявляются проблематичные для метода технические задания, описывающие лишь основные цели работы. Однако, как уже было сказано выше, мера V является лишь числовым представлением сходства и выступает только в роли первоначальной проверки, поскольку даже при высоком соответствии необходима детальная экспертиза. Тем не менее, эксперименты показали, что метод может применяться как часть автоматизированной системы ведения и хранения документации по проекту и помогать в принятии решений о доработке отчета или о его детальной экспертизе [54].

Для оценки точности выделения требований технического задания методом было произведено сравнение с ручным выделением информации. Две группы получили одинаковую коллекцию технических заданий с целью выделения тех фрагментов текста, которые, по их мнению, содержат требования. При этом одна группа состояла из экспертов со стажем работы с техническими заданиями и проектной документацией, а вторая не обладала подобным стажем и до этого не работала с документами ТЗ. На Рис. 14 представлены требования технического задания, выделенные экспертами (верхняя часть) и предложенным методом (нижняя часть). При этом необходимо отметить, что экспертом для экономии времени обычно выделялась вся страница или абзац, содержащий требование, в то время как метод выделяет только конкретный фрагмент. Представленный на рисунке текст технического задания, разделен на 72 равных фрагмента. Интенсивность цвета верхнего рисунка растет с количеством экспертов отметивших данных фрагмент, как содержащий требования. При этом разделяется 4 категории интенсивности цвета:

• меньше 33% экспертов;

• от 33% до 66% экспертов;

• от 66% до 99% экспертов;

• 100% экспертов.

Рис. 14. Сравнение выделения фрагментов

Как видно из рисунка, в метод чаще выделяет фрагменты, выделенные несколькими экспертов. В эксперименте были рассчитаны значения полноты и точности. Вычисление мер производилось на основе трех параметров:

• количество выделенных предложений методом, но не выделенных минимум половины экспертов;

• количество выделенных предложений, выделенных как методом, так и минимум половиной экспертов;

• количество не выделенных методом предложений, выделенных минимум половиной экспертов.

Общее качество выделения оценивалось при помощи Ргмеры, которая определяется как взвешенное гармоническое среднее точности Р и полноты И:

?1 = — ■ (24)

(р+л) у '

Полученные в ходе экспериментов средние значения полноты, точности и Р1-меры представлены в таблице 5. Среднее значение Р1-мера для разработанного метода равняется 0,685. Р1-мера для результатов, показанных экспертами (относительно их консолидированного мнения) не превысила 0,6 ни в одном из экспериментов. То есть точность и полнота работы предложенного метода как минимум не ухудшает результатов оценки, а скорее улучшает их. При этом затраты времени на выделение терминов предметной области и выделение значимых фрагментов разработанным методом не превышает 8 минут, а ручное выделение экспертами в среднем занимало 30 минут.

Таблица 5. Точность и полпота выделения требований

Полнота Точность Р1-мера

Метод 0,57 - 0,73 0,64 - 0,89 0,69

Человек со стажем 0,8 0,4 0,6

Человек без стажа 0,4 0,3 0,4

Разработанный метод позволяет пользователю быстрее принимать решение о принятие проектного документа. Определение системой некачественного документа позволяет лицу, принимающему решение, тратить меньше времени, поскольку происходит замена времени чтения всего текста отчета временем просмотра набора результатов работы метода. С учетом, что среднее время прочтения страницы 14 кегелем (1800 знаков на странице) составляет минуту, можно предполагать, что минимальное время чтение отчетного документа составляет от 10 до 90 минут в зависимости от размера документа. Данное время показывает лишь единичное прочтение документа, в котором ЛПР должен разобраться и отыскать упоминание всех требованиях. Кроме того, отсутствие упоминания и выполнения необходимо занести в документ отчета проверки, который впоследствии отправится разработчику. Полный разбор документа в таком случае, может занимать полную рабочую неделю. Принимая норму чтения текста равную 25 страницам в день и 8 часовой рабочий день, можно предполагать, что на чтение объемного 100 страничного текста, ЛПР будет тратить 32 часа рабочего времени. В случае, если проектная документация написана некачественно, ЛПР с использованием разработанной системы может сократить данное время до одного часа, получив отрицательный результат при работе программы и проверив отсутствие требований ТЗ, выделенных системой (см. Таблица 6).

Таблица 6. Качественная ог/енка эффективности метода

Отчет Предварительная проверка Прочтение отчета Итого на отчет в 100 страниц

С применением метода Полный 1 час 25 страниц в день 32 часа

Неполный 1 час 0 1 час

Без применения Полный - 25 страниц в день 32 часа

Неполный - 25 страниц в день 32 часа

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

4.2. Результаты экспериментов по выделению терминов предметной области из

документов организации

Для повышения точности выделения ключевых фрагментов текста технического задания была произведена еще одна серия экспериментов, связанная с выделением терминов предметной области. Выделение производилось в два шага, при этом результатом первого шага является набор терминов, связанных с разработкой в сфере топливно-энергетического комплекса. Из контрастного корпуса текстов и коллекции документов по разработке систем ТЭК были выбраны кандидаты в термины. Примеры выбранных кандидатов представлены на Рис. 15 и Рис. 16 соответственно.

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

Финальный набор терминов коллекции документов ТЭК, выделенный при помощи меры странности, представлен на Рис. 17. Данный набор терминов может быть использован в дополнение к словосочетаниям-маркерам при обработке документов, описывающих разработку в области топливно-энергетического комплекса. Для создания подобного списка необходима как коллекция документов, так и контрастный корпус текстов. Заметим, что список терминов по предметной области может накапливаться и впоследствии использоваться с новыми документами данной тематики.

ВРЕМЯ ВОЛНА ГРУДЬ ВЕЧЕР ГОСУДАРСТВО БОЛЬШИНСТВО

ГЛАЗ ЬУМАГА ГЕНЕРАЛ ВОЗДУХ ВПЕЧАТЛЕНИЕ ВС1РЕЧА

ГОД ГРЕХ воин ВЕТЕР БОРТ ВОЛЯ

ВОЗМОЖНОСТЬ ВЫСОТА АВТОР ВОЙНА ВОЛК Г'ОСПОДЬ

БОГ ВЕЩЬ АНДРЕЙ БРАТ БЕСЕДА БОЛЬ

голос ГЛАЗ НН БОЙ ГОЛОВА ГЕРЦОГ БАБУШКА

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

ГОРОД ВРЕМЯ ГОСТ ЮДИН ВРАГ БЕРЕГ ГАРРИ

ВЗГЛЯД БОЛЕЗНЬ ВЕРА ВЛАСТЬ I HFB ВСАДНИК

ВИД 1 ОРЛО гость ВРАЧ АННА АРМИЯ

Рис. 15. Наиболее частотные термины из контрастного корпуса

тэк сист ем а реесip развитие

документ информационный обмен формирование электронный карточка объект тип задача привес 1 и конкретный iijae разьяснение по поведение

информация бедс1вие объект срок

чрезвычайный ситуация типичный ситуация государственный тайна электронный карточка

объект тэк собы1ие классификатор тэк сотруд11ик

случай субъект тэк работа выполнение

нажатие на кнопка добавить объект тэк работа функциональный подсистема уведомление объект тэк

сценарий деятель! юсть учет карточка

задача минэнерго россия доступ порядковый номер

приложение время отчет тэк целесообразный

Рис. 16. Наиболее частотные термины из специализированной коллекции

рабочим давлении рассматривать субъект тэк расположить не на территория электричг.кая iюдстан11.ия

объек i нефт е1 шреработка

представить в реестр нп разработать карючка объект

разраба i ыва1ь элеме11т и11ф0рма11ио! ii1ый инфраструктура 1эк

предпринимать сац ми1ш1ерео россия усилие: i ю ан гоматизлция процесс

связь в ближайший время мипэнер1 о россия целесообразный

кабельная лэп

трубопровод mai ис тральный

разве i вить сеть и11форма1цю1ii1ый обмет i

объект 1 ос

сведение о категорированный объек т i "ж

проект уведомление не представить реляционный модель

предост авление и11формация содержат ься в реестр

проект уведомление. о приостановление исполнение еосударствеппый функция

представление колле1 иальный орган по 1 противодействие терроризм

Рис. 17. Выделенные термины коллещии Второй этап выделяет термины, уникальные именно для конкретного документа, но при этом входящие в общую тематику коллекции. Для их выделения из документа выбираются кандидаты в термины, для каждого из которых производится вычисление меры странности по уже вычисленному набору терминов предметной области. Набор терминов документа «Создание проекта автоматизированного комплекса по ведению в электронном виде реестра категорированных объектов ТЭК», выделенный при помощи меры странности, представлен на Рис. 18.

Как видно из полученных данных, выделение терминов проводится корректно. Поиск по выделенным терминам в тексте отчетного документа позволяет ЛПР отследить логику документа, поднимаемые в нем вопросы и полноту их изложения. Выделение терминов из ТЗ позволяет также выделить требования. Таким образом, выделение терминов как минимум помогает ЛПР сориентироваться в документах при их приемке.

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

катг1 орирова1шыи обы ki тэк рабочии давл1 пит

карючка kai1 гориропанныи обы kt cbi д1 ниь о кате горированпыи оьы-ki тэк

успешный аут! 111 ификация докум1н1 информационный оьм1 н

сотрудник сацми1ш11 рю и11форма11иош1ыи иодсисiгма

рассма1рива гь субъгкi 1эк каьингт с 01 руд1 ihk сац ми1п11lpí о

упр01ц1 ниь работа ohlpaiop сис 11 ма прикладной i1poi 1'аммныи оььспгч! пиг

оптимизация работа сис 11 ма о ¡крыться окно ы 30iiact юсть пользователь

hfpfiioc информация о номгр пунк1 оч1 редь для работа

chfk1p задача выполнять пользователь в процгсс раьоiа с класс ификатор 1 эк ipteobaiihl к докум1 111 информационный обмьн

pi зультат продела1 ь paboi а сотрудник сац минэнерго основа получить информация coi рудник сац минэнерго

Рис. 18. Выделенные термины документа

Как видно из рисунков, в числе выделенных терминов содержатся используемые только в области топливно-энергетического комплекса слова и словосочетания (Минэнерго, ТЭК, ТЭС и т.д.), а термины конкретного документа, представленные на Рис. 17 и Рис. 18 - описывающие требования к созданию информационной подсистемы категорированных объектов словосочетания.

Подобный набор терминов подтверждает аккуратность и точность метода выделения терминов предметной области. Использование тематических терминов позволяет выделять дополнительные фрагменты текста технического задания, пропускаемые набором стандартных словосочетаний-маркеров (см. раздел 4.4).

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

4.3. Визуальное представление результатов

Точечная диаграмма распределения ключевых фрагментов является основным инструментом ЛИР, используемым для работы с отчетным документом. Ниже приведены примеры полученных в результате экспериментов диаграммы технических заданий и отчетов различного качества оформления. Диаграммы читаются построчно, каждая точка представляет информацию по 100 символам. Каждая строка содержит 100 точек, следовательно, в каждой строке представлено 10000 символов текста. Основным критерием оценки полученных результатов является процентное отношение выделенных фрагментов (точек диаграммы) к общему количеству фрагментов.

На Рис. 19 и Рис. 20 представлены проанализированные технические задания [54]. На Рис. 19 представлена диаграмма разбора неудачно (по мнению эксперта) написанного ТЗ. Зеленым цветом отмечены фрагменты текста, в которых были найдены маркеры. Значимые фрагменты в ТЗ разбросаны по всему тексту: малое количество зеленых точек разнесено по всей диаграмме объемного текста.

Рис. 19. Пример визуализации результатов анализа неудачного ТЗ

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

В случае, когда ТЗ пишут в особом сжатом ключе (техническая записка), где нет ничего кроме перечисления требований, получается диаграмма, представленная на Рис. 21.

.....;' ' '