Оптимизация временных затрат на проверку проектной документации на предприятиях топливно-энергетического комплекса::Журнал СА 1-2.2015
www.samag.ru
     
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
Журнал "Системный администратор"
Журнал «БИТ»
Подписка
Архив номеров
Где купить
Наука и технологии
Авторам
Рекламодателям
Контакты
   

  Опросы
  Статьи

Дата-центры  

Дата-центры: есть ли опасность утечки данных?

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

 Читать далее...

Книжная полка  

Защиты много не бывает

Среди книжных новинок издательства «БХВ» есть несколько изданий, посвященных методам социальной инженерии

 Читать далее...

Событие  

В банке рассола ждет сисадмина с полей фрактал-кукумбер

Читайте впечатления о слете ДСА 2024, рассказанные волонтером и участником слета

 Читать далее...

Организация бесперебойной работы  

Бесперебойная работа ИТ-инфраструктуры в режиме 24/7 Как обеспечить ее в нынешних условиях?

Год назад ИТ-компания «Крок» провела исследование «Ключевые тренды сервисного рынка 2023». Результаты

 Читать далее...

Книжная полка  

Читайте и познавайте мир технологий!

Издательство «БХВ» продолжает радовать выпуском интересных и полезных, к тому же прекрасно

 Читать далее...

СУБД PostgreSQL  

СУБД Postgres Pro

Сертификация по новым требованиям ФСТЭК и роль администратора без доступа к данным

 Читать далее...

Критическая инфраструктура  

КИИ для оператора связи. Готовы ли компании к повышению уровня кибербезопасности?

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

 Читать далее...

Архитектура ПО  

Архитектурные метрики. Качество архитектуры и способность системы к эволюционированию

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

 Читать далее...

Как хорошо вы это знаете  

Что вам известно о разработках компании ARinteg?

Компания ARinteg (ООО «АРинтег») – системный интегратор на российском рынке ИБ –

 Читать далее...

Графические редакторы  

Рисование абстрактных гор в стиле Paper Cut

Векторный графический редактор Inkscape – яркий представитель той прослойки open source, с

 Читать далее...

День сисадмина  

Учите матчасть! Или как стать системным администратором

Лето – время не только отпусков, но и хорошая возможность определиться с профессией

 Читать далее...

День сисадмина  

Живой айтишник – это всегда движение. Остановка смерти подобна

Наши авторы рассказывают о своем опыте и дают советы начинающим системным администраторам.

 Читать далее...

Виртуализация  

Рынок решений для виртуализации

По данным «Обзора российского рынка инфраструктурного ПО и перспектив его развития», сделанного

 Читать далее...

Книжная полка  

Как стать креативным и востребованным

Издательский дом «Питер» предлагает новинки компьютерной литературы, а также книги по бизнесу

 Читать далее...

1001 и 1 книга  
19.03.2018г.
Просмотров: 6410
Комментарии: 0
Машинное обучение с использованием библиотеки Н2О

 Читать далее...

12.03.2018г.
Просмотров: 7116
Комментарии: 0
Особенности киберпреступлений в России: инструменты нападения и защита информации

 Читать далее...

12.03.2018г.
Просмотров: 4393
Комментарии: 0
Глубокое обучение с точки зрения практика

 Читать далее...

12.03.2018г.
Просмотров: 3085
Комментарии: 0
Изучаем pandas

 Читать далее...

12.03.2018г.
Просмотров: 3881
Комментарии: 0
Программирование на языке Rust (Цветное издание)

 Читать далее...

19.12.2017г.
Просмотров: 3897
Комментарии: 0
Глубокое обучение

 Читать далее...

19.12.2017г.
Просмотров: 6385
Комментарии: 0
Анализ социальных медиа на Python

 Читать далее...

19.12.2017г.
Просмотров: 3232
Комментарии: 0
Основы блокчейна

 Читать далее...

19.12.2017г.
Просмотров: 3529
Комментарии: 0
Java 9. Полный обзор нововведений

 Читать далее...

16.02.2017г.
Просмотров: 7363
Комментарии: 0
Опоздавших не бывает, или книга о стеке

 Читать далее...

17.05.2016г.
Просмотров: 10724
Комментарии: 0
Теория вычислений для программистов

 Читать далее...

30.03.2015г.
Просмотров: 12443
Комментарии: 0
От математики к обобщенному программированию

 Читать далее...

18.02.2014г.
Просмотров: 14095
Комментарии: 0
Рецензия на книгу «Читаем Тьюринга»

 Читать далее...

13.02.2014г.
Просмотров: 9192
Комментарии: 0
Читайте, размышляйте, действуйте

 Читать далее...

