Ответы на вопросы по информационным системам в экономике - файл n1.docx

приобрести
Ответы на вопросы по информационным системам в экономике
скачать (145 kb.)
Доступные файлы (1):
n1.docx146kb.14.09.2012 15:46скачать

n1.docx

  1   2   3   4
Понятие информации. Основные свойства информации

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

Понятие «информация» используется в различных науках, при этом в каждой науке понятие «информация»связано с различными системами понятий. Информация в биологии: Биология изучает живую природу и понятие «информация» связывается с целесообразным поведением живых организмов. В живых организмах информация передается и храниться с помощью объектов различной физической природы (состояние ДНК), которые рассматриваются как знаки биологических алфавитов. Генетическая информация передается по наследству и хранится во всех клетках живых организмов. Филосовский подход: Информация – это взаимодействие, отражение, познание. Кибернетический подход: Информация – это характеристики управляющего сигнала, передаваемого по линии связи

На свойства информации влияют как свойства данных, так и свойства методов её обработки.

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

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

  3. Адекватность информации. Это степень её соответствия реальному состоянию дел. Неадекватная информация может образовываться при создании новой информации на основе неполных или недостоверных данных. Однако полные и достоверные данные могут приводить к созданию неадекватной информации в случае применения к ним неадекватных методов.

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

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

Предмет и задача курса «Информационные технологии управления».

Задачи курса:

Цель изучения дисциплины:

Понятие информационной технологии управления

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

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

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

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

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

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

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

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

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

Основные этапы эволюции информационных технологий управления

Эволюция информационных технологий наиболее ярко прослеживается на процессах хранения, транспортирования и обработки информации.

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

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

Первое поколение (1900-1955) связано с технологией перфокарт, когда запись данных представлялась на них в виде двоичных структур. Процветание компании IBM в период 1915-1960 гг. связано с производством электромеханического оборудования для записи данных на карты, сортировки и составления таблиц. Громоздкость оборудования, необходимость хранения громадного количества перфокарт предопределили появление новой технологии, которая должна была вытеснить электромеханические компьютеры.

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

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

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

Третье поколение (оперативные базы данных, 1965-1980 гг.) связано с внедрением оперативного доступа к данным в интерактивном режиме, основанном на использовании систем баз данных с оперативными транзакциями.

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

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

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

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

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

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

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

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

Четвертое поколение (реляционные базы данных: архитектура «клиент - сервер», 1980-1995 гг.) явилось альтернативой низкоуровневому интерфейсу. Идея реляционной модели состоит в единообразном представлении сущности и связи. Реляционная модель данных обладает унифицированным языком для определения данных, навигации по данным и манипулирования данными. Работы в этом направлении породили язык, названный SQL, принятый в качестве стандарта.

Сегодня почти все системы баз данных обеспечивают интерфейс SQL. Кроме того, во всех системах поддерживаются собственные расширения, выходящие за рамки этого стандарта.

Кроме повышения продуктивности и простоты использования реляционная модель обладает некоторыми неожиданными преимуществами. Она оказалась хорошо пригодной к использованию в архитектуре «клиент-сервер», параллельной обработке и графических пользовательских интерфейсах. Приложение «клиент-сервер» разбивается на две части. Клиентская часть отвечает за поддержку ввода и представление выходных данных для пользователя или клиентского устройства. Сервер отвечает за хранение базы данных, обработку клиентских запросов к базе данных, возврат клиенту общего ответа. Реляционный интерфейс особенно удобен для использования в архитектуре «клиент-сервер», поскольку приводит к обмену высокоуровневыми запросами и ответами. Высокоуровневый интерфейс SQL минимизирует коммуникации между клиентом и сервером. Сегодня многие клиент-серверные средства строятся на основе протокола Open Database Connectivity (ODBC), который обеспечивает для клиента стандартный механизм запросов высокого уровня к серверу. Архитектура «клиент-сервер» продолжает развиваться. Имеется возрастающая тенденция интеграции процедур в серверах баз данных. В частности, такие процедурные языки, как BASIC и Java, были добавлены к серверам, чтобы клиенты могли вызывать прикладные процедуры, выполняемые на них.

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

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

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

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

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

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

