Таблица 5.6. Классификация рынка информационных систем
Локальные системы	Малые интегрированные системы	Средние интегрированные системы	Крупные интегрированные системы (IC)
· БЭСТ · Инотек · Инфософт · Супер-Менеджер · Турбо-Бухгалтер · Инфо-Бухгалтер	· Concorde XAL Exact · NS-2000 Platinum PRO/MIS · Scala SunSystems · БЭСТ-ПРО · 1C-Предприятие · БОСС-Корпорация · Галактика · Парус · Ресурс · Эталон	· Microsoft-Business Solutions - Navision, Axapta · J D Edwards (Robertson & Blums) · MFG-Pro (QAD/BMS) · SyteLine (COKAП/SYMIX)	· SAP/R3 (SAP AG) · Baan (Baan) · BPCS (ITS/SSA) · OEBS (Oracle E-Business Suite)

Существует классификация ИС в зависимости от уровня управления, на котором система используется.

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

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

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

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

· сравнение текущих показателей с прошлыми;

· составление периодических отчетов за определенное время, а не выдача отчетов по текущим событиям, как на оперативном уровне;

· обеспечение доступа к архивной информации и т.д.

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

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

С точки зрения программно-аппаратной реализации можно выделить ряд типовых архитектур ИС.

Традиционные архитектурные решения основаны на использовании выделенных файл-серверов или серверов баз данных. Существуют также варианты архитектур корпоративных информационных систем, базирующихся на технологии Internet (Intranet-приложения). Следующая разновидность архитектуры информационной системы основывается на концепции "хранилища данных" (DataWarehouse) - интегрированной информационной среды, включающей разнородные информационные ресурсы. И, наконец, для построения глобальных распределенных информационных приложений используется архитектура интеграции информационно-вычислительных компонентов на основе объектно-ориентированного подхода.

Индустрия разработки автоматизированных информационных систем управления зародилась в 1950-х - 1960-х годах и к концу века приобрела вполне законченные формы.

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

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

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

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

Согласно статистическим данным, собранным Standish Group (США), из 8380 проектов, обследованных в США в 1994 году, неудачными оказались более 30% проектов, общая стоимость которых превышала 80 миллиардов долларов. При этом оказались выполненными в срок лишь 16% от общего числа проектов, а перерасход средств составил 189% от запланированного бюджета.

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

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

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

· обеспечивать создание корпоративных ИС, отвечающих целям и задачам организации, а также предъявляемым требованиям по автоматизации деловых процессов заказчика;

· гарантировать создание системы с заданным качеством в заданные сроки и в рамках установленного бюджета проекта;

· поддерживать удобную дисциплину сопровождения, модификации и наращивания системы;

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

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

Проектирование ИС охватывает три основные области:

· проектирование объектов данных, которые будут реализованы в базе данных;

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

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

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

· требуемой функциональности системы и уровня ее адаптивности к изменяющимся условиям функционирования;

· требуемой пропускной способности системы;

· требуемого времени реакции системы на запрос;

· безотказной работы системы;

· необходимого уровня безопасности;

· простоты эксплуатации и поддержки системы.

Согласно современной методологии, процесс создания ИС представляет собой процесс построения и последовательного преобразования ряда согласованных моделей на всех этапах жизненного цикла (ЖЦ) ИС. На каждом этапе ЖЦ создаются специфичные для него модели - организации, требований к ИС, проекта ИС, требований к приложениям и т.д. Модели формируются рабочими группами команды проекта, сохраняются и накапливаются в репозитории проекта. Создание моделей, их контроль, преобразование и предоставление в коллективное пользование осуществляется с использованием специальных программных инструментов - CASE-средств.

Процесс создания ИС делится на ряд этапов (стадий [1]), ограниченных некоторыми временными рамками и заканчивающихся выпуском конкретного продукта (моделей, программных продуктов, документации и пр.).

Обычно выделяют следующие этапы создания ИС: формирование требований к системе, проектирование, реализация, тестирование, ввод в действие, эксплуатация и сопровождение [1] [2]. (Последние два этапа далее не рассматриваются, поскольку выходят за рамки тематики книги.)

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

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

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

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

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

Конечными продуктами этапа проектирования являются:

· схема базы данных (на основании ER-модели, разработанной на этапе анализа);