12.02.2014г.
Просмотров: 7141
Комментарии: 0
Рисуем наши мысли

 Читать далее...

10.02.2014г.
Просмотров: 5446
Комментарии: 3
Страна в цифрах

 Читать далее...

18.12.2013г.
Просмотров: 4683
Комментарии: 0
Большие данные меняют нашу жизнь

 Читать далее...

18.12.2013г.
Просмотров: 3494
Комментарии: 0
Компьютерные технологии – корень зла для точки роста

 Читать далее...

04.12.2013г.
Просмотров: 3211
Комментарии: 0
Паутина в облаках

 Читать далее...

03.12.2013г.
Просмотров: 3449
Комментарии: 0
Рецензия на книгу «MongoDB в действии»

 Читать далее...

02.12.2013г.
Просмотров: 3090
Комментарии: 0
Не думай о минутах свысока

 Читать далее...

Друзья сайта  

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

Архив номеров / 2015 / Выпуск №1-2 (146-147) / Оптимизация временных затрат на проверку проектной документации на предприятиях топливно-энергетического комплекса

Рубрика: Наука и технологии

Без фото КАЛАЧЕВ Я.Б., МИЭМ НИУ ВШЭ, Москва, rusfund@gmail.com

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

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

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

Особенностью российского ТЭК является его прямая взаимосвязь с государственными структурами, сложная структура отраслей промышленности и колоссальный географический разброс предприятий [13]. Все это требует постоянной разработки новых систем автоматизации для взаимосвязи различных отраслей. Современная модель проектирования систем включает набор документов, помогающих точно установить их задачи и сроки выполнения работ. Решение проектной задачи начинается с точного обозначения функций системы и составления технического задания, частного технического задания, плана-проспекта, технических условий или других документов, передаваемых исполнителю. Для обозначения всех видов документации начального уровня здесь будет использоваться термин «техническое задание» (ТЗ), понимаемый в смысле [5]. Техническое задание описывает основные требования, характеристики будущего объекта, а также стадии разработки и специальные требования. Такой документ определяет основные цели, требования и исходные данные, необходимые для разработки [1, 6, 17].

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

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

Обзор существующих решений

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

Автоматизированная обработка технической документации является одним из развивающихся направлений обработки текстов на естественном языке. Основное направление подобных методов – выделение значимой информации из документов. Разбор документов позволяет определить и выделить установленные требования [11], а также проверить текст на соответствие требованиям технической документации [16]. Задача обработки технической документации уже ставилась при решении различных проблем. Так, например, группа под руководством Невзорова В.Н. разрабатывала систему «Лота» для анализа документов, описывающих логику работы системы в области авиации [14]. Другой крупной системой является разработка ВолГТУ, осуществляемая под руководством Заболеевой-Зотовой А.В. и Орловой Ю.А. [7, 8, 15]. Данная система позволяет выделять из текста ТЗ основные параметры разрабатываемой системы и заносить их для дальнейшего анализа в заранее подготовленную фреймовую структуру. С нашей точки зрения эта работа, равно как и предыдущая, опирается на использование онтологий, так как в ней задается система знаний о предметной области.

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

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

Метод анализа документации

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

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

Определение полноты документа основывается на использовании значимых n-грамм и специализированных терминов, которые характеризовали бы текст технического задания и показывали бы установленные требования, представленные в документе [3].

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

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

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

Для вычисления специализированных терминов документа производится двойная выборка кандидатов в термины, предложенная в работе [12]. Текст документа разбивается на слова, которые приводятся к нормальной форме. Идущие подряд слова образуют кандидаты в термины, которые при этом могут состоять только из существительных, прилагательных, причастий, порядковых числительных, предлогов и союза «и», а наречия и местоимения опускаются. Вычисление производится в два шага. На первом шаге в список lcol выделяются кандидаты в термины коллекции специализированных текстов tcol, а в список lmos выделяются кандидаты в термины обобщенного корпуса текстов tmos. Списки представлены в виде:

l = < (w, f) >,

где w ∈ f –кандидат в термины, а f – его частота встречаемости.

Список терминов ltmp коллекции создается путем вычисления меры странности [18] списка коллекции документов lcol по списку обобщенного корпуса текстов lmos. Вторая выборка выделяет термины конкретного документа t1. Из текста документа выделяются кандидаты в термины, которые заносятся в список l1. Финальный набор терминов l выделяется вычислением меры странности списка l1 по уже посчитанному на первом шаге списку странности коллекции документов ltmp. Таким образом, l содержит уникальные термины для конкретного документа, входящие в его предметную область. Выделенные в итоге термины включаются во множество словосочетаний-маркеров.

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