Чтобы приблизиться к современному состоянию технологии управления данными, имеет смысл описать два крупных проекта, в которых используются предельные возможности сегодняшней технологии. Система Earth Observation System/Data Information System (EOS/DIS) разрабатывается агентством NASA и его подрядчиками для хранения всех данных, которые начали поступать со спутников серии «Миссия к планете Земля» с 1977 г. Объем базы данных, включающей данные от удаленных сенсорных датчиков, будет расти на 5 ТбаЙт в день (1 Тбайт - 106 Гбайт). К 2007 г. размер базы данных вырастет до 15 Пбайт. Это в 1000 раз больше объема самых больших современных оперативных баз данных. NASA желает, чтобы эта база данных была доступна каждому в любом месте и в любое время. Любой человек сможет осуществлять поиск, анализ и визуализацию данных из этой базы. Потребуются наиболее развитые методы хранения, поиска и визуализации данных. Большая часть данных будет обладать пространственными и временными характеристиками, так что для системы потребуются существенное развитие технологии хранения данных этих типов, а также библиотеки классов для различных научных наборов данных. Например, для этого приложения потребуется библиотека для определения снежного покрова, каталога растительных форм, анализа облачности и других физических свойств образов.

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

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

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

масштабирование баз данных по размеру (до петабайт), пространственному размещению (распределенные) и многообразию (неоднородные);

автоматическое обнаружение тенденций данных, структур и аномалий (поиск, анализ данных);

интеграция (комбинирование) данных из нескольких источников;

создание сценариев и управление потоком работ (процессом) и данными в организациях;

автоматизация проектирования и администрирования базами данных.
Понятие программного продукта. Фазы жизненного цикла программного продукта
Система качества представляет собой организационный стержень для компании, которая вынуждена тщательно продумывать и документально оформлять, а затем контролировать каждый этап проектирования программного продукта и его результаты. Для этого нужен специально обученный персонал и особые методы управления качеством. Эти методы варьируются от компании к компании, но основные их положения едины для всех и определяются стандартом. В конечном итоге система качества позволяет создать оптимальные условия для продуктивного труда специалистов, поскольку берет на себя все формальные и рутинные, но абсолютно необходимые операции. Она позволяет перейти от кустарного уровня сотворения замечательных программ "на коленке" к научно организованному массовому производству программного продукта .
ISO 9000-3 - система качества для ПО Стандарт ISO 9000-3 включает в себя все положения общего стандарта ISO 9001, а также необходимые дополнения к ним, относящиеся к разработке, поставке и обслуживанию ПО. ISO 9001 устанавливает требования к системе качества поставщика и позволяет оценивать его возможности по проектированию и поставке продукции, соответствующей этим требованиям.
Требования стандарта направлены в первую очередь на то, чтобы удовлетворить запросы пользователя, предупредив появление каких-либо несоответствий продукции на всех стадиях ее жизненного цикла - от проектирования до обслуживания. Стандарт определяет ряд важных понятий , которые затем используются в положениях стандарта, в том числе:
продукт - результат действий или процессов; программный продукт - набор компьютерных программ, процедур и, возможно, связанных с ними документов и данных;
элемент программного обеспечения (software item) - любая идентифицируемая часть программного продукта ; основание (baseline) - формально утвержденная версия элемента
конфигурации, зафиксированная в определенный момент времени в процессе жизненного цикла элемента конфигурации; разработка (development) - процесс жизненного цикла программного продукта , охватывающий анализ требований, проектирование, кодирование,
интеграцию, тестирование, установку и поддержку; модель жизненного цикла (life cycle model) - базовая модель, включающая процессы, действия и задачи, вовлеченные в разработку, функционирование и сопровождение программного продукта и хватывающие весь жизненный цикл системы от определения требований до завершения
использования; этап (phase) - определенный сегмент работы; регрессионное тестирование (regression testing) - тестирование, позволяющее убедиться в том, что изменения, внесенные с целью исправления обнаруженных ошибок, не породили новых; репликация (replication) - копирование программного продукта с одного носителя на другой. Важно отметить, что в большинстве пунктов стандарта поставщик обязывается не только определять соответствующие действия, но и оформлять их документально, регистрировать результаты и периодически анализировать, для того чтобы внести необходимые усовершенствования или полностью заменить.
Управление проектированием
Это самый обширный раздел стандарта, поскольку он затрагивает базовую составляющую общего процесса создания продукта , программного продукта в частности, решающим образом влияющую на его качество. Поставщик устанавливает и документирует методики управления и верификации проекта с целью обеспечения выполнения установленных требований. Этот раздел стандарта ISO 9000-3 дает руководящие указания по основным действиям в процессе разработки, таким как анализ требований к проекту, проектирование архитектуры системы, детальное проектирование и кодирование, а также планирование разработки.
Проект разработки программного продукта организуется в соответствии с определенной моделью жизненного цикла. ISO 9000-3 не определяет, какой должна быть модель жизненного цикла, это зависит от специфики решаемой задачи. Стандарт дает лишь общее определение модели жизненного цикла как множества процессов. Модель показывает, когда и как эти процессы подключаются к реализации проекта.
Разработка системы - это процесс преобразования исходных требований в конечный программный продукт . Стандарт оговаривает, что этот процесс должен проводиться в строго определенном порядке. Это позволит предотвратить появление ошибок и снизит зависимость от процессов проверки и утверждения как единственных методов определения проблемных ситуаций. Требование строгой дисциплины процесса разработки подразумевает наличие и поддержку в рабочем состоянии документированных процедур, которые послужат
гарантией того, что программный продукт создается в соответствии с заданными требованиями и планами разработки и обеспечения качества.

