Open Library - открытая библиотека учебной информации. Жизненный цикл автоматизированной информационной системы Каскадная модель аис

Каноническое проектирование АИС


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

Существует три класса методологий проектирования АИС :
· концептуальное моделирование предметной области;
· выявление требований и спецификация информационной системы через ее макетирование;
· системная архитектура программных средств, поддерживаемая инструментальными средствами CASE-технологии (CASE -- Computer Aided Software Engineering -- технология создания и сопровождения ПО различных систем).

Стадия создания автоматизированной системы — часть процесса создания АС, установленная нормативными документами и заканчивающаяся выпуском документации наАС, которая должна содержать модель системы на уровне данной стадии, изготовление несерийных компонентов или приемку АС в эксплуатацию.
Каждая стадия выделена по соображениям рационального планирования и организации работ и обязательно должна заканчиваться определенным результатом. Содержание документации на каждой стадии определяется составом и спецификой работ.
В ГОСТ 34.601-90 определено восемь стадий создания автоматизированных систем:

  1. Формирование требований к АС.
  2. Разработка концепции АС.
  3. Техническое задание.
  4. Эскизный проект.
  5. Технический проект.
  6. Рабочая документация.
  7. Ввод в действие.
  8. Сопровождение АС.
Можно выделить три периода создания системы: предпроектный, проектирование, ввод в эксплуатацию.
Стадии 1, 2, 3 относятся к первому периоду, стадии 4, 5, 6 — ко второму периоду, стадии 7, 8 — к третьему.
В предпроектный период разрабатывают технико-экономическое обоснование (ТЭО) и техническое задание (ТЗ) на проектирование системы. В этот период на стадии формирования требований к АС проводят три этапа работ:
  • обследование объекта предметной области и обоснование необходимости создания системы;
  • формирование требований пользователей к системе;
  • составление отчета о выполненной работе и заявки на разработку системы.
На стадии разработки концепции АС проводят четыре этапа работ:
  • изучение объекта;
  • проведение научно-исследовательских работ;
  • выбор варианта концепции системы из нескольких разработанных;
  • составление отчета о выполненной работе.
На 3-й стадии разрабатывают и утверждают техническое задание на создание АС.
Техническое задание (ТЗ) — это перечень основных эксплуатационных, технологических экономических и других требований, которым должен удовлетворять проектируемый объект на всех этапах его существования.После утверждения ТЗ начинается второй период создания АС — период проектирования системы.
Проектирование — процесс обоснованного выбора характеристик системы, формирования логико-математических и экономико-математических моделей, разработки документации.
На стадии создания эскизного проекта на 1-м этапе разрабатывают предварительные проектные решения по системе и ее частям, на 2-м — документацию наАС и ее части.
На 5-й стадии при создании технического проекта в четыре этапа проводят разработку:
  • проектных решений по системе и ее частям;
  • документации наАС и ее части;
  • документации на поставку изделий для комплектования АС и ТЗ на их разработку;
  • заданий н# проектирование в смежных частях проекта объекта автоматизации.
Третий период — ввод в эксплуатацию АС. Обеспечивают разработку нестандартного оборудования, комплектацию оборудования, материалов, покупных изделий, монтаж, наладку, внедрение.
На 7-й стадии система вводится в эксплуатацию в восемь этапов:
  • подготовка объекта автоматизации к вводу АС;
  • подготовка персонала;
  • комплектация АС программными, техническими, информационными средствами и изделиями;
  • строительно-монтажные работы;
  • пусконаладочные работы;
  • предварительные испытания;
  • опытная эксплуатация;
  • приемочные испытания.
Содержание этапов создания АС на различных стадиях
С целью улучшения управления ходом проектирования каждая стадия детализируется, т. е. разбивается на этапы.
Этап создания автоматизированной системы — часть стадии создания АС, определяемая по характеру работ, его результату или специализации исполнителей.
Современные методологии проектирования систем должны обеспечивать описание объектов автоматизации, описание функциональных возможностей АИС, спецификацию проекта, гарантирующую достижение заданных характеристик системы, детальный план создания системы с оценкой сроков разработки, описание реализации конкретной системы.

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