На первом шаге метода по тексту ТЗ с использованием описанного алгоритма ищутся значимые фрагменты. Каждый выделенный по правилам фрагмент из текста ТЗ t1 заносится в список F = { <s> }. Позиции вхождений словосочетаний-маркеров в текст технического задания t1 заносятся в список PA1. На втором шаге проводится выделение признаков из значимых фрагментов из списка F, а также производится поиск терминов специализации текста. Ключевые фрагменты разбиваются на группы из n слов (n-граммы) и заносятся в список VA1. В этот список попадают только n-граммы, состоящие из стоящих рядом друг с другом, не разделенных знаком слов. Для значимых фрагментов рассчитывается вектор признаков:

a = < (wn, f) >,

где wn ⊂ s – n-грамма, а f – ее частота встречаемости.

Для каждого отдельного фрагмента также создается список Vi, содержащий n-граммы этого фрагмента.

На третьем шаге выбранные ключевые словосочетания ищутся в отчете. Находим те предложения sj текста отчета t2, в которых встречаются n-граммы из VA1 (т.е. статистику нахождения упоминания требований в отчете). Для каждого Vi считаем меру mvi, равную отношению количества найденных совпадений из Vi в тексте отчета t2 к количеству n-грамм в Vi:

mvi =m / n,

где m – количество wn, таких что wn ∈ Vi и wn ∈ t2, а n – количество wn в Vi.

Поскольку требования, поставленные в ТЗ, могут находиться в различных абзацах отчета, то мера mvi показывает пользователю, какие конкретно предложения с требованиями не были найдены в отчете. Позиции вхождений n-грамм VA1 и Vi в текст отчета t2 заносятся в списки PA2 и Pi соответственно. При большом проценте выделения значимых частей технического задания (15% и более), но маленьком значении процентного отношения найденных ключевых словосочетаний в тексте отчета (15-20%) пользователь может просмотреть список мер mvi, показывающий, какие требования ТЗ не были представлены в отчете. Значение меры mv варьируется в пределах от 0 до 1, со средним показателем 0,6 для описанных в отчете требований, 0,2 и меньше для плохо описанных и 0 значением, если упоминание требования не найдено.

Из текста отчета формируется список n-грамм с частотами их встречаемости (вектор признаков VA2 = b = a = < (wn, f) >). На основе совпадающих n-грамм в VA1 и VA2 косинусная мера сходства документов. Полученная мера является одним из параметров, влияющих на финальное решение пользователя. Значения меры сходства документа должны лежать в пределах от 0,3 до 0,9 у близких по смыслу текстов и в пределах от 0,4 до 0,8 между документами технического задания и принадлежащими им отчетами. Значение меры меньше 0,1 говорит о несвязанности текстов по предметной области, а больше 0,9 – о возможном копировании текста технического задания в отчетный документ. Подобные значения должны насторожить пользователя и выявить ошибки в написании отчета. Текст отчета разбивается на абзацы, каждому из которых присваивается вектор признаков b, который формирует списки VOj (VO = {VOj} = {b}). Значимость абзаца с номером j вычисляется как максимум косинусной меры сходства вектора b с векторами a или равна нулю, если найденная значимость ниже заданного порога:

voj = maxi cos(ai, bj),

где ai ∈ Vi, а bi ∈ VOj.

На четвертом шаге метода эксперт получает результаты работы метода и принимает решение о дальнейшей работе с отчетом. Подробнее о представленном методе можно прочитать в статье [10].

Визуализация результатов

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

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

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

В результате работы метода пользователь получает три диаграммы: местонахождение слов-маркеров в техническом задании, местонахождение ключевых n-грамм в отчете по всему тексту, местонахождение ключевых n-грамм в отчете по фрагментам.

Точечная диаграмма распределения ключевых фрагментов является основным инструментом, используемым для работы с отчетным документом. Основным критерием оценки полученных результатов является процентное отношение выделенных фрагментов (точек диаграммы) к общему количеству фрагментов и общая кучность выделения. По точечной диаграмме выделенных значимых частей технического задания пользователь может установить качество самого технического задания. Отношение выделенных фрагментов к общему количеству меньше 1% – это граница, при которой техническое задание считается непригодным для работы метода. Хорошим процентным показателем выделения предложений со словосочетаниями-маркерами из документов, написанных по ГОСТ, являются 8-17%. Данный показатель достигает значения в 70-80% на коротких технических записках, в которых перечислены только требования к разработке. Основным показателем полноты отчетного документа является процентное отношение фрагментов с найденными ключевыми словосочетаниями к общему количеству фрагментов точечной диаграммы отчета. Нижней границей, при которой отчет считается негодным к проверке, является показатель в 15%, а верхней границей – 85%. Превышение верхней границей показывает пользователю, что отчет скорее всего списан с текста технического задания. Подробный анализ визуальных результатов был проведен в статье [9].