Управление проектом должно учитывать такие аспекты, как используемый метод проектирования и его соответствие конкретной задаче, опыт предыдущих проектов, требования последующих процессов: тестирования, установки, сопровождения и использования, наконец, соображения защиты и безопасности. В тех случаях, когда сбои системы могут нанести ущерб людям, собственности или окружающей среде, при проектировании должно быть сформулированы специальные требования, гарантирующие устойчивость системы или ее ответные действия на потенциальные аварийные ситуации. Для процессов кодирования должны задаваться правила использования языков программирования, принципы кодирования и правила составления адекватных комментариев.
Инструментальные средства и методы, используемые в разработке программного продукта , такие, например, как системы анализа и проектирования и компиляторы, должны заранее утверждаться и контролироваться системой конфигурационного управления. Область применения инструментария должна быть задокументирована, а его использование периодически анализироваться, дабы выявить необходимость усовершенствования инструментальных систем или замены на новые продукты.
Проектирование и разработка должны тщательно планироваться. План разработки программного продукта формулирует строго документированные действия по анализу требований к системе, проектированию, кодированию, интеграции, тестированию, установке и поддержке системы. План разработки должен быть проанализирован и утвержден.
План разработки включает также связанные с основным процессом планы обеспечения качества, управления рисками и конфигурацией, планы интеграции, тестирования, установки, обучения сотрудников и др.
Должны быть определены и задокументированы принципы организационно-технического взаимодействия между различными группами, участвующими в разработке. Здесь четко определяются границы ответственности каждого участника разработки и то, каким образом
техническая информация будет передаваться между участниками. Здесь же оговаривается ответственность заказчика проекта, если он принимает участие в разработке: необходимость участвовать в проекте, обязательства по своевременному предоставлению нужной информации. В случае обоюдной договоренности между поставщиком и заказчиком может быть запланирован совместный анализ ведения проект а, регулярно или на определенных его
этапах. Этот анализ затрагивает такие факторы, как ход разработки состороны поставщика, участие в разработке со стороны заказчика, соответствие системы требованиям заказчика, результаты проверок, результаты тестирования.
Входные проектные требования к продукции. Требования формулирует заказчик, а поставщик анализирует, насколько они адекватны. Неполные, двусмысленные или противоречивые требования являются предметом урегулирования с лицами, ответственными за их предъявление. В определенных ситуациях, по обоюдному согласию, спецификацию требований может проводить поставщик.
Выходные проектные данные также оформляются документально, причем таким образом, чтобы их можно было проверить и подтвердить относительно входных проектных требований. Выходные данные проекта программной системы могут включать: спецификацию архитектуры проекта, детальную спецификацию проекта, исходные коды, руководство пользователя. Поставщик программного продукта должен планировать и проводить официальный, документально оформленный анализ результатов проектирования.
Степень формальности и строгости процессов анализа соответствуют сложности разрабатываемой системы и степени риска, связанного с ее использованием. Анализ проектирования затрагивает такие аспекты, как выполнимость проекта, удовлетворение требованиям защиты и безопасности системы, выполнение правил программирования и возможность тестирования. На определенных стадиях проектирования проводится проверка соответствия выходных данных входным требованиям. Такая верификация проекта может
включать анализ выходных данных, демонстрации, в том числе с помощью прототипов и моделирования, или тестирование. Только проверенные выходные проектные данные утверждаются для окончательного приема и последующего использования. Все обнаруженные в процессе проверки проблемные ситуации должны адекватно разрешаться.
Прежде чем система будет передана заказчику, поставщик должен утвердить систему на соответствие заданному назначению. Заказчику может быть передан только утвержденный программный продукт .
Все изменения и модификации проекта должны быть идентифицированы, документально оформлены, проанализированы и утверждены до их реализации. Поставщик устанавливает и поддерживает в рабочем состоянии процедуры управления изменениями в проекте, которые могут возникнуть на любой стадии жизненного цикла системы. Управление документацией и данными
Обслуживание
Поддержка заказчиков обсуждается в стандарте ISO 9000-2. Сопровождение системы, как правило, включает в себя обнаружение и анализ несоответствий в программной системе, вызывающих сбои в ее работе; коррекцию программных ошибок; модификацию интерфейсов, что необходимо в случае внесения добавлений или изменений в аппаратуру; функциональное расширение или улучшение производительности Все действия по сопровождению должны проводиться и контролироваться в соответствии с планом сопровождения, который заранее определяется и согласовывается поставщиком и заказчиком. В заключение нам остается лишь добавить, что технология разработки программного обеспечения - это целая наука, которой в России, увы, почти не учат. Отсюда явный дефицит хороших менеджеров и специалистов по комплексным проектам. Общие положения стандарта по обеспечению качества - лишь верхушка айсберга. За пределами нашей статьи остались детали тех процессов, которые реально обеспечивают качество конечного продукта. Но это, как правило, "ноу хау" компании.

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

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

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

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

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