Для АИС условно выделяют следующие основные этапы их жизненного цикла:
1. анализ -- определение того, что должна делать система;
2. проектирование -- определение того, как система будет функционировать: прежде всего спецификация подсистем, функциональных компонентов и способов их взаимодействия в системе;
3. разработку -- создание функциональных компонентов и отдельных подсистем, соединение подсистем в единое целое;
4. тестирование -- проверку функционального и параметрического соответствия системы показателям, определенным на этапе анализа;
5. внедрение -- установку и ввод системы в действие;
6. сопровождение -- обеспечение штатного процесса эксплуатации системы на предприятии заказчика.

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

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

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

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

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

3. Проектирование АИС

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

Стадия проектирования состоит из следующих этапов:

1) предметное обследование (ПРО) существующей (традиционной) ИС;

2) разработка технического задания на создание системы;

3) разработка технического проекта на создание системы;

4) разработка рабочего проекта на создание системы.

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

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

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

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

­ цель, задачи, функции АИС, рассматриваются также внешние условия функционирования системы, распределение функций между ее компонентами;

­ системные параметры АИС - интерфейсы и распределение функций между оператором и системой;

­ конфигурация всех подсистем АИС, образующих её структуру - документационно-информационная, техническая, программно-математическая и организационно-правовая составляющие структуры системы;

­ структура и система управления БД, лингвистические средства, состав информационно-поисковых языков, классификаторов и кодификаторов, методик индексирования документов и запросов;

­ ведомость конфигурации комплекса технических средств АИС и их спецификация;

­ состав и характеристика математических моделей, алгоритмов и программ АИС;

­ схема функционирования АИС, технологического процесса обработки данных и др.;

­ должностные и рабочие инструкции для персонала АИС;

­ уточненное технико-экономическое обоснование проекта.

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

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

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

Методы и средства проектирования АИС. Проектирование АИС может выполняться:

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

­ силами штатных специалистов фирмы-заказчика.

Возможно и компромиссное решение: фирма-заказчик может пригласить консультанта по разработке АИС на контрактной основе.

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

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

На этапе предпроектного обследования используются методы изучения фактического состояния существующей (традиционной) ИС:

­ устный или письменный опрос;

­ письменное анкетирование;

­ наблюдение, измерение и оценка;

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

­ анализ задач;

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

­ процессов.

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

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

­ структурное проектирование;

­ декомпозиция;

­ анализ информационной технологии.

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

4. Автоматизация проектирования АИС

Автоматизированные системы проектирования - эффективное средство улучшения показателей проектирования АИС. В области проектирования сформировалось особое направление - программная инженерия или CASE-технологии (Computer-Aided Software/System Engineering - система компьютерной разработки программного обеспечения). CASE-технологии - это совокупность методов анализа, проектирования, разработки и провождения АИС, поддержанных комплексом взаимосвязанных средств автоматизации. CASE-технологии - это средство для системных аналитиков, разработчиков и программистов, обеспечивающее автоматизацию процессов проектирования АИС различного класса и значения.

Основная цель CASE-технологии - максимально автоматизировать процесс разработки и отделить процесс проектирования от кодирования программных средств АИС.

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

Расчленение сложной системы на части, представляемые как «черные ящики», каждый «черный ящик» реализует определенную функцию системы управления;

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

Использование графического представления взаимосвязей элементов системы.

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

В составе методологий структурного анализа к наиболее распространенным можно отнести следующие:

SADT - технология структурного анализа и проектирования, и ее подмножество - стандарт IDEFO.

DFD - диаграммы потоков данных.

ERD - диаграммы «сущность - связь».

STD - диаграммы переходов состояний.

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

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

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

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

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

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

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

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

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

3) разработка диаграмм объектов, которые показывают взаимосвязь объекта с другими объектами;

4) разработка архитектуры ПО, описывающей физический проект создаваемой системы.

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

Объектно-ориентированный подход не противопоставляется структурному, а может служить его дополнением.

