Проектирование экономических информационных систем
Методологические основы проектирования экономических информационных систем (ЭИС). Методология оригинального проектирования. Реинжиниринг бизнес-процессов корпоративных ЭИС. Автоматизированное проектирование ЭИС. Методы управления проектными работами.
Рубрика | Программирование, компьютеры и кибернетика |
Вид | учебное пособие |
Язык | русский |
Дата добавления | 21.10.2017 |
Размер файла | 791,1 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Достижение множества целей осуществляется путем выполнения соответствующего множества бизнес-процессов. Оценка степени достижения целей осуществляется с помощью значений показателей оценки эффективности бизнес-процессов.
Целевое состояние предприятия характеризуется множеством требуемых значений показателей эффективности бизнес-процессов.
Для того чтобы предприятие было переведено из текущего состояния в целевое, требуется выполнить такое преобразование дерева целей и множества бизнес-процессов, которое обеспечивает получение требуемых значений показателей. Другими словами, нужно разработать методологический подход организации и реорганизации деятельности предприятия, обеспечивающий:
ь проведение анализа и оценки эффективности функционирования предприятия;
ь создание плана мероприятий перевода предприятия из текущего состояния в целевое, а также поддержания предприятия в требуемом состоянии;
ь реализацию плана мероприятий.
Чтобы расхождения между ожидаемыми и достигнутыми результатами были минимальными, необходимо сначала реализовать небольшие проекты с реальными задачами. Методологический подход организации и реорганизации деятельности предприятия это есть проектирование КИнС.
Организация и реорганизация деятельности предприятия -- большая работа. Только после глубокого изучения структуры деятельности предприятия можно рассчитывать на удачу.
На тернистом пути организации и реорганизации деятельности предприятия возникает множество препятствий. Вот некоторые из них:
ь сопротивление изменениям, свойственное любому человеку (главное препятствие);
ь ограничения, налагаемые уже существующими технологиями и системами;
ь отсутствие у администрации единства взглядов на процесс реорганизации;
ь отсутствие активных сторонников среди высшего руководства.
5.2 Структура корпоративных ЭИС
Под предприятием понимается любая бизнес-система коммерческой, производственной, государственной и банковской природы. В качестве исходных данных формирования типовых решений используются результаты, полученные в процессе реорганизации деятельности бизнес-системы.
Процесс проектирования корпоративной информационной системы (КИнС) предприятия (далее бизнес-система) включает две основные последовательно выполняемые стадии:
ь предпроектное обследование и системное моделирование деятельности бизнес-системы;
ь разработка системного, эскизно-технического и рабочего проектов КИнС бизнес-системы.
Основными результатами выполнения предпроектного обследования и моделирования деятельности бизнес-системы являются предложения по построению:
ь рациональных технологий работы структурных подразделений бизнес-системы с учетом существующих средств автоматизации;
ь оргштатной структуры бизнес-системы, осуществляющей реализацию рациональных технологий работы;
ь информационных потоков и документооборота, обеспечивающих реализацию рациональных технологий работы.
Реализация полученных предложений способствует более эффективному достижению поставленных перед бизнес-системой целей с заданным уровнем качества, оцениваемым, как правило, количеством покупателей продукции и издержками ее производства. Фактически реализация предложений по совершенствованию деятельности бизнес-систем приводит к необходимости их реорганизации, причем опыт выполнения консалтинговых проектов показывает, что дальнейшее проектирование КИнС без учета предложений по совершенствованию деятельности бизнес-системы либо обречено на неудачу, либо приводит к трудоемкому, длительному и явно затратному процессу разработки, внедрения и сопровождения системы, не говоря уже об эффективности ее применения. Поэтому исходными данными для формирования решений, закладываемых в системный, эскизно-технический и рабочий проекты КИнС, являются результаты реализации предложений по совершенствованию деятельности бизнес-системы.
Двухступенчатый подход к проектированию КИнС бизнес- позволяет сформулировать общие типовые технические решения построения КИнС.
В самом общем виде КИнС бизнес-системы включает в свой состав:
ь информационное обеспечения деятельности бизнес-системы;
ь технические средства КИнС;
ь программное обеспечения деятельности бизнес-системы;
ь организационно-правовое обеспечение функционирования КИнС.
Типовые решения построения информационного обеспечения
В основе построения информационного обеспечения деятельности бизнес-системы лежит концепция информационного пространства, обобщенная структура которого приведена на рис. 2. В состав информационного пространства КИнС бизнес-системы входят:
ь фактографические базы данных;
ь базы документов;
ь базы прецедентов и знаний;
ь предметно-ориентированные базы.
В фактографических базах данных хранится структурированная оперативная информация о ходе выполнения типовых операций (например, заказов потребителей продукции, процессе производства продукции и ее сбыте), а также архивная структурированная информация, характеризующая ретроспективу типовых операций. Под продукцией в данном случае понимаются товары, услуги, материалы, информация или документы.
В базах документов хранится неструктурированная информация (текстовые и графические документы), связанная с типовыми операциями, например заказами потребителей, потребителями, продукцией, конкурентами и т.д.
Фактографическая информация базы данных и базы документов отличается степенью актуальности. Наиболее актуальная находится в оперативных базах данных и базах документов. С течением времени определенная часть информации оперативных баз данных и баз документов переходит в разряд архивной и хранится в архивных базах данных.
В процессе выполнения типовых операций, таких как заказы потребителей по заданным позициям, производство и сбыт продукции, формируется определенный опыт ведения бизнес-процессов. Для накопления опыта используются базы прецедентов и знаний.
С помощью информационного хранилища КИнС осуществляется быстрый доступ к предметно-ориентированным базам данных различного типа, представленных в виде логических групп (оперативные, архивные и внешние фактографические и текстовые данные, прецеденты и знания). Структура данных хранилища ориентирована на конкретные предметы, к которым они относятся, например продукцию, оргштатную структуру, финансы, сбыт, производство, потребителей, конкурентов и т.п. Именно информационное хранилище способно обеспечить оперативную аналитическую обработку и выдачу рекомендаций по поведению в различных ситуациях, возникающих при функционировании бизнес-системы.
В настоящее время в ряде консалтинговых проектов апробируется определенная методология построения информационного пространства. Поэтому описание метода проектирования информационного пространства КИнС бизнес-систем, результаты его применения и, главное, методика построения информационного хранилища являются темой дальнейших исследований.
В соответствии с концепцией информационного пространства КИнС и с учетом интеграции данных для их применения различными структурными подразделениями бизнес-системы информационное обеспечение состоит из нескольких уровней. Обобщенная структура информационного обеспечения КИнС приведена на рис. 5.3.
На первом уровне находятся локальные фактографические базы данных структурных подразделений бизнес-системы. На втором уровне расположены интегрированные фактографические базы данных функциональных подсистем бизнес-системы. Третий уровень содержит информацию интеллектуального плана, необходимую для процесса принятия решения, а также документарные базы данных. На четвертом уровне помещено информационное хранилище.
Типовые решения построения технических средств
В общем случае технические средства всей бизнес-системы строятся в виде мультисети, включающей несколько многосегментных локальных вычислительных сетей. Каждый сегмент локальной вычислительной сети имеет архитектуру «клиент/сервер», включает в свой состав несколько рабочих станций -- рабочих мест должностных лиц структурных подразделений бизнес-системы и несколько функционально разделенных серверов.
Обобщенная структура односегментной локальной вычислительной сети КИнС приведена на рис. 5.1. В том случае, когда объем данных, находящихся в информационном хранилище, либо слишком велик, либо КИнС необходимо реализовать в среде мультисети, целесообразно расположить корпоративное хранилище данных на отдельном сервере (см. рис. 5.2).
Типовые решения построения программного обеспечения.
ПО КИнС бизнес-системы включает в себя системное и прикладное программное обеспечение и имеет многоуровневую структуру. На рис. 5.6 представлена обобщенная многоуровневая структура программного обеспечения.
На первом уровне структуры находится системное программное обеспечение, в состав которого входят:
ь операционная система клиента;
ь сетевые протоколы.
Сетевая многозадачная многопользовательская операционная система обеспечивает:
ь поддержку многопользовательского многозадачного режима работы;
ь поддержку сетевых протоколов;
ь интеграцию с сетями общего доступа;
ь выбор прикладных пакетов;
ь перенос разработанного программного обеспечения на новые версии ОС с минимальными затратами;
ь гибкий механизм предоставления прав доступа к данным и вычислительным ресурсам;
ь выбор аппаратных платформ от ПЭВМ до RISC-ЭВМ и больших многопроцессорных систем. ПО сервера базы данных обеспечивает:
· возможность работы с базами данных большого количества пользователей;
· целостность и достоверность информации;
· использование находящегося в эксплуатации оборудования (ПЭВМ) в качестве автоматизированных мест путем подсоединения его к общей сети;
· CASE-средства, поддерживающие полный цикл создания прикладных программ -- от спецификации до сопровождения;
· использование стандартного языка запросов к базе данных (SQL);
· мощную систему обработки текстовых данных;
· высокую скорость реакции на запросы;
· широкий спектр вспомогательных средств, позволяющих осуществлять доступ к базам данных по сети, автоматизировать разработку пользовательского интерфейса, интегрировать программы, написанные на языках высокого уровня;
· задание структуры форм выходных документов (справок, отчетов);
· формирование содержания выходных документов (справок, отчетов) заданной структуры;
· выдачу выходных документов (справок, отчетов) на рабочее место сотрудника структурного подразделения.
Программное обеспечение сервера управления документооборотом позволяет осуществлять:
ь управление и обработку по заданному алгоритму (процедуре) в автоматическом или интерактивном режиме потоков документов и информации, циркулирующих как внутри структурных подразделений, так и между ними по заданным маршрутам;
ь интеграцию с необходимыми для работы средствами, работающими под MS-DOS / MS-Windows, и сетевой многопользовательской операционной системой, а именно текстовыми редакторами, электронной почтой (включая системы с протоколами Х25 и Х400), фактографическими базами данных, базами прецедентов, базами документов, электронными таблицами, средствами управления документами, автономными функциональными системами;
ь гибкую настройку на оргштатную структуру бизнес-системы и представленные в функционально-информационных моделях деятельности структурных подразделений технологии обработки документов, а также быструю перенастройку в случае изменения структуры бизнес-системы;
ь назначение и синхронизацию времени поступления документов к должностным лицам структурных подразделений бизнес-системы и контроль за сроком реакции на отдельные документы;
ь предоставление всей текущей информации по движению и готовности документов в виде различных отчетов и сообщений;
ь отслеживание прав доступа к закрытой информации, поддержку системы паролей и электронных подписей;
ь поддержку сервера базы прецедентов, обеспечивающего:
· описание текущей проблемы по актуальной типовой операции на естественном языке в произвольной форме;
· автоматическое сопоставление (сравнение) информации о проблеме с деталями прецедентов, хранящихся в базе прецедентов, для выявления аналогичных случаев;
· выбор прецедента выполненных типовых операций по позициям, которые наиболее близки к текущей проблеме, из базы прецедентов;
· поиск прецедентов по нечетко заданным критериям (контексту);
· задание вопросов в произвольной форме для уточнения текущей проблемы;
· автоматический анализ результатов ответов;
· уточнение результатов выбора прецедентов;
· формирование рекомендаций;
· занесение детальной информации о новом прецеденте выполненных типовых операций по позициям в базы прецедентов;
· возможность автоматического построения баз прецедентов выполненных типовых
· операций по позициям.
ПО сервера управления хранением и поиском документов обеспечивает:
ь простой и быстрый ввод текстовой и нетекстовой информации путем сканирования или считывания с магнитных и оптических дисков, лент и модемов;
ь распознавание информации;
ь решение проблемы ошибок распознавания;
ь автоматическую индексацию полного содержания документа;
ь рациональный объем создаваемой для поиска индексной информации по отношению к полезной информации документа;
ь поддержку взаимодействия с фактографической базой данных;
ь осуществление поиска по нечеткому критерию, заданному в свободной форме;
ь поиск по ключевым словам, названиям документов, именам папок, ящиков и шкафов;
ь поиск информации по синонимам;
ь поиск информации по значениям полей с использованием логических операторов.
Второй и последующие уровни связаны с прикладным программным обеспечением. В частности, на втором уровне находятся функциональные подсистемы для задач информационно-справочного типа, а также автономные функциональные подсистемы, входящие в состав конкретных рабочих мест КИнС.
Третий уровень содержит функциональные подсистемы обеспечения управления документооборотом в структурных подразделениях бизнес-системы в целом. Данные подсистемы обеспечивают поддержку управления, мониторинга, маршрутизации документооборота, а также контроля исполнения приказов, распоряжений и поручений по документам.
На четвертом уровне расположены функциональные подсистемы, обеспечивающие сотрудникам компании процесс поддержки принятия решения, а также системы, обеспечивающие работу с текстовыми документами и их графическими образами, и системы работы с хранилищем данных бизнес-системы.
Все прикладные уровни базируются на соответствующем сервере первого (системного) уровня и представляют собой программное обеспечение специализированных рабочих мест.
Типовые решения построения организационно-правового обеспечения
В состав организационно-правового обеспечения КИнС бизнес-системы входят:
ь описание структуры и функций КИнС;
ь описание обобщенного алгоритма применения КИнС структурными подразделениями бизнес-системы в процессе своей деятельности;
ь должностные инструкции для обслуживающего персонала КИнС, а именно для администраторов баз данных, документы прецедентов, хранилища данных, ЛВС и др.;
ь общее описание технологических процессов обработки данных;
ь руководства пользователей КИнС.
Рис. 5.1. Обобщённая структура мультисети КИнС
Рис.5.2. Структура информационного обеспечения КИнС
Рис.5.3.Обобщённая структура информационного пространства
Рис.5.4.Обобщенная структура программного обеспечения КИнС
Характерной чертой приведенных типовых решений является необходимость разработки в первую очередь решений по построению корпоративного информационного пространства бизнес-системы. Это связано с тем, что именно информационное пространство несет смысловую нагрузку эффективности применения КИнС структурными подразделениями бизнес-системы. Поэтому принятые решения построения информационного пространства являются исходными данными для формулирования обоснованных решений построения программного обеспечения, технических средств его поддержки и соответствующего организационно-правового обеспечения функционирования КИнС.
С другой стороны, типизация решений построения информационной системы предприятия должна привести к стандартизации процесса построения КИнС, что позволит снизить трудоемкость и стоимость создания системы при одновременном повышении качества функционирования КИнС. Особенно эффективно можно будет использовать стандартизацию типовых решений систем в одной и той же предметной области, например производственной, коммерческой или банковской сфере.
5.2.1 Расчёт экономической эффективности КИнС
В результате выполнения стадий проектирования в системный, эскизно-технический и рабочий проекты с различным уровнем детализации закладываются только те типовые решения построения информационного и аппаратно-программного обеспечения КИнС , которые обеспечивают эффективную реализацию рациональных технологий работы усовершенствованной орг-штатной структуры бизнес-системы с соответствующими информационными потоками и документооборотом.
Поэтому очень важно при оценке эффективности учитывать, с одной стороны, новые рациональные технологии работы структурных подразделений, а с другой -- уровень их автоматизированной поддержки в рамках КИнС бизнес-системы.
При этом оценка эффективности применения КИнС может быть сведена к оценке эффективности автоматизированных рациональных технологий работы структурных подразделений по сравнению с существующими технологиями и средствами их автоматизации.
Оценка эффективности применения КИнС бизнес-системы проводится в несколько этапов.
На первом этапе показателем эффективности применения КИнС служит относительная трудоемкость процесса выполнения и обеспечения выполнения типовых операций (банковской операции, операций сбыта продукции, обработки заказа клиента и т.д.) при существующих и рациональных технологиях работы бизнес-системы. За величину трудоемкости можно принять сумму временных затрат всех структурных подразделений бизнес-системы, занятых в данной типовой операции.
Чтобы получить значения временных затрат каждого из подразделений, необходимо с помощью функционально-информационных моделей существующих и рациональных технологий работы структурных подразделений бизнес-системы:
ь установить в функционально-информационных моделях так называемые центры затрат, то есть параметры, характеризующие время выполнения функций структурными подразделениями в процессе работы;
ь задать в соответствии с центрами затрат конкретные значения указанных временных параметров, то есть время выполнения работ;
ь провести расчет трудоемкости выполнения типовой операции при использовании существующих и рациональных технологий.
Например, на рис.5.1 приведены результаты относительной оценки трудоемкости выполнения типовой операции при существующих и рациональных технологиях агентства занятости и трудоустройства. В качестве типовой операции в данном случае выступает выполнение заказа на трудоустройство клиента.
Рис. 5.1. Трудоемкость выполнения типовой операции
На втором этапе оценки эффективности необходимо определить количество типовых операций Z (например, подготовка документа), которые можно дополнительно выполнить за единицу времени по отношению к количеству выполняемых типовых операций при существующих технологиях работы и средствах автоматизации. Значение Z определяется выражением Z=a*K,
а=(1-2)/100% (5.2.1)
а -- показатель, характеризующий изменение трудоемкости при переходе от существующих технологий работы структурных подразделений к рациональным технологиям;
1 -- трудоемкость выполнения типовой операции при существующих технологиях работы;
2 -- трудоемкость выполнения типовой операции при рациональных технологиях работы структурных подразделений;
К -- среднее количество типовых операций, выполняемых в настоящее время.
Например, если принять, что в настоящее время К = 100 в месяц, 1 = 100%, а значение 2 = 80%, то получаем в среднем Z = 20. Таким образом, использование новых рациональных технологий работы структурных подразделений и КИнС, осуществляющей их автоматизированную поддержку, позволит дополнительно выполнить около 20 типовых операций в месяц.
Третий этап оценки связан с определением срока окупаемости затрат на разработку КИнС бизнес-системы.
Пусть S -- срок окупаемости затрат на разработку КИнС бизнес-системы определяется по формуле:
S = (Z * C)/N (5.2.2)
С-- средняя прибыль, получаемая бизнес-системой при выполнении одной типовой операции;
N-- стоимость разработки КИнС.
В свою очередь, стоимость разработки КИнС (N) можно определить по формуле:
N=s0+s1+s2+s3+s4 (5.2.3)
s0 -- стоимость проектирования КИнС бизнес-системы;
s1 -- стоимость закупаемых программно-аппаратных средств в соответствии с заданными спецификациями;
s2 -- стоимость развертывания или модификации ЛВС;
s3 -- стоимость разработки и отладки прикладного программного обеспечения, а также интеграции всего программного обеспечения в рамках КИнС бизнес-системы;
s4 -- стоимость разработки эксплутационной документации и обучения специалистов.
Рассмотрим следующий пример.
Пусть средняя стоимость типовой операции составляет 5000 р., а средняя прибыль от реализации этой типовой операции составляет 15 - 20% ее стоимости. Получаем при N = 100000 млн. р., учитывая, что срок минимальной работы системы составляет 2 года, S = 0,04 месяца
Следует отметить, что срок окупаемости рассчитывается исходя из прибыли, получаемой от осуществления дополнительных типовых операций, появление которых возможно только при использовании новых рациональных технологий работы структурных подразделений бизнес-системы и средств автоматизации их поддержки.
Оценка эффективности применения КИнС бизнес-системы имеет важное значение при принятии решений о финансировании разработки информационной системы по созданному системному проекту. Предложенный способ достаточно прост, обеспечивает комплексность проведения оценки эффективности и позволяет дать ответы на следующие главные вопросы:
ь как изменится в процентном отношении эффективность работы основных подразделений бизнес-системы при перераспределении функций между подразделениями по
ь сравнению с существующим вариантом распределения функций;
ь сколько типовых операций (выполнение заказов, банковские операции, подготовка документов) дополнительно можно будет выполнить при внедрении новых рациональных технологий работы структурных подразделений по сравнению с существующими технологиями работы;
ь через какой срок можно окупить вложенные финансовые средства в разработку КИнС бизнес-системы, осуществляющей автоматизированную поддержку рациональных технологий работы структурных подразделений.
5.3 Технология проектирования корпоративных ЭИС
При проектировании КИнС могут быть рекомендованы следующие стадии.
1. Предпроектное обследование объекта управления.
2. Выбор технических средств.
3. Выбор СУБД
4. Выбор системы автоматизации документооборота.
5. Выбор программных средств для управления документами.
6. Выбор специализированных прикладных программных средств.
7. Выбор специального класса предложений систем поддержки принятия решений.
Предпроектное обследование объекта управления
ь Формулировка и описание функций каждого подразделения компаний.
ь Описание технологии работы “Как есть”.
ь Описание технологии работы “Как надо”.
ь Отображение технологии “Как надо” на структуру компании, определение её функционального состава, а так же описание функции каждого рабочего места.
ь Описание основных путей, а так же технологии их обработки.
Результатом обследования компании является её деятельность и информационная инфраструктура компании, конструирование модели деятельности, на базе которых разрабатывается проект системы и требования к техническому и программному обеспечению, описание основных путей и алгоритмы прохождения входной, выходной информации, а так же технологии их обработки.
Выбор технических средств.
По результатам исследования необходимо выбрать архитектуру системы. Для корпоративных систем рекомендуемая архитектура типа клиент-сервер. На 1998г. на эту архитектуру перешли 45% организаций в США. 50% в Европе и 29% в Японии.
Выбор СУБД.
Выбор СУБД целиком и полностью зависит от возможностей и желания заказчика, плюс имеющиеся СУБД на рынке.
Выбор системы автоматизации документооборота.
Обеспечение высокой производительности в рамках решения задач по документообороту.
Гибкость системы (способность настраиваться на любые документы фирмы).
Простота в использовании, обслуживании, возможность работать на русском языке.
Выбор программных средств для управления документами.
Сокращение потока бумажных документов. Уменьшение затрат времени связанных с поиском. Только электронные документы. Основной способ ввода информации - сканирование.
Выбор специализированных прикладных программных средств.
Этот выбор зависит от специфики работы фирмы.
Выбор специального класса приложений системы поддержки принятия решений.
Основано на технологии искусственного интеллекта.
На первом этапе это были экспертные системы, а затем появилась технология вывода на основе прецедента. Прецедент - это описание проблемы или ситуации в совокупности с подробным указанием действий предпринимаемых в данной ситуации или для решения данной проблемы.
Интеллектуальная система, использующая прецеденты состоит из следующих компонентов:
1. Получение подробной информации о текущей проблеме.
2. Сопоставление этой информации с прецедентами хранящимися в базе для выявления аналогичных случаев.
3. Выбор прецедентов наиболее близких к текущей проблеме.
4. Адаптация выбранного решения.
5. Проверка корректности полученного решения.
6. Занесение детальной информации прецедентов в БД.
Требования и принципы, предъявляемые к КИнС.
Основные принципы построения:
1. Интеллектуальность - управление предприятием отличное от традиционного подхода регистрации и накопления информации.
2. Интеграция - сквозное прохождение документов через различные службы предприятия.
3. Модульность - возможность поэтапного внедрения системы.
4. Доступность - наличие полного комплекта документации, подсказок, удобство ввода.
5. Открытость системы - возможность сопряжения с другими программными системами.
6. Адаптивность - возможность наличия всевозможных настроек способных создавать различные модификации эксплуатации системы.
7. Минимальная - максимальная полнота КИнС - наличие функциональных задач, способных работать в этой системе.
Минимальная система задач:
1. Планирования, бюджетирования, прогнозирования
2. Оперативный и управленческий учёт
3. Бухгалтерский учёт
4. Финансово- экономический анализ
Система должна обеспечивать надёжную защиту информации. Для этого необходима парольная система разграничения доступа к данным и функциям. Многоуровневая система защиты данных. Авторизация вводимой и корректируемой информации. Время ввода и модификации данных. Количество учитываемых параметров должно быть от 2000 до 10000, а количество таблиц БД в современных КИнС колеблется от 800 до 3000 тысяч.
На рис.5.7 представлена ТСП проектирования КИнС, в котором приняты следующие обозначения:
П1 - информационное обследование объекта управления
Вход:
Д1 - организационные документы предприятия
Д2 - поток экономических документов
Д3 - методика информационного обследования предприятия
G1 - программный комплекс CASE - технологий обследования
Выход:
Д4 - фирма «как есть»
Д5 - ТЗ
U1 - описание комплекса технических средств
Д6 - фирма «как надо»
П2 - выбор архитектуры вычислительных средств
Вход:
Д6 - фирма «как надо»
U1 - описание комплекса технических средств
Д7 - требования заказчика
Выход:
Д8 - комплекс технических средств (архитектура системы)
П3 - выбор СУБД
Вход:
Д8 - комплекс технических средств (архитектура системы)
U2 - существующие СУБД
Выход:
Д9 - требования к СУБД
П4 - выбор системы автоматизации документооборота
Вход:
Д9 - требования к СУБД
Выход:
Д10 - описание системы документооборота
П5 - выбор системы управления электронным документооборотом
Вход:
Д8 - комплекс технических средств (архитектура системы)
Д9 - требования к СУБД
Д10 - описание СУБД
Д11 - описание системы документооборота
Выход:
Д11 - описание системы документооборота
П6 - выбор специализированных прикладных программных средств по решению функциональных задач
Вход:
Д9 - требования к СУБД
Д10 - описание СУБД
Д11 - описание системы документооборота
Выход:
Д14 - описание функциональных задач (руководство пользователя) через описание методов анализа
П7 - построение систем поддержки принятия управленческих решений (ППУР)
Вход:
Д14 - описание функциональных задач (руководство пользователя) через описание методов анализа
U3 - существующие экспертные системы поддержки принятия решений
Выход:
Д14 - описание систем ППУР
G2 - программный комплекс системы ППУР
Контрольные вопросы
1. Что такое бизнес-процесс на предприятии?
2. Какой категории бывают бизнес-процессы?
3. Чем характеризуются бизнес-процесс?
4. Чем характеризуется текущее состояние бизнес-системы?
5. Что такое целевое состояние бизнес-системы?
6. Определите структуру технического состояния КИнС.
7. Определите структуру информационного обеспечения КИнС.
8. Какова структура информационного обеспечения КИнС?
9. Какую структуру имеет организационно-правовое обеспечения КИнС?
10. Сколько этапов проходит определение оценки эффективности КИнС?
11. Какие вопросы решает определение оценки эффективности КИнС?
Глава 6. Автоматизированное проектирование ЭИС
6.1 Проектирование ЭИС средствами САПР на основе гипотетической модели
При разработке экономических информационных систем (ЭИС) с помощью модельного метода проектирования применяется системный подход; при этом на всех стадиях проектирования предполагается использование ЭВМ. Ключевым требованием, предъявляемым к системам автоматизированного проектирования, реализующим основные концепции модельного проектирования, является возможность построения и поддержания в адекватном состоянии некоторой глобальной модели экономической информационной системы объекта управления. Моделью ЭИС будем называть некоторое отображение информационных компонентов объекта управления и отношений между ними, заданное в явном виде. Основная цель построения модели ЭИС -- автоматизированное создание соответствующего этой модели проекта системы машинной обработки данных, учитывающей и активно использующей характеристики ЭИС Объекта.
В основу разработки некоторых систем проектирования средствами САПР положен метод информационного моделирования, заключающийся в использовании на всех стадиях проектирования гипотетической модели (ГМ).
Гипотетическая модель -- модель ЭИС обобщенного (гипотетического) объекта управления.
Использование ГМ обеспечивает: накопление, обобщение и хранение сведений об ЭИС некоторого класса объектов управления; системный анализ данных об ЭИС объектов управления с точностью до реквизитов, показателей и взаимосвязей между ними; создание модели ЭИС конкретного объекта, предназначенной для генерации ЭИС, включая построение структуры базы данных и программных средств ее ведения.
Структурными элементами гипотетической модели являются: каталог реквизитов; каталог показателей; матрица реквизитного состава показателей; направленный граф, определяющий информационные и алгоритмические связи показателей; формулы расчета показателей; матрица связей показателей с выходными и входными документами; таблица описаний входных документов; таблица описаний выходных документов.
В целом информационная модель представляет собой некоторое статическое отображение ЭИС объекта или класса объектов.
Гипотетическая модель является информационной базой системы машинного проектирования ЭИС и служит накопителем проектных решений ЭИС для соответствующего класса объектов.
Для создания гипотетической модели используются специальные языковые средства, позволяющие описывать как отдельные фрагменты и структурные элементы, так и информационную модель в целом.
Из гипотетической модели посредством параметрического описания предметной области формируется модель ЭИС конкретного объекта управления. При необходимости модели ЭИС объекта она дополняется оригинальными проектными решениями. В дальнейшем такая модель объекта активно используется при проведении работ на всех последующих этапах проектирования (выбор комплекса технических средств, структурирование базы данных, создание программ ее организации и ведения, генерирования программ обработки данных) и при сопровождении созданного проекта системы.
Следует заметить, что гипотетическая информационная модель является одноуровневой.
Этапы процесса автоматизированного проектирования составляют следующую последовательность:
1. Обследование информационной системы предприятия;
2. Настройка гипотетической модели по параметрам конкретного предприятия;
3. Автоматизированное проектирование базы данных;
4. Автоматизированное составление программ функциональных задач (кодогенерация программ);
5. Автоматизированное тестирование;
6. Автоматизированное составление проектной документации.
Процесс автоматизированного проектирования должен поддерживаться определенными инструментальными средствами.
Трудности применения метода автоматизированного проектирования на базе одноуровневых моделей возникают не в связи с количеством типов элементов модели, а в связи с большой размерностью задачи.
Значительно лучше соответствуют большой размерности задачи иерархические САSЕ-модели.
6.2 Анализ систем автоматизированного проектирования ЭИС
В основу анализа САПР положены эксплуатационные характеристики систем с учетом требований как проектировщика, так и пользователя системы проектирования.
Рассмотрим следующие параметры: структурированность, функциональная полнота и степень автоматизации.
Структурированность САПР означает, что каждая функция проектирования реализуется автономным комплексом системы, который должен функционировать независимо от остальных. Кроме того, каждый комплекс должен быть снабжен необходимой эксплуатационной документацией, где четко оговариваются требования к форме представления входной информации и дается полное описание выходной. Этой характеристике трудно поставить в соответствие некоторый параметр, имеющий явное количественное значение.
Параметр функциональной полноты САПР (Пф) может быть определен следующим образом:
Пф = К1/К2 (6.1)
где K1 -- число операций канонической технологической сети проектирования системы проектирования, выполняемых с помощью САПР; K2--общее число операций канонической технологической сети проектирования системы.
Степень автоматизации процесса проектирования системы при использовании САПР будем определять по формуле:
А = (Т2 - Т1)/Т2 , (6.2)
где T1--суммарная трудоемкость выполнения технологических операций проектирования, входящих в ТСП системы проектирования, построенную с учетом использования САПР; Т2 -- суммарная трудоемкость выполнения технологических операций канонической ТСП.
В свою очередь Т1 и Т2 определяются так:
(6.3)
(6.4)
где ti - трудоёмкость выполнения i-й технологической операции ТСП в условиях использования системы САПР; I - число технологических операций ТСП ЭИС, построенной с учётом использования САПР; tj - трудоёмкость выполнения j -й технологической операции канонической ТСП ЭИС; J - число технологических операций канонической ТСП ЭИС.
6.2 Проектирование с использованием CASE-технологий
Аббревиатура CASE (Computer-Aided Software/System Engineering) используется в довольно широком смысле. Первоначальное использование термина CASE было ограничено вопросами автоматизации разработки только лишь программного обеспечения, а в настоящие время охватывает процесс разработки сложных ЭИС в целом.
Большинство существующих CASE-систем ориентировано на автоматизацию проектирования и основано на методологиях структурного или объектно-ориентированного проектирования и программирования, использующих спецификации в виде диаграмм или текстов для описания системных требований, связей между моделями системы, динамики поведения системы и архитектуры программных средств.
Рассмотрим методологические основы CASE-технологии.
Основой CASE-методологии является моделирование. CASE-технология -- это модельный метод автоматизации проектирования системы.
CASE-технология основана на парадигме:
методология -- метод -- нотации -- средства.
Методология определяет общие подходы к оценке и выбору варианта системы, последовательность стадий и этапов проектирования, подходы к выбору методов.
Метод конкретизирует порядок проектирования отдельных компонентов системы (например, известны методы проектирования потоков данных в системе, задания спецификаций (описаний) процессов, представления структур данных в хранилище и т.д.).
Нотации -- это графические средства обозначения и правила, предназначенные для описания структуры системы, этапов обработки информации, структуры данных и т.д. Нотации включают графы, диаграммы, таблицы, блок-схемы, формальные и естественные языки.
Наконец, средства -- это инструментарий, средства автоматизации проектирования в виде программных продуктов для обеспечения интерактивного режима проектирования (создание и редактирование графического проекта информационной системы) и кодогенерации программ (автоматического создания кодов программ системы).
Методология проектирования на основе компьютерной поддержки очевидно требует построения формализованного описания информационной системы в виде информационной модели. Построение CASE-модели системы предусматривает декомпозицию системы и иерархическое упорядочивание декомпозированных подсистем.
Модель системы должна отражать:
ь функциональную часть системы;
ь отношения между данными;
ь переходы состояний системы при работе в реальном времени.
Для моделирования информационной системы в трех указанных аспектах используются следующих разновидности графических средств с определенными нотациями:
ь Диаграмма бизнес-функций (функциональные спецификации) BFD (Business Flow Diagram).
ь SADT (Structured Analysis and Design Technique) - технология структурного анализа проектирования и ее подмножество IDEF0
ь Диаграммы потоков данных -- DFD (Data Flow Diagrams). Они используются совместно со словарями данных и спецификациями процессов.
ь Диаграммы „сущность-связь" -- ERD (Entity Relationship Diagrams), показывающие отношения между данными.
ь Диаграммы переходов состояний -- STD (State Transitign Diagrams) для отражения зависящего от времени поведения системы (в режиме реального времени).
BFD позволяет представить структуру ИС, отражающую взаимосвязь различных задач (процедур) в процессе получения требуемых результатов.
Основными объектами BFD являются:
ь Функция - некоторое действие информационной системы, необходимое для решения экономический задачи.
ь Декомпозиция функции - разбиение функции на множество подфункций.
Изображение объектов диаграммы иерархии функций представлено в табл. 6.1. в нотациях Гейна-Сарсона и Йордана.
Таблица 6.1.
Изображение объектов диаграммы иерархии функций
Объект |
Нотация Гейна-Сарсона |
Нотация Йордана |
|
Функция |
|||
Декомпозиция функции |
Методология IDEFO. В методологии IDEF0 используются четыре основных понятия: функциональный блок, интерфейсная дуга, декомпозиция и глоссарий.
Функциональный блок обозначает определенную функцию в рамках рассматриваемой системы и в графическом виде обозначается прямоугольником. Каждая из четырех сторон этого прямоугольника имеет свое значение: левая сторона - вход, верхняя сторона -управление, нижняя сторона - механизм и правая сторона - выход.
Интерфейсная дуга обозначает элемент системы, который обрабатывается функциональным блоком или оказывает некоторое влияние на выполнение блоком своей функции. Графически интерфейсная дуга изображается в виде однонаправленной стрелки. В зависимости от того, к какой из сторон блока примыкает интерфейсная дуга, она носит название входящей, исходящей, управляющей или дуги механизма. Началом и концом каждой дуги могут быть только функциональные блоки, при этом началом может быть только выходная сторона блока, а концом - любые другие. При построении моделей функционирования предприятия входящими и исходящими дугами могут обозначаться финансовые потоки, материальные потоки (товары, сырье и др.), потоки информации (документы, устные распоряжения и др.) и ресурсы (персонал, оборудование и др.). Управляющими дугами обозначаются только объекты, относящиеся к потокам информации, а дугами механизмов - только ресурсы.
Декомпозиция предполагает разбиение сложного процесса на составные части. Уровень детализации процесса определяется непосредственно разработчиком модели. В результате общая модель процесса представляется в виде иерархической структуры отдельных диаграмм, что делает ее более обозримой. Модель IDEF0 всегда начинается с представления процесса как единого функционального блока с интерфейсными дугами, выходящими за пределы рассматриваемой области. Такая диаграмма называется контекстной. В пояснительном тексте к контекстной диаграмме должно быть указано краткое описание цели построения диаграммы и определена так называемая точка зрения.
Цель определяет те области деятельности предприятия, на которые необходимо обратить внимание в первую очередь. Например, модель, построенная с целью оптимизации процесса продаж, может существенно отличаться от модели, разработанной с целью повышения эффективности управления персоналом.
Точка зрения определяет направленность и уровень детализации разрабатываемой модели. Ее четкая фиксация позволяет упростить модель, исключив детализацию элементов, не являющихся существенными в данном случае. Например, функциональные модели одного и того же предприятия с точки зрения коммерческого директора и, скажем, руководителя службы безопасности будут явно отличаться по направленности их детализации. В процессе декомпозиции функциональные блоки диаграммы верхнего уровня детализируются на диаграмме следующего уровня.
Глоссарием называется набор определений, ключевых слов, повествовательных изложений и др., характеризующий объекты, отображенные на диаграмме. Глоссарий обеспечивает включение в диаграммы IDEF0 необходимой дополнительной информации. Например, для управляющей интерфейсной дуги «распоряжение об оплате» глоссарий может содержать перечень полей соответствующего Дуге документа, необходимый набор виз и т.д.
Пример структурной диаграммы IDEF0 приведен на рис. 6.1.
Ведущая роль в моделировании принадлежит DFD. DFD предназначена для отражения взаимосвязей источников и приемников данных (так называемых внешних сущностей по отношению к информационной системе), потоков данных, процессов обработки (вычислительных процессов, соответствующих функциям системы), хранилищ данных (накопителей).
Рис.6.1. Структурная диаграмма.
В качестве основных символов диаграмм потоков данных могут быть использованы следующие.
Как видно из обозначений DFD, эти диаграммы идентифицируют основные компоненты CASE-модели.
Графическое представление диаграммы потоков данных на экране дисплея обеспечивает наглядность моделирования и удобство корректировки основных компонентов модели в интерактивном режиме.
Поскольку графического представления недостаточно для точного определения компонентов DFD, используются текстовые описания и другие средства конкретизации процессов обработки и структуры данных.
Так, потоки данных конкретизируются в части их структуры в словарях данных. Каждый процесс (функция системы) может быть детализирована с помощью DFD нижнего уровня, где он разделяется на несколько процессов с одновременной детализацией потоков данных.
Таблица 6.2.
Основные символы диаграммы потоков данных
Символы DFD |
Нотация Гейна-Сарсона |
Нотация Йордона |
|
Поток данных |
|||
Процесс обработки |
|||
Хранилище данных |
|||
Внешняя сущность |
Детализация процессов заканчивается, когда описание каждого детализированного процесса может быть сделано с помощью выбранного метода написания алгоритма процесса. Спецификация процесса содержит номер и имя процесса, списки имен входных и выходных данных из словаря данных и алгоритм процесса, трансформирующий входные потоки данных во входные. В CASE-технологии используются такие методы задания алгоритмов процессов, как:
ь текстовое описание;
ь естественный структурированный язык;
ь таблицы решений;
ь деревья решений;
ь визуальные языки;
ь языки программирования.
Структурированный естественный язык легко понимается не только проектировщиками и программистами, но и конечными пользователями. В этом его достоинство. Однако он не обеспечивает автоматической кодогенерации из-за наличия неоднозначностей.
Таблицы и деревья решений, наглядно отражая связь комбинации условий с необходимыми действиями, не обладают процедурными возможностями для кодогенерации программ.
Визуальные языки обеспечивают автоматическую кодогенерацию, но представленные с их помощью спецификации процессов сложно корректировать.
Содержимое каждого хранилища данных, представленного на диаграмме потока данных, описывается словарем данных и моделью данных ERD. В случае работы системы в реальном времени DFD дополняется STD.
Важным методологическим принципом CASE-технологии создания информационной системы является четкое разделение процесса создания системы на 4 стадии:
ь предпроектную (стадию анализа, прототипирования, и построения модели требований к системе);
ь проектную, предполагающую логическое проектирование системы (без программирования);
ь стадию программирования (включая проектирование физической базы данных);
ь послепроектную, включающую в себя ввод в действие, эксплуатацию и сопровождение системы.
На предпроектной стадии строится модель требований к системе, т. е. подробное описание того, что она должна делать, без указания путей реализации требований.
На проектной стадии происходит уточнение модели требований (разработка подробной иерархической модели на основе DFD и спецификаций процессов) и расширение ее до модели реализации на логическом уровне. В заключение этой стадии происходит тщательный контроль проекта на уровне логической модели реализации.
На следующей стадии (программирования) осуществляется физическое проектирование системы. Эта стадия предусматривает автоматическую кодогенерацию по спецификациям процессов программного обеспечения системы и физическое проектирование базы данных.
Заключительная послепроектная стадия начинается с приемосдаточных испытаний. Далее следуют ввод в постоянную эксплуатацию, сопровождение и развитие системы.
Классификация CASE-средств
Интегрированное CASE-средство (или комплекс средств, поддерживающих полный жизненный цикл ЭИС) содержит следующие компоненты;
ь репозиторий, являющийся основой CASE-средства. Он должен обеспечивать хранение версий проекта и его отдельных компонентов, синхронизацию поступления информации от различных разработчиков при групповой разработке, контроль метаданных на полноту и непротиворечивость;
ь графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм (DFD, ERD и др.), образующих модели ИС;
ь средства разработки приложений, включая языки 4GL и генераторы кодов;
ь средства конфигурационного управления;
ь средства документирования;
ь средства тестирования;
ь средства управления проектом;
ь средства реинжиниринга.
Все современные CASE-средства могут быть классифицированы в основном по типам и категориям. Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы ЖЦ. Классификация по категориям определяет степень интегрированности по выполняемым функциям и включает отдельные локальные средства, решающие небольшие автономные задачи (tools), набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла ИС (toolkit) и полностью интегрированные средства, поддерживающие весь ЖЦ ИС и связанные общим репозиторием. Помимо этого, CASE-средства можно классифицировать по следующим признакам:
ь применяемым методологиям и моделям систем и БД;
ь степени интегрированности с СУБД;
ь доступным платформам.
Классификация по типам в основном совпадает с компонентным составом CASE-средств и включает следующие основные типы:
ь средства анализа (Upper CASE), предназначенные для построения и анализа моделей предметной области (Design/IDEF (Meta Software), BPwin (Logic Works));
ь средства анализа и проектирования (Middle CASE), поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций (Vantage Team Builder (Cayenne), Designer/2000 (ORACLE), Silverrun (CSA), PRO-IV (McDonnell Douglas), CASE.Аналитик (МакроПроджект)). Выходом таких средств являются спецификации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных;
ь средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL) для наиболее распространенных СУБД. К ним относятся ERwin (Logic Works), S-Designor (SDP) и DataBase Designer (ORACLE). Средства проектирования баз данных имеются также в составе CASE-средств Vantage Team Builder, Designer/2000, Silverrun и PRO-IV;
ь средства разработки приложений. К ним относятся средства 4GL (Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer/2000 (ORACLE), New Era (Informix), SQL Windows (Gupta), Delphi (Borland) и др.) и генераторы кодов, входящие в состав Vantage Team Builder, PRO-IV и частично - в Silvrrun;
ь средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций. Средства анализа схем БД и формирования ERD входят в состав Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin и S-Designor. В области анализа программных кодов наибольшее распространение получают объектно-ориентированные CASE-средства, обеспечивающие реинжиниринг программ на языке C++ (Rational Rose (Rational Software), Object Team (Cayenne)). Вспомогательные типы включают:
ь средства планирования и управления проектом (SE Companion, Microsoft Project и др.);
ь средства конфигурационного управления (PVCS (Intersolv));
ь средства тестирования (Quality Works (Segue Software));
ь средства документирования (SoDA (Rational Software)). На сегодняшний день Российский рынок программного обеспечения располагает следующими наиболее развитыми CASE-средствами:
ь Vantage Team Builder (Westmount I-CASE);
ь Designer/2000;
ь Silverrun;
ь ERwin
ь BPwin
ь S-Designor;
ь CASE-Аналитик.
Рассмотрим факторы эффективности CASE-технологии.
1. Следует отметить, что CASE-технология создает возможность и предусматривает перенос центра тяжести в трудоемкости создания системы на предпроектную и проектную стадии. Тщательная проработка этих стадий в интерактивном режиме с компьютерной поддержкой уменьшает число возможных ошибок в проектировании, исправлять которые на последующих стадиях затруднительно.
2. Доступная для понимания пользователей-непрограммистов графическая форма представления модели позволяет осуществить принцип пользовательского проектирования, предусматривающий участие пользователей в создании системы. CASE-модель позволяет достичь взаимопонимания между всеми участниками создания системы (заказчиками, пользователями, проектировщиками, программистами).
...Подобные документы
Методология структурного анализа и проектирования информационных систем. Базовый стандарт процессов жизненного цикла программного обеспечения. Цели и принципы формирования профилей информационных систем. Разработка идеальной модели бизнес-процессов.
презентация [152,1 K], добавлен 07.12.2013Технология разработки информационных систем (ИС). Жизненный цикл информационной системы. Состав и содержание работ на стадиях проектирования ИС. Проектирование унифицированной системы документации. Автоматизированное проектирование корпоративных ИС.
реферат [176,9 K], добавлен 15.04.2012Жизненный цикл информационных систем, методологии и технологии их проектирования. Уровень целеполагания и задач организации, классификация информационных систем. Стандарты кодирования, ошибки программирования. Уровни тестирования информационных систем.
презентация [490,2 K], добавлен 29.01.2023Особенности проектирования информационных систем основанных на базах данных. Использование CASE-средств и описание бизнес процессов в BP-Win. Этапы проектирования современных информационных систем, виды диаграмм и визуальное представление web-сайта.
курсовая работа [1,9 M], добавлен 25.04.2012Сущность проектирования информационных систем как поиска способа, который удовлетворяет требованиям функциональности системы средствами имеющихся технологий с учетом заданных ограничений. Характеристика даталогического и физического проектирования.
контрольная работа [30,7 K], добавлен 30.09.2011Основные области проектирования информационных систем: базы данных, программы (выполнение к запросам данных), топология сети, конфигурации аппаратных средств. Модели жизненного цикла программного обеспечения. Этапы проектирования информационной системы.
реферат [36,1 K], добавлен 29.04.2010Развитие информационных систем. Современный рынок финансово-экономического прикладного программного обеспечения. Преимущества и недостатки внедрения автоматизированных информационных систем. Методы проектирования автоматизированных информационных систем.
дипломная работа [1,5 M], добавлен 22.11.2015Недостатки позадачного подхода к проектированию. Понятие реинжиниринга бизнес-процессов предприятий, их структурные и оценочные характеристики, модели классификации. Структура бизнес-процесса SY, разработка систем и технологий. Правила декомпозиции.
презентация [409,8 K], добавлен 06.09.2015Анализ тенденций развития информационных технологий. Назначение и цели применения систем автоматизированного проектирования на основе системного подхода. Методы обеспечения автоматизации выполнения проектных работ на примере ЗАО "ПКП "Теплый дом".
курсовая работа [210,0 K], добавлен 11.09.2010Изучение понятия корпоративной информационной системы; требования к их разработке. Ознакомление с процессом проектирования и внедрения данных компьютерных технологий на производстве. Рассмотрение специфики работы корпоративных информационных систем.
курсовая работа [33,1 K], добавлен 02.11.2014Классификация информации по разным признакам. Этапы развития информационных систем. Информационные технологии и системы управления. Уровни процесса управления. Методы структурного проектирования. Методология функционального моделирования IDEF0.
курсовая работа [5,2 M], добавлен 20.04.2011Информационные системы - обычный программный продук, но они имеют ряд существенных отличий от стандартных прикладных программ и систем. Классификация, области применения и реализации информационных систем. Фазы проектирования информационных систем.
реферат [22,9 K], добавлен 05.01.2010Visual Basic for Application. Объекты и коллекции. Использование VBA в среде Access. Основы современной технологии проектирования АИС. Автоматизированное проектированиеCASE-технологий. Реинжиниринг бизнес-процессов и проектирование корпоративной ИС.
курсовая работа [2,1 M], добавлен 22.02.2008Теоретические основы проектирования информационно-справочных систем. Значение информационно-справочных компонент в корпоративных информационных системах. Разработка концептуальной и инфологической модели информационно-справочной системы ГОУ НПО ПУ №33.
дипломная работа [645,4 K], добавлен 02.09.2010Методы и технологии проектирования корпоративных сетей. Учет основных нужд предприятия в области информационных технологий при проектировании. Выбор схемы адресации сети, количества и функционального назначения серверов, настройка активного оборудования.
курсовая работа [360,3 K], добавлен 05.03.2012Анализ и проектирование информационных систем. Структурное и функциональное моделирование (Visio). Информационная модель базы данных для проектирования. Задача анализа статических состояний объекта проектирования (системы линейных и нелинейных уравнений).
курсовая работа [3,8 M], добавлен 05.04.2014Основы принятия проектно–конструкторских решений, направленных на получение описания системы, удовлетворяющего требованиям заказчика. Формальное определение операции проектирования, построение технологической сети. Описание документов на входе и выходе.
презентация [1,1 M], добавлен 19.10.2014Общее понятие, история возникновения и эволюция корпоративных информационных систем. Сущность, виды, возможности и механизм работы систем класса MRPII/ERP. Способы внедрения и оценка эффективности использования систем класса MRPII/ERP на предприятии.
курсовая работа [263,5 K], добавлен 03.06.2010Методология проектирования и особенности организации технического обслуживания информационных систем. Понятие, сущность, стадии, стандарты, структура и процессы жизненного цикла информационной системы, а также анализ достоинств и недостатков его моделей.
реферат [66,1 K], добавлен 07.05.2010Методологические основы оценки качества информационных ресурсов. Анализ принципов методологии, используемых при решении задач ОКФИС. Логика организации, ее теоретический базис, нормы и правила. Методы и средства моделирования информационных систем.
контрольная работа [66,7 K], добавлен 23.01.2011