•  экономическая осуществимость — стоимость, эффективность с точки зрения пользователя;

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

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

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

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

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

Фаза использования начинается, когда изделие передается в систему распределения и обычно продолжается от 2 до 6 лет. В фазе использования выполняется обучение персонала, внедрение, настройка, сопровождение и, возможно, расширение программного продукта. Фаза заканчивается, когда изделие изымается из употребления.

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

Банковские информационные технологии

С точки зрения банковских профессионалов и их клиентов банк является

финансовым учреждением . Однако с точки зрения телекоммуникационных

специалистов банк выглядит как предприятие по переработке и передаче

информации . Финансовые и денежные процессы , протекающие в банке , могут и

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

информации . Это относится в равной мере как к расчётным процессам ,

манипулирующими информацией о состоянии счетов клиентов , так и к процессам

управления банком и принятия решений в сфере , например , кредитной или

дилинговой деятельности . Особенно ярко такая интерпретация проявляет себя

при переходе банков , делового мира и всего общества на новые методы

денежного обращения , когда кредитные и дебетовые карты , банкоматы ,

электронное обслуживание клиентов и другие подобные процессы ведет к тому ,

что все платёжные , расчётные и другие финансовые процедуры не будут

нуждаться в бумажных деньгах и документах , а будут заключаться в

компьютерной обработке и передаче информации . Имея в виду такую

перспективу , нельзя переоценивать роль компьютерных информационных систем

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

широко понимаемая проблема управления становится ключевой в обеспечении

эффективности и надёжности работы банка , именно её качественное решение

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

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

предпочтительно использовать и учитывать существующие международные

стандарты и рекомендации в данной области . Эти рекомендации суммируют

накопленный опыт управления локальными , глобальными сетями и интерсетями

на их основе , выделяют основные функциональные области сетевого управления

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

управления . Использование стандартных методов и средств управления

позволяет обеспечивать совместимость аппаратно-программных средств ,

разработанных различными изготовителями .

Международные рекомендации определяют следующие основные области

сетевого управления :

управление неисправностями - обнаружение неисправностей и других проблем в

работе системы , их изоляция и устранение , регистрация ошибок , их

идентификация и диагностическое тестирование ;

управление учётом - учёт и контроль использования системных ресурсов и

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

ресурсах , тарификация , ведение счетов и установление лимитов на

использование тех или иных ресурсов ;

управление конфигурацией - регистрация всех сетевых устройств , их

местоположения , адресов и идентификаторов , осуществление контроля , сбора

и подготовки данных о состоянии сетевых ресурсов с целью их инициализации ,

запуска в работу , обеспечения непрерывного функционирования , завершения

работы ;

управление эффективностью - оценка эффективности функционирования

системных ресурсов , сбор статистической информации о работе сетевых

объектов , её анализ и обработка , прогнозирование эффективности работы

системы и планирование её развития . Эффективность работы системы тесно

связана с управлением неисправностями , так как для эффективной работы

требуется если не полностью устранить отказы , то , во всяком случае ,

уметь прогнозировать и сводить к минимуму их последствия ;

управление безопасностью - управление аутентификацией , полномочиям ,

доступом , засекречиванием и обеспечением целостности передаваемой ,

обрабатываемой и хранимой информации ;

В более агрегированном виде можно выделить два класса задач , решаемых

системой управления :

сетевое управление - мониторинг сетевых устройств и управление ими ;

системное управление - управление пользователями , их средствами и

ресурсами , включая ПО и пользовательские процессы .

