Недостатки каскадной схемы

Лекция 2

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

Под функциональными подсистемами АСОИУ понимается набор автоматизированных функций управления, объединенных между собой установленным видом деятельности (снабжение, производство, сбыт и т.п.).

В состав обеспечивающих подсистем АСОИУ входят:

– основные обеспечивающие подсистемы;

– вспомогательные обеспечивающие подсистемы.

Основные обеспечивающие подсистемы включают в себя:

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

– математическое обеспечение (алгоритмы и программы). Это совокупность методов, моделей и алгоритмов обработки информации, используемых при функционировании системы. Здесь представлены общесистемное математическое обеспечение и проблемное математическое обеспечение (алгоритмы и программы);

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

Кроме того, дополнительно выделяют в качестве вспомогательных обеспечивающих подсистем:

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

– экономическое обеспечение. Здесь выделены затраты на внедрение проектных решений по АСОИУ, экономическая эффективность, источники экономической эффективности от внедрения проектных решений по АСОИУ;

– методическое обеспечение. В его состав входят принципы создания АСОИУ, методические основы построения АСОИУ, инструментарий проектирования (CASE-средства).

Кроме того, в состав обеспечивающих подсистем АСОИУ входят:

– программное обеспечение. Это совокупность программ на носителях информации с соответствующей документацией.

– правовое обеспечение. Это совокупность правовых норм, регламентирующих правоотношения при функционировании системы и юридический статус её результатов (работы системы). В состав правового обеспечения АСОИУ входят нормативные документы, определяющие правовой статус АСОИУ, персонала АСОИУ, правил функционирования АСОИУ и нормативы на автоматически формируемые документы, в том числе на машинных носителях информации. Правовое обеспечение АСОИУ в составе функционирующей системы реализуется в виде документов организационного обеспечения АСОИУ.

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

– метрологическое обеспечение. Это совокупность способов, обеспечивающих выполнение требований к точности измерения параметров и к метрологическим характеристикам измерительных каналов системы.

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

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

Так, к примеру, для машиностроительного предприятия можно выделить такие функциональные подсистемы:

– конструкторская подготовка производства;

– технологическая подготовка производства;

– управление материально-техническим снабжением;

– управление кадрами;

– АСУ технологическими процессами и т. д.

Под функциональными задачами понимаются те задачи, для решения которых создается АСОИУ. Они различны для различных видов АСУ. Характерными признаками функциональной задачи являются:

– полное раскрытие функции в замкнутом контуре управления бизнес-процессом (планирование, учет и отчетность, анализ, регулирование);

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

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

– получение по детальной спецификации расхода материалов на изделие;

– расчет среднего снижения норм расхода материалов;

– оперативный учет загрузки станков (в том числе с ЧПУ).

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

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

Принципы разработки многопользовательских АИС / АСУ. Очевидно, что разрабатываемые на предприятиях АИС должны быть многопользовательскими. Принципы их разработки заключаются в соблюдении двух обязательных условий: системный подход и стандартизация.

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

– учитывать интересы всех потенциальных пользователей систем;

– контролировать обеспечение целостности информации.

Пример. Учет интересов всех пользователей информационной системы (требование, направленное на уменьшение затрат при разработке и эксплуатации информационной системы).

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

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

Пример. Обеспечение целостности информации.

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

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

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

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

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

Жизненный цикл АСОИУ – совокупность взаимосвязанных процессов создания и последовательного изменения состояния АСОИУ, от формирования исходных требований к ней до окончания эксплуатации и утилизации комплекса средств автоматизации АСОИУ.

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

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

Методология проектирования информационных систем описывает процесс создания и сопровождения систем в виде жизненного цикла (ЖЦ) АС, представляя его как некоторую последовательность стадий и выполняемых на них процессов. Для каждой стадии определяются:

· состав и последовательность выполняемых работ,

· получаемые результаты,

· методы и средства, необходимые для выполнения работ,

· роли и ответственность участников и т.д.

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

Модель жизненного цикла – это структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач на протяжении ЖЦ. Наибольшее распространение получили каскадная, а затем спиральная модели. Можно условно выделить следующие основные этапы жизненного цикла АСОИУ:

– анализ – определение того, что должна делать система. Стадию анализа требований называют также предпроектной стадией или стадией системного анализа предметной области.

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

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

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

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

На стадии проектирования компания решает, как удовлетворить свои потребности. Первая задача – определить и оценить возможные альтернативы. Если одна из альтернатив принята руководством для разработки, то формируется план разработки АС, содержащий следующие ключевые элементы:

