CC BY
29
данных: дата и время создания фотографии партии деревьев, фотография партии деревьев, уникальный идентификатор партии, изображение каждой области (отдельные деревья), уникальный идентификатор
для каждого дерева, преобразованное в декартовы координаты изображение дерева, ключ данного дерева (результат БПФ).
Статья поступила 25.05.2015 г.
Библиографический список
1. Введение в контурный анализ; приложения к ражений. М.: Техносфера, 2005. 1072 с. обработке изображений и сигналов / Я.А. Фурман 3. Sobel I. An isotropic 3x3 image gradient operator // [и др.]. 2-е изд., испр. М.: Физматлит, 2003. 592 с. Machine Vision for Three-Dimensional Scenes. San
2. Гонсалес Р., Вудс Р. Цифровая обработка изоб- Diego: Academic Press, 1990. P. 376-379.
УДК 004.414.22
ОТРАЖЕНИЕ ТРЕБОВАНИЙ ПОЛЬЗОВАТЕЛЯ В СОВРЕМЕННЫХ СТАНДАРТАХ ПРОЕКТИРОВАНИЯ АВТОМАТИЗИРОВАННЫХ ИНФОРМАЦИОННЫХ СИСТЕМ
© А.П. Петров1
Иркутский национальный исследовательский технический университет, 664074, Россия, г. Иркутск, ул. Лермонтова, 83.
Появление автоматизированных систем повлекло за собой потребность в формулировании требований к их разработке. С течением времени по мере развития систем менялись и требования к ним. Однако до настоящего момента не выработано формальных способов их корректного формулирования, что приводит к проблемам при проектировании и последующей эксплуатации систем. В статье кратко рассмотрены вопросы отражения требований к информационным системам, сформулированных как в ГОСТ советского периода, так и в аналогичного рода документах на современном этапе.
Ключевые слова: стандарты создания автоматизированных систем; стадии создания автоматизированных систем; требования к информационным системам
USER'S REQUIREMENT REFLECTION IN MODERN DESIGN STANDARDS OF AUTOMATED INFORMATION SYSTEMS A.P. Petrov
Irkutsk National Research Technical University, 83 Lermontov St., Irkutsk, 664074, Russia.
Emergence of automated systems has caused the need to formulate the requirements for their development. Over time, the requirements for the systems have changed with their development. However, there is still no formal methods of their correct formulation that causes problems in design and subsequent operation of systems. The article summarizes the issues dealing with the requirements to information systems formulated both in the Soviet period standards and contemporary similar documents.
Keywords: automated system development standards; stages of automated system creation; requirements for information systems.
Внедрение автоматизированных систем управления для предприятий в России началось с 60-х гг. ХХ века. Создавались такого типа системы при ориентации на те вычислительные возможности ЭВМ, которыми они обладали в те годы.
На заре внедрения ЭВМ все предприятия в нашей стране разрабатывали системы управления исключительно под внутренние нужды, а поддержанием их ра-
ботоспособности и функциональным дополнением занимались штатные отделы АСУ, которые имелись на каждом из них. Объяснялось это тем, что производство вычислительной техники относилось фактически к крупносерийному производству, стоимость одной ЭВМ была довольно высока, и предприятие не могло позволить себе, за редким исключением, иметь больше одной вычислительной машины. Кроме
1
Петров Александр Павлович, аспирант кафедры автоматизированных систем, тел.: 89149327011, e-mail: appetroff@yandex.ru
Petrov Alexander, Postgraduate of the Department of Automated Systems, tel.: 89149327011, e-mail: appetroff@yandex.ru
того, потребности предприятия в вычислительных ресурсах вполне удовлетворялись использованием одной ЭВМ. Отсутствовали также специализированные проектные организации, которые бы предлагали типовые тиражируемые решения для программного обеспечения по решению текущих задач. Хотя при некоторых министерствах и ведомствах существовали подразделения, решавшие отдельные задачи такого характера.
Например, таким образом создавались АСУП для ряда предприятий электротехнической промышленности, которые, тем не менее, дорабатывались с учетом специфики деятельности конкретных предприятий.
Подобного рода неупорядоченность нашла отражение в том, что вплоть до середины 80-х гг. не было выработано какого-либо стандарта на разработку информационных систем, поскольку в нем не было большой необходимости. Соответственно, отсутствовали исследования подходов к формулированию требований в комплексном виде.
Однако с течением времени к середине 80-х гг. ХХ в. произошли серьезные изменения в аппаратной платформе ЭВМ, и был накоплен определенный опыт в программировании автоматизированных управленческих задач.
Изменившееся состояние дел послужило основанием для появления документа, в котором был бы описан общий порядок разработки автоматизированных систем (АС). Причем здесь имелись в виду не только системы управления, а любые системы, в которых для решения задач использовались ЭВМ. И таким документом стал ГОСТ 24.601-86, а позднее его «преемник» - ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания» [1]. В нем впервые были отражены основные этапы создания автоматизированной системы:
1. Формирование требований к АС.
2. Разработка концепции АС.
3. Техническое задание.
4. Эскизный проект.
5. Технический проект.
6. Рабочая документация.
7. Ввод в действие.
8. Сопровождение АС.
Данный документ описывает последовательность стадий разработки АС с разбиением каждой стадии на этапы. Большое внимание уделено этапам согласования и отчетной работы по завершению каждого этапа. Таким образом, переход от одной фазы разработки к другой был возможен только после полного и успешного завершения предыдущего этапа, т.е. данный стандарт отражает каскадную модель проектирования АС. Впоследствии на базе данной модели появились такие модели, как итерационная и спиральная.
Поскольку изначально любая автоматизированная система управления предприятием (АСУП), по сути, является прикладной, то требования ее будущих пользователей в отношении реализуемых алгоритмов, соответствующей информационной базы, а также форм хранения и представления исходной и результирующей информации являются ключевыми. И жесткие ограничения на последовательность разработки не предполагают изменений в процессе выполнения проекта. Поэтому пользователь вынужден сформировать свои требования только один раз перед началом проекта. Это объяснялось тем, что специфика организации информационной базы в форме взаимосвязанных файлов с однажды закрепленной структурой записи в каждом из них не была рассчитана на какие-либо изменения, возникающие в связи с новыми или измененными требованиями. Более того, любые изменения подобного рода, если они были критически важными, требовали изменений в структуре записи и, как следствие, обязательного перепрограммирования всех задач, которые были «завязаны» на файлы, в структурах которых изменения производились.
Но основной проблемой стандарта является то, что описание стадий представлено в очень сжатой форме, рекомендации и пояснения к каждому этапу не приводятся. Структура стандарта состоит из 4
разделов:
1. Общие положения.
2. Стадии и этапы создания, где идет указание на соответствие между стадиями и этапами работ.
3. Содержание работ, где тезисно расшифровывается содержание вышеперечисленных этапов работ.
4. Перечень организаций, участвующих в работах по созданию АС.
По сути, данный документ является лишь некой «памяткой», которая направлена на то, чтобы разработчик не «сбился с пути».
Также обращает на себя внимание наличие таких этапов, как п. 7.4. «Строительно-монтажные работы», п. 7.5. «Пуско-наладочные работы», которые представляются с точки зрения современных компьютерных технологий некоторым анахронизмом, но четверть века назад являлись непреложными. В настоящее время либо объем подобных работ ничтожно мал, либо их содержание совершенно отличается от того, которое предусматривалось 20 лет назад.
Кроме того, некоторые понятия, такие как, например, «тактико-техническое задание» или «проведение научно-исследовательских работ» вышли в настоящее время из употребления при формировании требований к АС и разработке ее концепции.
После принятия данного стандарта развитие вычислительной техники и программных средств (ERP-систем, в частности) не остановилось и приобрело новые черты:
1. Повсеместное внедрение персональных компьютеров. Теперь работник «не оторван» от прямого контакта с информационной системой (ИС), в каком бы качестве она ни была представлена в рамках его автоматизированного рабочего места. Более того, отныне доступ к информационной системе может осуществляться удаленно, а персональные компьютеры стали выполнять роль рабочих станций.
2. Появление рынка программных продуктов разработчиков систем, предна-
значенных для автоматизации управления предприятиями (например, «1С», SAP, «Галактика» и др.), которые предлагают тиражные, «коробочные» решения для разных отраслей предпринимательской деятельности.
3. Подразделения предприятий, которые ранее занимались разработкой автоматизированных управленческих систем, принципиально изменили свою деятельность. А на некоторых предприятиях либо существенно сокращено количество работающего в них персонала, либо вообще прекращена деятельность. При этом соответствующая совокупность функций по обслуживанию вычислительной инфраструктуры делегирована специализированным организациям, т.е. передана на аутсорсинг. Например, в компании «1С» действует широкая сеть франчайзи, которые выполняют различного рода работы как по информационно-технологическому сопровождению программных продуктов «1С», так и по выпуску отраслевых решений («1С-Рарус», «1С:ВДГБ» и др.).
4. На фоне перечисленных выше пунктов появилась такая область деятельности, как управление проектами.
Данные особенности потребовали выработки нового стандарта, который бы учел изменившиеся реалии. Новым стандартом стал ГОСТ Р ИСО/МЭК 12207-99 и его развитие в виде стандарта ГОСТ Р ИСО/МЭК 15288-2005 [2], который является более расширенным и дополненным. Данный документ можно считать адаптацией мирового регламента, и называется он «Процессы жизненного цикла систем». Новый ГОСТ является достаточно объемным (60 страниц), и процессы в нем разбиваются на следующие группы:
1. Процессы соглашения. При выполнении данной группы процессов определяются шаги, необходимые для достижения согласия между двумя организациями, участвующими в создании системы.
2. Процессы предприятия. Данная группа процессов обеспечивает ресурсы и инфраструктуру, необходимые для осуществления проектов и исполнения обяза-
тельств по соглашениям.
3. Процессы проекта. Данная группа процессов используется для установления соответствия намеченных планов ходу их фактического выполнения, вплоть до завершения проекта.
4. Технические процессы. Данная группа процессов позволяет определить требования к системе, преобразовать их в эффективный продукт, позволяющий осуществить при потребности его устойчивое воспроизводство и использование для обеспечения требуемых услуг.
Последний пункт стандарта, а именно группа «Технические процессы», фактически представляет собой аналогию прежнего ГОСТ, потому на ней остановимся более подробно.
В новом документе введено понятие «процесс», а сами процессы составляют следующую последовательность:
1. Процесс определения требований правообладателей, т.е., по существу, будущих потенциальных пользователей проектируемой системы. При осуществлении данного процесса производится анализ и систематизация требований правообладателей, описание ожидаемого поведения системы.
2. Процесс анализа требований. При выполнении данного процесса создается образ будущей системы, которая сможет осуществить сформулированные ранее потребности правообладателей. В ходе выполнения данного процесса задаются такие системные требования, которые как измеримы, так и способны удовлетворить требования правообладателей.
3. Процесс проектирования архитектуры. В рамках данного процесса исследуется некоторое количество путей реализации системы с такой степенью детализации, которая соответствует требованиям и рискам. Сформированные по результатам процесса требования становятся основой для проведения верификации разработанной ИС, а также для разработки методик комплексирования.
4. Процесс реализации элементов системы. При выполнении данного процес-
са производится создание элементов системы в соответствии с заданными ограничениями разного рода (поведенческими, интерфейсными, производственными и т.д.). Вновь созданный элемент должен удовлетворять как архитектурным решениям (проверяется при верификации), так и требованиям правообладателей (проверяется при валидации).
5. Процесс комплексирования. При выполнении данного процесса производится сборка ранее созданных программных элементов системы, согласно разработанной архитектуре.
6. Процесс верификации. Данный процесс связан с подтверждением того, что требования проекта полностью реализованы в системе. Полученная в ходе процесса информация позволяет корректировать обнаруженные несоответствия.
7. Процесс передачи. В ходе данного процесса производится приведение в рабочее состояние верифицированной системы. Кроме того, производится настройка сопроводительных систем, таких как, например, операционная система, система обучения операторов, система обучения пользователей и т.д.
8. Процесс валидации. При осуществлении данного процесса производится сравнительный анализ, направленный на получение объективных доказательств того, что функции, обеспечиваемые разработанной системой при ее использовании, соответствуют заявленным требованиям правообладателей. Обнаруженные недочеты фиксируются и устраняются. Результат данного процесса утверждается правообладателем.
9. Процесс функционирования. При выполнении данного процесса разработанная система используется для выполнения заданных функций. Определяется персонал для работы с системой, выявляются и анализируются проблемы функционирования.
10. Процесс технического обслуживания. В ходе данного процесса производится поддержание способности системы выполнять заданные функции, обнаружен-
ные проблемы фиксируются, анализируются и устраняются.
11. Процесс изъятия и списания. При осуществлении этого процесса происходит демонтаж и удаление системы.
Интересно отметить, что для каждого процесса определены цели и задачи, а также приведено описание соответствующей деятельности.
В новом документе декларируется подход, согласно которому процессы жизненного цикла организация должна осуществлять избирательно ради достижения необходимых целей и результатов на конкретной стадии. Кроме того, любой процесс может выполняться одновременно с любыми другими процессами жизненного цикла, имеющими непосредственную логическую связь. Это позволяет комбинировать процессы в зависимости от специфики конкретного проекта, т.е. назначения создаваемой системы и ее функционального наполнения. Анализируемый регламент предоставляет возможность проектировщикам варьировать совокупность необходимых процессов. При этом принципиальное содержание процессов задано.
Таким образом, в анализируемом стандарте выражается новая идея, которая заключается в том, что жесткая последовательность этапов разработки, которая являлась обязательной для предыдущего варианта ГОСТ, теперь более не актуальна, а сам порядок действий может варьироваться в зависимости от конкретного проекта. Поэтому данный стандарт в настоящее время не является проявлением каскадной методологии разработки и приобретает черты итеративности.
Между этапами и процессами прежнего и текущего стандартов можно провести определенные параллели. В новом стандарте введен ряд новых понятий. Например, вместо термина «заказчик» введен термин «правообладатель», вместо этапов и стадий работ введено понятие процесса. Некоторые этапы, однако, претерпели значительные изменения. Например, описание стадий и этапов создания АС в прежнем ГОСТ завершается приемкой
АС в промышленную эксплуатацию. И данная стадия находит развитие в новом стандарте, где указывается, что любое использование ИС является конечным, и после периода эксплуатации неизбежно следует процесс ее (системы) изъятия и списания. Кроме того, старый и новый стандарты расходятся в части эскизного и технического проектирования. Если ранее подразумевалось комплексное проектирование системы как на стадии создания эскиза проекта, так и на стадии технического проектирования, то согласно новому стандарту вначале осуществляется процесс реализации элементов системы, а за ним - процесс комплексирования, т.е. сборки разработанных элементов системы воедино.
Итак, можно заключить, что функциональные требования к информационным системам на данный момент отвечают текущим реалиям. Однако сами по себе стандарты остаются, скорее, набором ориентиров, позволяющих разработчикам придерживаться вектора проектирования, но практическим рекомендациям оба документа по разным причинам мало соответствуют. Если предыдущий ГОСТ был просто своего рода блок-схемой, то новый стандарт, несмотря на большую развернутость формулировок, является весьма абстрактным, что усложняет работу с ним.
Краткий анализ ранее существовавших и современных стандартов, предназначенных для регламентации проектных работ в процессе создания АС, показал, что ни один из них не содержит конкретных рекомендаций по формулированию требований потенциальных пользователей к будущим системам. Это, безусловно, негативно сказывается на качестве выполняемых проектов, а также на увеличении сроков их реализации и стоимости.
Поэтому необходимо наличие некоторого унифицированного (хотя бы в отношении определенного класса задач) подхода, позволяющего внести элементы формализации в формулирование требований к АС.
Статья поступила 25.05.2015 г.
Библиографический список
1. ГОСТ 34.601-90 Автоматизированные системы. 2. ГОСТ Р ИСО/МЭК 15288-2005. Информацион-
Стадии создания [Электронный ресурс]. URL: ная технология. Системная инженерия. Процессы
http://ockc.ru/wp-content/standart/34-601-90.pdf жизненного цикла систем. [Электронный ресурс].
(18.03.2015). URL: http://www.novsu.ru/file/977849 (18.03.2015).
УДК 004.891
УПРАВЛЕНИЕ РАЗРЕШЕНИЕМ КОНФЛИКТОВ В ПРОДУКЦИОННЫХ ЭКСПЕРТНЫХ СИСТЕМАХ
Л
© Д.П. Проскуряков1
Иркутский национальный исследовательский технический университет, 664074, Россия, г. Иркутск, ул. Лермонтова, 83.
Рассмотрены особенности управления выводом в продукционных базах знаний экспертных систем и их взаимосвязь с возможностью возникновения смысловых ошибок. Представлен подход к разрешению конфликтов, основанный на использовании описаний ситуаций, возникающих в процессе вывода. Рассмотрено применение средств рассуждения по прецедентам к представлению и обработке описаний ситуаций. Предложенный подход направлен на упрощение интеграции знаний, добавляемых в экспертную систему, и позволит облегчить организацию управления выводом в постоянно увеличивающейся базе знаний.
Ключевые слова: экспертные системы; стратегии управления продукциями; онтологии; рассуждения по прецедентам; динамическая память; конструкционная адаптация.
CONFLICT RESOLUTION MANAGEMENT IN RULE-BASED EXPERT SYSTEMS D.P. Proskuriakov
Irkutsk National Research Technical University, 83 Lermontov St., Irkutsk, 664074, Russia.
The paper describes the features of inference control in rule-based knowledge bases of expert systems and their relationship with the possibility of semantic error emergence. An approach to conflict resolution management based on the use of the descriptions of situations occurred in the inference process is presented. The application of case-based reasoning to representation and processing of situation description is considered. The proposed approach is aimed at simplifying the integration of the knowledge being added to the expert system. It will facilitate inference control in ever-expanding knowledge base.
Keywords: expert systems; product control strategies; ontologies; case-based reasoning; dynamic memory; constructive adaptation.
Важным этапом разработки экспертной системы (ЭС) является верификация -процесс доказательства того, что база знаний (БЗ) экспертной системы не содержит внутренних ошибок, таких как избыточность, противоречивость и неполнота [11]. Главной задачей верификации продукционной БЗ является выявление аномалий, а именно противоречивых или избыточных правил, циклов и т. п. Основываясь на полученной в результате анализа информации, в базу вносятся изменения, необходимые для организации корректного вывода.
Одним из ключевых элементов верификации продукционной БЗ является выявление ошибок в цепочках вывода. С уве-
личением размеров БЗ возрастает число ветвлений и взаимосвязей между цепочками вывода, и их анализ становится достаточно сложной задачей [2]. Кроме того, даже если в результате выполнения верификации в БЗ отсутствуют аномалии, вывод в такой базе все же может давать неверные результаты [1]. Причина этого состоит в наличии смысловых ошибок, характерных для конкретной предметной области (ПО). В свою очередь, возникновение таких смысловых ошибок в процессе вывода является следствием того, что машина вывода и стратегии управления продукциями (за исключением, до некоторой степени, метапродукций) выполняют действия над пра-
1
Проскуряков Дмитрий Павлович, аспирант, тел.: 89149150998, e-mail: dpprosk@gmail.com Proskuriakov Dmitry, Postgraduate, tel.: 89149150998, e-mail: dpprosk@gmail.com