· набор спецификаций модулей системы (они строятся на базе моделей функций).

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

· будет ли это архитектура "файл-сервер" или "клиент-сервер";

· будет ли это 3-уровневая архитектура со следующими слоями: сервер, ПО промежуточного слоя (сервер приложений), клиентское ПО;

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

· будет ли база данных однородной, то есть, будут ли все серверы баз данных продуктами одного и того же производителя (например, все серверы только Oracle или все серверы только DB2 UDB). Если база данных не будет однородной, то какое ПО будет использовано для обмена данными между СУБД разных производителей (уже существующее или разработанное специально как часть проекта);

· будут ли для достижения должной производительности использоваться параллельные серверы баз данных (например, Oracle Parallel Server, DB2 UDB и т.п.).

Этап проектирования завершается разработкой технического проекта ИС.

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

Этап тестирования обычно оказывается распределенным во времени.

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

· обнаружение отказов модуля (жестких сбоев);

· соответствие модуля спецификации (наличие всех необходимых функций, отсутствие лишних функций).

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

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

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

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

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

6. Технология создания информационных систем (ИС)

6.1 Требования к инструментальным средствам

Рассмотрим основные этапы проектирования ИС (без учета деления на стадии проектирования по ГОСТу):

1) описание бизнес-логики предметной области;

2) проектирование архитектуры ИС;

3) непосредственное создание;

4) тестирование;

5) сопровождение.

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

- ошибки, допущенные на предыдущей стадии проектирования, обходятся в 10 раз дороже, чем на текущей;

- жизненный цикл создания сложной ИС без использования инструментальных средств, сопоставим с ожидаемым временем ее эксплуатации;

- реализация проекта по созданию ИС предполагает коллективную работу;

- изменение внешних условий при проектировании ИС может потребовать внесения дорогостоящих изменений в проект.

Требования к инструментальным средствам:

1) средства должны автоматизировать начальные этапы проектирования;

2) средства должны в несколько раз уменьшать время на проектирование по сравнению с традиционными подходами;

3) средства должны быть достаточно гибкими к изменяющимся требованиям;

4) средства должны поддерживать коллективный режим работы.

6.2 Что такое CASE-средства?

В дословном переводе Computer Aided Software Engineering - разработка программного обеспечения с помощью компьютера.

В настоящее время термин применяется в более широком смысле.

CASE-средства - это инструментальные средства автоматизации проектирования ИС.

Рассмотрим функции проектирования, наиболее часто автоматизируемые в рамках CASE-средств:

- анализ и формулировка требований к ИС;

- проектирование баз данных и приложений;

- генерация программного кода;

- тестирование;

- обеспечение качества;

- управление конфигурацией ИС;

- управление проектом (организация проектирования самой ИС) и др.

CASE-система - набор CASE-средств, выполненных в рамках единого программного продукта.

CASE-технология - методология проектирования ИС с использованием CASE-средств.

В настоящее время на рынке коммерческих программных продуктов присутствуют и отдельные CASE-средства, и системы, и технологии.

6.3 Подходы к проектированию ИС

Методики, используемые при проектировании, сначала программ, а затем и систем в целом, формировались в течение длительного промежутка времени. Необходимость таких методик проявлялась при разработке сложных программных систем в условиях дефицита времени на разработку. Подобные ситуации были характерны для крупных промышленных корпораций и учреждений оборонного ведомства, поэтому многие современные методики изначально были, например, внутренними стандартами МО США.

В основе наиболее известных методик проектирования ИС лежат два подхода: структурный и объектно-ориентированный.

Структурные методы анализа и проектирования используют иерархические структуры для моделирования объекта исследования.

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

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

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

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

6.4 Методы структурного проектирования

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

Все наиболее распространенные структурные методы базируются на следующих принципах:

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

- принцип организации составных частей в иерархические структуры.

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

- SADT (Structured Analysis and Design Technique) - метод структурного анализа и проектирования - модели и соответствующие функциональные диаграммы, объединенные данным названием;

- DFD (Data Flow Diagrams) - диаграммы потоков данных;

- ERD (Entity-Relationship Diagrams) - диаграммы "сущность-связь".

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

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

