Будь умным!


У вас вопросы?
У нас ответы:) SamZan.net

Типовое проектирование ИС

Работа добавлена на сайт samzan.net:

Поможем написать учебную работу

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

Предоплата всего

от 25%

Подписываем

договор

Выберите тип работы:

Скидка 25% при заказе до 2.11.2024

Реферат по дисциплине «Проектирование информационных систем» на тему:

«Типовое проектирование ИС»

Оглавление.

Основные понятия типового проектирования информационных систем и классификация_3

Параметрически-ориентированное проектирование информационных систем__________7

Модельно-ориентированное проектирование информационных систем_______________13

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

Заключение_________________________________________________________________20

Список использованной литературы____________________________________________21

Основные понятия типового проектирования информационных систем и классификация.

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

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

Существует три метода типового проектирования информационных систем, в зависимости от варианта декомпозиции: элементный, подсистемный и объектный (рис.1).

Рис. 1. Классификация методов типового проектирования.

В случае элементного метода типового проектирования информационных систем типовым элементом считается либо типовое решение задачи, либо типовое решение какого-либо обеспечения задачи (например: технического, информационного, организационного и др.) (рис.2).

Рис.2. Типовое проектное решение уровня «Задача».

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

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

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

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

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

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

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

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

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

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

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

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

Рис.3. Представление пакета прикладных программ в виде «черного ящика».

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

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

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

Блок функционирования производит обработку входных данных и создает результат работы.

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

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

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

Рис.4. Технологическая сеть проектирования при помощи настройки пакета прикладных программ.

Д1.1 – характеристики проблемной области;  Д1.2 – список критериев оценки функционального пакета прикладных программ; Д2.1 – техническая документация пакета;  Д2.2 – договор на закупку и сопровождение; Д3.1 – результаты обучения персонала; Д4.1 – описание внешних изменений; U1 – универсум функциональных пакетов прикладных программ; G1 – комплекс программ функционального пакета прикладных программ; G2 – настроенный функциональный пакет прикладных программ.

Определение критериев оценки функционального пакета прикладных программ.

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

Главные классификации критериев таковы:

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

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

Таблица 1

Наименование критерия

Содержание подкритериев

1

Назначение и возможности пакета

  1.   Предметная область использования

  1.   Степень обеспечения функций управления

  1.   Общий или специализированный

  1.   Коллективного или индивидуального пользования

  1.   Возможности расширения функций пакета

  1.   Возможности оптимизации расчетов

  1.   Возможность адаптации к различным применениям на основе модульного строения пакета

  1.   Возможность взаимозаменяемости технических средств

  1.   Возможность повышения эффективности обработки данных

  1.  Универсальность

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

2

Оптимальные признаки и свойства пакета

2.1. Входной язык

2.2. Управляющий язык

2.3. Структура массива

2.4. Способ хранения данных

2.5. Способ доступа данных

2.6. Выдача выходных документов

2.7. Дистанционная обработка и разделение времени

2.8. Представление входных данных

2.9. Способы проверки входных данных

2.10. Представление входных данных

2.11. Редактирование входных данных

2.12. Диалоговый режим

2.13. Язык программирования

3

Требования к техническим и программным средствам

3.1. Вычислительная система

3.2. Объем оперативной памяти

3.3. Объем внешней памяти

3.4. Периферийные устройства

3.5. Тип операционной системы

3.6. Вспомогательные и программные средства

3.7. Использование средств организации массивов

3.8. Совместимость с системой управления базами данных

4

Документация пакета

4.1. Общее руководство по использованию

4.2. Руководство системного и программного уровня

5

Факторы финансового порядка

5.1. Затраты на приобретение пакета

5.2. Затраты на аренду пакета

5.3. Затраты на обработку пакета, установку, подготовку персонала, техники, обслуживания и поддержания

5.4. Экономическая эффективность использования пакета

6

Особенности установки

6.1. Объем работ по установке пакета

6.2. Время установки

6.3. Требуемые модификации пакета

6.4. Требования пользователя к квалификации программистов

6.5. Требования настройки входных и выходных форм пакета

6.6. Трудоемкость организации информационной базы

6.7. Требуемые модификации операционных систем и систем управления базами данных

7

Особенности

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

7.2. Возможность обслуживания пакета силами специалистов организации-пользователя

7.3. Техническая эффективность, надежность

7.4. Защита данных

7.5. Трудоемкость внесения изменений

7.6. Трудоемкость реорганизации информационной базы

7.7. Трудоемкость и время обнаружения и исправления ошибок

7.8. Время повторного запуска системы

7.9. Время цикла обработки информации

7.10. Производительность

8

Помощь поставщика по внедрению и поддержанию пакета

8.1. Обучение персонала организации-пользователя

8.2. Участие поставщика при внедрении пакета

8.3. Переход от старой системы к новой

8.4. Участие поставщика в обследовании пакета

8.5. Корректировка системы ошибок

8.6. Внесение модификаций

8.7. Обеспечение обновления документов

8.8. Простота использования

9

Оценка качества пакета и опыт его использования

9.1. Источник появления

9.2. Характеристика первой версии пакета

9.3. Число и характер переделок пакета

9.4. Число организаций, пользующихся пакетом

9.5. Оценка уже установленных пакетов

9.6. Сравнение с аналогичными пакетами

9.7. Помехозащищенность

