Моделирование интегрированных информационных систем

Моделирование интегрированных информационных систем Среди наиболее распространенных языков описания и соответствующих им моделей можно выделить: Вербальная модель - описание на естественном языке. Математическая модель - описание с помощью средств и правил определенного раздела (разделов) математики. Графическая модель - описание объекта с помощью средств и правил графического изображения. Наиболее приемлемая для описания производственных процессов. Этапы построения информационной системы • • • • 1. Определение целей проекта Осуществление процедуры бенчмаркинга: анализ опыта других предприятий Возможность внедрения принципиально новых управленческих технологий. Определение укрупненных показателей эффективности бизнес-процессов. Определение приемлемого финансового плана-графика проекта 2. Обследование предприятия и подготовка к проекту внедрения • Выбор управляющей (внедряющей) компании • Подготовка персонала компании к проекту изменений, разработка новой политики мотивации труда • Утверждение проектной методологии. Как правило, любая проектная методология базируется на трех обязательных понятиях: модель команды, модель процессов и модель рисков. Этапы построения информационной системы Модель команды определяет ролевой состав рабочей группы, правила взаимодействия между ролями и ответственность за выполнение проектных задач. Модель процессов описывает регламент выполнения работ, отчётную политику и правила предоставления результатов. Модель рисков описывает правила выявления и отслеживания статусов рисков, а также принципы поиска решений по их устранению. • Определение приемлемого финансового плана-графика проекта. • Построение и утверждение бизнес-модели "как есть". • Анализ бизнес-модели "как есть", разработка и утверждение бизнес-модели "как должно быть", планирование проекта реорганизации • Реорганизация бизнес-процессов и отдельных подсистем 3. Выбор поставщика программного комплекса (ПК). • • • • Формулирование требований к ПК. Формулирование требований к конкурсантам. Организация тендера. Выбор поставщика решения или принятие решения об индивидуальной разработке. Этапы построения информационной системы 4. Управление проектом построения и развития ИС • • • • Внесение в бизнес-модель корректив, обусловленных развитием компании Разработка и утверждение плана-графика работ. Управление конфигурацией ПК, согласно требованиям бизнес-модели. Управление тестированием (стабилизацией). Обычно тестирование бывает двух категорий: функциональное и пользовательское. • Целью функционального тестирования является максимально полная проверка каждого программного модуля на предмет сбоев. • Пользовательское тестирование выполняется, когда формальные контрольные примеры уже практически не выявляют ошибок. В этом случае, продукт тестируется путем имитации действий различных групп пользователей. 5. Управление рисками и качеством внедрения.  процедурное управление рисками на всем протяжении проекта является одним из самых главных факторов успеха.  Обеспечение качества готового продукта (версии) достигается нахождением оптимального баланса между тремя составляющими: функциональность, надежность, дата выпуска.  Каждая из этих составляющих формируется на основе ожиданий заказчика. Очевидно, что не каждый проект является критичным к дате выпуска, так же как не каждый проект критичен к полноте реализации функциональности Этапы построения информационной системы 6. Запуск ИС (версии) в опытную эксплуатацию. 7. Разработка правил работы с ИС и утверждение процедуры внесения изменений в конфигурацию. 8. Обучение и сертификация пользователей и администраторов. 9.Организация работы подразделения технической и пользовательской поддержки. Методологии построения бизнес-процессов Для построения моделей бизнес-процессов и описания бизнес-процессов в настоящее время используют методологии SADT, семейства IDEF, DFD, UML, Rational Rose, АВС, ARIS, SCOR и другие. SADT (Structured Analysis and Design Technique) Методология SADT (методология структурного анализа и проектирования) разработана Дугласом Россом. Методология SADT представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. На ее основе разработана, в частности, известная методология IDEF0 (Icam DEFinition), которая является основной частью программы ICAM (Интеграция компьютерных и промышленных технологий), проводимой по инициативе ВВС США. Стандарты семейства IDEF В настоящий момент к семейству IDEF можно отнести следующие стандарты: IDEF0 - методология функционального моделирования. Как правило, моделирование средствами IDEF0 является первым этапом изучения любой системы; IDEF1 – методология моделирования информационных потоков внутри системы, позволяющая отображать и анализировать их структуру и взаимосвязи; IDEF1X - (IDEF1 Extended) – методология построения реляционных структур. IDEF1X относится к типу методологий “Сущность-взаимосвязь” (ER – Entity-Relationship) и, как правило, используется для моделирования реляционных баз данных; IDEF2 – методология динамического моделирования развития систем. В связи с весьма серьезными сложностями анализа динамических систем от этого стандарта практически отказались, и его развитие приостановилось на самом начальном этапе. IDEF3 – методология документирования процессов, происходящих в системе, которая используется, например, при исследовании технологических процессов на предприятиях. С помощью IDEF3 описываются сценарий и последовательность операций для каждого процесса. IDEF4 – методология построения объектно-ориентированных систем. Средства IDEF4 позволяют наглядно отображать структуру объектов и заложенные принципы их взаимодействия, тем самым позволяя анализировать и оптимизировать сложные объектно-ориентированные системы; Стандарты семейства IDEF IDEF5 – методология онтологического исследования сложных систем. С помощью методологии IDEF5 онтология системы может быть описана при помощи определенного словаря терминов и правил, на основании которых могут быть сформированы достоверные утверждения о состоянии рассматриваемой системы в некоторый момент времени. На основе этих утверждений формируются выводы о дальнейшем развитии системы и производится её оптимизация. IDEF6 - Назначение IDEF6 (Design Rationale Capture method) состоит в описании процесса создания модели и отвечает на вопрос "почему модель получилась такой, какой получилась?" IDEF7 - Information System Auditing - аудит информационных систем. Этот метод определён как востребованный, однако так и не был полностью разработан. IDEF8 – методы разработки интерфейсов взаимодействия оператора и системы (пользовательских интерфейсов). IDFE8 фокусирует внимание разработчиков интерфейса на программировании желаемого взаимного поведения интефеса и пользователя на трех уровнях: выполняемой операции (что это за операция); сценарии взаимодействия, определяемом специфической ролью пользователя; на деталях интерфейса (какие элементы управления, предлагает интерфес для выполнения операции IDEF9 - (Business Constraint Discovery method) (метод исследования бизнес ограничений) был разработан для облегчения обнаружения и анализа органичений в условиях которых действует предприятие. Стандарты семейства IDEF IDEF10 - Implementation Architecture Modeling - моделирование архитектуры выполнения. Этот метод определён как востребованный, однако так и не был полностью разработан. IDEF11 - Information Artifact Modeling. Этот метод также определён как востребованный, однако так и не был полностью разработан. IDEF12 - Organization Modeling - организационное моделирование. Этот метод определён как востребованный, однако так и не был полностью разработан IDEF13 - Three Schema Mapping Design - трёхсхемное проектирование преобразования данных. Этот метод определён как востребованный, однако так и не был полностью разработан. IDEF14 - метод проектирования компьютерных сетей, основанный на анализе требований, специфических сетевых компонентов, сущестующих конфигураций сетей. Также он обеспечивает поддержку решений, связанных с рациональным управлением матеральными ресурсами, что позволяте достичь существенной экономии. Стандарт IDEF0 Cтандарт был разработан в 1981 году в рамках обширной программы автоматизации промышленных предприятий, которая носила обозначение ICAM (Integrated Computer Aided Manufacturing) и была предложена департаментом Военно-Воздушных Сил США. Cемейство стандартов IDEF унаследовало свое обозначение от названия этой программы (IDEF=ICAM DEFinition) В 2000 году принят в качестве руководящего документа по стандартизации в Российской Федерации Основные элементы и понятия IDEF0:  Первое - понятие функционального блока (Activity Box);  Вторым “китом” методологии IDEF0 является понятие интерфейсной дуги (Arrow).  Третьим основным понятием стандарта IDEF0 является декомпозиция (Decomposition).  Должна быть указана цель (Purpose) построения диаграммы в виде краткого описания и зафиксирована точка зрения (Viewpoint). Функциональный блок Управление Вход Функциональный блок А0 Механизм Выход Стандарт IDEF0 Каждая из четырех сторон функционального блока имеет своё определенное значение (роль), при этом: • Верхняя сторона имеет значение “Управление” (Control); • Левая сторона имеет значение “Вход” (Input); • Правая сторона имеет значение “Выход” (Output); • Нижняя сторона имеет значение “Механизм” (Mechanism). Аналогичное название имеют стрелки, подходящие к граням или выходящие из них. Название функционального блока должно сформулировано в глагольном наклонении Интерфейсные дуги Интерфейсная дуга отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, отображенную данным функциональным блоком. Графическим отображением интерфейсной дуги является однонаправленная стрелка. Каждая интерфейсная дуга должна иметь свое уникальное наименование (Arrow Label). Стандарт IDEF0 “Источником” (началом) и “приемником” (концом) каждой интерфейсной дуги могут быть только функциональные блоки, при этом “источником” может быть только выходная сторона блока, а “приемником” любая из трех оставшихся. По требованию стандарта, наименование дуги должно быть оборотом существительного Любой функциональный блок по требованиям стандарта должен иметь по крайней мере одну управляющую интерфейсную дугу и одну исходящую. Отделять входящие интерфейсные дуги от управляющих часто бывает непросто. Например Декомпозиция Декомпозиция позволяет постепенно и структурировано представлять модель системы в виде иерархической структуры отдельных диаграмм, что делает ее менее перегруженной и легко усваиваемой. Модель IDEF0 всегда начинается с представления системы как единого целого – одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой, и обозначается идентификатором “А-0”. Декомпозиция Дисциплина работы над разработкой IDEF0-модели Процесс разработки является итеративным и состоит из следующих условных этапов  Создание модели группой специалистов, относящихся к различным сферам деятельности предприятия. Эта группа в терминах IDEF0 называется авторами (Authors). На основе имеющихся положений, документов и результатов опросов создается черновик (Model Draft) модели. • • • • • Авторы опрашивают специалистов подразделений примерно так: Что поступает в подразделение “на входе”? Какие функции, и в какой последовательности выполняются в рамках подразделения? Кто является ответственным за выполнение каждой из функций? Чем руководствуется исполнитель при выполнении каждой из функций? Что является результатом работы подразделения (на выходе)? Распространение черновика для рассмотрения, согласований и комментариев. На этой стадии происходит обсуждение черновика модели с широким спектром компетентных лиц (в терминах IDEF0- читателей) на предприятии. Каждая из диаграмм черновой модели письменно критикуется и комментируется, а затем передается автору. Автор, в свою очередь, также письменно соглашается с критикой или отвергает её с изложением логики принятия решения и вновь возвращает откорректированный черновик для дальнейшего рассмотрения. Этот цикл продолжается до тех пор, пока авторы и читатели не придут к единому мнению.  Дисциплина работы над разработкой IDEF0-модели  Официальное утверждение модели. Окончательная модель представляет собой согласованное представление о предприятии (системе) с заданной точки зрения и для заданной цели.  В результате получается модель “Как есть”.  Эта модель передается на анализ и обработку к бизнес-аналитикам, которые занимаются поиском “узких мест” в управлении компанией и оптимизацией основных процессов, трансформируя модель “Как есть” в соответствующее представление “Как должно быть”. На основании этих изменений и выносится итоговое заключение, которое содержит в себе рекомендации по реорганизации системы управления. Пример разработки IDEF0-модели учета персонала в среде Bpwin Пример разработки IDEF0-модели учета персонала в среде Bpwin Пример разработки IDEF0-модели учета персонала в среде Bpwin Пример разработки IDEF0-модели учета персонала в среде Bpwin Пример разработки IDEF0-модели учета персонала в среде Bpwin