Применение терминов предметной области

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

Рисунок 2. Диаграмма технического задания и отчета, только термины

Рисунок 2. Диаграмма технического задания и отчета, только термины

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

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

Рисунок 3. Диаграмма технического задания и отчета, только словосочетания-маркеры

Рисунок 3. Диаграмма технического задания и отчета, только словосочетания-маркеры

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

Рисунок 4. Диаграмма технического задания и отчета, термины и словосочетания-маркеры

Рисунок 4. Диаграмма технического задания и отчета, термины и словосочетания-маркеры

Результаты трех вариаций работы метода представлены в таблице 1.

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

  Термины Словосочетания-маркеры Объединение
Косинусные меры сходства векторов признаков 0,234 0,279 0,278
Отношение выделенных фрагментов ТЗ к общему количеству 0,279 0,060 0,063
Отношение выделенных фрагментов отчета к общему количеству 0,278 0,172 0,174

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

Результаты

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

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

Работа метода проверялась относительно мнения экспертов, которые предварительно прочитали работы, выделили значимые части и высказались о качестве выполнения отчетов.

Документы перекрестно проверялись с помощью разработанного метода. Все технические задания проверялись по всем отчетам, чтобы подтвердить гипотезу о том, что максимум совпадений для качественно написанных отчетов должен находиться на соответствующих им технических заданиях. Для определения меры сходства была выбрана косинусная мера. Значение меры сходства для сопоставимых пар ТЗ-отчет находится в промежутке от 0,4 до 0,7. Между ТЗ и отчетом одинаковой тематики – от 0,3 до 0,5; между ТЗ и отчетом другой тематики – от 0,01 до 0,04.

Вторая кросс-проверка была произведена без выделения ключевых фрагментов словосочетаниями-маркерами и терминами для определения точности выделения ключевых фрагментов. Значение меры сходства для сопоставимых пар ТЗ-отчет одинаковой тематики – от 0,3 до 0,6; между ТЗ и отчетом другой тематики – от 0,2 до 0,3.

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

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

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

На рис. 5 представлены результаты сравнения выделенных ключевых фрагментов методом и экспертами. Требования технического задания, выделенные экспертами, представлены на верхней части рисунка, а предложенные методом – на нижней. Для отображения результатов на рисунке текст технического задания был разделен на 72 равных фрагмента, каждый из которых представлен полосой. Необходимо заметить, что при сравнении границы фрагментов, выделенные методом и экспертами, были аппроксимированы до уровня страницы. Каждая страница содержит три фрагмента. Два выделенных фрагмента считаются одинаковыми, если совпадает больше 70% выделенного текста на трети рассматриваемой страницы. Данное условие было введено из-за особенностей стилистики выделения разных экспертов. Интенсивность цвета верхнего рисунка растет с количеством экспертов, отметивших данных фрагмент как содержащий требования. При этом разделяется четыре категории интенсивности цвета (меньше 30% экспертов, от 30 до 60% экспертов, от 60 до 99% экспертов, 100% экспертов).

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

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

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

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

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

Общее качество оценивалось с помощью F1-меры, которая определяется как взвешенное гармоническое среднее точности P и полноты R:

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

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

  Полнота Точность F1-мера
Метод 0,57 - 0,73 0,64 - 0,89 0,69
Человек со стажем 0,8 0,4 0,6
Человек без стажа 0,4 0,3 0,4

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

Таблица 3. Сравнение временных затрат

  Отчет Предварительная проверка Прочтение отчета Итого на отчет в 100 страниц
С применением метода Полный 1 час 25 страниц в день 32 часа
Неполный 1 час 0 1 час
Без применения метода Полный - 25 страниц в день 32 часа
Неполный - 25 страниц в день 32 часа