5. Построение и внедрение АИС

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

Определение источников финансирования и выделение средств на закупку необходимого оборудования, предусмотренного проектом, - «Ведомость спецификации оборудования АИС»;

Выбор поставщиков и заключение контрактов на поставку оборудования;

Выделение помещения для дислокации АИС и его подготовка к монтажу оборудования;

Размещение, сборка, монтаж, настройка оборудования АИС в соответствии с проектом;

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

Выполнение работ по проверке качества оборудования (контроль, тестирование). При обнаружении дефектов - оформление и предъявление рекламаций к поставщикам;

Инсталляция ПО и выполнение работ по тестированию программного комплекса АИС. При условии обнаружения дефектов - принятие мер по их устранению;

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

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

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

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

2) обучение персонала технологии АИС и изучение соответствующих разделов проектной документации;

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

4) сдача АИС в производственную эксплуатацию с оформлением соответствующей документации.

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

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

6. Методика расчета технико-экономической эффективности автоматизированной обработки информации

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

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

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

Максимального сокращения времени на выполнение отдельных операций;

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

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

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

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

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

С э = С б – С п (1)

где С э - величина снижения затрат на обработку данных;

С б - затраты при базисном варианте;

С п - затраты при проектируемом варианте.

Относительный показатель экономической эффективности проекта АИС - коэффициент эффективности (К э) затрат и индекс изменения затрат (I з).

К э = С э / С б * 100 % (2)

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

Значение индекса изменения затрат можно определить по формуле:

I з = С э / С б. (3)

Этот индекс свидетельствует о том, во сколько раз снизятся затраты на обработку данных при реализации проекта АИС.

При внедрении проекта АИС необходимо учитывать дополнительные капитальные затраты, значение которых (К 3) можно определить по формуле:

K 3 = K п – K б (4)

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

Эффективность капитальных затрат определяется сроком окупаемости (Т) дополнительных капитальных затрат на модернизацию ИС:

Т = K 3 / С э (5)

Е = С э / K 3 = 1 / Т. (6)

Наряду с расчетом стоимостных затрат полезно получение показателей снижения трудовых затрат на обработку данных. Абсолютным показателем снижения трудовых затрат (t) выступает разность между годовыми трудовыми затратами базового и проектируемого вариантов обработки данных:

t = Т б. – Т п (7)

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

Значение относительного показателя снижения трудовых затрат можно отобразить коэффициентом снижения трудовых затрат (К):

K t = t / T б. (8)

Индекс изменения трудовых затрат (I t) характеризует рост производительности труда за счет освоения более трудосберегающего варианта проекта обработки данных, его можно определить по формуле:

I t = Т б / Т п. (9)

Абсолютный показатель снижения трудовых затрат (Р) применяется для определения потенциального высвобождения трудовых ресурсов (исполнителей) из системы обработки данных:

Р = (t / Т ф) * f (10)

где Т ф – годовой фонд времени одного исполнителя, занятого в технологии обработки данных;

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

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

Экономию трудовых затрат (Э тз) при автоматизированной обработке информации по проекту можно определить по формуле

Э тз = Т о6щ – Т сов (11)

где Т о6щ - трудоемкость обработки данных традиционным способом при базовым варианте;

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

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

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

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

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

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

1. Формирование требований;

2. Проектирование;

3. Разработка;

4. Тестирование;

5. Внедрение;

6. Эксплуатация и сопровождение.

Преимущества:

-Полная и согласованная документация на каждом этапе;

-Определенный порядок последовательности работ;

-Позволяет четко спланировать сроки и затраты.

Недостатки:

-Существенная задержка получения готовых результатов;

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

-Сложность управления проектом.

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

Каждая итерация – законченные циклы разработки в виде 1й версии АИС.

Этапы итерации:

1.Формирование требований

3.Проектирование

4.Разработка

5.Интеграция

На каждой итерации оцениваются:

Риск превышения сроков и стоимости проекта;

Необходимость выполнения ещё одной итерации;

Степень полноты и точности понимания требований к системе;