Большинство производителей базовых средств корпоративного уровня , как

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

стандарты . Только этот путь позволяет эффективно внедрять их в уже

работающие системы и не ограничивать пользователя рамками и возможностями

именно систем управления .

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

следует отнести :

OpenView+IT operation/administration компании Hewlett-Packard ;

Sun Connect SunNet Manager компании Sun Solution ;

Tivoli компании IBM ;

SMS компании Microsoft ;

Каждый из этих продуктов является прекрасным средством построения

системы управления , имеющим широкий спектр применения и развития

приложения . Однако , на мой взгляд , первые два продукта ориентированы в

основном на решение задачи сетевого управления и в меньшей степени

затрагивают вопросы системного управления , а вторые два , предназначенные

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

достаточно жесткими рамками либо конкретной области применения , либо

используемых платформ (операционные системы , СУБД , технические средства)

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

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

позволяла централизованно решать текущие задачи по управлению конфигурацией

и оперативному устранению возникающих проблем . Попробуем перечислить

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

Архитектура системы и реализация основных функций

Архитектура подобной системы должна содержать три основных уровня :

уровень глобального отображения - поддержка интегрированного

пользовательского интерфейса и ведение репозитария общих объектов ;

уровень управления банком , или уровень менеджеров - управление

информационными процессами , происходящими во всех субъектах информационно-

телекоммуникационной инфраструктуры корпорации ;

уровень агентов - наблюдение и контроль за всеми элементами информационно-

телекоммуникационной инфраструктуры банка .

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

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

высокого уровня интеграции средств управления разнородными ресурсами , так

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

управления характеристик , как открытость , расширяемость ,

масштабируемость и многоплатформенность .

Особо следует отметить , сто система должна обладать достаточно широким

набором функций управления , которые за счёт интеграции с инфраструктурой

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

Система должна допускать дальнейшее развитие и совершенствование этих

функций . Расширяемость - прямое следствие объективно-ориентированной

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

репозитарии общих объектов , а способы управления им полностью

документированы .

Высокая степень масштабируемости должна позволять настраивать систему

на задачи конкретного бизнеса , используя сети TCP/IP , SNA , DECnet и IPX

, мейнфреймы IBM операционные системы VMS , OS/400 , NonStop Kernel , Unix

, Windows NT и Windows 95 .

Все функции системы должны быть открыты не только для клиентов , но и

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

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

уровень архитектуры имеет открытые точки интеграции . Клиенты и партнёры

могут создавать дополнительных агентов и менеджеров , изменять или

создавать новые объекты , интегрировать их путём настройки

пользовательского интерфейса и использовать все виды услуг , которые

предоставляются менеджерами .

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

основополагающих принципах :

регистрация и отображение информационных процессов , обеспечивающих

реализацию бизнес-функций банка ;

управляемость любым ресурсом системы независимо от его место расположения

«дружественный» трёхмерный графических интерфейс пользователя .

В результате пользователь получает в руки инструмент , позволяющий

визуализировать объект управления и управлять им на трёх уровнях :

глобальном (система в целом) , банка или менеджера (управление бизнес-

процессами) , агентском (управление программными и техническими средствами)

Глобальный уровень

На верхнем уровне объектно-ориентированной архитектуры системы

реализуется графический интерфейс реального мира , с помощью которого

управляющие приложения распознают подчинённые им ресурсы и устанавливают

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

трёхмерная анимация и элементы виртуальной реальности , позволяющие

администратору «перемещаться» по вычислительным ресурсам и сетевым

соединениям . Таким образом , со своего «пульта управления» администратор

может наблюдать за функционированием информационно-телекоммуникационной

инфраструктуры корпорации и решать возникающие проблемы .

Должна представляться возможность логически совмещать структуру

корпорации с картой местности или планом здания , что способствует более

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

. Если администратор имеет дело с сильно распределённой в пространстве

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

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

их физическим расположением . На карте можно размещать различные условные

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

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

Вся информация о субъектах управления поступает из репозитария общих

объектов , играющего роль ключевого звена в интеграции управленческих

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

объекты (прикладные программы , аппаратные средства , базы данных , расчёты

с заказчиками , складской учёт , производственные процессы и т. д.) , их

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

об отображении бизнес-процессов .

Создание репозитария общих объектов и наполнение его конкретной

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

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

. Затем полученные объекты можно отобразить с помощью интерфейса реального

мира . Определение топологии может осуществляться одновременно по разным

направлениям , что важно при работе с большими разветвлёнными сетями .

Уровень менеджера (функции управления банком)