10

Перспективы развития пакета

10.1. Совершенствование концепции и используемых методов

10.2. Подключение новых функциональных возможностей

10.3. Расширение интерфейса, переход на совершенные технические средства

10.4. Совместимость со старой версией

Модельно-ориентированное проектирование информационных систем.

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

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

Для моделирования и конфигурации информационных систем часто используются такие модельно-ориентированные компонентные системы, как R/3 и BAAN IV, которые позволяют накапливать опыт от создания предыдущих информационных систем и создавать типовые модели. Эти типовые модели предоставляют пользователю в форме репозитория, т.е. пользователи обретают знания о том, как эффективно управлять организацией и работать с бизнес-процессами, адаптируя затем эти знания под конкретную организацию.

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

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

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

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

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

Рис.5. Конфигурация информационной системы на основе модельно-ориентированной технологии.

Модель функций.

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

Просмотр функциональности типовой информационной системы в модельно-ориентированной компонентной системе R/3 происходит посредством программы-навигатора репозитория. Пример такой навигации изображен на рис. 6.

Рис. 6. Фрагмент модели функций в системе R/3.

Модель процессов.

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

В модельно-ориентированной компонентной системе R/3 для демонстрирования процессов используется диаграмма EPC  (модель управления событиями), реализация которой происходит в программе ARIS Toolset (рис. 7). В данной системе переходы между операциями зависят от событий, связанных между собой логическими операторами AND, OR, XOR. Помимо этого, если того требует пользователь, на модели могут быть отображены организационные единицы, входные и выходные данные, интерактивный/пакетный тип обработки данных. Весь бизнес-процесс и его операции документируются.

Рис.7. Модель управления событиями бизнес-процесса в системе R/3.

Модели объектов (данных).

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

Бизнес-объекты отличны от простых объектов своей сложной структурой и являются самодостаточными элементами. В системе R/3 есть ограничения на возможные типы связей бизнес-объектов с другими объектами. Модель бизнес-объектов в данной системе изображается в качестве статистической ER-модели, в которой любая сущность может представлять собой как бизнес-объект, так и обычный объект.

Модель организационной структуры.

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

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

Рис.8. Установление связи модели бизнес-процессов и модели организационной структуры.

Модели бизнес-правил.

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

Технологическая сеть модельно-ориентированного проектирования информационных систем.

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

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

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

 

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

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

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

Для того, чтобы осуществить прототипное проектирование информационной системы нужно иметь высокоуровневые инструментальные средства. Это средства делятся на два класса: интегрированные инструменты быстрой разработки приложений (Builder) и инструменты быстрой разработки приложения в развитых системах управления базами данных (Developer).

Заключение.

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

Затем, было рассмотрено параметрически-ориентированное проектирование информационных систем, а также, устройство «черного ящика», в виде которого принято представлять пакеты прикладных программ. Более подробно останавливалось внимание на определении критериев оценки функционального пакета прикладных программ.

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

И наконец, было уделено внимание прототипному проектированию информационных систем.

В связи с этим, все основные положения типового проектирования информационных систем были рассмотрены.

Список использованной литературы.

  •  Все изображения и таблицы были взяты из учебника: Г.Н. Смирнова, А.А.Сорокин, Ю.Ф. Тельнов Проектирование экономических информационных систем. Учебник. Москва, «Финансы и статистика»,2002г.
  •  В.И. Грекул, Г.Н. Денищенко, Н.Л. Коровкина. Проектирование информационных систем. -  М.: Интернет-Ун-т Информ. технологий, 2005
  •  http://www.neudov.net/4students/otvety-po-pive/tipovoe-proektirovanie-informacionnyx-sistem/
  •  http://csgtr.narod.ru/pis.html




1. Правоохранительная деятельность по контролю за незаконным оборотом наркотиков
2. Модуль 1 Частота випорожнень у здорової дитини яка знаходиться на грудному вигодовуванні може становит
3. Лекция 15 Криминологическая характеристика рецидивной преступности План лекции 1
4. Неприкосновенность жилища как принцип уголовного процесса
5. Курскоблнефтепродукт Утверждаю Генеральный
6. Основы для брака в 1-ом послании к Коринфянам 11 216
7. Черноморская деревня в условиях НЭПА. (Социально-экономический аспект)
8. Невыбранная дорога Для моих родителей и мужа потому что когда я сказала что хочу прикоснутьс
9. I. Сетевой уровень
10. Интерпретация Николаем Лосским теодицеи Достоевског
11. The success of your job seeking depends on the wy you mke up your Curriculum Vite
12. по теме Роль факта в познании законов природы и общественной жизни
13. Обліковий запис користувача PostgreSQL Як і з будьяким демоном сервера що є доступним ззовні рекомендовано з
14. Лекция 1Возбудители гнойно воспалительных процессов
15. Реферат- Ответы на билеты по конфликтологии
16. ТЮМЕНСКИЙ ГОСУДАРСТВЕННЫЙ НЕФТЕГАЗОВЫЙ УНИВЕРСИТЕТ МЕТОДИЧЕСКИЕ УКАЗАНИЯ
17. Методы и приборы для изучения анализа и диагностики наночастиц и наноматериалов
18. Понятие и сущность юридического лица в свете изменений в ГК РФ
19.  Постановка и свойства транспортной задачи Описание ситуации
20. Проезд перекрестков