Информационные системы

3. Внедрение разработанного  проекта (блоки 7-10). Процесс предполагает выполнение этапов опытного и промышленного внедрения. Опытное внедрение заключается в проверке работоспособности элементов и модулей проекта, устранения ошибок на уровне элементов и связей между ними.

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

4. Эксплуатация и сопровождение  проекта. На этой стадии (блоки  11-12) выполняются этапы: эксплуатация  проекта системы и модернизация проекта ЭИС.

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

Важной чертой жизненного цикла ЭИС является его повторяемость. Это соответствует представлению  о ней как о развивающейся  динамической системе.

Другой характерной  чертой ЖЦ является наличие нескольких циклов внутри схемы:

Первый цикл (1-12) цикл первичного проектирования

Второй цикл (7-8, 6-7) –  цикл, который возникает после  опытного внерения, в результате которого выявляются частные ошибки в элементах  проекта, исправляемые, начиная с 6-го блока

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

Четвертый цикл (блоки12, 5-12) возникает если требуется модификация  системной архитектуры в связи  с необходимостью адаптации проекта  к новым условиям функционирования системы

Пятый цикл (блоки 12, 1-120 возникает, если проект системы совершенно не соответствует требованиям, предъявляемым к организационно-экономической системе ввиду того, что осуществляется моральное его старение и требуется полное перепроектирование системы.

Чтобы исключить пятый  цикл и максимально уменьшить  необходимость выполнения третьего и четвертого циклов, необходимо выполнять проектирование ЭИС в соответствии с требованиями:

1) Разработка должна быть выполнена в строгом соответствии со сформулированными требованиями к создаваемой системе

2) Требования к ЭИС должны адекватно соответствовать целями и задачам эффективного фунгкционирования экономического объекта

3) Созданная ЭИС должна соответствовать сформулированным требованиям на момент окончания внедрения, а не на момент начала разработки

4) Внедренная ЭИС должна развиваться и адаптироваться в соответствии с постоянно меняющимися требованиями к ЭИС.

 

Лекция 8 (БД: ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ)

1. Методология проектирования

Любую сложную систему  необходимо проектировать. Это связано  с нашей физиологией: мы не можем  решать одновременно более 7 задач, а разработка и проектирование сопряжены с большим их числом: написанием кода приложения, его отладкой, тестированием, взаимоувязкой модулей приложения, дизайном форм, хранением, обработкой данных и многими другими. Для проектирования ИС необходимо знать регламентирующие этапы проектирования стандарты, определять модули системы и проектировать БД.

Основой для проектирования любой сложной системы служит ее концептуальная модель.

Определение. Концептуальную модель можно определить как результат абстрагирования части реального мира, которую моделируют ИС. Для обозначения «части реального мира» используют термин «предметная область»

Методологии, которые  используют для абстрагирования  предметной области, отражают специфику  применения ИС. Одни из них – OLTP-системы (Online Transaction Processing) предназначены для хранения данных в реальном масштабе времени– OLAP(OnLine Analitical processing)используют в процессе управления бизнесом.

Выделяют два типа ИС. Одни из них сопровождают операционные (OLTP), а другие – аналитические (OLAP) базы данных.

OLTP – базы хранят данные в реальном масштабе времени, т.е. мгновенно фиксируют события (отгрузку товара со склада).

OLAP хранят «историю» изменения БД. Т.е. в них сохраняют данные OLTP – базы с какой-то конкретной периодичностью.

Состояние OLTP-базы следующего месяца можно изображать в виде куба. Если провести некий кросстабличный анализ, например, построить график изменения значений какой-то комплектующей по одной позиции, то можно предсказать тенденцию ее сбыта. А значит предсказать прибыль от реализации товара в будущем или принять решение о прекращении его поставок. Это не единственный вариант анализа. Можно сравнивать кривые сбыта разных товаров, чтобы определить. Какой из товаров дает большую прибыль, оптимизировать затраты на рекламу с целью получения максимальной прибыли от реализации товара и т.д.

Эти задачи решают с помощью  систем поддержки принятия решений (Decision Support System, DSS) на основе данных OLAP-баз. Этот тип ИС ориентирован на решение стратегических вопросов типа прогнозирования сбыта. Поэтому OLAP-системы никогда не оперируют данными реального времени.

К системам поддержки  принятия решений относят, например, Excel. Большинство средств разработки ИС содержат библиотеки классов или компонентов. Так в Borland Delphi есть компоненты DecisionCube.

