Обобщенная схема жизненного цикла ЭИС

Обобщенная схема жизненного цикла ЭИС 1. Системный анализа (до направления совершенствования объекта) К основным целям процесса относится следующее:  сформулировать потребность в новой ЭИС (идентифицировать все недостатки существующей ЭИС)  выбрать направление и определить экономическую целесообразность проектирования ЭИС. СА начинается с описания и анализа функционирования рассматриваемого экономического объекта в соответствии с требованиями (целями), которые к нему предъявляются (блок 1). В результате выявляются основные недостатки существующей ЭИС, на основе которых формулируется потребность в совершенствовании системы управления этим объектом, И ставится задача определения экономически обоснованной необходимости автоматизации определенных функций управления (блок 2), т.е. создается технико-экономическое обоснование проекта. После определения этой потребности возникает проблема выбора направлений совершенствования объекта на основе выбора программно-технических средств (блок 3). Результаты оформляются в виде технического задания на проект, в котором отражаются технические условия и требования к ЭИС, а также ограничения на ресурсы проектирования. Требования определяются в терминах функций, реализуемых системой. И предоставляемой ею информацией. 2. Системный синтез (от ФА до проекта системы) Процесс предполагает  Разработать функциональную архитектуру ЭИС, которая отражает структуру выполняемых функций  Разработать системную архитектуру, выбранного варианта ЭИС, т.е. состав обеспечивающих подсистем  Выполнить реализацию проекта Этап по составлению функциональной архитектуры (ФА) представляющей собой совокупность функциональных подсистем и связей между ними (блок 4) является наиболее ответственным с точки зрения качества всей последующей разработки Построение системной архитектуры (СА) на основе ФА (блок 5) предполагает выделение элементов и модулей информационного, технического, программного обеспечения и других обеспечивающих подсистем, определение связей по информации и управлению между выделенными элементами и разработку технологии обработки информации. Этап конструирования (физического проектирования системы) включает разработку инструкций пользователя и программиста, создание информационного обеспечения, включая наполнение баз данных (блок 6). 3. Внедрение разработанного проекта (блоки 7-10). Процесс предполагает выполнение этапов опытного и промышленного внедрения. Опытное внедрение заключается в проверке работоспособности элементов и модулей проекта, устранения ошибок на уровне элементов и связей между ними. Этап сдачи в промышленную эксплуатацию предполагает организацию проверки проекта на уровне функций и контроля соответствия его требованиям, сформулированным на стадии системного анализа. 4. Эксплуатация и сопровождение проекта. На этой стадии (блоки 11-12) выполняются этапы: эксплуатация проекта системы и модернизация проекта ЭИС. Рассмотренная схема включает в свой состав только основные процессы, реальный набор которых и их разбиение на этапы и технологические операции в значительной степени зависят от выбираемой технологии проектирования, о чем более подробно будет сказано в последующих разделах данной работы. Важной чертой жизненного цикла ЭИС является его повторяемость. Это соответствует представлению о ней как о развивающейся динамической системе. Другой характерной чертой ЖЦ является наличие нескольких циклов внутри схемы: Первый цикл (1-12) цикл первичного проектирования Второй цикл (7-8, 6-7) – цикл, который возникает после опытного внерения, в результате которого выявляются частные ошибки в элементах проекта, исправляемые, начиная с 6-го блока Третий цикл (9-10, 4-9) возникает после сдачи в промышленную эксплуатацию. Когда выявляются ошибки в функциональной архитектуре системы, связанные с несоответствием проекта требованиям заказчика по составу функциональных подсистем. Составу задач и связям между ними Четвертый цикл (блоки12, 5-12) возникает если требуется модификация системной архитектуры в связи с необходимостью адаптации проекта к новым условиям функционирования системы Пятый цикл (блоки 12, 1-120 возникает, если проект системы совершенно не соответствует требованиям, предъявляемым к организационно-экономической системе ввиду того, что осуществляется моральное его старение и требуется полное перепроектирование системы. Чтобы исключить пятый цикл и максимально уменьшить необходимость выполнения третьего и четвертого циклов, необходимо выполнять проектирование ЭИС в соответствии с требованиями:  Разработка должна быть выполнена в строгом соответствии со сформулированными требованиями к создаваемой системе  Требования к ЭИС должны адекватно соответствовать целями и задачам эффективного фунгкционирования экономического объекта  Созданная ЭИС должна соответствовать сформулированным требованиям на момент окончания внедрения, а не на момент начала разработки  Внедренная ЭИС должна развиваться и адаптироваться в соответствии с постоянно меняющимися требованиями к ЭИС. 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-базы данных можно так – это большие объемы структурированной информации. Несмотря на упрощенность определения, следует подчеркнуть два аспекта:  Регулярная однородность данных (структурированность)  Большие объемы информации Второй аспект определяет область применения БД – относительно развитые бизнесструктуры, или автоматизация бизнеса с небольшим оборотом и узкой номенклатурой товара нецелесообразна. Для моделирования систем и сопровождаемых ими БД используют методологии 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- модели, либо вместо него, в зависимости от сложности моделируемого объекта или предпочтений исполнителя. После этапа моделирования исследуемого объекта наступает этап физической реализации этой модели в виде ИС. И тут возникает вопрос об адекватности отображения, т.е. как представить в ИС управляющие потоки и др. Хотя понятно, что, например, потоки данных в ИС будут реализованы как хранилища данных, т.е. файлы. Тот факт, что IDEF0модель не разделяет потоки данных на материальные, информационные и управляющие приводит разработчиков к необходимости использовать диаграммы потоков данных. Это можно делать после этапа составления IDEF0-модели, либо вместо него в зависимости от сложности моделируемого объекта или предпочтений исполнителя. ДИАГРАММЫ ПОТОКОВ ДАННЫХ При построении DFD –диаграмм используют следующие элементы:  Поток данных – некая информация, которая требует обработки;  Процесс – преобразование входных потоков данных в выходные в соответствии с определенным алгоритмом;  Внешняя сущность – источник или приемник данных, который является внешним по отношению к предметной области;  Хранилище данных (data storage) Внешняя сущность – это объект, который не принадлежит моделируемому объекту и обменивается с ним потоками данных. Это, как правило, потребитель услуг моделируемого объекта. На концептуальной схеме его именуют существительным. В общем случае, сущность – это объект или концепция, которая в рамках конкретной предметной области существует самостоятельно. Процесс описывают глаголом, который обозначает некое действие, связанное с обработкой потока. Построим, используя DFD-методологию, концептуальную модель некоторой риэлтерской конторы, которая специализируется на заключении договоров аренды жилых помещений. При этом будем считать, что круг клиентов конторы относительно стабилен. На рис. 2 внешня сущность обозначена прямоугольником, потоки данных стрелками, процессы – кругами, а хранилища данных – параллельными линиями. Отправка договора менеджеру Заявка на аренду Арендатор, владелец (потенциал ьный) Подготовить договор аренды Вступление Владелец Недвижимост ь Заключить договор аренды в силу договора аренды Арендатор Договор Рис. 2. Концептуальная модель работы риэлтерской конторы Как видно из концептуальной модели заключения договора, внешние сущности – это потенциальные Арендатор и Владелец. Поскольку элементами концептуальной модели являются одноименные хранилища: Арендатор и Владелец, то можно усомниться в правильности определения внешних сущностей. Но, так как потенциальные Арендатор и Владелец могут быть таковыми лишь после заключения договора, то конфликтов с определением здесь нет. Другими словами, это разные сущности. Для составления договора используют данные хранилищ Арендатор и Владелец. Эти хранилища необходимы по причине того, что круг клиентов риэлтерской конторы относительно стабилен. Не подвержен значительным изменениями и перечень арендуемых объектов недвижимости, что отражает на концептуальной схеме хранилище Недвижимость. Наличие на диаграмме процесса «Подготовить договор аренды» - это следствие того, что черновик договора аренды готовит клерк, а менеджер принимает решение о заключении договора. Это повышает эффективность работы фирмы в целом. РОЛЬ МЕТОДОЛОГИЙ В АНАЛИЗЕ МОДЕЛИРУЕМОГО ОБЪЕКТА В результате анализа моделируемого ИС объекта на основе построения IDEF0 и DFDдиаграмм: Определяют главную функцию проектируемой системы: например, сопровождать аренду недвижимости; Описывают происходящие в моделируемом объекте бизнес-процессы. Например: Заключать договора аренды Сопровождать хранение информации об объектах недвижимости Определяют обрабатываемые бизнес процессами информационные потоки. Например, отправка договора менеджеру. Разрабатывают концептуальную модель системы, которая представляет собой описание моделируемого объекта, присущих ему бизнес-правил, потоков и хранилищ данных Примечание: Потоки данных – это прообразы процедур приложения, а хранилища данных – таблиц БД. Подводя итог, можно отметить, что построение концептуальной модели системы в соответствии с IDEF0 и DFD-методологией позволяет прийти к общему с заказчиком представлению о проектируемой ИС. ОПРЕДЕЛЕНИЕ МОДУЛЕЙ И ПРОЕКТИРОВАНИЕ БД. На данном этапе проектирования ИС:  На основе анализа назначения потоков концептуальной модели определяют модули приложений, которые позволяют реализовать функции системы  Проектируют концептуальную схему БД. Эта схема не зависит от конечной реализации БД и аппаратной платформы. При разработке ИС немаловажную роль играет выбор среды. Объектноориентированная методология позволяет рассматривать разработку прикладных систем, как процесс их конструирования из готовых классов. Модули проектируемого приложения можно определить на основе назначения потоков концептуальной модели. Проектирование БД. Возникновение ситуаций «аномалия удаления» и «аномалия добавления». Необходимость разделения данных. Модель данных должна состоять из совокупности файлов. Разделение данных обеспечивают следующие модели: иерархическая, сетевая, реляционная и объектно-ориентированная. Они по разному связывают данные таблиц данных. Структуры данных иерархической и сетевой моделей В иерархической модели данные упорядочены как главные (родительские) и подчиненные (дочерние). Достоинством является простота описания предметных областей с иерархической структурой. НО поиск информации возможен только сверху вниз. Почему? Физическое представление логической структуры иерархических моделей в компьютере – это совокупность записей различных типов, каждая из которых ссылается только на Владелец следующую 1:N Договор 1:1 Арендатор Рис. 3. Связь данных в иерархической модели 1:1 Недвижимость