На стадии анализа и проектирования DFD-диаграммы используются для описания структуры проектируемой системы, а ERD-диаграммы - для описания модели данных логического и физического уровней. Кроме перечисленных средств на этой стадии широко используются всевозможные структурные схемы (архитектура ИС, иерархия экранных форм, меню и т.п.).

В начале 90-ых годов прошлого века в США на основе SADT был принят стандарт моделирования бизнес-процессов IDEF0 (http://www.idef.com). Этот стандарт принят в нескольких международных организациях, в том числе в НАТО и МВФ. С 2000г. Стандарт принят в РФ и является стандартом в области построения функциональных моделей при проектировании ИС (РД IDEF0-2000).

6.5 Методы объектно-ориентированного проектирования

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

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

6.6 Пример взаимодействия CASE-средств

На примере пакетов программ BPwin, Erwin, Rational Rose и Paradigm Plus рассмотрим возможности CASE-средств (рис. 6.1).

CASE-средства ERwin и BPwin были разработаны фирмой Logic Works. После слияния с PLATINUM technology они стали продаваться под новой торговой маркой. Позднее владельцем этих пакетов стала Computer Associates.

BPwin - средство проектирования верхнего уровня, поддерживает три методологии моделирования: функциональное моделирование (IDEF0); описание бизнес-процессов (IDEF3); диаграммы потоков данных (DFD).

ERwin - средство проектирования баз данных, поддерживает стандарт IDEF1X.

Paradigm Plus (Computer Associates) поддерживает язык объектно - ориентированного моделирования UML. Rational Rose (фирма Rational Software) также реализует объектно-ориентированный подход на основе языка UML.

Power Builder - среда разработки под СУБД Sybase.

Model Mart - хранилище моделей, обеспечивает коллективный доступ и совместное моделирование, работает в архитектуре клиент-сервер;

Silverrun (Silverrun technology) -

Oracle Designer (Oracle) -

Rational Rose (Rational Software) - .

Комментарии к линиям связи:

1 - переход от функциональных моделей к моделям данных (автоматизирован частично);

2 - прямое проектирование базы данных под конкретную СУБД (физическое моделирование) и обратное проектирование (по имеющейся физической модели восстановление логической модели).

Взаимодействие CASE-средств

Рис. 6.1

3 - автоматическая генерация кода приложения (клиентская часть) под наиболее популярные средства разработки (техника генерации кода различна для разных сред);

4 - сгенерированный программный код может быть выполнен в среде СУБД;

5 - связь с хранилищем моделей;

6 - прямая генерация программного кода и обратная генерация объектной модели по программному коду;

7 - прямое и обратное проектирование структуры базы данных по объектной модели.

6.7 Развитие методологий проектирования

Исследования в области построения моделей и методов проектирования ИС не заканчиваются моментом принятия некоторого стандарта.

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

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

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

6.8 Методология функционального моделирования IDEF0. Общие положения (см. РД IDEF0 - 2000)

Модель - искусственный объект, представляющий собой отображение (образ) системы и ее компонентов.

М моделирует А, если М отвечает на вопросы относительно А.

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

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

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

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

При разработке моделей не рекомендуется "привязывать" функции к существующей организационной структуре объекта исследования. Организационная структура должна явиться результатом использования модели. Сравнение результата с существующей структурой позволяет оценить ее адекватность и предложить решения по совершенствованию структуры.

6.9 Синтаксис графического языка

6.9.1 Блок

Блок - это графическое представление функций, процессов, действий, операций и т.п. Блок представлен на рис. 6.2.

Изображение блока

Рис. 6.2

6.9.2 Стрелка

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

Стрелки могут состоять только из горизонтальных и вертикальных отрезков со скругленными стыками.

Стрелки должны присоединяться к блоку на его сторонах. Присоединение в углах не допускается.

Стрелки помечаются существительными или оборотами существительных.

Способы изображения стрелок

Рис. 6.3

6.10 Семантика языка IDEF0

6.10.1 Семантика блоков и стрелок

На рис. 6.4. показано стандартное изображение блока.

Изображение блока со стрелками

Рис. 6.4

Вход - это то, что преобразуется или расходуется функцией.

Выход - это то, что произведено функцией (данные или материальные объекты).

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

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

Вызов - это переход к другому фрагменту модели.

Пример приведен на рис. 6.5.

Пример

Рис. 6.5

6.10.2 Контекстная диаграмма

Контекстная диаграмма - это диаграмма верхнего уровня. Она описывает одну функцию и отображает связи объекта моделирования с внешней средой. Стандартное название контекстной диаграммы А-0.

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

Пример контекстной диаграммы

А-0

Рис. 6.6

6.10.3 Дочерние диаграммы

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

Все дочерние функции должны находиться в области действия родительской функции.

На каждой диаграмме должен быть представлен один уровень декомпозиции.

Между блоками одной диаграммы могут существовать следующие типы отношений:

· доминирование;

· управление;

· выход-вход;

· обратная связь по управлению;

· обратная связь по входу;

· выход-механизм.

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

Управление. Выход доминирующего блока служит управляющим воздействием для блока с меньшим доминированием (рис. 6.7).

Отношение управления

Рис. 6.7

Выход-вход. Выход одного блока с входом другого (рис. 6.8).

Отношение выход-вход

Рис. 6.8

Обратная связь по управлению. Возникает, когда выход некоторого блока создает управляющее воздействие на блок с большим доминированием (рис. 6.9).

Обратная связь по управлению

Рис. 6.9

Обратная связь по входу. Выход блока на вход блока с большим доминированием (рис. 6.10).

Обратная связь по входу

Рис. 6.10

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

Выход-механизм

Рис. 6.11

6.10.4 Граничные стрелки

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

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

Для сохранения преемственности стрелок используются специальные коды: I (Input), C (Control), O (Output), M (Mechanism), которые соответствуют расположению стрелок на родительской диаграмме.

Так, стрелка С3 на дочерней диаграмме указывает, что стрелка соответствует третьей слева управляющей стрелке родительского блока.

6.10.5 Тоннелирование стрелок

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

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

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

6.11 Правила построения диаграмм

1. Должна быть одна контекстная диаграмма А-0.

2. Блоки на диаграмме декомпозиции должны располагаться по диагонали от верхнего левого угла до нижнего правого.

3. Диаграмма декомпозиции должна содержать от трех до шести блоков (оптимальное количество).

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

5. Каждый родительский блок должен иметь ссылку на дочернюю диаграмму, ссылка помещается под правым нижним углом блока.

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

7. Если одни и те же данные служат и для управления, и для входа, вычерчивается только стрелка управления, что уменьшает сложность диаграммы.

8. Можно выполнять слияние и разветвление стрелок, если они имеют сходный смысл.

9. Каждая диаграмма имеет узловой номер. Контекстная - А-0, первая дочерняя - тоже А-0, следующие - А1, А2, А3, … ,А6; далее - А11, А12, … и т.д.

6.12 Методика разработки функциональных моделей в среде IDEF0

6.12.1 Общие положения

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

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

Информация, которая участвует в преобразовании, может быть разделена на три группы:

- ограничительная информация;

- описательная информация;

- управляющая информация.

Ограничительная информация - сведения о том, чего нельзя делать: всегда или в рамках одной функции.

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

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

Управляющая информация - сведения о том, как, при каких условиях и по каким правилам следует выполнять функцию. Содержится в инструкциях, руководствах, документах, определяющих функцию.

Взаимодействие перечисленных понятий представлено на рис. 6.12.

Основные понятия

Рис. 6.12

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

6.12.2 Классификация видов функций

По уровню декомпозиции можно выделить следующие виды функций:

· деятельность;

· процесс;

· операция;

· действие;

· субдеятельность;

· подпроцесс.

Для всех функций:

· части функций могут выполняться последовательно или/и параллельно;

· все функции потребляют финансовые, энергетические, трудовые и материальные ресурсы;

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

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

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

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

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

Субдеятельность - совокупность нескольких процессов в составе деятельности, объединенных некоторой подцелью основной цели.

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

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

По степени участия в достижении основной цели деятельности функции можно разделить на:

· основные;

· вспомогательные.

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

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

Вспомогательный процесс

Рис. 6.13

6.12.3 Классификация механизмов

Механизмы можно разделить на следующие виды:

· организационно-техническая система;

· организационно-техническая подсистема;

· организационно-технический комплекс (модуль);

· организационно-технический блок.

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

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

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

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

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

6.12.4 Классификация управляющих воздействий

Управление - это разновидность функций, которая определяет условия правильного функционирования блока.

Для управления возможна следующая классификация:

· управление деятельностью;

· управление процессом;

· управление операцией.

Управление деятельностью - процесс, состоящий, как минимум, из следующих операций:

· формулирование целей деятельности;

· оценка ресурсов, "сколько надо и сколько есть";

· сбор информации о состоянии деятельности и условиях ее протекания;

· выработка и принятие решений (распределение ресурсов, оформление решений);

· реализация решений и контроль исполнения;

· корректировка ранее сформулированных целей.

Управление процессом - операция, состоящая, как минимум, из следующих действий:

· анализ директивы на управление процессом, ее декомпозиция на директивы управления операциями;

· сбор информации о выполнении операций, ее обобщение и формирование сведений о состоянии процесса; передача данных в подсистему управления деятельностью;

· анализ информации и выработка локальных решений, направленных на устранение отклонений;

· корректировка директив на выполнение операций процесса.

Управление операцией - действие, состоящее в выработке на основании директивы на управление операцией, например, следующих команд:

· на управление действиями;

· на выполнение команд;

· по оценке результатов выполнения;

· по передаче необходимой информации в комплекс управления процессом;

· по корректировке команд.

Блоки управления должны присутствовать на каждой IDEF0-диаграмме. Через них осуществляются управляющие воздействия на остальные блоки диаграммы.

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

6.12.5 Типизация функциональных моделей

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

6.12.6 Выводы по методологии функционального моделирования

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

В этом случае рекомендуется переходить к другим моделям - математическим, имитационным моделям и др.

По терминологии, принятой в исследовании операций, IDEF0 - модели относятся к классу концептуальных. Концептуальные модели являются основой построения математических моделей.

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

Учебники к курсу

1. Грекул В.И., Денищенко Г.Н., Коровкина Н.Л. Проектирование информационных систем Интернет-университет информационных технологий - ИНТУИТ.ру, 2008.

2. Данилин А., Слюсаренко А. Архитектура и стратегия. "Инь" и "янь" информационных технологий Интернет-университет информационных технологий - ИНТУИТ.ру, 2005.

Список литературы

1. Вендров А.М. Проектирование программного обеспечения экономических информационных систем М: «Финансы и статистика», 2000.

2. Проектирование информационных систем М: «КомпьютерПресс», №9, 2001.

3. Колтунова Е. Требования к информационной системе и модели жизненного цикла.

4. Автоматизированные Системы Стадии создания. ГОСТ 34.601-90. Комплекс стандартов на автоматизированные системы ИПК издательство стандартов. 1997.

5. ISO/IEC 12207:1995.

6. Буч Г., Рамбо Д., Джекобсон А. Язык UML. Руководство пользователя: Пер. с англ. М.: ДМК, 2000.

7. Thiele D. Life cycle management using life cycle process standards. Abstract.

8. Козленко Л. Проектирование информационных систем.

9. Clegg, Dai and Richard Barker Case Method Fast-track: A RAD Approach Adison-Wesley, 1994.

10. Смирнова Г.Н., Сорокин А.А., Тельнов Ю.Ф. Проектирование экономических информационных систем М.: Финансы и статистика, 2002.

11. Построение и совершенствование систем управления.

12. Елиферов В.Г., Репин В.В. Бизнес-процессы: регламентация и управление М.: ИНФРА-М, 2004.

13. Основы организационного бизнеса (01.2002, Эмитент. Существенные факторы, события, действия).

14. Кондратьев В.В., Краснова В.Б. Модульная программа для менеджеров. Реструктуризация управления компанией М.: Инфра-М, 2000.

15. Калянов Г.Н. Теория и практика реорганизации бизнес-процессов М.: СИНТЕГ, 2000.

16. Калянов Г.Н. Структурный системный анализ М.: Лори, 1996.

17. Калянов Г.Н. Структурный системный анализ М.: Лори, 1997.

18. Марка Д.А., МакГоуэн К. SADT -- методология структурного анализа и проектирования М.: Метатехнология, 1993.

19. Маклаков С.В. Создание информационных систем с AllFusion Modelling Suite М.: Диалог-МИФИ, 2003.

20. Черемных С.В., Ручкин В.С., Семенов И.О. Структурный анализ систем. IDEF-технологии М.: Финансы и статистика, 2001.

21. Смирнова Г.Н.,Сорокин А.А., Тельнов Ю.Ф. Проектирование экономических информационных систем. Учебник М.: «Финансы и статистика», 2002.

22. ГОСТ 6.01.1-87 Единая система классификации и кодирования технико-экономической информации М.: Изд. стандартов, 1987.

23. Маклаков С.В. Создание информационных систем с AllFusion Modelling Suite М.: Диалог-МИФИ, 2003.

24. Буч Г. Объектно-ориентированное проектирование с примерами применения М.: Конкорд, 1992.

25. Нейбург Э. Д., Максимчук Р.А. Проектирование баз данных с помощью UML М.: Издательский дом «Вильямс», 2002.

Размещено на Allbest.ru

ПРИЛОЖЕНИЕ 1

Постановка задачи

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

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

Организационно-экономическая сущность задачи:

- наименование задачи, место ее решения;

- цель решения;

- назначение (для каких объектов подразделений и пользователей предназначена);

- периодичность решения и требования к срокам решения;

- источники и способы поступления данных;

- потребители результатной информации и способы ее отправки;

- информационная связь с другими задачами.

Описание исходной (входной) информации:

- перечень исходной информации;

- формы представления (документ) по каждой позиции перечня; примеры заполнения документов;

- количество документов (информации) в единицу времени, количество строк в документе (массиве);

- описание структурных единиц информации (каждого элемента данных, реквизита);

- точное и полное наименование, идентификатор, максимальная разрядность в знаках;

- способы контроля исходных данных:

- контроль разрядности реквизита;

- контроль интервала значений реквизита;

- контроль соответствия списку значений;

- балансовый или расчетный метод контроля количественных значений реквизитов;

- метод контроля с помощью контрольных сумм и любые другие возможные способы контроля.

Описание используемой условно-постоянной информации:

- перечень условно-постоянной информации (классификаторов, справочников, таблиц, списков с указанием их полных наименование);

- формы представления;

- описание структурных единиц информации (по аналогии с исходными записями);

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

Описание результатной (выходной) информации:

- перечень результатной информации;

- формы представления (печатная сводка, видеограмма, машинный носитель и его макет и т.д.);

- периодичность и сроки представления;

- количество документов (информации) в единицу времени, количество строк в документе (массиве);

- перечень пользователей результатной информацией (подразделение и персонал);

- перечень регламентной и запросной информации;

- описание структурных единиц информации (каждого элемента данных, реквизита) по аналогии с исходными данными;

- способы контроля результатной информации:

- контроль разрядности;

- контроль интервала значений реквизита;

- контроль соответствия списку значений;

- балансовый или расчетный метод контроля отдельных показателей;

- метод контроля с помощью контрольных сумм и любые другие возможные способы контроля.

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

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

Разрядность реквизита указывается количеством знаков (алфавитных, цифровых и алфавитно-цифровых).

Описание алгоритма решения задачи (последовательности действий и логики решения задачи):

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

- описание связей между частями, операциями, формулами алгоритма;

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

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

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

ПРИЛОЖЕНИЕ 2

Инструментальная среда BPwin

BPwin имеет достаточно простой и интуитивно понятный интерфейс пользователя. При запуске BPwin по умолчанию появляется основная панель инструментов, палитра инструментов (вид которой зависит от выбранной нотации) и, в левой части, навигатор модели -- Model Explorer (рис. П2.1).

При создании новой модели возникает диалог, в котором следует указать, будет ли создана модель заново или она будет открыта из файла либо из репозитория ModelMart, затем внести имя модели и выбрать методологию, в которой будет построена модель (рис. П2.2).

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

Рис. П2.1. Интегрированная среда разработки модели BPwin

Рис. П2.2. Диалог создания модели

Модель в BPwin рассматривается как совокупность работ, каждая из которых оперирует с некоторым набором данных. Работа изображается в виде прямоугольников, данные -- в виде стрелок. Если щелкнуть по любому объекту модели левой кнопкой мыши, появляется контекстное меню, каждый пункт которого соответствует редактору какого-либо свойства объекта.

Построение модели IDEF0

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

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

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

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