Выводы

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

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

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

  1. Абрамов Г.С. Проблемы внедрения Национального стандарта РФ «Порядок измерений количества добываемых нефти и нефтяного газа» в ХМАО-Югра на уровне кустов нефтедобывающих скважин. // НТЖ «Автоматизация, телемеханизация и связь в нефтяной промышленности». – М.: ОАО «ВНИИОЭНГ1». – №11, 2005 г. – С. 3.
  2. Байков Н. Топливно-энергетический комплекс. // «Мировая экономика и международные отношения». – №8, 1998 г. – С. 26-28.
  3. Большакова Е. И. и др. Автоматическая обработка текстов на естественном языке и компьютерная лингвистика. – М.: МГИЭМ, 2011. – 272 с.
  4. Волкова Г. А. Создание «онтологии всего». Проблемы классификации и решения. / Сб. трудов научно-практического семинара «Новые информационные технологии в автоматизированных системах». – 2013. – С. 293-300.
  5. ГОСТ 25123-82. Машины вычислительные и системы обработки данных. Техническое задание. Порядок построения, изложения и оформления.
  6. Грекул В. И., Денищинко Г. Н., Коровкина Н. Л. Проектирование информационных систем. / Учебное пособие. – М., 2005. – С. 34-38.
  7. Заболеева-Зотова А. В., Орлова Ю. А. Автоматизация процедур семантического анализа текста технического задания. / Известия Волгоградского гос. технического университета. – Т. 9. – №3, 2007 г. – С. 52-55.
  8. Заболеева-Зотова А. В., Орлова Ю. А. Атрибутная грамматика формального документа «Техническое Задание». / Cб. Научных статей «Актуальные проблемы управления, вычислительной техники и информатики в технических системах». – №4, 2008 г.
  9. Калачев, Я.Б. Метод визуального представления полноты отчетных документов. / Э.С. Клышинский, Я.Б. Калачев. // Журнал «Научная Визуализация». – 2014.
  10. Калачев, Я.Б. Методика автоматизации проверки полноты технической отчетной документации / Э.С. Клышинский, Я.Б. Калачев, В.В. Жаднов // Научно-техническая информация. – Сер. 2: Информационные системы и процессы, №5. 2014 г. – С.11-15.
  11. Клышинский, Э. С. Анализ комплексных мер тематического сходства документов. / Научно-техническая информация. – Сер. 2: Информационные системы и процессы. № 9, 2011 г. – С. 6-11.
  12. Кочеткова Н. А., Клышинский Э. С. Метод извлечения технических терминов с использованием меры странности. / Новые информационные технологии в автоматизированных системах. – 2014; Клышинский, Э. С. Перспективные методы обработки проектной документации. / Труды 12-й Всероссийской научной конференции «Электронные библиотеки: перспективные методы и технологии, электронные коллекции» – RCDL’2010. – Казань, Россия. – 2010.
  13. Мастепанов, А. М. Топливно-энергетический комплекс России на рубеже веков: состояние, проблемы и перспективы развития. / Справочно-аналитический сборник, том 1. – М.: ИАЦ «Энергия». – 2009.
  14. Невзорова О. А., Невзоров В. Н., Зинькина Ю. В., Пяткин Н. В. Интегральная технология разрешения омонимии в системе анализа текстовых документов «ЛоТА». / Компьютерная лингвистика и интеллектуальные технологии: Труды международной конференции «Диалог 2007». – М.: Изд-во РГГУ. – 2007. – С. 422-427.
  15. Орлова, Ю. А. Автоматизация семантического анализа текста технического задания: дис. … канд. тех. Наук. – Волгоград. – 2008.
  16. Тарасенко, А. В. Разработка и исследование методов и моделей автоматической проверки текстов на соответствие требованиям технической документации: дис. … канд. тех. наук: 05.13.17. – Таганрог. – 2009.
  17. Трубчанинов С. А. Сопоставление требований к системам послеаварийного мониторинга атомных электростанций. // «Радіоелектронні і комп’ютерні системи». – №5, 2013 г. – С. 100-105.
  18. Ahmad, K., Gillam, L., Tostevin, L. University of Surrey Participation in TREC8: Weirdness Indexing for Logical Document Extrapolation and Retrieval WILDER / K. Ahmad, L. Gillam, L. Tostevin // The Eighth Text Retrieval Conference TREC-8. – 1999.
  19. Text Mining Resources: Ontologies[Электронный ресурс] / The National Centre for Text Mining. Электрон. дан., 2012. Режим доступа: http://www.nactem.ac.uk/resources.php?view=5 – Загл. с экрана.

     


Kalachev Y.B, MIEM HSE, Moscow, rusfund@gmail.com

Optimization of time spent on verification of design documentation for the fuel and energy complex

Abstract. The article describes a method for calculating of completeness of report documents in energy industry. The method was designed to reduce labor costs at the stage of acceptance of project documentation. The article provides the results of comparison for various combinations of methods, proposed method, and expert evaluation of report documentation completeness.

Кеуwords: document comparison, document completeness, weirdness, term extraction, technical documentation, report documents, energy industry.


Комментарии отсутствуют

Добавить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-45
E-mail: sa@samag.ru