На втором уровне архитектуры - уровне менеджера - реализованы функции

управления банком или бизнес-процессами . Для этого имеется набор

управляющих функций : генерация сообщения о важных системных , сетевых или

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

системных и пользовательских сбоев ; автоматическое выполнения часто

повторяющихся или плановых операций ; аппарат поддержки целостности

жизненно важных ресурсов ; защита информационной среды .

Указанные функции объединяются в следующие основные группы :

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

управление рабочей нагрузкой ;

управление носителями данных , хранением и восстановлением информации ;

управление защитой ;

управление проблемами .

Функция управления событиями позволяет создавать алгоритмы определения

важных событий , реагировать на них и при необходимости принимать

неотложные меры . При обработке событий больше всего времени обычно

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

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

очень трудно определить источник неприятностей .

Для определения причин сбоев реализуются функции фильтрации и

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

При управлении событиями выделяются сообщения , имеющие для системы

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

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

так и агента - не только распознавать события , но и обрабатывать их . В

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

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

интерфейсе управляющих функций , которое позволяет следить за всем

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

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

состоит в возможности видеть график сообщений в целом и сразу же

реагировать на них .

По мере того как информационные системы становятся всё сложнее и растёт

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

компьютеры в рабочем состоянии .

Функция управления рабочей нагрузкой решает задачу автоматизации

ведения графика работ . Она управляет такими важнейшими процессами , как

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

, учёт временных требований , выбор компьютеров для выполнения тех или иных

заданий Для эффективного управления рабочей нагрузкой необходимо иметь

информацию о том , какая работа должна быть выполнена , где когда и как .

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

основных элементов :

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

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

выполняются ручные операции ;

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

набор . Для каждого задания также указывается точное время начала его

выполнения ;

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

содержащие информацию о времени начала выполнения , предшествующих заданиях

, необходимых ресурсах и признаках завершения задания ;

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

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

заданий - прогнозируемый и событийный . Прогнозируемое планирование

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

Последний тип удобен для выполнения заданий при возникновении

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

Комбинирование обоих способов позволяет эффективно планировать выполнение

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

В системе реализуется мониторинг выполнения работ в режиме реального

времени . Администратор системы получает возможность видеть , какие задания

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

задания уже выполнены . В распределённой среде логически связанная

информация хранится в разрозненных системах , что затрудняет процесс

управления ими .

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

необходимое для выполнения резервного копирования и архивирования

информации с отслеживанием перемещения данных с активных носителей на

резервные . Менеджеры хранения данных поддерживают также такие функции ,

как шифрование ,сжатие , коррекция избыточности и ошибок . Подчинённые им

агенты поддерживают широкий диапазон устройств , в том числе RAID ,

оптические диски и роботы .

Система обеспечивает также иерархическое управление запоминающими

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

первой же попытке обращения к таким данным они автоматически переносятся из

архива обратно на активный носитель . Кроме того , имеется средство

предотвращения случайного или преднамеренного стирания или перезаписи

данных на резервных носителях . Интеграция функции управления хранения с

управлением рабочей нагрузкой позволяет планировать централизованные

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

делает выполнение этих операций более эффективным .

В современном банке информация является одним из наиболее важным

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

распределённой среде - далеко не простая задача . Для ей решения необходимо

согласование множества факторов , таких , в частности , как аутентификация

, авторизация , администрирование и аудит , в рамках единой , легко

управляемой системы .

Функция защиты реализует решение проблемы аутентификации для

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

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

системы , компьютеры среднего класса или ПК . Пользователю достаточно

зарегистрироваться один раз , чтобы работать со всеми доступными системами

, не запоминая множество имён и паролей для входа в каждую . Средства

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

паролей , который соответствовал бы уже сложившимся в банке требованиям .

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

а также расширенные средства авторизации (помимо стандартных прав чтения и

записи) . В отличие от традиционных систем файлы защищаются не их

физическими атрибутами , например списком прав доступа , а правилами

которые устанавливаются в специальной реляционной базе данных управления

защитой . В этой базе хранится вся информация , связанная с защитой , и

администраторы всегда могут получить оттуда нужные сведения . Система

предоставляет средства определения ресурсов , нуждающихся в защите : файлы

, терминалы , принтеры , настольные ПК ,порты TCP/IP , Web-страницы и

объединяет их в группу по отображению конкретного бизнес-процесса . Затем

администратор может назначать полномочия для пользователей ,

задействованных в этом процессе . Кроме того , развитые аудиторские функции

дают возможность контролировать использование алгоритмов защиты в системе -

ведется журнал неавторизованного доступа и попыток взлома защиты , а также