Целесообразность прекращения проекта.

Преимущества:

-Упрощается процесс внесения изменений в проект;

-Обеспечивает большую гибкость в управлении проектом;

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

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

Недостатки:

-Сложность планирования;

-Напряженный режим работы для разработчиков;

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

Требования к технологии проектирования, разработки и сопровождения АИС

Технология проектирования - определяет совокупность трех составляющих:



-пошаговой процедуры, определяющей последовательность технологических операций проектирования;

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

-представление проектной разработки на экспертизу и утверждению.

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

Технология проектирования, разработки и сопровождения ИС должна удовлетворять следующим общим требованиям:

Технология должна поддерживать полный ЖЦ ПО;

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

Технология должна обеспечивать возможность ведения работ по проектированию отдельных подсистем небольшими группами (3-7 человек). Это обусловлено принципами управляемости коллектива и повышения производительности за счет минимизации числа внешних связей;

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

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

-стандарт проектирования;

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

-стандарт пользовательского интерфейса.

Требование разработки

- Выполнение работ по созданию программного обеспечения;

Подготовка к внедрению АИС;



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

Требования к сопровождению

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

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

Введение

1. Архитектура автоматизированных информационных систем и проблемы её совершенствования 13

1.1. Модели архитектуры и основные компоненты АИС 13

1.2. Проблемы развития АИС 47

1.3. Платформы реализации новой архитектуры АИС УП 53

1.4. Выводы по главе 1 57

2. Модель архитектуры АИС УП 58

2.1. Основные требования к АИС УП 59

2.2. Архитектура АИС УП 66

2.3. Компоненты АИС УП 89

2.4. Выводы по главе 2 102

3. Методы практической реализации АИС УП 104

3.1. Инструментальные средства разработки АИС УП 104

3.2. Опыт практической реализации модели АИС УП 111

3.3. Выводы по главе 3 123

4. Заключение 125

5. Терминология и аббревиатуры 128

6. Литература

Введение к работе

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

На протяжении последних 40 лет автоматизированные информационные технологии (ИТ) активно применяются для решения задач учёта, планирования и анализа хозяйственной деятельности предприятий различных форм собственности, отраслевой принадлежности, организационной структуры и масштабов деятельности. За это время накоплен большой практический опыт создания автоматизированных информационных систем управления предприятиями (АИС УП), разработаны и получили всеобщее признание методологии управления, применение которых невозможно вне компьютерной среды. Можно с полной ответственностью утверждать, что АИС УП стали неотъемлемой составляющей инфраструктуры бизнеса. Теоретические и практические проблемы автоматизации экономических процессов глубоко исследованы в работах Глушкова В.М., Волкова СИ., Исакова В.И., Островского О.М., Подольского В.И., Ратмирова Ю.А., Романова А.Н., Хотяшова Э.Н., Брэди Р., Захмана Дж., Кука М., Финкельштейна К., Хаммера М. и других авторов. Предложенные ими подходы стали базой для применения вычислительной техники на предприятиях при решении задач учёта, планирования и анализа финансово-хозяйственной деятельности. Однако

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

Развитие средств коммуникаций способствует все более тесному взаимодействию производителей с потребителями, поставщиков с покупателями, усиливает конкуренцию на рынке, расширяет границы локальных рынков до национальных и транснациональных, ускоряет время совершения экономических операций и финансовых транзакций. Внедрение глобальных компьютерных сетей в экономические процессы привело к появлению новых понятий: экономика информационного общества, электронный бизнес (e-business), электронная коммерция (e-commerce), электронная торговая площадка (e-marketplace) и др. Тенденции глобализации экономики нашли отражение в новой методологии организации бизнеса, в которой на первый план выходит проблематика повышения гибкости построения бизнес-процессов и эффективности взаимоотношений с клиентами и поставщиками.

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

