Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
Лекции: Разработка АИС
Лекция 1
ПОНЯТИЕ И СТРУКТУРА ЭКОНОМИЧЕСКОЙ
ИНФОРМАЦИОННОЙ СИСТЕМЫ
Экономическая информационная система (ЭИС) - совокупность организационных, технических, программных и информационных средств, объединенных с целью сбора, хранения, обработки и выдачи информации, необходимой для выполнения функций управления.
ЭИС связывает объект и систему управления между собой и с внешней средой через информационные потоки :
• ИП1 - информационный поток из внешней среды в систему управления (нормативная информация, создаваемая государственными учреждениями; поток информации о конъюнктуре рынка);
• ИП2 - информационный поток из системы управления во внешнюю среду (отчетная информация в государственные органы, инвесторам; маркетинговая информация потенциальным потребителям;
• ИПЗ - информационный поток из системы управления на объект управления (плановая, нормативная и распорядительная информация для осуществления хозяйственных процессов);
• ИП4 - информационный поток от объекта управления в систему управления (обратная связь - учетная информация о состоянии объекта управления - сырья, материалов, денежных, энергетических, трудовых ресурсов, готовой продукции и выполненных услугах).
На различных уровнях управления (оперативном, тактическом и стратегическом) выделяются следующие типы информационных систем:
• система обработки данных (СОД);
• информационная система управления (ИСУ);
• система поддержки принятия решений (СППР).
Системы обработки данных (СОД) предназначены для учета и оперативного регулирования хозяйственных операций. Реализуют регистрацию и обработку событий (оформление заказов, приход и расход материальных ценностей на складе, ведение табеля учета рабочего времени и т.д.).
Задачи имеют регулярный характер и выполняются непосредственными исполнителями хозяйственных процессов (рабочими, кладовщиками, администраторами и т.д.).
Связаны с оформлением и пересылкой документов в соответствии с четко определенными алгоритмами. Результаты выполнения хозяйственных операций через экранные формы вводятся в базу данных.
Информационные системы управления (ИСУ) ориентированы на тактический уровень: среднесрочное планирование, анализ и организацию работ в течение нескольких недель (месяцев).
Для задач этого класса характерны:
• регламентированность (периодическая повторяемость) формирования результатных документов;
• четко определенный алгоритм решения задач.
Решение задач предназначено для руководителей различных служб предприятий (отделов материально-технического снабжения и сбыта, цехов и т.д.). Задачи решаются на основе накопленной базы оперативных данных.
Системы поддержки принятия решений (СППР) используются на верхнем уровне управления (руководство фирм, предприятий, организаций) для формирования стратегических целей, планирования привлечения ресурсов, источников финансирования и т.д.
Для задач СППР характерны:
• нерегулярный характер;
• недостаточность и нечеткость имеющейся информации;
• преобладание качественных оценок целей и ограничений,
• слабая формализованность алгоритмов решения.
В качестве инструментов обобщения используются средства составления аналитических отчетов произвольной формы, методы статистического анализа, экспертных оценок, математического и имитационного моделирования. При этом используются базы обобщений информации, информационные хранилища, базы знаний о правилах и моделях принятия решений.
Идеальной считается ЭИС, которая включает все три типа перечисленных информационных систем.
В зависимости от охвата функций и уровней управления различают:
• корпоративные;
• локальные ЭИС.
Корпоративная (интегрированная) ЭИС автоматизирует все функции управления на всех уровнях управления. Такая ЭИС является многопользовательской и функционирует в распределенной вычислительной сети.
Локальная ЭИС автоматизирует отдельные функции управления на отдельных уровнях управления. Такая ЭИС может быть однопользовательской, функционирующей в отдельных подразделениях системы управления.
На рынке автоматизированных ИС для крупных корпораций и финансово-промышленных групп сегодня можно выделить два основных субъекта:
• рынок автоматизированных банковских систем (АБС);
• рынок корпоративных ИС промышленных предприятий.
Несмотря на имеющиеся различия в реализации функциональных модулей данных систем, общие подходы к их разработке во многом схожи.
СТРУКТУРА ЭКОНОМИЧЕСКОЙ ИНФОРМАЦИОННОЙ СИСТЕМЫ
В рамках ЭИС выделяют различные по своему назначению компоненты, которые можно рассматривать как самостоятельные подсистемы :
• функциональные;
• обеспечивающие;
Функциональная подсистема ЭИС - комплекс экономических задач с высокой степенью информационных связей между этими задачами
Декомпозиция ЭИС по функциональному признаку включает выделение отдельных частей, называемых функциональными подсистемами (функциональными модулями, бизнес-приложениями). В зависимости от сложности объекта количество функциональных подсистем колеблется от 10 до 50 наименований.
С функциональной точки зрения объектами проектирования являются:
СИСТЕМА – ПОДСИСТЕМА – КОМПЛЕКС ЗАДАЧ – ЗАДАЧА
Функциональная подсистема - независимая часть системы, ориентированная на выполнение конкретных функций управления.
Комплекс задач - совокупность взаимосвязанных задач для реализации функций управления на основе общей информационной базы.
Задача - упорядоченная совокупность процедур преобразования исходной информации в результатную (начисление сдельной заработной платы, учет прихода материалов, оформление заказа на закупку и т.д.). Именно задача является объектом разработки, внедрения и эксплуатации конечным пользователем.
Выбор и обоснование состава функциональных задач является одним из важнейших элементов создания ЭИС. Состав функциональных подсистем определяется особенностями экономической системы, ее отраслевой принадлежностью, формой собственности, размером, характером деятельности.
Принципы построения функциональных подсистем ЭИС:
• предметный;
• функциональный;
• проблемный;
• смешанный (предметно-функциональный).
С учетом предметной направленности в хозяйственных процессах промышленного предприятия выделяют подсистемы, соответствующие управлению отдельными ресурсами:
• управление сбытом готовой продукции;
• управление производством;
• управление материально-техническим снабжением;
• управление финансами;
• управление персоналом.
Функциональная структура ИС - совокупность функциональных подсистем, комплексов задач и процедур обработки информации, реализующих функции системы управления. В системе управления крупных предприятий — корпораций выделяются самостоятельные подсистемы (контуры) функционального и организационного уровня управления (рис. 1.3).
3. Логистика — управление материальными потоками (заготовка материалов и комплектующих изделий), управление производством, управление сбытом готовой продукции. Все компоненты логистики тесно интегрированы с финансовой бухгалтерией и функционируют на единой информационной базе. Основные комплексы задач логистики:
4. Управление производством включает комплексы задач:
5. Бухгалтерский учет информационно связан с управленческим учетом затрат в производстве, финансовым менеджментом, складским учетом. Бухгалтерский учет хозяйственных операций в финансовой бухгалтерии осуществляется на основе бухгалтерских проводок, формируемых на основании первичных учетных документов. Создание документов и их отражения в бухгалтерском учете разделены во времени и пространстве. Основные участки бухгалтерского учета:
Лекция 3
ТЕХНОЛОГИЯ ПРОЕКТИРОВАНИЯ
ЭКОНОМИЧЕСКОЙ ИНФОРМАЦИОННОЙ СИСТЕМЫ
Проектирование ЭИС - процесс преобразования входной информации об объекте проектирования, о методах проектирования и об опыте проектирования аналогичных объектов в проект ЭИС.
Объектами проектирования ЭИС являются отдельные элементы функциональных и обеспечивающих частей, а также их комплексы.
В качестве субъектов проектирования ЭИС выступают:
• специализированная проектная организация
• организация-заказчик, для которой необходимо разработать ЭИС.
При большом объеме и жестких сроках в разработке ЭИС может принимать участие несколько организаций-разработчиков. В этом случае выделяется головная организация , координирующая деятельность организаций-соисполнителей. Иногда функции заказчика и разработчика совмещаются.
Осуществление проектирования ЭИС предполагает использование проектировщиками определенной технологии проектирования.
Технология проектирования ЭИС - совокупность методологии, инструментальных средств проектирования, а также методов и средств организации проектирования.
Современная технология проектирования ЭИС должна обеспечивать:
• соответствие стандарту ISO / I ЕС 12207 (поддержка процессов ЖЦ);
• гарантированное достижение целей разработки ЭИС в рамках бюджета, с заданным качеством и в установленное время;
• возможность декомпозиции проекта на составные части, разрабатываемые группами в 3 - 7 человек, с последующей интеграцией частей,
• минимальное время получения работоспособного ПО подсистем ЭИС;
• независимость получаемых проектных решений от средств реализации ЭИС (СУБД, ОС, языков и систем программирования);
• поддержку CASE-средств, обеспечивающих автоматизацию процессов, выполняемых на всех стадиях ЖЦ.
Основу технологии проектирования ЭИС составляет методология проектирования . Она предполагает наличие некоторой концепции (принципов проектирования), реализуемой набором методов.
Метод проектирования - способ создания проекта системы, поддерживаемый определенными средствами проектирования.
Методы проектирования ЭИС можно классифицировать:
По степени автоматизации:
• ручного проектирования , при котором проектирование компонентов ЭИС осуществляется без использования специальных инструментальных программных средств, а программирование - на алгоритмических языках;
• компьютерного проектирования , которое производит генерацию или конфигурацию (настройку) проектных решений на основе использования специальных инструментальных программных средств.
По степени использования типовых проектных решений:
• оригинального (индивидуального) проектирования , когда проектные решения разрабатываются <с нуля>;
• типового проектирования , предполагающего конфигурацию ЭИС из готовых типовых проектных решений (программных модулей).
По степени адаптивности проектных решений:
• реконструкции , когда адаптация проектных решений выполняется путем переработки компонентов (перепрограммирования программных модулей);
• параметризации , когда проектные решения настраиваются (переконфигурируются) в соответствии с изменяемыми параметрами;
• реструктуризации модели , когда изменяется модель проблемой области, на основе которой автоматически перегенерируются проектные решения.
Сочетание различных признаков классификации методов проектирования обусловливает характер используемой технологии проектирования.
Выделяются два основных класса:
• каноническая технология;
• индустриальная технология.
Индустриальная технология проектирования, в свою очередь, разбивается на два подкласса:
• автоматизированное (использование CASE-технологий);
• типовое (параметрически- или модельно-ориентированное) проектирование.
Средства проектирования ЭИС можно разделить на два класса:
• без использования ЭВМ;
• с использованием ЭВМ.
Средства проектирования без использования ЭВМ - средства организационно-методического обеспечения: стандарты, регламентирующие процесс проектирования, единая система классификации и кодирования информации, унифицированная система документации, модели описания и анализа потоков информации и т.п.
Средства проектирования с использованием ЭВМ делят на четыре подкласса.
1) Средства, поддерживающие проектирование операций обработки информации.
К данному подклассу относятся алгоритмические языки, библиотеки стандартных подпрограмм, макрогенераторы, генераторы программ, средства тестирования и отладки программ, средства расширения функций операционных систем (утилиты) и т.п.
С их помощью повышается производительность труда проектировщиков, но не разрабатывается законченное проектное решение.
2) Средства, поддерживающие проектирование отдельных компонентов проекта ЭИС.
К этому подклассу относятся средства общесистемного назначения: СУБД, ППП общего назначения (текстовые, табличные и графические редакторы), методоориентированные ППП (сетевое планирование, математическая статистика, дискретное и нелинейное программирование, имитационное моделирование), оболочки экспертных систем.
Используются для разработки технологических подсистем ЭИС: ввода информации, организации хранения и доступа к данным, вычислений, анализа и отображения данных, принятия решений.
3) Средства, поддерживающие проектирование разделов проекта ЭИС.
К этому подклассу относятся: типовые проектные решения, функциональные ППП (автоматизация бухгалтерского учета, финансовой деятельности, управления персоналом, управления материальными запасами, управления производством).
4) Средства, поддерживающие разработку проекта на стадиях и этапах процесса проектирования.
К этому подклассу относятся средства автоматизации проектирования ЭИС (CASE-средства).
ЖИЗНЕННЫЙ ЦИКЛ ЭКОНОМИЧЕСКИХ
ИНФОРМАЦИОННЫХ СИСТЕМ
Жизненный цикл ЭИС - это период времени с момента принятия решения о создании ЭИС до момента полного изъятия ЭИС из эксплуатации.
Основным нормативным документом, регламентирующим состав процессов ЖЦ ЭИС, является международный стандарт ISO / IEC 12207: 1995 "Information Technology - Software Life Cycle Processes".
ISO - International Organization for Standardization - Международная организация по стандартизации, IEC - International Electrotechnical Commission - Международная комиссия по электротехнике.
Процесс - совокупность взаимосвязанных действий, преобразующих входные данные в выходные. Каждый процесс разделен на набор действий, каждое действие - на набор задач.
В соответствии со стандартом ISO / I ЕС 12207 все процессы ЖЦ ПО разделены на три группы:
• пять основных процессов (приобретение, поставка, разработка, эксплуатация, сопровождение);
• восемь вспомогательных процессов , обеспечивающих выполнение основных процессов (документирование, управление конфигурацией, обеспечение качества, верификация, аттестация, совместная оценка, аудит, разрешение проблем);
• четыре организационных процесса (управление, создание инфраструктуры, усовершенствование, обучение).
Процесс приобретения состоит из действий и задач заказчика, приобретающего ЭИС.
Процесс поставки охватывает действия и задачи, выполняемые поставщиком, снабжающим заказчика программным продуктом или услугой.
Процесс разработки предусматривает действия и задачи, выполняемые разработчиком по созданию ЭИС.
Процесс эксплуатации охватывает действия и задачи оператора - организации, эксплуатирующей систему.
Процесс сопровождения предусматривает действия и задачи, выполняемые сопровождающей организацией (службой) сопровождения.
Процесс документирования предусматривает формализованное описание информации, созданной в течение ЖЦ ЭИС.
Процесс управления конфигурацией предполагает применение административных и технических процедур для определения состояния компонентов ЭИС, управления модификациями, описания и подготовки отчетов о состоянии компонентов, обеспечения полноты, совместимости корректности компонентов.
Процесс обеспечения качества гарантирует то, что ЭИС и процессы ЖЦ соответствуют заданным требованиям и утвержденным планам.
Процесс верификации состоит в определении того, что программные продукты полностью удовлетворяют требованиям или условиям, обусловленным предшествующими действиями (формальное доказательство правильности ПО - непротиворечивость требований, корректность описаний данных, последовательности событий, интерфейсов, логики, соответствие кода, тестируемость и корректность кода и т. д.)
Процесс аттестации предусматривает определение полноты соответствия требований и системы их конкретному функциональному назначению. Под аттестацией понимается подтверждение и оценка достоверности проведенного тестирования ЭИС. Аттестация должна гарантировать полное соответствие спецификациям, требованиям и документации. Аттестацию выполняют путем тестирования во всех возможных ситуациях и используют при этом независимых специалистов.
Процесс совместной оценки предназначен для оценки состояния работ двумя любыми сторонами, участвующими в договоре, при этом одна сторона проверяет другую. Контроль управления ресурсами, персоналом, аппаратурой и инструментальными средствами.
Процесс аудита представляет собой определение соответствия реальных работ планам и условиям договора. Аудит может выполняться двумя любыми сторонами, участвующими в договоре, когда одна сторона проверяет другую. Аудиторы (ревизоры) не должны иметь прямой зависимости от разработчиков ЭИС.
Процесс разрешения проблем предусматривает анализ и решение проблем, обнаруженных в ходе разработки, эксплуатации, сопровождения или других процессов.
Процесс управления состоит из действий и задач, выполняемых любой стороной, управляющей своими процессами (приобретение, поставка, разработка, эксплуатация, сопровождение и др.)
Процесс создания инфраструктуры охватывает выбор и поддержку технологии, стандартов и инструментальных средств, выбор и установку аппаратных и программных средств, используемых для разработки, эксплуатации или сопровождения ЭИС.
Процесс усовершенствования предусматривает оценку, измерение, контроль и усовершенствование процессов ЖЦ ЭИС.
Процесс обучения охватывает первоначальное обучение и последующее постоянное повышение квалификации персонала.
ФУНКЦИОНАЛЬНО-ОРИЕНТИРОВАННОЕ ПРОЕКТИРОВАНИЕ ЭКОНОМИЧЕСКИХ ИНФОРМАЦИОННЫХ СИСТЕМ
Основными идеями функционально-ориентированной CASE -технологии являются идеи структурного анализа и проектирования ЭИС:
• декомпозиция всей системы на некоторое множество иерархически подчиненных функций;
• представление всей информации в виде графической нотации (систему всегда легче понять, если она изображена графически).
При этом выделяются:
Модель требований (логическая модель) описывает, что должна делать проектируемая система, без ссылки на то, как это достигается. Строится средствами структурного системного анализа.
Модель реализации (физическая модель) является расширением модели требований. Демонстрирует, как система будет удовлетворять предъявленным к ней требованиям (без технических подробностей). Строится средствами структурного проектирования.
В качестве инструментальных средств структурного анализа и проектирования выступают следующие диаграммы:
• BFD (Bussiness Function Diagram) - диаграмма бизнес - функций ;
• DFD (Data Flow Diagram) - диаграмма потоков данных;
• STD (State Transition Diagram) - диаграмма переходов состояний;
• ERD (Entity Relationship Diagram) - модель <сущность-связь> данных предметной области (информационно-логическая модель);
• SSD (System Structure Diagram) - диаграмма структуры программного приложения.
ПРОТОТИПНОЕ ПРОЕКТИРОВАНИЕ ЭКОНОМИЧЕСКИХ ИНФОРМАЦИОННЫХ СИСТЕМ
Основное желание заказчика ЭИС - получить готовое приложение высокого качества быстро при минимальных затратах на его разработку. Кроме того, заказчики желают контролировать процесс разработки.
Процесс разработки ИС каскадным методом может затянуться время, а соответствие результата потребностям заказчика не гарантируется.
В рамках спиральной модели ЖЦ широкое распространение получила методология прототипного проектирования . Ядром этой методологии является способ быстрой разработки приложений - RAD (Rapid Application Development). Подход RAD предусматривает наличие трех составляющих :
• небольшие группы разработчиков (3 - 7 человек), выполняющие работы по проектированию отдельных подсистем (требование максимальной управляемости коллектива);
• короткий, но тщательно проработанный производственный график (до 3 месяцев);
• повторяющийся цикл, при котором разработчики по мере того, как приложение обретает форму, запрашивают и реализуют требования, полученные в результате взаимодействия с заказчиком.
Технология обеспечивает создание на ранней стадии действующей интерактивной модели - системы-прототипа . Прототип позволяет:
• наглядно продемонстрировать пользователю будущую систему;
• уточнить требования пользователя;
• оперативно модифицировать интерфейсные элементы (формы ввода сообщений, меню, выходные документы, структуру диалога, состав реализуемых функций).
Согласованная система-прототип служит спецификацией для дальнейшей разработки ЭИС, что позволяет на ранних этапах выявить возможные ошибки проектирования и определить параметры будущей системы.
Для реализации технологии прототипного проектирования необходимо применять высокоуровневые инструментальные средства , позволяющие быстро преобразовать прототип в функционирующую версию и внести в дальнейшем необходимые изменения.
Такие инструментальные средства можно разделить на два класса :
• интегрированные инструменты быстрой разработки приложений (класс BUILDER );
• инструменты быстрой разработки приложения в развитых СУБД (класс DEVELOPER ).
К интегрированным инструментам класса BUILDER относятся Power Builder Enterprise , Delphi , Builder Си ++, Visual Basic и др.
Отличительной чертой является то, что инструменты класса легко интегрируются с CASE-средствами и представляют собой единую среду быстрой разработки приложения.
К инструментам этих классов можно отнести средства 4 GL (генераторы компонентов приложений):
• генераторы таблиц базы данных;
• генераторы форм ввода-вывода;
• генераторы запросов;
• генераторы отчетов;
• генераторы меню.
Такие генераторы существуют почти во всех СУБД, как персональных ( Access , FoxPro , Paradox ), так и в окружении промышленных серверов БД ( Oracle , Informix , Adabas D и др.).
Инструментальная среда быстрой разработки приложений СУБД Access включает ряд мастеров (конструкторов).
• мастер (конструктор) таблиц предназначен для быстрого создания структуры таблиц БД и их взаимосвязей;
• мастер (конструктор) форм ввода-вывода позволяет быстро создать экраны ввода информации в БД различного типа;
• мастер (конструктор) запросов позволяет создавать запросы различной сложности;
• мастер (конструктор) отчетов позволяет создавать отчеты на базе нескольких таблиц или запросов;
• мастер (конструктор) кнопочных форм позволяет разрабатывать управляющие интерфейсные объекты, которые используются для управления работой приложения.
Работа с мастером заключается в пошаговом выполнении настройки мастера. Работа с конструктором заключается в детальном определении конструктивных элементов содержания проектируемой компоненты ЭИС.
ОБЪЕКТНО-ОРИЕНТИРОВАННОЕ ПРОЕКТИРОВАНИЕ ЭКОНОМИЧЕСКИХ ИНФОРМАЦИОННЫХ СИСТЕМ
Структурная декомпозиция ЭИС на основе объектно-ориентированного подхода лучше отражает динамическое поведение системы в зависимости от возникающих событий.
Модель проблемной области рассматривается как совокупность взаимодействующих во времени объектов. Тогда конкретный процесс обработки информации формируется в виде последовательности взаимодействий объектов. Одна операция обработки данных может рассматриваться как результат одного взаимодействия объектов.
Конечным результатом процесса объектно-ориентированного проектирования (ООП) должно стать множество классов объектов с присоединенными методами обработки атрибутов. Если в функциональном подходе модели данных и операций разрабатываются относительно независимо друг от друга и только координируются между собой, то ООП предполагает совместное моделирование данных и процессов.
В связи с этим система объектно-ориентированных моделей последовательно разворачивается по направлению от модели общего представления функциональности ЭИС к модели динамического взаимодействия объектов, на основе которой могут быть сгенерированы классы объектов в конкретной программно-технической среде.
В настоящее время для объектно-ориентированного моделирования проблемной области широко используется унифицированный язык моделирования UML (Unified Modeling Language), который разработан группой ведущих компьютерных фирм мира OMG ( Object Management Group ) и фактически является стандартом по объектно-ориентированным технологиям. Язык UML реализован многими фирмами - производителями программного обеспечения в рамках CASE-технологий, например Rational Rose ( Rational ), Natural Engineering Workbench ( Software AG ) и др.
Система объектно-ориентированных моделей в соответствии с нотациями UML включает в себя следующие диаграммы:
• диаграмму прецедентов использования ( Use - case diagram );
• диаграмму классов объектов ( Class diagram );
• диаграммы состояний ( Statechart diagram );
• диаграммы взаимодействия объектов ( Interaction diagram );
• диаграммы деятельностей ( Activity diagram );
• диаграммы пакетов ( Package diagram );
• диаграмму компонентов ( Component diagram );
• диаграмму размещения ( Deployment diagram ).
ПРОЕКТИРОВАНИЕ ЭКРАННЫХ ФОРМ ЭЛЕКТРОННЫХ ДОКУМЕНТОВ
Борьба с возрастающим потоком бумажных форм на предприятиях и в организациях ведется в двух направлениях:
• переход от бумажных форм документов к электронным;
• применение более эффективных технологий извлечения данных из бумажных форм.
Под электронными формами документов понимается не изображение бумажного документа, а изначально электронная (безбумажная) технология работы; она предполагает появление бумажной формы только в качестве твердой электронной копии.
Электронная форма документа (ЭД) - это страница с пустыми полями, оставленными для заполнения пользователем. Формы могут допускать различный тип входной информации и содержать командные кнопки, переключатели, выпадающие меню и списки выбора.
После заполнения формы ее можно отправить по электронной почте, по факсу или на рабочий стол другого сотрудника. Для этого нужно лишь нажать кнопку, поскольку электронный адрес получателя заранее определен.
Можно назвать несколько видов форм , имеющих различный тип технологии обработки:
• формы, предназначенные для сбора данных, ввода их в базу данных и последующей обработки (заполнение и сбор по электронной почте или через формы, размещенные на Web-серверах);
• формы, предназначенные для сбора информации внутри и вне предприятия, требующие процедуры ознакомления и подтверждения (заказы на покупку, счета, отчеты о командировочных расходах).
Электронная (безбумажная) технология подразумевает работу с электронными формами сразу с этапа заполнения до этапа извлечения данных и их сбора в определенной базе данных (или экспорт этих данных в какое-либо специализированное приложение).
Основные достоинства электронных форм :
• доступны в режиме on - line ; печать осуществляется по требованию;
• легко модифицируются благодаря графическим инструментам проектирования форм;
• не требуют места в шкафах и работы обслуживающих их клерков;
• включают интеллектуальные элементы, в т. ч. проверку правильности и целостности заполнения, автоматически вычисляемые поля, заполнение из справочников;
• могут динамически адаптироваться под конкретного пользователя (изменяются количество и размер полей и т. д.)
Недостаток ЭД - неполная юридическая проработка процесса <подписи формы> - использование электронной подписи или различных видов биометрических подписей (от снятия уникальных характеристик обычной подписи до отпечатков пальцев и изображения лица).
К средствам создания ЭД можно отнести средства MS Office . Компоненты этой системы позволяют автоматизировать процессы заполнения и вычисления полей, отсылку по электронной почте. Помимо них в настоящее время используются специализированные программные продукты, например "1C. Документооборот", которые позволяют встраивать ЭД в подсистему электронного документооборота. К наиболее мощным разработкам такого рода относится система JetForm (разработанная компанией JetForm ). Она обеспечивает хорошо структурированные средства проектирования форм ЭД, их заполнение, клиент-серверную обработку, а также предоставляет мощные возможности централизованного управления выдачей информации в готовые формы из корпоративных баз данных и прикладных приложений.
Проектирование форм ЭД , т.е. создание шаблона формы с помощью ПО, включает в себя выполнение следующих шагов:
• создание структуры ЭД - рисование линий, создание графических элементов (например, логотипов), т. е. подготовка внешнего вида с помощью графических средств проектирования;
• определение содержания формы ЭД - выбор способов, которыми будут заполняться поля. Поля могут заполнены вручную или посредством выбора значений из списка, меню, базы данных. В последнем случае дизайнер форм должен связать форму с базой данных.
ДИАГРАММЫ СУЩНОСТЬ-СВЯЗЬ
Цель моделирования данных - обеспечить разработчика ЭИС концептуальной схемой базы данных в форме одной модели или нескольких локальных моделей, которые может быть относительно легко отображены в любую систему баз данных.
Наиболее распространенным средством моделирования данных являются диаграммы "сущность-связь" (ERD), нотация которых была впервые введена Питером Ченом в 1976 г . и получила дальнейшее развитие в работах Ричарда Баркера. Различные CASE-средства используют несколько отличающиеся друг от друга нотации ERD. Одна из наиболее распространенных нотаций предложена Баркером (Oracle Designer). В CASE-средстве SilverRun используется один из вариантов нотации Чена. CASE-средства ERwin, ER / Studio, Design / IDEF используют методологию IDEF 1Х.
Методология IDEF 1Х была разработана для армии США и широко используется в государственных учреждениях, финансовых и промышленных корпорациях. Является развитием методологии IDEF 1, но в большей мере ориентирована на автоматизацию и более проста для понимания. Позволяет построить модель данных, эквивалентную реляционной модели, приведенной к третьей нормальной форме.
Диаграммы "сущность-связь" (ERD) предназначены для разработки моделей данных и обеспечивают стандартный способ определения данных и отношений между ними.
Фактически с помощью ERD осуществляется детализация хранилищ данных проектируемой системы, а также документируются сущности системы и способы их взаимодействия, включая идентификацию объектов, важных для предметной области (сущностей), свойств этих объектов (атрибутов) и их отношений с другими объектами (связей).
Эти диаграммные техники используются, прежде всего, для проектирования реляционных баз данных (хотя также могут с успехом применяться и для моделирования иерархических и сетевых баз данных).
Диаграммы "сущность-связь" включают:
• сущности;
• атрибуты;
• связи.
Сущность (Entity) - любой объект, событие или концепция, имеющие существенное значение для предметной области, и информация о которых должна сохраняться.
Каждая сущность является множеством подобных объектов, называемых экземплярами . Каждый экземпляр индивидуален и должен отличаться от остальных.
Атрибут (Attribute) - любая характеристика сущности, значимая для рассматриваемой предметной области. Атрибут предназначен для квалификации, идентификации, классификации, количественной характеристики или выражения состояния сущности.
Каждая сущность может обладать любым количеством связей с другими сущностями. Связь (Relationship) - поименованное логическое соотношение между двумя сущностями, значимое для рассматриваемой предметной области.
Сущность является независимой , если каждый экземпляр ее может быть однозначно идентифицирован без определения его отношений с другими сущностями. Независимая сущность изображается прямоугольником с четко выраженными углами. Сущность является зависимой , если однозначная идентификация экземпляра сущности зависит от его отношения к другой сущности. Зависимая сущность изображается прямоугольником со скругленными углами.
Первичный ключ (Primary Key) - это атрибут или группа атрибутов, однозначно идентифицирующих экземпляр сущности. На диаграмме первичные ключи размещаются выше горизонтальной линии. Ключ может быть сложным, т.е. состоять из нескольких атрибутов.
Альтернативный ключ (Alternate Key) - потенциальный ключ, не ставший первичным. На диаграмме альтернативный ключ обозначается AK n . m , где n - порядковый номер ключа, m - порядковый номер атрибута в ключе.
Внешние ключи (Foreign Key) создаются автоматически, когда сущности соединяются связью (миграция ключа). Связи между таблицами реляционной БД представляются одинаковыми ключами в таблицах (внешними ключами).
Связи (логические отношения между сущностями) именуются глаголами или глагольными фразами. Имена связей выражают некоторые ограничения или бизнес-правила и облегчают чтение диаграмм.
На логическом уровне можно установить:
• идентифицирующую связь один-ко-многим;
• неидентифицирующую связь один-ко-многим;
• связь многие-ко-многим.
Разработка ERD включает следующие основные этапы:
• Идентификация сущностей, их атрибутов, а также первичных и альтернативных ключей.
• Идентификация отношений между сущностями и указание типов отношений.
• Разрешение неспецифических отношений (отношений многие-ко-многим).
МЕТОД ФУНКЦИОНАЛЬНОГО МОДЕЛИРОВАНИЯ SADT
Метод SADT (Structured Analysis and Design Technique) разработан в 1973 г . Дугласом Россом (SoftTech, Inc.). Успешно использовался в военных, промышленных и коммерческих организациях США. Метод поддерживается Министерством обороны США, которое было инициатором разработки стандарта IDEF0 (Icam DEFinition) - подмножества SADT, являющегося основной частью программы ICAM (Integrated Computer Aided Manufacturing - интегрированная компьютеризация производства). Более того, среди менеджеров и руководителей компьютерных фирм считается, чуть ли не правилом хорошего тона знать основы SADT и при обсуждении каких-либо вопросов нарисовать простейшую диаграмму, поясняющую суть дела.
Метод SADT представляет собой совокупность правил и процедур, предназначенных для построения функциональной модели объекта (производимые им действия - работы - и связи между ними).
Диаграммы функциональных спецификаций позволяют представить общую структуру ЭИС, отражающую взаимосвязь различных задач (процедур) в процессе получения требуемых результатов. Основными объектами диаграмм являются:
• функция - некоторое действие ЭИС, необходимое для решения экономической задачи.
• декомпозиция функции - разбиение функции на множество подфункций.
Система разбивается на функциональные подсистемы , которые делятся на подфункции, те - на задачи и так далее до конкретных процедур. При этом автоматизируемая система сохраняет целостное представление.
Метод основан на следующих концепциях :
• графическое представление блочного моделирования;
• строгость и точность;
• отделение организации от функции (исключение влияния административной структуры на функциональную модель).
Диаграммы - главные компоненты модели, на которых в виде блоков и дуг представлены все функции (работы) организации и интерфейсы.
Работы - поименованные процессы, функции или задачи, которые происходят в течение определенного времени и имеют распознаваемые результаты. Изображаются в виде прямоугольников. Имя работы выражается отглагольным существительным.
В IDEF0 различают пять типов стрелок:
Вход (Input) - материал или информация, используемые работой для получения результата (выхода). Входит в левую грань работы. Работа может не иметь ни одной стрелки входа.
Управление (Control) - правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Каждая работа должна иметь хотя бы одну стрелку управления. Входит в верхнюю грань работы.
Часто сложно определить, являются данные входом или управлением. Подсказкой может служить, перерабатываются (изменяются) данные в работе или нет. Если изменяются, то скорее всего это вход, если нет - управление.
Выход (Output) - материал или информация, которые производятся работой. Каждая работа должна иметь хотя бы одну стрелку выхода. Работа без результата не имеет смысла и не должна моделироваться. Выходит из правой грани работы.
Механизм (Mechanism) - ресурсы, которые выполняют работу (персонал предприятия, станки, устройства и т. д.). Входит в нижнюю грань работы. По усмотрению аналитика механизм может не изображаться в модели.
Вызов (Call) - специальная стрелка, указывающая на другую модель работы. Рисуется как исходящая из нижней грани работы. Указывает на то, что некоторая работа выполняется за пределами моделируемой системы.
Построение SADT-модели начинается с представления всей системы в виде контекстной диаграммы . Контекстная диаграмма представляет самое общее описание системы и ее взаимодействия с внешней средой. Имеет вид одного блока и дуг, изображающих набор внешних интерфейсов системы. Затем проводится разбиение системы на крупные фрагменты (функциональная декомпозиция) . Декомпозиция выявляет полный набор подфункций, каждая из которых показана как блок с интерфейсными стрелками. Каждая подфункция может быть декомпозирована для большей детализации. Получаемые диаграммы называются диаграммами декомпозиции .
ЭТАПЫ РАЗРАБОТКИ АВТОМАТИЗИРОВАННЫХ ИНФОРМАЦИОННЫХ СИСТЕМ
С позиций трансформации бизнес-модели в объекты базы данных и приложения можно выделить следующие основные этапы разработки АИС:
1. Разработка и анализ бизнес-модели
Определяются основные задачи АИС, проводится декомпозиция задач по модулям и определяются функции с помощью которых решаются эти задачи. Описание функций осуществляется на языке:
• производственных требований (описание процессов предметной области);
• функциональных требований (описание форм обрабатываемых документов);
• технических требований (аппаратное, программное, лингвистическое обеспечение АИС).
Исследование бизнес-процессов банка или предприятия - необходимо выяснить, кому и почему выгодно выполнять те или иные процессы, имеющие место.
Метод решения : Функциональное моделирование.
Результат:
• концептуальная модель АИС, состоящая из описания предметной области, ресурсов и потоков данных, перечень требований и ограничений к технической реализации АИС;
• аппаратно-технический состав создаваемой АИС.
2. Формализация бизнес-модели, разработка логической модели бизнес-процессов
Разработанная концептуальная модель формализуется, т.е. воплощается в виде логической модели АИС.
Метод решения : Разработка CASE-диаграмм, диаграмм "сущность-связь" (ERD - Entity-Reationship Diagram).
Результат : Разработанное информационное обеспечение АИС - схемы и структуры данных для всех уровней модульности АИС, документация по логической структуре АИС, сгенерированные скрипты для создания объектов БД.
3. Выбор лингвистического обеспечения, разработка программного обеспечения АИС
Разработка АИС: выбирается лингвистическое обеспечение (среда разработки - инструментарий), проводится разработка программного и методического обеспечения. Разработанная на втором этапе логическая схема воплощается в реальные объекты, при этом логические схемы реализуются в виде объектов базы данных, а функциональные схемы - в пользовательские формы и приложения.
Метод решения: Разработка программного кода с использованием выбранного инструментария.
Результат: Работоспособная АИС.
4. Тестирование и отладка АИС
На данном этапе осуществляется корректировка информационного, аппаратного, программного обеспечения, проводится разработка методического обеспечения (документации разработчика, пользователя) и т.п.
Результат:
• оптимальный состав и эффективное функционирование АИС.
• комплект документации: разработчика, администратора, пользователя.
5. Эксплуатация и контроль версий.
Особенность АИС созданных по архитектуре <клиент сервер> является их многоуровневость и многомодульность, поэтому при их эксплуатации и развитии на первое место выходят вопросы контроля версий, т.е. добавление новых и развитие старых модулей с выводом из эксплуатации старых. Например, если ежедневный контроль версий не ведется, то в как показала практика, БД АИС за год эксплуатации может насчитывать более 1000 таблиц, из которых эффективно использоваться будет лишь 20-30%.
Результат: Наращиваемость и безизбыточный состав гибкой, масштабируемой АИС.
РЕИНЖИНИРИНГ БИЗНЕС-ПРОЦЕССОВ
Цель реинжиниринга бизнес-процессов - системная реорганизация материальных, финансовых и информационных потоков, направленная на упрощение организационной структуры, перераспределение и минимизацию использования ресурсов, повышение качества обслуживания клиентов.
Реинжиниринг бизнеса предусматривает новый способ мышления - взгляд на построение компании как на инженерную деятельность . Компания или бизнес рассматривается как нечто, что может быть построено, или перепроектировано в соответствии с инженерными принципами.
Этапы реинжиниринга бизнес-процессов
Работы по идентификации БП инициируют менеджеры верхнего звена - лица, принимающие решения. На специальных двухдневных семинарах руководителей предприятия решаются следующие задачи :
• формулирование (уточнение) миссии предприятия;
• определение критических факторов успеха (7-8 факторов) - длительность, издержки, качество, сервисное обслуживание и т. д.;
• выявление основных видов БП, как существующих, так и перспективных (10-15 процессов);
• оценка важности БП по степени влияния на реализацию критических факторов успеха.
• определение ограничений, связанных с уровнем квалификации персонала, технической оснащенности, наличием информационных технологий, финансовых ресурсов;
• описание возможных сценариев развития предприятия - появление новых технологий, ресурсов, изменение поведения клиентов, партнеров, конкурентов;
• определение внешних рисков обеспечения финансовыми ресурсами, надежности партнеров, конъюнктуры рынка;
• ранжирование БП для проведения РБП в соответствии с оценкой важности, ограничениями, рисками и перспективами.
Обратный инжиниринг предполагает исследование существующих на предприятии БП. Цель - проведение диагностики <узких мест> в организации существующих БП и формулирование направлений их реорганизации.
Для оценки эффективности существующих БП используются методы и средства функционально-стоимостного анализа , позволяющие выявить:
• наиболее трудоемкие и затратные функции;
• функции, не вносящие вклад в образование прибыли; функции с низким коэффициентом использования ресурсов.