Open Library - открытая библиотека учебной информации. Разработка концептуальной модели аис Жизненный цикл и модели жизненного цикла аис
Введение
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 гг. КИС «Флагман» была сертифицирована как информационная система масштаба предприятия экспертами жюри конкурса «Бизнес-Софт», проводимого Ассоциацией разработчиков программного обеспечения в области экономики (АРЭП), ЦИЭС «Бизнес-Программы-Сервис», журналом «Бухгалтерский учет» и «Финансовой газетой».
Описание презентации Этапы создания АИС Модели жизненного цикла АИС по слайдам
Жизненный цикл АИС -совокупность стадий и этапов, которые проходит АИС в своем развитии от момента принятия решения о создании системы до момента прекращения ее функционирования.
Этапы жизненного цикла 1 Планирование и анализ (предпроектная стадия) – определение того, что должна делать система. Оформление технико-экономического обоснования (ТЭО) и технического задания (ТЗ).
2 Проектирование (техническое и логическое проектирование) – определение того, как система будет функционировать (спецификация* подсистем, функциональных компонентов и способов их взаимодействия). Оформление технического проекта. * Спецификация — точное, полное, ясно сформулированное описание требований для данной задачи.
3. Реализация (рабочее проектирование, программирование) — Создание функциональных компонентов и отдельных подсистем, соединение подсистем в единое целое. Заполнение БД. Создание инструкций для персонала. Оформление рабочего проекта
4 Внедрение (тестирование, опытная эксплуатация) – установка и ввод системы в действие, отладка подсистем, обучение персонала. Оформление акта о приемо-сдаточных испытаниях.
Замечания 1. Этапы 2 и 3 можно объединить в одну: техно-рабочее проектирование или системный синтез. 2. На каждом этапе жизненного цикла используется определенный набор технических решений и соответствующих документов
3. Для каждого этапа исходными являются документы и решения принятые на предыдущем этапе. 4. Модели жизненного цикла определяют порядок исполнения этапов в процессе создания системы и критерии перехода от этапа к этапу.
Модель жизненного цикла — это модель создания и использования АИС, которая отражает различные состояния системы с момента возникновения до момента его полного выхода из употребления.
Основные модели ЖЦ Каскадная – предполагает переход на следующий этап после полного завершения работ предыдущего. Эта модель используется при построении АИС для которых с самого начала точно и полно сформулированы все требования. Недостатки: жесткая схема – невозможность возврата к предыдущим этапам и использование для сложных систем.
Поэтапная итерационная модель Предполагает наличие обратной связи между циклами. Преимущество в том, что межэтапные корректировки обеспечивают большую гибкость и меньшую трудоемкость. Недостаток – время жизни каждого из этапов может растянуться на весь период создания системы.Трудности и недостатки спиральной модели ЖЦ Основная проблема — определение перехода на следующий этап: для ее решения вводятся временные ограничения на каждый из этапов. Переход осуществляется в соответствии с планом составленным на основе статистических данных предыдущих проектов и опыта разработчиков. Недостатки: ошибки, допущенные на этапах анализа и проектирования, могут привести к проблемам на следующих этапах и к неуспеху всего проекта.
Роль пользователя АИС создается для удовлетворения информационных потребностей конкретного пользователя. Он принимает непосредственное участие в ее работе. .
Пользователь участвует в постановке задачи и проводит опытную эксплуатацию, в ходе которой может обнаружить недостатки постановки, корректировать входную и выходную информацию, формы выдачи результатов и оформление документов.
Участие пользователя в создании АИС обеспечивает оперативное и качественное решение задач, сокращает время на внедрение новых технологий
ЖЦИС - это период создания и использования ИС, начиная с момента возникновения потребности в ИС и заканчивая моментом полного ее выхода из эксплуатации.
Стадии жизненного цикла информационной системы:
1. Предпроектное обследование:
· сбор материалов для проектирования, при этом выделяют формулирование требований, с изучения объекта автоматизации, даются предварительные выводы предпроектного варианта ИС;
· анализ материалов и разработка документации, обязательно дается технико экономическое обоснование с техническим заданием на проектирование ИС.
2. Проектирование:
2.1 предварительное проектирование;
· выбор проектных решений по аспектам разработки ИС;
· описание реальных компонент ИС;
· оформление и утверждение технического проекта (ТП).
2.2 детальное проектирование:
· выбор или разработка математических методов или алгоритмов программ;
· корректировка структур БД;
· создание документации на доставку и установку программных продуктов;
· выбор комплекса технических средств с документацией на ее установку.
2.3 разработка техно-рабочего проекта ИС (ТРП).
2.4 разработка методологии реализации функций управления с помощью ИС и описанием регламента действий аппарата управления.
3. Разработка ИС:
· получение и установка технических и программных средств;
· тестирование и доводка программного комплекса;
· разработка инструкций по эксплуатации программно-технических средств.
4. Ввод ИС в эксплуатацию:
· ввод технических средств;
· ввод программных средств;
· обучение и сертификация персонала;
· опытная эксплуатация;
· сдача и подписание актов приемки-сдачи работ.
5. Эксплуатация ИС:
· повседневная эксплуатация;
· общее сопровождение всего проекта.
Модели жизненного цикла информационной системы :
· каскадная модель - предлагает переход на следующие этапы после полного осуществления работ по предыдущему этапу. Модель демонстрирует классический подход в любых прикладных областях;
· итерационная модель - поэтапная модель с промежуточным контролем и циклами обратной связи. Преимущество данной модели - поэтапные корректировки, которые обеспечивают меньшую трудоемкость по сравнению с каскадной. Однако время жизни каждого из этапов рассчитывается на весь период разработки;
· спиральная модель - данная модель делает упор на начальные этапы анализа и проектирования. Эта модель представляет собой итерационный процесс разработки, где каждая итерация (цикл), представляет собой законченный цикл разработки, приводящий к выпуску версии изделия (версии проекта ИС), который совершенствуется от итерации к итерации, чтобы стать значимой информационной системой. При этом каждый виток спирали соответствует поэтапной модели создания информационной системы. Т.о. углубляется и последовательно конкретизируется обоснованный вариант ИС, который и доводится впоследствии до реализации.
Основные способы построения ИС:
· разработка системы "под себя";
· использование прототипов - вместо полной системы создается прототип, отвечающий основным потребностям пользователей:
Определение основных запросов;
Создание рабочего прототипа;
Использование рабочего прототипа;
Пересмотр и улучшение прототипа;
Работа с окончательной версией прототипа;
· использование услуг сторонней организации для передачи функций управления ИС - организация использует специализированную фирму, которая выполняет управляющие функции по функционированию и развитию ИС компании.
Плюсы:
· гарантийное качество обслуживания;
· экономия денежных средств;
· человеческие ресурсы.
Минусы:
· не дешево;
· утечка информации;
· зависимость;
· потеря контроля за ИТ.
Систему управления экономическим объектом можно рассматривать как совокупность двух взаимосвязанных элементов (двух составных частей): субъекта управления (СУ) и объекта управления (ОУ).
Субъект управления представляет собой управленческий аппарат, объединяет в себе сотрудников, разрабатывающих планы, вырабатывающих требования к принимаемым решениям, а также контролирующих их выполнение.
Объект управления представляет собой непосредственно предприятие, которое осуществляет выполнение поставленных перед ним задач. В задачу объекта управления входит выполнение планов, выработанных управленческим аппаратом, т.е. реализация той деятельности, для которой создавалась система управления.
Субъект управления и объект управления связаны прямой и обратной связями. Прямая связь выражается потоком директивной информации, направляемой от управленческого аппарата к объекту управления, а обратная представляет собой поток отчетной информации о выполнении принятых решений, направляемый в обратном направлении (см. рис.12).
Директивная информация порождается управленческим аппаратом в соответствии с целями управления и информацией о сложившейся экономической ситуации, об окружающей среде. Отчетная информация формируется объектом управления и отражает внутреннюю экономическую ситуацию, а также степень влияния на неё внешней среды (задержки платежей, нарушения подачи энергии, погодные условия, общественно - политическая ситуация в регионе и т.д.). Таким образом, внешняя среда влияет не только на объект управления: она поставляет информацию и управленческому аппарату, решения которого зависят от внешних факторов (состояние рынка, наличие конкуренции, величина процентных ставок, уровень инфляции, налоговая и таможенная политика).
Взаимосвязь информационных потоков (П и О), средств обработки, передачи и хранения данных, а также сотрудников управленческого аппарата, выполняющих операции по переработке данных, и составляет информационную систему экономического объекта.
Потребность в управлении возникает при необходимости координации деятельности членов трудового коллектива, объединенных для достижения поставленных перед ними локальных и глобальных целей. Первоначально любая цель носит обобщенный характер и лишь в процессе уточнения она формализуется управленческим аппаратом в виде целевых функций.
В процессе управления экономическим объектом принимаются оперативные , тактические и стратегические решения. В соответствии с этим, обычно говорят, что управленческий аппарат состоит из трех уровней управления: оперативного , среднего ивысшего .
На высшем уровне управления экономическим объектом находятся менеджеры-руководители. Они определяют цели управления, внешнюю политику, материальные, финансовые и трудовые ресурсы, разрабатывает долгосрочные планы и стратегию их выполнения. В их компетенцию обычно входит проведение анализа рынка, уровня конкуренции, конъюнктуры и поиск альтернативных стратегий развития предприятия на случай выявления угрожающих тенденций в сфере его интересов.
На среднем уровне управления экономическим объектом находятся менеджеры-исполнители. На этом уровне основное внимание сосредоточено на составлении тактических планов, контроле за их выполнением, слежении за ресурсами и разработке управляющих директив для вывода предприятия на требуемый планами уровень.
На оперативном уровне управления экономическим объектом находятся менеджеры структурных подразделений (отделов, служб, цехов и т.д.). На данном уровне происходит реализация планов и составляются отчеты о ходе их выполнения. Основная задача оперативного управления заключается в согласовании всех элементов производственного процесса во времени и пространстве с необходимой степенью его детализации.
На каждом из уровней управления экономическим объектом выполняются работы, в комплексе обеспечивающие управление. Эти работы принято называть функциями. В зависимости от целей можно выделить функции различной степени общности. Типичными являются следующие функции: планирование , учет и контроль , анализ и регулирование .
Планирование - функция, посредством которой в идеальной форме реализуется цель управления. Планирование занимает значительное место в деятельности высшего руководства, меньшее - на среднем и минимальное - на оперативном уровне. Планирование на высшем уровне управления касается будущих проблем и ориентировано на длительный срок. На среднем уровне планирование осуществляется на более короткий срок, при этом план высшего уровня управления детализируется. Показатели на этом уровне более точные. Оперативное управление предполагает самую детальную проработку плана.
Учет и контроль - функции, направленные на получение информации о ходе работы предприятия проверки соответствия достигнутых результатов с плановыми. Учет принято подразделять на оперативный , бухгалтерский и статистический . Бухгалтерский учет в свою очередь может подразделяться на финансовый и управленческий . Учет в основном осуществляется на оперативном и среднем уровнях управления. На высшем уровне управления учет отсутствует, однако на его основе в полной мере выполняются анализ результатов производства и регулирование его ходом.
Анализ и регулирование - это сопоставление фактических показателей с нормативными (директивными, плановыми), определение отклонений, выходящих за пределы допустимых параметров, установление причин отклонений, выявление резервов, нахождение путей исправления создавшейся ситуации и принятие решения по выводу объекта управления на плановую траекторию. Действенным инструментом для выявления причин отклонений является факторный анализ, а для поиска путей выхода из создавшейся ситуации -э кспертные системы.
Взаимосвязь между уровнями управления и осуществляемыми ими функциями по объему выполняемых работ представлена в табл.7.
Н а рис. 12 представлена взаимосвязь основных этапов процесса управления экономическим объектом.
I. Блоки построения АИС. Методы и средства проектирования Проектирование - процесс создания проекта-прототипа, прообраза предполагаемого или возможного объекта, его состояния. Современная технология создания АИС - совокупность эффективных средств и методов проектирования, позволяющих упростить данный процесс, уменьшить стоимостные затраты, сократить календарные сроки проектирования системы и, в конечном итоге, за счет возможности более широкого выбора проверенных прогрессивных проектных решений, повысить качество разработки. Основные средства проектирования : -стандартные средства операционных систем, обеспечивающих автоматическое прохождение на ЭВМ определенного класса задач; -процедуры, реализующие типовые процессы обработки данных, например контроль выходной информации и ее сортировку; -инструментальные средства, к которым относится совокупность взаимосвязанных специальных программных средств, предназначенных для инструментальной поддержки отдельных элементов процесса проектирования АИС. Это создание и актуализация словаря данных, документирование проекта, автоматизация контроля проектирования и др.; -типовые компоненты, представленные в виде типовых проектных решений (ТПР) и пакетов прикладных программ (ППП). ТПР - совокупность алгоритмических, программных, инструктивно-методических элементов, обеспечивающих машинную реализацию задач или комплекса с помощью соответствующих технических средств. ТПР - основа создания ППП, к которым относятся комплексы программ, обеспечивающих работу типовых конфигураций вычислительной техники, диалоговых систем при решении типовых функциональных задач; -системы автоматизированного проектирования (САПР), предполагающие использование ЭВМ на всех этапах создания АИС и занимающие высшую ступень в эволюции средств проектирования системы. В методах проектирования различают классы и подклассы: Классы: -оригинальное проектирование . Средства, используемые при этом методе: - стандартные средства операционных систем; - процедуры, реализующие типовые процессы обработки данных. -типовое проектирование . Подклассы: элементы, подсистемы, объектное, групповое. Средства: стандартные средства операционных систем; типовые компоненты (ТПР, ППП); некоторые инструментальные средства. -автоматизированное проектирование . Подклассы: модульное; др. Средства: стандартные средства операционных систем САПР; взаимосвязанный комплекс инструментальных средств. Средства проектирования подразделяются на: -комплексные - это ТПР, ППП, типовые проекты автоматизированных систем, САПР. -локальные - большое разнообразие, в их состав входят системы управления базами данных, телеобработки, инструментальные средства и др. Общие требования к средствам проектирования : -полный охват всего процесса создания АИС; -совместимость, требующая согласованных решений как в процессе создания системы и ее обеспечивающих подсистем, так и в процессе их функционирования; -универсальность в своем классе, допускающем возможность применения одних и тех же средств для различных объектов; -д.б. легко доступными, не требующими особых усилий в освоении и просты в реализации; -возможность организации процесса проектирования в режиме интерактивного взаимодействия разработчика системы, проектировщика и ЭВМ; -д.б. адаптированными и экономически эффективными. Методы оригинального проектирования являются традиционными и ориентированы на одно предприятие. Характерная черта - разработка оригинальных методик обследования объекта, его внедрения, создания необходимой проектной документации в виде индивидуального проекта. Достоинство - отражение в проекте АИС специфических особенностей объекта автоматизации. Недостатки: сравнительно высокая трудоемкость и большие сроки разработки, низкий показатель функциональной надежности и адаптируемости к изменяющимся условиям. Проекты, созданные оригинальным методом, поддаются модернизации, однако в чистом виде этот метод используется редко. При его реализации используются в настоящее время различные средства проектирования и лишь для отдельных частей проекта требуются оригинальные проектные решения. Так, общесистемные проектные решения по разработке информационного обеспечения включают методы сбора, контроля и передачи данных, создание нормативно- справочных массивов информации, по программному обеспечению, определяют версию операционной системы, типовые процедуры обработки информации и т.д. Это несколько сглаживает его недостатки. Этот метод особенно актуален при автоматизации сложных, неординарных объектов. Типовое проектирование - индустриальный метод создания АИС, использующий ТПР и ППП, характеризуется наличием апробированных, типовых организационно-экономических, технических, информационных, математических и программных средств автоматизации управления. Достоинства: уменьшает трудоемкость, снижает стоимость и сокращает сроки проектирования, повышая его качество путем более полного охвата задач функциональных подсистем, строгого соблюдения требований нормативных документов, применения передовых технических решений. Типовое проектирование призвано устранить дублирование проектов, создать основу для расширения обмена готовыми типовыми компонентами, облегчить разработку рекомендаций по изменению организационной структуры и методов управления с учетом отраслевых и внутрихозяйственных особенностей. Процесс типового проектирования заключается в выборе и привязке указанных средств в соответствии с треб-ми конкретной системы. Типовая часть АИС представляет собой комплекс информационного, программного и технического обеспечения. Типовой характер первого достигается путем строгого соблюдения единства структуры информационной базы, состава массивов, форм входных и выходных документов; второго- на использовании ППП, и последнего в результате применения ЭВМ одного или совместных типов. Основами элементного проектирования являются ТПР - результат выполнения нескольких взаимосвязанных технологических операций проектирования, при разработке проекта используется уже готовое решение с небольшими модификациями, а не разрабатывается новое. Комплекс типовых проектных решений подразделяется на три группы: “Техника”, “ Задача”, “ Персонал”. Первая группа служит для выбора и комплектации всех видов технических средств вычислительных центров или др. организационных форм их применения. Вторая - содержит документацию по организационно-экономической сущности каждой задачи, алгоритмы их решения, описание входной и выходной информации, соответствующие программные модули с их описаниями и инструкциями по применению. Третья - должностные инструкции всех категорий работников, определяющие их права и обязанности. ТПР создаются по модульному принципу, когда каждое проектное решение расчленяется на отдельные составные части- модули, которые реализуют определенную часть ТПР. Это позволяет создать проект новой автоматизированной системы путем сочетания отдельных типовых модулей. При использовании подсистемного метода проектирования предполагается более высокая степень интеграции типовых элементов системы, когда для каждой подсистемы создаются проекты решений и пакеты прикладных программ. Выделение подсистем- в зависимости от объекта хозяйственно-производственного процесса. Для каждой из подсистем разрабатывается свое автоматизированное проектное решение и ППП, которые могут быть общесистемного или функционального назначения. К первой группе относятся ППП управления данными, типовых процедур их обработки, методовматематической статистики и дискретного программирования, решения непрерывных задач, например дифференциальных уравнений. Во вторую группу входят пакеты, ориентированные на промышленные предприятия с дискретным или непрерывным характером производства, на непромышленную сферу, отраслевое управление. Важное требование, предъявляемое к ППП,- совместимость, т.к. при проектировании АИС целесообразно использовать сразу несколько пакетов. Проектирование систем с применением ППП фактически сводится к привязке выбранных по определенным параметрам пакетов к конкретным условиям объекта автоматизации. Достоинства: менее трудоемкий процесс, занимает меньше времени по сравнению с оригинальным проектированием, реализует прогрессивные методы обработки данных, упрощает документирование проекта, т.к. используется документация пакетов, повышается надежность проектируемых систем. Метод объектного проектирования базируется на применении типовых проектов автоматизированных систем управления. Применяется недостаточно широко, т.к. слишком много разнообразных объектов, а модификация типового проекта системы в соответствии с конкретными условиями объекта автоматизации требует больших трудовых и материальных затрат. Отдельной группой выделяется метод группового проектирования . Его сущность: предварительно подбирается группа объектов, однотипных по характеристикам их информационных систем, среди них выбирается базовый объект, для которого и разрабатывается проект, причем могут использоваться различные методы и способы проектирования, главное- это обеспечение его высокой адаптивности. Основная сфера применения этого метода- непромышленные объекты (например склады), т.к. они более устойчивы с позиции экономической информационной системы. Среди автоматизированных методов особое место занимают методы модульного проектирования . Создание и использование САПР обеспечивает достаточно высокий уровень функциональной надежности, комплексный охват всех технологических процессов, снижение трудоемкости проектных работ с максимальным учетом интересов объекта автоматизации. Однако этот метод достаточно дорог и требует высококвалифицированных разработчиков. Ключевое требование, предъявляемое к САПР, - возможность построения и поддержания в системе проектирования в адекватном состоянии некоторой глобальной экономической информационной модели объекта автоматизации. Модель - отображение информационных компонентов объекта автоматизации и отношение между ними, заданные в явном виде. Основная цель построения модели - создание соответствующего этой модели проекта АИС, учитывающего и активно использующего все характеристики объекта. Такая модель должна содержать в формализованном виде описание совокупностей информационных компонентов и отношения между ними, включая информационные связи и алгоритмическое взаимодействие. С помощью модульного метода проектирования применяется системный подход, обусловливающий использование ЭВМ не только на всех стадиях создания системы, но и в процессе анализа результатов ее промышленной эксплуатации. Развитие и применение САПР предопределило переход к созданию индивидуальных проектов, но на значительно более высоком уровне, по сравнению с оригинальным методом проектирования. Разработкой, внедрением, сопровождением и эксплуатацией корпоративных информационных систем (или сокращенно КИС) занимаются специалисты по информационным технологиям (ИТ). Информационные технологии являются очень широким понятием, поскольку они определяют методы и средства создания, сбора, регистрации, передачи, обработки, хранения и выдачи информации в информационных системах. В настоящее время наряду с названием Корпоративные информационные системы (КИС) употребляются, например, следующие названия: · Автоматизированные системы управления (АСУ); · Интегрированные системы управления (ИСУ); · Интегрированные информационные системы (ИИС); · Информационные системы управления предприятием (ИСУП). Основные стадии проектирования автоматизированных информационных систем · Перед началом проектирования АИС необходимо детально обосновать необходимость ее создания, подробно описать цели и задачи проекта, ожидаемую прибыль, временные затраты, доступные ресурсы, ограничения и т. д. Такие работы часто называют стратегическим планированием информационной системы, и для их осуществления назначается менеджер проекта. Необходимость разработки любой АИС может быть обусловлена следующими факторами: ростом значимости информационной среды предприятия; комплексностью системы управления предприятием; необходимостью анализа потенциальных возможностей и опасностей предприятия; необходимостью систематизации деятельности предприятия; необходимостью постоянного повышения эффективности использования основных фондов предприятия, улучшения соотношения цены и качества; повышением роли капиталовложений в сферу информатизации предприятия; необходимостью кадрового планирования для адекватного обеспечения развития предприятия; ростом сложности и комплектности существующих ИС, влекущим за собой усложнение функциональных требований к ИС и их развитию. Главная особенность стратегического планирования информационной системы состоит в том, что именно в этот период уточняются потребности организации в информации, что и определяет возможные варианты структуры информационной системы. В зависимости от интенсивности функционирования информационно-технологического комплекса выделяют следующие группы организаций: организации, развитие которых зависит от использования информационных технологий для ежедневной деятельности (банки, страховые компании и т. д.); организации, не зависящие от информационных технологий, но способные в будущем широко их использовать для достижения конкурентных преимуществ; организации, в деятельности которых информационные технологии не могут стать источником конкурентного преимущества; организации, использующие информационные технологии для поддержки деятельности, не являющейся основной. Для каждой из описанных групп разрабатываются информационные системы, автоматизирующие соответствующие участки деятельности организации . Разработка и внедрение любой АИС осуществляется в определенной последовательности в соответствии с техническим заданием. Содержание первой очереди управленческой системы определяется составом задач учета, анализа, планирования и оперативного управления, наиболее поддающихся автоматизации и имеющих существенное значение для принятия управленческих решений в организации. В процессе разработки последующих очередей системы происходит расширение и интеграция информационного, программного и математического обеспечения, модернизация технических средств. Жизненный цикл АИС позволяет выделить четыре основных периода: предпроектный, проектный, внедрение, эксплуатация и сопровождение . Технология проектирования автоматизированных информационных систем в настоящее время определяется действующим ГОСТ 34.601-90, согласно которому весь процесс разбит на стадии и этапы . 1. Стадия «Формирование требований к АИС»: определение объема обоснования, необходимого для создания АИС (сбор данных об объекте автоматизации и осуществляемых видах деятельности, оценка качества его функционирования, выявление проблем, решение которых возможно средствами автоматизации, оценка целесообразности создания АИС); формирование требований пользователя к АИС; оформление отчета о выполненных работах и подача заявки на разработку АИС. 2. Стадия «Разработка концепции АИС»: изучение объекта АИС; проведение необходимых исследовательских и проектных работ; разработка вариантной концепции АИС и выбор варианта, который удовлетворяет требованиям пользователя, оценка преимуществ и недостатков альтернативных вариантов; оформление отчета о выполненной работе. 3. Стадия «Техническое задание»: разработка и оформление технического задания на создание АИС (общие сведения, назначение и цели создаваемой системы, характеристика объекта автоматизации, требования к системе в целом, ее функциям и задачам, видам обеспечения, планам работ по созданию, вводу в действие и приемке). 4. Стадия «Эскизный проект»: разработка предварительных проектных решений по системе и ее частям (функции АИС, ее подсистемы, состав задач, концепция и структура информационной базы, состав и основные характеристики технических средств); разработка документации на АИС и ее элементы. 5. Стадия «Технический проект»: разработка проекта решений по системе и ее элементам, по функциональной, алгоритмической и организационной структуре системы, структуре технических средств, организации и ведения базы данных, по системе классификации и кодирования информации, алгоритму решения задач, используемым языкам программирования и программному обеспечению; разработка документов АИС; разработка и оформление документации на поставку изделий для комплектования АИС и технических требований на их разработку; разработка заданий на проектирование. 6. Стадия «Рабочее проектирование»: разработка рабочей документации на систему и ее части; разработка или адаптация программ. 7. Стадия «Ввод в действие»: подготовка АИС к внедрению; сдача задач и подсистем в опытную эксплуатацию; составление отчета о вводе в действие. 8. Стадия «Сопровождение АИС»: анализ функционирования системы; авторский надзор. Особенность разработки АИС заключается в концентрации сложности и трудоемкости на стадиях предпроектного обследования, так как ошибки, допущенные на этапах обследования, анализа и проектирования, порождают на этапах внедрения и эксплуатации часто неразрешимые проблемы достижения поставленных целей и эффективности использования АИС. Формирование требований к системе подразумевает определение ее функциональных возможностей, пользовательских требований, требований к надежности и безопасности, к внешним интерфейсам и т. д. Планирование работ включает предварительную экономическую оценку проекта, построение плана-графика выполнения работ, создание и обучение совместной рабочей группы. На этом этапе осуществляется системный анализ рассматриваемой системы, который включает в себя описание структуры элементов системы и проведение обследования деятельности автоматизируемого объекта; анализ распределения функций по подразделениям и сотрудникам, информационных потоков внутри подразделений и между ними, внешних по отношению к организации объектов и внешних информационных взаимодействий. Fuckyeah. Анализ завершается построением моделей деятельности организации, предусматривающих обработку материалов обследования и построения функциональных и информационных моделей двух видов: модели «as is» («как есть»), отражающей существующее положение дел в организации; модели «to be» («как должно быть»), отражающей представление о новых технологиях и бизнес-процессах организации. По результатам обследования определяется перечень задач, решение которых целесообразно автоматизировать, и очередность их разработки (рис. 8.2). Рис. Результаты обследования Техническое задание - это документ, определяющий цели, требования и основные исходные данные, необходимые для разработки АИС и определения уровня экономической эффективности ее внедрения. Содержание и оформление технического задания регламентируются требованиями ГОСТ 34.602-89. Стадия эскизного проектирования предполагает предварительный выбор методов проектирования и оценку ожидаемых результатов, однако зачастую эта стадия вводится в состав технического проектирования . Технический проект разрабатывается в целях определения основных проектных решений по созданию системы. На этом этапе осуществляется комплекс исследовательских работ для выбора наилучших вариантов решений, провіодятся эксперименталь ная оценка проектных решений и расчет экономической эффективности системы. Для каждой задачи, включенной в комплекс первоочередных задач, выполняется детальная постановка задачи и разработка алгоритма ее решения. Целью этой стадии является формирование новой структуры системы и логических взаимосвязей ее элементов, которые будут функционировать на выбранной технологической основе. Построение системной архитектуры предполагает выделение элементов и модулей информационного, технического, программного обеспечения и других обеспечивающих подсистем, определение связей по информации и управлению между выделенными элементами и разработку технологии обработки информации . Рабочее проектирование включает разработку спецификаций каждого компонента и материалов, обеспечивающих эффективную эксплуатацию АИС, которые содержат уточненные данные и детализированные общесистемные проектные решения, программы и инструкции по решению задач, а также уточненную оценку экономической эффективности АИС. Техническая часть рабочего проекта предусматривает определение технических средств, описание технологического процесса обработки данных, расчет и составление графика загрузки комплекса технических средств, описание режима функционирования АИС . Внедрение разработанного проекта предполагает выполнение следующих этапов : подготовка объекта управления к внедрению АИС, опытное внедрение, т. е. проверка работоспособности элементов и модулей проекта и устранение выявленных ошибок, и промышленное внедрение - этап сдачи в эксплуатацию и проверки на уровне функций, контроль соответствия требованиям, сформулированным на стадии системного анализа (рис. 8.3). На стадии эксплуатации и сопровождения собирается статистика о качестве работы каждого из компонентов системы, исправляются обнаруженные недостатки, в некоторых случаях принимается решение о необходимости расширения функциональности системы (рис. 8.4) . В целом процесс проектирования АИС условно включает в свой состав только основные стадии, а реальный набор этапов и технологических операций в значительной степени зависит от выбранного подхода проектирования. Рис. Основные работы, выполняемые на стадии внедрения АИС Рис. Работы, выполняемые на стадии эксплуатации и сопровождения