· определение масштаба проекта, в рамках которого анализируются основные функции и взаимодействие с внешними системами;

· детализированная формулировка проблем;

· уточнение необходимых процессов обработки информации и ограничений;

· ресурсное обеспечение разработки: люди, время, финансовые средства для разработки и функционирования АС;

· график выполнения различных этапов проекта.

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

– разработка – создание функциональных компонентов и подсистем по отдельности, соединение подсистем в единое целое;

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

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

– тестирование – проверка функционального и параметрического соответствия системы показателям, определенным на этапе анализа;

– внедрение – установка и ввод системы в действие;

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

– сопровождение – обеспечение штатного процесса эксплуатации системы на предприятии заказчика.

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

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

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

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

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

Данная модель предполагает строго последовательное (во времени) и однократное выполнение всех фаз проекта с жестким (детальным) предварительным планированием в контексте предопределенных или однажды и целиком определенных требований к программной системе. Каскадная модель разбивает процесс ЖЦ на пять этапов, выполняемых последовательно, один за другим.

Положительные стороны применения каскадного подхода заключаются в следующем:

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

· этапы работ выполняются в логичной последовательности;

· возможно жестко планирование сроков завершения работ и соответствующих затрат.

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

Недостатки каскадной схемы

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

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

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

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

Каскадная схема порождает системы, обладающие следующими недостатками:

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

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

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

Поэтапная модель с промежуточным контролем. Поэтапная модель с промежуточным контролем (80-85 гг.) - итерационная модель разработки АЭИС с циклами обратной связи между этапами. Преимущество такой модели заключается в том, что межэтапные корректировки обеспечивают меньшую трудоемкость по сравнению с каскадной моделью; однако время жизни каждого из этапов растягивается на весь период разработки.

Спиральная модель. Спиральная модель была впервые сформулирована Барри Боэмом (Barry Boehm) в 1988 году. Делает упор на начальные этапы ЖЦ – анализ и проектирование. Реализуемость технических решений проверяется на этих этапах путем создания прототипов.

Спиральная модель жизненного цикла ПО

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

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

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

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

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

В основе спиральной модели жизненного цикла лежит применение прототипной технологии или RAD – технологии (rapid application development – технологии быстрой разработки приложений). (J. Martin. Rapid Application Development. New York: Macmillan, 1991). Согласно этой технологии ЭИС разрабатывается путем расширения программных прототипов, повторяя путь от детализации требований к детализации программного кода.

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

го репозитория и использованию CASE-технологий.

Основные недостатки спиральной модели:

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

2) Зачастую не уделяется достаточного внимания разработке документации по системе.

Специалистами отмечаются следующие преимущества спиральной модели:

· накопление и повторное использование программных средств, моделей и прототипов;

· ориентация на развитие и модификацию системы в процессе ее проектирования;

· анализ риска и издержек в процессе проектирования.

Именно поэтому спиральная модель служит в настоящее время основой для создания методологий проектирования систем.

Особенности отдельных классов АСОИУ.Информационно-поисковая система (ИПС) – это система, обеспечивающая поиск и отбор необходимых данных в специальной базе с описаниями источников информации (индексе) на основе информационно-поискового языка и соответствующих правил поиска.

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

Релевантность – это соответствие результатов поиска сформулированному запросу.

Примерами информационно-справочных и информационно-поисковых систем являются: СПС “Консультант плюс”, “Гарант”, “Кодекс”, “Абитуриент” и многие другие.

Конечные пользователи информационно-поисковых систем, как правило, имеют доступ к хранимым данным только "по чтению" и используют данные системы для поиска ответов на те или иные вопросы. Доступ по модификации данных имеет администратор системы, в функции которого входит обеспечение актуальности информации, устранение ошибок. Классические примеры ИПС – системы поиска в библиотеках, на транспорте (справки о наличии билетов). На современном этапе развития информационных технологий классические ИПС постепенно вытесняются поисковыми серверами интернет – общего назначения и специализированными.

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

Автоматизированная система контроля исполнения директивных документов (АСКИ) может быть как многоуровневой системой (в разрезе всего предприятия), так и одноуровневой системой (в разрезе одного структурного подразделения).

АСКИ создается, как правило, отдельно для топ–менеджеров для контроля за исполнением их директивных документов (приказов, распоряжений, мероприятий, протоколов оперативных совещаний), а также с использованием АСКИ ставятся на контроль директивные документы вышестоящих организаций и документы партнеров по бизнесу. В принципе на контроль ставят все, что топ–менеджер считает нужным проконтролировать. Для этого топ менеджер на документе, выполнение которого он желаем проконтролировать, ставит пометку “на контроль”. Выходными документами АСКИ являются:

– сведения по всем исполнителям по всем, поставленным на контроль документам;

– сведения по всем исполнителям по выполнению одного или нескольких документов;

– сведения по одному исполнителю по всем поставленным на контроль документам;

– сведения по исполнительной дисциплине.

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

Системы поддержки принятия решений (DSS – Decision Support Systems) предназначены для помощи в подготовке принятия решения. Обычно такая система имеет три основных составляющих: базу данных, базу моделей и модуль взаимодействия. База данных содержит данные, предназначенные для принятия решения. База моделей содержит некоторое количество моделей, которые могут использоваться для анализа ситуации принятия решения. Модуль диалога обеспечивает взаимодействие в процессе принятия решения конечного пользователя. DSS позволяет менеджеру проверять или предлагать различные решения, а также изучать результаты принятия решений с использованием различных моделей.

Экспертные системы – это прикладные системы, в которых база знаний представляет собой формализованные эмпирические знания высококвалифицированных специалистов (экспертов) в какой либо узкой предметной области. Экспертные системы предназначены для замены при решении задач экспертов в силу их недостаточного количества, недостаточной оперативности в решении задачи или в опасных (вредных) для них условиях.

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

Экспертные системы (ES – Expert Systems) предназначены для представления и манипулирования знаниями. Знание – это приобретенное через опыт глубокое и всестороннее обучение. Экспертные системы основаны на принципах исследования искусственного интеллекта. Обычно пользователи общаются с ES посредством диалога, в течение которого ES задает вопросы, а пользователь дает ответы, которые используются для выбора применяемого правила. Данная процедура заканчивается рекомендацией, основанной на использовании правил.

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

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

Методология создания АСОИУ.Цель методологии создания АСОИУ заключается в организации процесса построения автоматизированной системы и обеспечении управления этим процессом для того, чтобы гарантировать выполнение требований как к самой АСОИУ, так и к характеристикам процесса разработки. Основными задачами, решение которые должна обеспечивать методология создания АСОИУ (вместе с соответствующим набором инструментальных средств) являются следующие задачи:

– обеспечивать создание АСОИУ, отвечающих предъявляемым к ним требованиям по автоматизации деловых процессов и отвечающих целям и задачам предприятия;

– гарантировать создание системы с заданным качеством в заданные сроки и в рамках бюджета;

– поддерживать удобную дисциплину сопровождения, модификации и наращивания системы, чтобы АСОИУ могла отвечать быстро изменяющимся требованиям работы предприятия;

– обеспечивать создание АСОИУ, отвечающих требованиям открытости, переносимости и масштабируемости;

– обеспечивать использование в разрабатываемой АСОИУ задела в области информационных технологий, существующего на предприятии (программного обеспечения, баз данных, средств вычислительной техники, телекоммуникаций, технологий).

Современная методология создания АСОИУ состоит из двух основных взаимосвязанных частей:

– методологии анализа АСОИУ, включающей описание деятельности организации и формирование требований к АСОИУ на основе бизнес-процессов;

– методологии проектирования от данных, предназначенной для проектирования и быстрой разработки программного и информационного обеспечения АСОИУ.

Методология должна обеспечивать снижение сложности процесса создания АСОИУ за счет полного и точного описания этого процесса и применения современных методов и технологий создания АСОИУ на всем жизненном цикле АСОИУ – от замысла до реализации. Заложенные в методологию и поддержанные инструментальными средствами принципы, должны упрощать разработку и обеспечивать возможность быстрого внесения изменений как на стадиях создания АСОИУ, так и на стадиях сопровождения и развития.

Сегодня широкое распространение получила методология, основанная на итерационной спиральной модели жизненного цикла АСОИУ. Принципиальной особенностью этой методологии является то, что охватывая все этапы жизненного цикла (ЖЦ) АСОИУ, она делает основной упор на поддержку начальных этапов создания АСОИУ, главной задачей которых является формирование требований к АСОИУ, точно отвечающих целям и задачам предприятия.

В рамках этой методологии предполагается построение системы моделей, которые могут использоваться для трех целей:

1) построенные модели могут быть использованы для формирования требований к АСОИУ;

2) система моделей может быть использована для анализа деятельности предприятия с целью ее улучшения, путем проведения инжиниринга или реинжиниринга предприятия в зависимости от результатов анализа;

3) на основании анализа построенных систем моделей, а также функционирующей на предприятии АСОИУ, формируется стратегический план создания, развертывания, сопровождения и развития информационной системы (IT-стратегия предприятия).

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