данных о внесении изменений в алгоритмы защиты .

Функция управления проблемами - это набор инструментов оперативного

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

деятельности системных администраторов . Управление проблемами включат в

себя три основных функциональных элемента :

определение компонентов - конфигурирование системы , включая аппаратные и

программные средства , а также некомпьютерное оборудование , такое ,

например , как телекоммуникационные , охранные и другие системы банка , за

которыми также необходимо вести наблюдение ;

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

разбирательства или вмешательства . Определение проблем вводится либо

вручную персоналам справочной службы , либо с помощью специальной функции

генерации ;

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

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

управления событиями . Алгоритмы казанного механизма позволяют распознавать

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

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

обнаружения и разрешения проблемных ситуаций , а также вести статистику

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

банка . Функция управления проблемами хранит сведения о проблемных

ситуациях для каждого компонента информационной инфраструктуры , что

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

управления проблемами .

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

бизнес-процессов . Бизнес-процессы , такие , например , как обработка

заказа , электронный платёж , обслуживание клиента , осуществляемые в

рамках автоматизированных финансовых и промышленных систем типа MANMAN/X ,

Baan , SAP/R3 , могут включаться в так называемое отображение бизнес-

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

«положив» туда все атрибуты , отвечающие за его функционирование :

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

В результате можно сформировать динамическую картинку актуального состояния

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

возникновение потенциальных коллизий и своевременно , например,

перераспределить или добавить ресурсы.

Уровень агентов

Как уже отмечалось , модель управления распределёнными системами

реализуется в виде гибкой структуры, в основе которой лежит технология

«менеджер - агент» , реализованная на двух нижних уровнях архитектуры

системы . Агент- это программа на языке программирования Си , использующая

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

верхних уровней управления . Данная программа запускается централизованно и

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

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

известных агентов и установления с ними связи . Агенты по аналогии с

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

информационной системы и позволяет наблюдать за семи элементами сетевой

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

системе должен включать поддержку таких наиболее распространенных ОС и баз

данных , как Windows NT , Unix , Oracle , Sybase , SQL Server , CA-

OpenIngres . Дополнительные агенты могут создаваться с помощью системных

инструментальных средств .

Для эффективного использования агентов все ресурсы сгруппированы в

домены , которые могут быть организованы по топологическому (сетевому) ,

географическому , организационному (в соответствии со структурой банка) или

функциональному (с группировкой по типам ресурсов) принципу . Домены

позволяют добиться более точного и целенаправленного применения алгоритмов

управления . Каждый домен может использовать свои алгоритмы для управления

собственными ресурсами .

Архитектура «менеджер - агент» может масштабироваться -

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

агентами , фильтровать и взаимоувязывать события , реагировать на них .

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

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

менеджеры могут вступать также и в роли агентов для других менеджеров . Всё

это уменьшает трафик сети и снижает нагрузку на менеджеров , одновременно

повышая масштабируемость и производительность системы в целом .

Дополнительная избыточность обеспечивает устойчивость к сбоям , когда агент

или менеджер выходить из строя .

Средства разработки

Важнейшим требованием к базовым средствам построения систем управления

является возможность их использования для развивающихся систем . Наилучшим

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

средств разработки новых приложений . В системе предусмотрены широкие

возможности для пользователя быстро интегрировать в систему свои

собственные технологии . Для этого предлагается комплект инструментальных

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

инструменты , средства генерации агентов и интерфейсы прикладных программ ,

открывающие доступ ко всем уровням архитектуры системы . С помощью этих

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

приложения под конкретные задачи банка .

Однако стоит отметить , что этот мощный инструмент будет работать

только в умелых руках - система предоставляет пользователю среду ,

технологию интеграции приложений , а дальше многое зависит от квалификации

пользователя или работающего с ним системного интегратора . В конце 1996

года компания Computer Associates (CA) развернула активную деятельность по

продвижению одного из ведущих своих продуктов Unicenter TNG (The New

Generation), предназначенного для управления корпоративными и

информационными системами и наиболее отвечающего изложенному выше перечню

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

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

планирование и выполнение заданий , управление хранением и восстановлением

информации . Всё это и является основной задачей указанной системы ,

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