Системы поддержки решений  масштаба предприятия строят на серверных OLAP-средствах: Oracle Express Server, MS SQL Server 2000 Analysis Services, Hyperion Essbase и др.

В дальнейшем мы будем  рассматривать OLTP-базы данных (OLTP-системы).

Кратко охарактеризовать OLTP-базы данных можно так – это большие объемы структурированной информации.

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

1) Регулярная однородность данных (структурированность)

2) Большие объемы информации

Второй аспект определяет область применения БД – относительно развитые бизнес-структуры, или автоматизация  бизнеса с небольшим оборотом и узкой номенклатурой товара нецелесообразна.

Для моделирования систем и сопровождаемых ими БД используют методологии IDEF0 (Integrated Definition Function Modeling) DFD и (Data Flow Diagrams).

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

МЕТОДОЛОГИЯ IDEF0

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

IDEF0 – это подмножество SADT (Structured Analysis and Design Technique). Изначально эта методология применялась для проектирования систем общего назначения.

Суть методологии IDEF0 на примере производства товара.

Для производства используют ингредиенты, инструкции, регламентирующие процесс производства, инструменты, используемые в процессе производства.

В терминах IDEF0 моделируемое ИС производство представляется блоком и дугами, как показано на рис.

 

 

 

 

 

 

 

 

 

 

Рис. 1. Базовые элементы IDEF0 – модели

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

Правила интерпретации  модели:

Функциональный  блок (функция) преобразует входные объекты в выходные;

Управление определяет, когда и как это преобразование может или должно произойти;

Исполнитель осуществляет это преобразование.

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

Каждый блок IDEF0 – диаграммы может быть представлен несколькими блоками, соединенными интерфейсными дугами на диаграмме следующего уровня. Эти блоки представляют подфункции исходной функции. Каждый из подмодулей может быть декомпозирован аналогичным образом. Число уровней не ограничено, но рекомендуют на диаграмме использовать от 3 до 6 блоков.

Анализ объекта на основе построения его IDEF0- модели является этапом, который должен предварять разработку ИС по следующим причинам:

• При ознакомлении строят модель «как есть», которая фиксирует бизнес-процессы и используемые ими информационные потоки
• Функциональная модель «как есть» позволяет увидеть информационно-перегруженные бизнес-процессы – узкие места обследуемого объекта
• На основании модели «как есть» строится модель «как будет», т.е. предложить более совершенную структуру организации (реинжиниринг);
• В процессе построения модели «как есть» выявляются бизнес-правила – положения, которые регламентируют процесс функционирования моделируемого объекта;
• IDEF0 – модель  -  это лучший способ совместно с заказчиком разработать модель функционировании его фирмы.

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

Тот факт, что IDEF0-модель не разделяет потоки данных на материальные, управляющие и информационные приводит разработчиков к необходимости использования диаграммы ПОТОКОВ ДАННЫХ. Это можно делать после этапа составления IDEF0-модели, либо вместо него, в зависимости от сложности моделируемого объекта или предпочтений исполнителя.

Лекция 9.

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

ДИАГРАММЫ ПОТОКОВ ДАННЫХ

При построении DFD –диаграмм используют следующие элементы:

• Поток данных – некая информация, которая требует обработки;
• Процесс – преобразование входных потоков данных в выходные в соответствии с определенным алгоритмом;
• Внешняя сущность – источник или приемник данных, который является внешним по отношению к предметной области;
• Хранилище данных (data storage)

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

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

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

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

На рис. 2 внешня сущность обозначена прямоугольником, потоки данных стрелками, процессы – кругами, а  хранилища данных – параллельными линиями.

 

 

 

 

 

 

 

                            Рис. 2. Концептуальная модель работы риэлтерской конторы

 

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

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

Наличие на диаграмме  процесса «Подготовить договор аренды» - это следствие того, что черновик договора аренды готовит клерк, а  менеджер принимает решение о заключении договора. Это повышает эффективность работы фирмы в целом.

РОЛЬ МЕТОДОЛОГИЙ В  АНАЛИЗЕ МОДЕЛИРУЕМОГО ОБЪЕКТА

В результате анализа  моделируемого ИС объекта на основе построения IDEF0 и DFD- диаграмм:

Определяют главную  функцию проектируемой системы: например, сопровождать аренду недвижимости;