В публикациях учёных и практиков давно обсуждается идея реализации стандартов системной интеграции программных средств, поставляемых различными производителями. Прогресс системного инструментария привёл к появлению объектно-ориентированных и компонентных технологий разработки программного обеспечения (ПО), которые позволяют строить крупномасштабные системы из готовых блоков. Ведущие поставщики аппаратного и системного программного обеспечения (Intel, Microsoft, Sun, Oracle, IBM и др.), коммуникационных средств (Cisco, Nortel, Ericsson, Motorola), прикладных решений (SAP, PeopleSoft, Siebel и др.), авторитетные государственные, международные, коммерческие и некоммерческие организации и ассоциации (ISO, IEEE, ASCII, APICS, РосСтандарт и др.) к настоящему моменту разработали и активно внедряют на практике технологии интеграции аппаратных и программных средств, позволяющие создавать открытые системы на базе стандартов и протоколов обмена данными и взаимодействия компонент в гетерогенной среде в режиме реального времени.

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

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

Необходимость разработки целостного подхода к решению вопросов системной интеграции АИС УП и сквозной автоматизации микроэкономических процессов на базе современных ИТ определила выбор темы и направления данного исследования.

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

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

Провести анализ и обобщить существующие подходы к проектированию, разработке и внедрению ПО АИС УП;

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

Исследовать существующие технологии и стандарты, обеспечивающие интеграцию разнородных программных средств;

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

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

Разработать модель архитектуры АИС УП и выделить основные её составляющие;

Разработать принципы взаимодействия и обмена данными компонент АИС УП;

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

Объектом исследования являются ИС управления предприятиями.

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

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

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

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

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

Автоматизированной обработки экономической информации и моделирования экономических процессов ;

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

Реинжиниринга и компьютерного проектирования бизнес-процессов ;

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

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

Информационную базу исследования составили программные продукты российских и зарубежных производителей, публикации в экономических и компьютерных изданиях, исследования международных исследовательских групп Gartner Group, Aberdeen, IDC, MetaGroup, DataQuest и др. , методические материалы ведущих отечественных и международных консалтинговых и аудиторских компаний, результаты исследований Ассоциации разработчиков программного обеспечения в области экономики,

исследования рынка программного обеспечения России и стран СНГ ЦИЭС "Бизнес-Программы-Сервис" .

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

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

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

Модель архитектуры АИС УП, ориентированной на комплексную автоматизацию сквозных бизнес-процессов;

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

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

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

Принципы реализации взаимодействия подсистем АИС УП на базе объектно-ориентированных и компонентных технологий и взаимодействия программных компонент в распределённой сетевой

среде в соответствии с промышленными стандартами и протоколами Интернет;

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

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

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

Самостоятельное практическое значение имеют:

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

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

Предложения по созданию единого информационного пространства предприятия при помощи механизма веб-порталов;

Предложения по адаптации спирально-итерационного подхода при разработке и внедрении ПО АИС УП.

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

Комплексной системы управления предприятием «Флагман» компании «Инфософт»,

Системы управления взаимоотношениями с клиентами «eRelationship» корпорации «Pivotal Software» (Канада),

Системы корпоративной отчётности «Monarch ES» компании «DataWatch» (США),

Проекта интеграции информационных систем компаний «Совинтел» и «Теле Росс».