Автоматизированная экспертная система – это продвинутая компьютерная программа (набор команд), которая имитирует знания и способности эксперта к рассуждениям в какой-либо специальной области. Создатели такой системы стремятся клонировать знания одного или нескольких специалистов чтобы создать инструмент, который может быть использован непрофессионалом для решения сложных задач. Основное преимущество экспертных систем состоит в их низкой стоимости по сравнению со стоимостью услуг экспертов или групп специалистов. Экспертные системы отличаются от обычных компьютерных программ, основными функциями которых являются поиск информации, манипуляция данными и вычисления. В отличие от таких программ они применяют к фактам определенные правила, которые устанавливают отношения между этими фактами с целью получения рассуждений, подобных тем, которые бывают у человека. Двумя основными компонентами экспертных систем являются: 1) база знаний, которая отличается от базы данных в том, что она содержит исполняемый программный код (предписания), и 2) логическая машина (решатель задач), которая интерпретирует и оценивает предписания и данные, содержащиеся  в базе знаний. 
Концепция экспертных систем появилась еще в 60-х годах прошлого столетия, но впервые она привлекла к себе внимание благодаря трудам профессора Стэнфордского университета Эдварда Фейгенбаума (Edward Feigenbaum). В 1977 году он показал, что  эффективность компьютерных программ при решении сложных логических задач в большей степени определяется объемом знаний в соответствующей проблемной области, которыми они располагают, чем от формализмов и техники программирования, которые они используют. Вначале экспертные системы применялись в области диагностики и лечения болезней человека. Позднее они стали использоваться в таких областях деятельности как химия, банковское дело, налогообложение и геология. Был такой период времени, когда многие специалисты считали, что нейронные сети и экспертные системы являются конкурирующими направлениями в работах по искусственному интеллекту. Но в настоящее время преобладает точка зрения, что это два равноправных альтернативных подхода к решению задач со свойственными им достоинствами и недостатками. При этом экспертные системы ориентированы преимущественно на использование наборов правил и их последовательное применение, а нейронные сети - на использование примеров. Оба подхода являются достаточно общими и должны применяться с учетом характера решаемых задач.  Задача может быть решена либо путем обучения нейронной сети, либо путем проектирования экспертной системы. 
Для проектировщика интеллектуальной системы автоматической обработки информации экспертная система проще для понимания, чем нейронная сеть, так как в ней применяются правила типа “ЕСЛИ …, ТО …”, используемые и в человеческих рассуждениях.  Нейронная же сеть имитирует малопонятные биологические процессы в мозгу и может показаться странной. Проектировщик практически не может видеть, как обучается нейронная сеть. По свидетельству авторов ряда американских научных публикаций, проектирование экспертной системы часто занимает многие месяцы, затрачиваемые на сбор и осмысление необходимой исходной информации, перевода ее на язык правил и фактов, составление и отладку программ и разработку интерфейса. При этом необходимо понять задачу и  представить процесс ее решения в виде последовательности логических операций. После того, как это сделано, экспертная система может быть построена и отлажена за нескольких дней.  
При проектировании нейронной сети нет необходимости формализовать процесс решения задачи. Достаточно лишь подготовить представительную выборку обучающих примеров и провести обучение системы. Продолжительность обучения может варьировать, но большинство нейронных сетей обучается за период времени продолжительностью от нескольких часов до нескольких дней. Возникает естественный вопрос, какой тип интеллектуальной системы следует выбирать при решении той или иной конкретной задачи. Этот выбор  зависит, прежде всего, от характера исходной информации, которой располагает проектировщик. Если задача может быть решена “по правилам” и эти правила известны или могут быть легко определены, то следует выбирать экспертную систему. Если правила неизвестны, но есть много эмпирических сведений о входных и выходных данных автоматизируемого процесса, то следует выбирать нейронную сеть. Нейронные сети целесообразно использовать вместо традиционных методов программирования, когда правила функционирования автоматизируемых объектов и процессов неопределенны или когда они изменяются во времени.  
Нейронные сети и экспертные системы могут использоваться совместно в составе гибридных систем. При этом нейронные сети могут применяться для распознавания образов (например, для распознавания финансовых ситуаций или чувственных данных), а экспертные системы - для последующей логической обработки результатов распознавания. Экспертные системы могут также применяться в процессах обучения нейронных сетей. Многие сложные задачи могут быть решены путем совместного использования процедур логического вывода и процедур, моделирующих человеческую интуицию. В гибридных системах логический вывод может выполняться с помощью экспертных систем, а человеческая интуиция моделироваться с помощью нейронных сетей. Обученные нейронные сети могут быть представлены в виде матриц порогов чувствительности входов в нейроны, храниться на компьютерном диске или на чипе и использоваться в составе экспертных систем в качестве специальных процедур.

Основные понятия нейросетевых технологий
  1   2   3   4


Учебный материал
© nashaucheba.ru
При копировании укажите ссылку.
обратиться к администрации