Функциональная, информационная, математическая модели экономической информационной системы

Автор работы: Пользователь скрыл имя, 29 Марта 2012 в 15:17, шпаргалка

Описание

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

Работа состоит из  1 файл

Проектирование информационных систем.doc

— 548.00 Кб (Скачать документ)

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

         формирование запроса на исправление документов с ошибками и отсылка их к источнику информации, т.е. в то подразделение, из которого они поступили.

Если информация поступает на машинном носителе (гибком диске), то в этом случае проверяется качество записи диска, регистрируется имя файла, объем, источник и время поступления.

При поступлении информации по каналам связи определяется источник поступления, время, количество поступивших записей. Операция ввода информации в ЭВМ может осуществляться несколькими методами:

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

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

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

         визуальный контроль на экране дисплея ;

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

         документа или по всему документу до ввода в ЭВМ и после ввода ,

         которые затем сверяются между собой ;

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

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

         вводимых оператором второй раз ;

         метод двойного массива , при котором файлы по первичным

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

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

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

 


29. Технология решения задач в диалоговых системах.

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

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

-задач, обрабатываемых в диалоговом режиме;

-задач, обрабатываемых в пакетном режиме;

-задач, решаемых с использованием смешанного режима.

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

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

• составление “Технического задания” на разработку программного обеспечения задачи;

• разработка “Постановки задачи”;

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

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

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

• разработка экранов сообщений и описание их структуры;

• выбор языка программирования и написание текстов программы;

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

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

Средства разработки диалоговых систем.

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

1. метод оригинального проектирования с помощью таких средств программирования, как СУБД, языки Паскаль, С и другие, или

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

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

1. Первой операцией является разработка документа «Постановка задачи». На вход данной операции поступает документ «Техническое задание» и материалы обследования. Результатом выполнения операции является получение документа "Постановка задачи".

2. Далее осуществляется операция «Функциональный анализ задачи», выполнение которой позволяет определить состав функциональных блоков. Результатом этой операции служит функциональная блок-схема задачи.

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

4. Далее выполняется операция – «Разработка структуры программного обеспечения». В результате выполнения этой операции строится дерево программных модулей.

5. Операция – «Разработка информационного обеспечения» должна включать проектирование системы классификаторов, системы документации и информационной базы.

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

7. Операция «Разработка кодов программных модулей и выбор алгоритмического языка»  осуществляется на основе универсума языка программирования. На выходе получают документы с кодами программных модулей.

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

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

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

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

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

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

• формирование контрольных примеров и их отладка по каждой задаче;

• подготовка программной и технологической документации.

 


30. Методология проектирования «сверху-вниз».

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

Проектирование методом "сверху-вниз" (Метод "Шахт")

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

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

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

бухгалтерский учёт и т.д.

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

Преимущества метода "Шахт"

1. Кажущаяся простота.

2. Задачи могут разрабатываться и внедряться, не приводя к глубоки* структурным изменениям.

3. Возможность делить системы и подсистемы на столько частей сколько это нужно для их лучшего выполнения. Но нельзя увлекаться, так как вся система станет "тяжеловесной".

4. Разработка каждой задачи ведётся практически отдельно и часто, поэтому проще (кодирование только под задачу). При этом могут работать несколько коллективов разработчиков, каждый со своими методами и инструментами.

5. Легко вносить изменения в уже реализованные задачи из-за слабой связи "шахт".

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

Недостатки метода "Шахт"

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

2. При изменении функции или структуры организации требуется разработка новых "шахт".

3. Дублирование информации, которое неизбежно при чистом методе "шахт", может свести на нет все преимущества информатизации

 


31. Методология структурного анализа и структурного проектирования ЭИС.

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

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

Выделяют два главных этапа структурного проектирования:

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

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

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

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


32. Технология прототипного проектирования.

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

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

Информация о работе Функциональная, информационная, математическая модели экономической информационной системы