Учебный центр компании «Весть-МетаТехнология» применяет материалы, подготовленные автором на основе подхода, предложенного в ходе данного исследования, при проведении курсов по разработке информационных систем управления предприятиями (см. http://www.vest.msk.ru).

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

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

Конференции «Решения IBM в области интеграции бизнеса для телекоммуникационных компаний», представительство IBM в Восточной Европе (г. Москва, 18 июня 2002 г.);

Симпозиуме «Call Center CRM Solutions 2002/Центры обработки вызовов и управление взаимоотношениями с клиентами» (г. Москва, март 2002 г.);

Конференции разработчиков информационных систем на базе инструментария корпорации Centura Software Corp. (г. Берлин, Германия, 17-19 ноября 1999г.);

Конференции «ИнфоГород: практика и проблемы информатизации городов» (г. Москва, октябрь 1999 г.);

Научно-практических конференциях фирмы «Инфософт» (г. Москва, 1995-1999 гг.);

Конференции специалистов в области АСУ и КИС «Корпоративные системы» (Москва, апрель 1998 г. и 28-30 апреля 1997 г., организаторы: компания «СофтСервис» и представительства компаний Oracle, Informix, Sybase, Borland и Centura);

3-ей ежегодной конференции «Корпоративные базы данных 98» (Москва, 31 марта-3 апреля 1998 и 26-29 марта 1996 г., организаторы «Центр Информационных технологий» при участии ИД «Открытые системы»);

Конференции «Техником-97» (Москва, 24-26 ноября 1997 г., организаторы: фирма «СофтСервис», Российская Ассоциация Пользователей Oracle, представительства компаний Microsoft, Borland, Computer Associates, Lucent Software).

Проблемы развития АИС

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

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

Интеграция разнородных приложений в рамках единой АИС должна обеспечивать поддержку: сквозных бизнес-процессов; единого пользовательского интерфейса (портала); общего информационного пространства.

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

Обобщим плюсы и минусы различных вариантов архитектуры ИС с точки зрения возможностей построения интегрированного решения.

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

Однако, даже если центральный сервер БД способен обеспечить требуемую производительность, при таком построении ИС неизбежно возникают проблемы поддержки единой структуры общей БД, если отдельные программные компоненты ИС разрабатываются разными компаниями или даже командами разработчиков внутри одной и той же организации. Установка общей базы с доступом из программ решения различных прикладных задач позволяет обеспечить общее информационное пространство, перечисленные выше технологии позволяют обращаться к БД большому числу пользователей, однако это не дает гарантии правильной работы с разделяемыми данными. Остаётся проблема логической целостности данных. При использовании программ различных производителей становится неизбежным разделение данных по подсистемам, возможно, путем их денормализации и создания избыточных структур. Схематично архитектура с общей базой представлена на следующем рисунке (Рисунок 1-14). Как следует из приведённой схемы, модули не взаимодействуют, то есть нет вызова одного модуля другим в режиме реального времени, нет оперативной поддержки сквозного процесса. Данные сохраняются в базе, из которых они доступны другим модулям, которым необходимо содержать функции отслеживания изменений в ней, а от частоты проверки обновлений зависит актуальность данных. Примером сквозного процесса может быть выписка счёта сотрудником отдела сбыта. Если он использует для этого CRM-систему, сформированный счёт параллельно с выпиской должен быть обработан в модуле логистики ERP-системы для резервирования товара, и сразу после этого - финансовым модулем для увеличения задолженности покупателя. Для этого соответствующие модули должны проверить наличие нового счета. Если этого не сделать своевременно, может быть выписан счет на фактически зарезервированный товар.

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

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

Платформы реализации новой архитектуры АИС УП

К началу XXI века в индустрии ИТ разработаны и освоены на промышленном уровне следующие решения, обеспечившие повсеместное внедрение ИТ в экономические процессы:

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

средства автоматизированной поддержки согласованной совместной работы группы («команды») работников над одним проектом, документом, заданием и т.п.;

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

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

Решение проблемы интеграции модулей АИС и выбора централизованного или децентрализованного подхода в организации их взаимодействия также возможно благодаря последним разработкам ведущих производителей системного ПО: операционных систем, веб-серверов, серверов приложений, СУБД и платформ промежуточного уровня (middleware platforms). Интеграция приложений становится возможной за счет применения объектно-ориентированной технологии разработки и компонентной многозвенной архитектуры . Ключевым принципом здесь является понятие программных интерфейсов и регламента их изменения и расширения (язык IDL).

Для работы в распределённой гетерогенной среде, какой является Интернет, активно разрабатываются спецификации веб-служб (web services), каждая из которых может реализовать одну или несколько бизнес-процедур или функций (business procedures, functions). Организация OASIS, институт BPMI и компании IBM, Microsoft и ВЕА опубликовали спецификации регулирования потоков работ в рамках бизнес-процессов BPEL4WS (Business Process Execution Language for Web Services), языки веб-служб XLANG и WSFL (Web Services Flow Language), а коалиция WfML - XPDL (XML Process Definition Language).

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

Технических препятствий к реализации подобной архитектуры нет. Современные промышленные серверы приложений (к примеру, MTS/COM+/.Net, ONE или J2EE/EJB) позволяют строить многозвенные системы, предоставляют общую платформу для доступа к различным веб-службам, обеспечивают транзакционную целостность операций, балансировку нагрузки при конкурентном доступе десятков тысяч пользователей в режиме реального времени, а также гарантируют отказоустойчивость и восстановление после сбоев.

Важным достижением индустрии ИТ являются получившие широкое распространение и признанные ведущими производителями ПО стандарты: протоколы взаимодействия компонент (COM/DCOM, CORBA, Java RMI ) и форматы обмена данными (EDI, XML , ).

Стандарт EDI и его отраслевые варианты (EDIFACT, XI2, HIPAA и др.) эксплуатируются в финансовой и производственной сфере Северной Америки и Европы с середины 70-х и доминируют на сегодняшний день во всём мире. С ростом популярности XML в Интернет EDI был переведён на XML.

На базе XML (DTD и XDR) разработаны, структурированы и форматированы данные в различных экономических сферах в виде так называемых предметных словарей или типов документов, к примеру, WIDL, OFX, FpML, IFX, XBRL, CRML и многочисленные другие на Западе, а также CommerceML.ru и XML Partnership/ARB в России. Американское общество по управлению производством и запасами APICS, которое занимается сертификацией систем класса ERP/MRP, публикует спецификации экономических сущностей в формате XML, к примеру, структуру и формат данных клиента или счёт-фактуры. Самодокументированность XML обеспечивает однозначное понимание данных как человеком, так и программами.

Архитектура АИС УП

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

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

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

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

В качестве ядра АИС УП необходимо разработать систему, совмещающую несколько функций, рассмотренных в обзоре систем управления процессами (параграфы «1.1.7 Системы управления документооборотом» на стр. 31 и «1.1.8 Системы управления процессами» на стр. 34). В их числе: Workflow - подсистема управления рабочими и технологическими процессами, обеспечивающая предопределённую и свободную маршрутизацию заданий между исполнителями; Docflow - подсистема управления документооборотом и маршрутизацией документов с отслеживанием их состояний; Groupware - подсистема поддержки функций оперативного назначения заданий и свободной машрутизации (ad hoc) задач между членами группы исполнителей; Dataflow - маршрутизация данных, пакетов данных, сообщений между приложениями.

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

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

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

Опыт практической реализации модели АИС УП

С 1995 по 1999 годы под руководством автора диссертации была разработана система комплексной автоматизации управления предприятием «Флагман» компании «Инфософт», которая на текущий момент внедрена в более чем в ста крупных и средних промышленных, строительных, коммерческих, сельскохозяйственных предприятиях и бюджетных организациях России и стран СНГ. Система продолжает развиваться на базе ядра, разработанного автором, и к 2002 году «Флагман» включает более десяти основных подсистем, представленных на следующем рисунке (Рисунок 3-2):

Основой системы «Флагман» является базовый модуль «Документооборот», который отвечает за ввод, обработку, маршрутизацию и печать всех первичных документов. Другими базовыми модулями являются «Администрирование» и «Инструментальные средства», общие для всех функциональных модулей. Они позволяют настраивать ролевые группы и права доступа, АРМ вплоть до пунктов меню, макетов документов и шаблонов отчётов.

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

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

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

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

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

Необходимо ещё отметить, что в системе «Флагман» реализован унифицированный внешний вид подсистем. Общий модуль администрирования элементов пользовательского интерфейса, функций АРМ, включая меню и панель инструментов, позволяет настраивать внешний вид единообразно.

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

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

В феврале 1999 г. система «Флагман» фирмы «Инфософт», созданная под руководством автора, была признана лучшей российской разработкой на инструментарии Centura Team Developer корпорацией Centura Software Corp. (США) и компанией «Интерфейс» (Россия). В 1999, 2000 и 2001 гг. КИС «Флагман» была сертифицирована как информационная система масштаба предприятия экспертами жюри конкурса «Бизнес-Софт», проводимого Ассоциацией разработчиков программного обеспечения в области экономики (АРЭП), ЦИЭС «Бизнес-Программы-Сервис», журналом «Бухгалтерский учет» и «Финансовой газетой».

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

Существует 2 способа описания моделœей:

1) статический, рассматривающий структуру модели, ᴛ.ᴇ. такие её аспекты, в которых можно пренебречь временем;

2) динамический, рассматривающий поток событий, ᴛ.ᴇ. изменение моделируемых явлений во времени, которым нельзя пренебречь с точки зрения решаемых задач.

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

Исполнительный директор должен иметь общую картину: процессы, продукцию, финансы, перспективы и т.д., ᴛ.ᴇ. интегрированную картину в целом. Для того, чтобы управляющий персонал мог принимать правильные решения в любых ситуациях, крайне важно иметь набор моделœей, описывающих разные стороны деятельности фирмы и их взаимоотношения. В моделях, используемых на верхнем уровне управления, самое главное - ϶ᴛᴏ краткость и понятность. В них должны быть подчёркнуты основные моменты, а детали бывают скрыты.

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

Рисунок 1 – Модель иерархически организованной компании

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

Среди известных моделœей жизненного цикла АИС можно выделить каскадные, итерационные и спиральные модели.

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

Рисунок 2 – Схема каскадной модели

Преимущества каскадной модели:

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

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

Недостатки каскадной модели:

1) запоздание с получением результатов;

2) крайне важность возврата к предыдущим этапам.

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

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

Рисунок 3 – Схема поэтапной итерационной модели

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

Спиральной модель (80-90 ᴦ.ᴦ.) – опирается на начальные этапы жизненного цикла: анализ, предварительное и детальное проектирование.

Каждый виток спирали соответствует поэтапной модели создания фрагмента или версии системы, на нем уточняются цели и характеристики проекта͵ определяется его качество, планируются работы следующего витка спирали. Основная проблема - определœение момента перехода на следующий этап. Для ее решения крайне важно ввести временные ограничения на каждый из этапов ЖЦ. Переход осуществляется в соответствии с планом, который составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков. Недостатком этого подхода являются нерешенные вопросы и ошибки, допущенные на этапах анализа и проектирования. Οʜᴎ могут привести на последующих этапах к проблемам и даже к неуспеху всœего проекта. По этой причинœе анализ и проектирование должны выполняться особенно тщательной

Рисунок 4 – Схема спиральной модели

В основе спиральной модели жизненного цикла лежит применение прототипной технологии или RAD-технологии (Rapid Application Development – технологии быстрой разработки приложений). Согласно этой технологии АИС разрабатывается путём расширения программных прототипов, повторяя путь от детализации требований к детализации программного кода. Естественно, что при этой технологии сокращается число итераций и возникает меньше ошибок и несоответствий, которые крайне важно исправлять на последующих итерациях. При этом проектирование АИС идёт более быстро, упрощается создание проектной документации. Для более точного соответствия проектной документации разработанной АИС всё большее значение придаётся ведению общесистемного репозитария и использованию САSЕ-технологий.

Жизненный цикл при использовании RAD-технологии предполагает активное участие конечных пользователœей будущей системы на всœех этапах разработки и включает 3 основные стадии информационного реинжиниринга:

1) анализ и планирование информационной стратегии : пользователи вместе со специалистами-разработчиками принимают участие в идентификации проблемной области;

2) проектирование : пользователи принимают участие в техническом проектировании под руководством специалистов-разработчиков;

3) внедрение : специалисты-разработчики обучают пользователœей работе в среде новой АИС.

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

Существует три класса методологий проектирования АИС:

Концептуальное моделирование предметной области;

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

Системная архитектура программных средств, поддерживаемая инструментальными средствами CASE-технологии (CASE - Computer Aided Software Engineering - технология создания и сопровождения ПО различных систем).

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

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

 

Возможно, будет полезно почитать: