Проектирование сложных систем связи. МТУСИ, кафедра мультимедийных

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

2016_gk__idef_proektirovanie_is_i_servisov.ppt

  • Размер: 2.9 Мб
  • Автор: Дима Вербицкий
  • Количество слайдов: 180

Описание презентации Проектирование сложных систем связи. МТУСИ, кафедра мультимедийных по слайдам

Проектирование сложных систем связи.  МТУСИ, кафедра мультимедийных сетей и систем связи.  Москва,Проектирование сложных систем связи. МТУСИ, кафедра мультимедийных сетей и систем связи. Москва, 2010 г.

Оглавление 1. Введение в дисциплину. Термины, определения и описания ландшафта внедрения АСУ в РФ.Оглавление 1. Введение в дисциплину. Термины, определения и описания ландшафта внедрения АСУ в РФ. 2. Ознакомление с особенностями современных методов и средств проектирования корпоративных информационных систем управления предприятием, основанных на использовании CASE-технологий. 3. В разделе «Проектирование сложных систем связи – КИСУ предприятия» из всего множества CASE-средств будут рассматриваться СММ/ CMMI средства и возможности интеграции прикладных АС КИСУ предприятия.

Введение в дисциплину.  Эффективное управление предприятием в современных условиях невозможно без использования современныхВведение в дисциплину. Эффективное управление предприятием в современных условиях невозможно без использования современных ИТ технологий. Правильный выбор программного продукта и фирмы-разработчика — это первый и определяющий этап создания корпоративной системы управления предприятием (КИСУ). В настоящее время проблема модернизации или выбора и внедрения новых специализированных автоматизированных систем (АС) из специфической задачи превращается в стандартную процедуру. В этом смысле, что российские предприятия сильно уступают зарубежным конкурентам. Иностранные предприятия, как правило, имеют опыт модернизации и внедрения не одного поколения АС. В развитых западных странах происходит смена уже четвертого поколения АС. На российских предприятиях зачастую используют системы первого или второго поколения. Руководители многих средних и крупных российских предприятий имеют слабое представление о современных компьютерных интегрированных системах и предпочитают содержать большой штат собственных программистов, которые разрабатывают индивидуальные программы для решения стандартных управленческих задач на существующих платформах. Процедура принятия решения о выборе наиболее эффективной компьютерной системы управления предприятием – дорогое удовольствие и потому неприемлема для большинства отечественных руководителей, а ее последствия во многом будут оказывать значительное влияние на предприятие в течение нескольких лет. Т. к. применение полнофункциональной интегрированной КИС, которая отвечала бы всем современным требованиям предприятия (масштабу, специфике бизнеса и т. д. ), позволила бы руководителю минимизировать издержки, повысить оперативность и адаптивность системы к изменениям в среде управления предприятием в целом в реальном режиме времени. Все это в значительной степени усложняет работы по развитию и модернизации КИСУ.

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

Основные термины и определения.  Системы (подсистемы) класса A - системы (подсистемы) контроля иОсновные термины и определения. Системы (подсистемы) класса A — системы (подсистемы) контроля и управления технологическими объектами и/или процессами. Эти системы, как правило, характеризуются следующими свойствами: достаточно высоким уровнем автоматизации выполняемых функций; наличием явно выраженной функции контроля за текущим состоянием объекта управления; наличием контура обратной связи; объектами контроля и управления такой системы выступают: — технологическое оборудования; — датчики; — исполнительные устройства и механизмы. малым временным интервалом обработки данных (т. е. интервалом времени между получением данных о текущем состоянии объекта управления и выдачей управляющего воздействия на него); слабой (несущественной) временной зависимостью (корреляцией) между динамически изменяющимися состояниями объектов управления и системы (подсистемы) управления. В качестве классических примеров систем класса A можно считать: SCADA — Supervisory Control And Data Acquisition (диспетчерский контроль и накопление данных); DCS — Distributed Control Systems (распределенные системы управления); Batch Control — системы последовательного управления; АСУ ТП — Автоматизированные Системы Управления Технологическими Процессами.

Основные термины и определения.   Системы класса B - это системы (подсистемы) подготовкиОсновные термины и определения. Системы класса B — это системы (подсистемы) подготовки и учета производственной деятельности предприятия. Системы класса B предназначены для выполнения класса задач, требующих непосредственного участия человека для принятия оперативных (тактических) решений, оказывающих влияние на ограниченный круг видов деятельности или небольшой период работы предприятия. В некотором смысле к таким системам принято относить те, которые находятся на уровне технологического процесса, но с технологией напрямую не связаны. В перечень основных функций систем (подсистем) данного класса можно включить: выполнение учетных задач, возникающих в деятельности предприятия; сбор, предварительную подготовку данных, поступающих в КИСУ из систем класса A, и их передачу в системы класса C; подготовку данных и заданий для автоматического исполнения задач системами класса A. С учетом прикладных функций этот список можно продолжить следующими пунктами: управление производственными и человеческими ресурсами в рамках принятого технологического процесса; планирование и контроль последовательности операций единого технологического процесса; управление качеством продукции; управление хранением исходных материалов и произведенной продукции по технологическим подразделениям; управление техническим обслуживанием и ремонтом. Эти системы, как правило, имеют следующие характерные признаки и свойства: наличие взаимодействия с управляющим субъектом (персоналом), при выполнении стоящих перед ними задач; интерактивность обработки информации; небольшой длительностью обработки данных, колеблющейся от нескольких минут до несколько часов или суток; наличием существенных временной и параметрической зависимостей (корреляций) между обрабатываемыми данными; система оказывает влияние на ограниченный круг работ и видов деятельности предприятия; система оказывает влияние на небольшой период работы предприятия (в пределах от месяца до полугода); наличием сопряжения с системами класса A и/или C.

Основные термины и определения. Классическими примерами систем класса B можно считать:  MES -Основные термины и определения. Классическими примерами систем класса B можно считать: MES — Manufacturing Execution Systems (системы управления производством); MRP — Material Requirements Planning (системы планирования потребностей в материалах); MRP II — Manufacturing Resource Planning (системы планирования ресурсов производства); CRP — C Resource Planning (система планирования производственных мощностей); CAD — Computing Aided Design (автоматизированные системы проектирования — САПР); CAM — Computing Aided Manufacturing (автоматизированные системы поддержки производства); CAE — Computing Aided Engineering (автоматизированные системы инженерного проектирования – САПР специализированное проектирование при строительстве объектов); PDM — Product Data Management (автоматизированные системы управления данными); C RM — Customer Relationship Management (системы управления взаимоотношениями с клиентами); всевозможные учетные системы и т. п. Одна из причин возникновения подобных систем — необходимость выделить отдельные задачи управления на уровне технологического подразделения предприятия.

Основные термины и определения.  Системы класса C - это системы (подсистемы) планирования иОсновные термины и определения. Системы класса C — это системы (подсистемы) планирования и анализа производственной деятельности предприятия. Системы класса C предназначены для выполнения класса задач, требующих непосредственного участия человека для принятия стратегических решений, оказывающих влияние на деятельность предприятия в целом. В круг задач решаемых системами (подсистемами) данного класса можно включить: анализ деятельности предприятия на основе данных и информации, поступающей из систем класса B; планирование деятельности предприятия; регулирование глобальных параметров работы предприятия; планирование и распределение ресурсов предприятия; подготовку производственных заданий и контроль их исполнения. наличие взаимодействия с управляющим субъектом (персоналом), при выполнении стоящих перед ними задач; интерактивность обработки информации; повышенной длительностью обработки данных, колеблющейся от нескольких минут до несколько часов или суток; длительным периодом принятия управляющего решения; наличием существенных временной и параметрической зависимостей (корреляций) между обрабатываемыми данными; система оказывает влияние на деятельность предприятия в целом; система оказывает влияние на значительный период работы предприятия (от полугода до нескольких лет); наличием непосредственного сопряжения с системами класса B. Классическими названиями системы класса B можно считать: ERP/ ERP 2 — Enterprise Resource Planning (Планирование Ресурсов Предприятия); IRP — Intelligent Resource Planning (системами интеллектуального планирования); АСУП; EIS.

Обобщенная модель предприятия.  Обобщенная модель предприятия.

Обощенная структура ИТ предприятия Обощенная структура ИТ предприятия

Краткое описание ландшафта ПО АСУ предприятия.  Современный рынок финансово-экономического прикладного программного обеспечения. Краткое описание ландшафта ПО АСУ предприятия. Современный рынок финансово-экономического прикладного программного обеспечения. Сегодняшний рынок финансово-экономического прикладного программного обеспечения КИСУ формируется под воздействием трех основных факторов: • постоянно растущих требований потребителей; • конъюнктурного мировоззрения большинства разработчиков АС ИТ; • неустойчивости нормативно-правовой среды в РФ.

Видение состояния внедрений АС   Анализ внедрений АС предприятий, осуществленных на сегодняшний день,Видение состояния внедрений АС Анализ внедрений АС предприятий, осуществленных на сегодняшний день, выявляет несколько причин сложностей и неудач при создании КИСУ: 1. Первая состоит в том, что готовые западные системы ориентированы на некие идеальные бизнес-процессы, оторванные от реальной структуры конкретной компании. А реальные учреждения, компании и корпорации вовсе не идеальны, а наоборот, очень сложны с точки зрения иерархии управления. Более того, зачастую формальная иерархия причудливо переплетается с реальной. 2. Вторая причина — в том, что исторически разработкой систем занимались программисты, в силу чего они строились согласно теории автоматизированных систем. Получался замкнутый автоматизированный процесс, по возможности исключающий человека. В результате весь средний менеджмент такой системой отторгался. Поэтому руководители среднего звена противятся внедрению таких систем и сознательно, и бессознательно. 3. Третье — это сложности при разработке ПО и недостаточный анализ существующих задач на этапе обследования, моделирования и проектирования. Например, на Западе, в частности, в США, у компаний-заказчиков, как правило, есть специальные отделы, которые планируют работы по автоматизации и анализируют: что надо автоматизировать, что не надо, что выгодно, а что убыточно, и как вообще должна быть построена система, какие функции она должна выполнять. У отечественных компаний подобные структуры, как правило, отсутствуют. 4. Внедренные на предприятии разно платформенных ИС, перечисленные выше, как правило, не интегрированы друг с другом. Что вызывает необходимость: — разработки программных средств сложного регламентного обмена данными в технологиях ETL ; — интеграции разнородных приложений, закупки и внедрение интеграционных платформ. 5. Соблюдение стандартов. ITIL, ITSM, Cobit, Отклонения от требований мониторинга и анализа за состоянием, поддержки, развития и модернизации инфраструктуры предприятия с учетом изменяющихся информационных потоков и объемов обработки информации в службах ИТ. Все это со временем неизбежно приводит к потери доверия бизнеса, необходимости модернизации ИТ инфраструктуры и, даже , перепроектирования КИСУ и функциональных АС предприятия, в частности.

Видение состояния внедрений АС Видение состояния внедрений АС

Видение состояния внедрений АС Видение состояния внедрений АС

Корпоративная информационная система управления предприятием (КИСУ)   Многослойная модель программно-технических средств КИСУ: Корпоративная информационная система управления предприятием (КИСУ) Многослойная модель программно-технических средств КИСУ: • Комплекс разнородных ( по производителям, функциональности ) прикладных АС; • Системные сервисы: интернет, электронная почта, порталы, специализированные АС и др. ; • Системы управления базами данных (СУБД), средства групповой работы; • Пользовательские и сетевые операционные системы и общесистемные программные компоненты; • Транспортная сеть локальных и глобальных систем (корпоративная сеть передачи данных); • Компьютеры и телефония: персональные, рабочие станции, серверы, кластеры, телефонные станции, включая IP- сервисы); Разнородные операционные системы ( Windows, Linux, VMware и др. ).

Общая классификация  АС предприятия. По масштабам применения Настольные - для работы одного человека.Общая классификация АС предприятия. По масштабам применения Настольные — для работы одного человека. Офисные — для работы подразделения, например службы Персонала. Корпоративные — для работы специалистов целого предприятия или даже нескольких связанных предприятий По охвату функций Специализированные АС — автоматизируют отдельные виды деятельности организации систем класса A, B, C. Например, АСУП, АСУТП, САПР, экспертные и аналитические системы и т. п. Универсальные АС — ставят своей целью автоматизацию подмножества видов деятельности применяемых на предприятии. Интегрированные АС , — ставят своей целью создание единой информационной среды (платформы), в рамках которой осуществляется выполнение деятельности всего предприятия.

Платформенные (функционально интегрированные) информационные системы Наиболее востребованные универсальные КИСУ в России в 2000 -Платформенные (функционально интегрированные) информационные системы Наиболее востребованные универсальные КИСУ в России в 2000 — 2010 г. Российские * • система « 1 C » • система «Галактика» • система «Парус» • система «Флагман» • система БОСС «Корпорация» • другие Зарубежные * • MS « Axapta » • SAP R/3 • Baa. N IV • Oracle Application • другие. * Перечисленные АС обеспечивают обработку внешних и внутренних данных предприятия (Enterprise Resource and Relationship Processing, или, другими словами, являются дальнейшим расширением системы ERP — ERPII).

Интегрированные системы (продолжение).  Пример интеграции  данных АС «Галактика» База данных системы Интегрированные системы (продолжение). Пример интеграции данных АС «Галактика» База данных системы «Галактика» Компонент извлечения данных Данные Галактики Компонент передачи данных Базы данных других систем Выходные документы Программные компоненты системы «Галактика» Программные компоненты других производителей Экранные формы Внешняя программа обработки Общая схема возможных вариантов организации взаимодействия «Галактики» с другими программными системами Источник: http: //atlants. dp. ua/integration. htm Возможные области интеграции с др. системами: • Функции, специфичные для отдельных предприятий, • взаимодействие с унаследованными программами, • обеспечение специальных интерфейсов доступа к данным для конкретных специалистов предприятия, • нестандартные (для «тиражной» функциональности системы) способы представления информации

Интеграция. Компоненты интегрированных АС i. BUS,  WORKFLOW - системы автоматизации и описания потокаИнтеграция. Компоненты интегрированных АС i. BUS, WORKFLOW — системы автоматизации и описания потока работ на предприятии GROUPWARE — системы автоматизации и обеспечения выполнения работы группы специалистов Doc. FLOW — системы автоматизации электронного документооборота предприятия Виртуальное предприятие — системы формирования информационных связей нескольких организаций, объединяющихся на временной основе CALS-технология — стратегия создания эффективной системы обмена, управления и использования электронных данных, поддерживающих полный жизненный цикл изделия

WORKFLOW - системы автоматизации и описания процессов  организации Технология автоматизации потока работ (workflow)WORKFLOW — системы автоматизации и описания процессов организации Технология автоматизации потока работ (workflow) — это технология компьютеризированной поддержки процессов управления предприятием (деловых процессов в целом или какой-то их части) например, функциональной АС, средствам технологии ETL (Extract – Transformation — Load). Объединяет потоки данных в следующих АС и сервисах ИТ: электронная почта портал управление проектами работа с базами данных ETL , выборка, преобразование и загрузка данных во внешние АС программирование CASE-технологии i. BUS, интеграционная шина Конкретные реализации технологии представляют собой программные системы автоматизации потока ( workflow), каждая из которых основывается на некоторой комбинации перечисленных технологий. В том числе из разных АС.

W orkflow ,  BPM – интеграционные платформы автоматизации и описания бизнес процессов предприятияW orkflow , BPM – интеграционные платформы автоматизации и описания бизнес процессов предприятия Наиболее известны: Oracle Fusion Middleware, корпорация Oracle TIBCO Software. IBM, Web. Sphere и др.

GROUPWARE - системы автоматизации и обеспечения выполнения работы группы специалистов Пример - TMU Group.GROUPWARE — системы автоматизации и обеспечения выполнения работы группы специалистов Пример — TMU Group. Ware (TMU Consulting Inc. , Япония) Единая информационная среда на базе web-технологий , специально разработанная для обеспечения эффективного коллективного взаимодействия сотрудников в контексте бизнес-процессов. Предоставляет защищенную рабочую среду в Интернете с возможностями: управления документами, календарного планирования, координации действий и совместной работы над любыми проектами, общения и поддержки отношений с клиентами.

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

Виртуальное предприятие – предприятие, состоящее из сообщества географически разделенных  экономических субъектов, которые взаимодействуютВиртуальное предприятие – предприятие, состоящее из сообщества географически разделенных экономических субъектов, которые взаимодействуют в производстве , используя преимущественно электронные средства коммуникаций (словарь http: //www. bb 2. ru/lexicon/) Виртуальные предприятия представляют собой группы людей, совместно занимающихся общим делом, независимо от их физического местонахождения , в реальном времени или отсроченном режиме. Они (и предприятия, и люди) могут быстро реагировать на изменения рынка при критически низких затратах с точки зрения традиционного бизнеса (http: //knowhow. virtech. ru/qa/10013, 2)

CALS-технология Вся информация представлена в электронном виде;  ЕИП охватывает всю информацию, созданную обCALS-технология Вся информация представлена в электронном виде; ЕИП охватывает всю информацию, созданную об изделии; ЕИП является единственным источником данных об изделии (прямой обмен данными между участниками ЖЦ исключен); ЕИП строится только на основе международных, государственных и отраслевых информационных стандартов; Для создания ЕИП используются программно-аппаратные средства, уже имеющиеся у участников ЖЦ; ЕИП постоянно развивается. Предполагает создание единого информационного пространства (ЕИП) для всех участников ЖЦ изделия (в том числе, эксплуатирующих организаций). ЕИП должно обладать следующими свойствами :

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

Виды обеспечения (ГОСТ 34. 602 -89) Техническое обеспечение Информационное обеспечение Программное обеспечение Математическое обеспечениеВиды обеспечения (ГОСТ 34. 602 -89) Техническое обеспечение Информационное обеспечение Программное обеспечение Математическое обеспечение Организационное обеспечение Лингвистическое обеспечение Методическое обеспечение Метрологическое обеспечение Правовое обеспечение

Программное обеспечение Базовое (системное) ПО • операционные системы • трансляторы • сервисное ПО •Программное обеспечение Базовое (системное) ПО • операционные системы • трансляторы • сервисное ПО • ПО технического обслуживания и поддержки Прикладное ПО

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

Методо-ориентированное ППО Математического программирования Сетевого планирования Теории массового обслуживания Математической статистики Системы имитационного экспериментаМетодо-ориентированное ППО Математического программирования Сетевого планирования Теории массового обслуживания Математической статистики Системы имитационного эксперимента

Проблемно-ориентированное ППО • бухгалтерского учета • финансового менеджмента • бюджетного учета • правовые справочныеПроблемно-ориентированное ППО • бухгалтерского учета • финансового менеджмента • бюджетного учета • правовые справочные системы • прочие

Основы методологии проектирования АС Жизненный цикл (ЖЦ) АС  - это непрерывный процесс, которыйОсновы методологии проектирования АС Жизненный цикл (ЖЦ) АС — это непрерывный процесс, который начинается с момента принятия решения о необходимости его создания и заканчивается в момент его полного изъятия из эксплуатации.

Стадии и этапы создания АС (ГОСТ 34. 601 -90) 1. Формирование требований к автоматизированнойСтадии и этапы создания АС (ГОСТ 34. 601 -90) 1. Формирование требований к автоматизированной системе ( АС ) 2. Разработка концепции АС 3. Техническое задание 4. Эскизный проект 5. Технический проект 6. Рабочая документация 7. Ввод в действие 8. Сопровождение АС

ЖЦ АС и международный стандарт ISO/IEC 12207 Основной нормативный документ,  регламентирующий ЖЦ АС,ЖЦ АС и международный стандарт ISO/IEC 12207 Основной нормативный документ, регламентирующий ЖЦ АС, = международный стандарт ISO/IEC 12207 ( ISO — International Organization of Standardization — Международная организация по стандартизации, IEC — International Electrotechnical Commission – Международная комиссия по электротехнике). Стандарт определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ИС.

Три группы процессов в структуре ЖЦ АС (по стандарту ISO/IEC 12207  ) Три группы процессов в структуре ЖЦ АС (по стандарту ISO/IEC 12207 )

Три группы процессов в структуре ЖЦ АС (по стандарту ISO/IEC 12207  ) ОсновныеТри группы процессов в структуре ЖЦ АС (по стандарту ISO/IEC 12207 ) Основные процессы ЖЦ (приобретение, поставка, разработка, эксплуатация, сопровождение); Вспомогательные процессы, обеспечивающие выполнение основных процессов (документирование, управление конфигурацией, обеспечение качества, верификация, аттестация, оценка, аудит, решение проблем); Организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого ЖЦ, обучение).

Базовый набор взаимосвязей между процессами АС ( ISO / IEC  12207 ) Базовый набор взаимосвязей между процессами АС ( ISO / IEC 12207 )

Стадии и этапы создания АС  ( ISO 12207: 1995) Приобретение Поставка Разработка ЭксплуатацияСтадии и этапы создания АС ( ISO 12207: 1995) Приобретение Поставка Разработка Эксплуатация Сопровождение

Поддержка жизненного цикла  АС ( ISO 12207: 1995) Документирование Конфигурационное управление Обеспечение качестваПоддержка жизненного цикла АС ( ISO 12207: 1995) Документирование Конфигурационное управление Обеспечение качества Верификация Аттестационное тестирование Управление проектом Ревизия-аудит

Стадии создания ПО 1. Формирование требований к ПО. 2. Проектирование. 3. Реализация. 4. Тестирование.Стадии создания ПО 1. Формирование требований к ПО. 2. Проектирование. 3. Реализация. 4. Тестирование. 5. Ввод в действие. 6. Эксплуатация и сопровождение. 7. Снятие с эксплуатации.

Стадии создания ПО 1. Формирование требований к ПО. 1. Планирование работ  2. ОбследованиеСтадии создания ПО 1. Формирование требований к ПО. 1. Планирование работ 2. Обследование деятельности автоматизируемого объекта (организации) 3. Построение моделей деятельности организации 2. Проектирование. 3. Закупка или разработка. 4. Тестирование. 5. Ввод в действие. 6. Эксплуатация и сопровождение. 7. Снятие с эксплуатации.

Стадия приобретения лицензионного ПО Стадия приобретения лицензионного ПО

Стадии выбора или разработки ПО 1. Формирование требований к ПО. 2. Проектирование. 1. РазработкаСтадии выбора или разработки ПО 1. Формирование требований к ПО. 2. Проектирование. 1. Разработка системного проекта, результат — Технические требования, Техническое задание 2. Разработка Технического проекта (собственно проектирование) 3. Реализация (закупка или разработка). 4. Тестирование. 5. Ввод в действие. 6. Эксплуатация и сопровождение. 7. Завершение эксплуатации.

Модель CMM/ CMMI CMM ( Capability Maturity Model ) – модель зрелости процессов организацииМодель CMM/ CMMI CMM ( Capability Maturity Model ) – модель зрелости процессов организации CMMI ( CMM Integration) — интеграция CMM Стандарт в области менеджмента качества Цель разработки CMMI – объединить лучшее из различных моделей CMM: модель зрелости процессов разработки ПО (Capability Maturity Model for Software – SW-CMM) модель зрелости процессов для системного реинжиниринга (Electronic Industries Alliance Interim Standard – EIA/IS 731) модель зрелости процессов интегрированной разработки продуктов (Integrated Product Development Capability Maturity Model – IPD-CMM) Помогает предприятию усовершенствовать свои бизнес процессы

Характеристика процессов, находящиеся на разных уровнях модели зрелости  Процессы первого уровня зрелости, Характеристика процессов, находящиеся на разных уровнях модели зрелости Процессы первого уровня зрелости, характеризуются хаотичностью, реактивностью, непредсказуемостью. Несмотря на это, очень часто предприятия, находящиеся на данном этапе развития, производят довольно качественные продукты и ИТ решения. При этом, как правило, превышается бюджет и время разработки. Качественные продукты таких организаций производятся не за счет устойчивых и отлаженных процессов, а благодаря титаническим усилиям отдельных личностей на предприятии или сторонних исполнителей. В случае ухода таких людей очень тяжело повторить успешные проекты. На данном этапе очень тяжело предсказать производительность процессов, протекающих в организации На этом уровне зрелости проектируемый производственный ИТ процесс (а вместе с ним и все связанные с процессы) представляется аморфной сущностью, практически черным ящиком , представление о процессах в АС очень ограниченное, чрезмерно много усилий тратится на выяснение статуса развития проекта и текущего хода работ. Уровень зрелости 2 – управляемый уровень, например, сторонними исполнителями. На данном этапе основные процессы описаны, их, возможно, использовать неоднократно. Другими словами, проекты, выполняемые организацией, отвечают требованиям. Процессы управляемы, они планируются, выполняются, измеряются и контролируются. Однако процессы все же имеют некоторую долю реактивности в своей сущности. На уровне 2 контролируются требования заказчиков и промежуточные продукты, а также установлены основные практики управления проектом. Эти средства позволяют управлять проектом, однако дают фрагментарное представление о нем. Фактически, производственный процесс можно представить последовательностью «черных ящиков» и реальное видение проекта присутствует лишь на промежуточных этапах. Уровень зрелости 3 – определенный уровень. В этом случае процессы в АС определены и формализованы. Установлены стандарты и регламенты предприятия в пределах организации. На данном этапе процессы описаны не на уровне отдельного проекта, а на уровне всей организации. Присутствует детальное описание всех процессов проектируемой АС, в котором лучше раскрываются связи и зависимости внутри самой АС и с другими АС, знание которых позволяет улучшить управление. На этом уровне становится видимой внутренняя сторона «черных ящиков» . Эта внутренняя структура отражает требований к АС и способ, как стандартного производственного процесса предприятия Уровень зрелости 4 – количественно-управляемый уровень. На данном этапе достигнуты все цели предыдущих уровней. Выбраны практики, которые при использовании методов и стандартных практик позволяют контролировать качество выполнения процессов в АС. Самое главное отличие этого варианта уровня зрелости от предыдущих заключается в предсказуемости и эффективности процессов, возможности эффективно ими управлять и контролировать в АС. На уровне 4 определенные процессы количественно контролируются с помощью соответствующих средств и практик. Уровень зрелости 5 – уровень постоянного улучшения (оптимизации) процессов. На данном этапе мы имеем точные характеристики оценки эффективности бизнес процессов , что позволяет нам постоянно и эффективно улучшать бизнес процессы путем развития существующих методов и техник и внедрения новых.

Модели жизненного цикла ПО 1. Под моделью ЖЦ понимается структура,  определяющая последовательность выполненияМодели жизненного цикла ПО 1. Под моделью ЖЦ понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ. 2. Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.

Основные модели ЖЦ АС Каскадная модель (70 -85 г. г. );  Спиральная модельОсновные модели ЖЦ АС Каскадная модель (70 -85 г. г. ); Спиральная модель (86 -90 г. г. ).

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

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

Спиральная модель ЖЦ проектирования АС  1. Разработка итерациями отражает объективно существующий спиральный циклСпиральная модель ЖЦ проектирования АС 1. Разработка итерациями отражает объективно существующий спиральный цикл создания системы. Каждый виток спирали соответствует созданию фрагмента или версии ПО, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Главная задача — как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований. 2. Можно переходить на следующий этап, не дожидаясь полного завершения работы на текущем. Недостающую работу можно будет выполнить на следующей итерации. Основная проблема спирального цикла — определение момента возможности и целесообразности перехода на следующий этап.

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

Структура унифицированного процесса проектирования ИС, КИСУ Управление проектом Внешняя среда. Бизнес-моделирование Детализация Тестирование. АнализСтруктура унифицированного процесса проектирования ИС, КИСУ Управление проектом Внешняя среда. Бизнес-моделирование Детализация Тестирование. Анализ и проектирование Preliminary Iteration(s) Iter. #1 Фазы Стадии основного процесса Итерации. Работы поддержки Iter. #2 Iter. #n+1 Iter. #n+2 Iter. #m+1 Размещение Управление конфигурацией Установление требований Проектир Переход. Начало Пос т роение

Методология RAD  (Rapid Application Development).  Rapid Application Development ( RAD ) –Методология RAD (Rapid Application Development). Rapid Application Development ( RAD ) – средства разработки программных продуктов. Примеры RAD- систем: Borland Delphi, Borland C++ MS Visual C++ др.

Методология RAD  (Rapid Application Development). Небольшая! команда программистов (от 2 до 10 человек)Методология RAD (Rapid Application Development). Небольшая! команда программистов (от 2 до 10 человек) Короткий производственный график (от 2 до 6 мес. ) Повторяющийся цикл, при котором разработчики, по мере того, как приложение начинает обретать форму, запрашивают и реализуют в продукте требования, полученные через взаимодействие с заказчиком. Применяется для относительно небольших проектов, разрабатываемых для конкретного заказчика. Жизненный итерационный цикл методологии RAD состоит из четырех этапов: 1. Фаза анализа и планирования требований 2. Фаза проектирования 3. Фаза построения 4. Фаза внедрения.

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

Преимущества RAD технологии Преимущества модели RAD:  Использование концепции создания средств разработки программных продуктовПреимущества RAD технологии Преимущества модели RAD: Использование концепции создания средств разработки программных продуктов — модели RAD при проектировании информационных систем в определенных условиях (!!!) может выявить следующие преимущества: применение мощных инструментальных средств разработки (С++ Builder, Delphi, MS Visual Studio и др. ) позволяет сократить время цикла разработки всего проекта; создание системы выполняется коллективом, знающим процессы предметной области; уменьшаются затраты благодаря сокращенному времени цикла, а также меньшему количеству задействованных разработчиков; уменьшается риск, связанный с соблюдением графика работ, за счет сокращенного времени цикла; сведение к минимуму риска того, что система не будет удовлетворять требованиям предметной области; основное внимание уделяется не документации, а кодированию (программированию), при этом поддерживается принцип «получаете то, что видите» ); использование различных стандартных методологий моделирования и программирования: — моделирование потоков данных (описание методов передачи информации, источников генерирования информационных потоков, кем и куда направляется информационный поток, каким образом обрабатывается); — моделирование данных (выполняется идентификация объектов данных, их атрибутов и взаимосвязей); — моделирование бизнес-процессов (методы структурного и объектно-ориентированного моделирования бизнес-процессов); генерирование приложения (объектно-ориентированные методы); — повторное использование компонентов уже разработанных программ.

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

Требования RAD технологии  При использовании данного метода Заказчик участвует во всех фазах жизненногоТребования RAD технологии При использовании данного метода Заказчик участвует во всех фазах жизненного цикла проекта — определение требований, проектирование, разработка, тестирование, поставка программного продукта. Характерной чертой метода RAD является короткое время перехода от определения требований до создания полной системы. Метод основан на последовательности итераций эволюционной разработки системы или ее существующих прототипов, которые анализируются совместно с заказчиком. В процессе такого анализа формируются или уточняются требования к продукту. Разработка программного продукта ограничивается четко определенным периодом времени, кото рый, как правило, составляет 60 дней и называется временным блоком.

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

CASE-технология обеспечивает структурный подход к проектированию АС Сущность структурного подхода к разработке АС заключаетсяCASE-технология обеспечивает структурный подход к проектированию АС Сущность структурного подхода к разработке АС заключается в ее декомпозиции (разбиении) на автоматизируемые функции: система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и так далее. Процесс разбиения продолжается вплоть до конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. Отличным примером современной реализации CASE-технологии является ПО обеспечение компании Software AG – www. softwareag. ru

SADT ( Structured Analysis and Design Technique ) - методология структурного анализа и проектированияSADT ( Structured Analysis and Design Technique ) — методология структурного анализа и проектирования систем 1. Под термином «система» понимается совокупность взаимодействующих компонент и взаимосвязей между ними. 2. Описание системы с помощью SADT называется моделью. 3. Под термином «моделирование» понимается процесс создания точного описания системы. 4. В SADT-моделях используются как естественный, так и графический языки. Для передачи информации о конкретной системе источником естественного языка служат люди, описывающие систему, а источником графического языка — сама методология SADT.

История В начале 70 -х годов вооруженные силы США применили подмножество SADT, касающееся моделированияИстория В начале 70 -х годов вооруженные силы США применили подмножество SADT, касающееся моделирования процессов, для реализации проектов в рамках программы ICAM (Integrated Computer-Aided Manufacturing). В дальнейшем это подмножество SADT было принято в качестве федерального стандарта США под наименованием IDEF: IDEF — методологии семейства ICAM (Integrated Computer-Aided Manufacturing) для решения задач моделирования сложных систем, позволяет отображать и анализировать модели деятельности широкого спектра сложных систем в различных разрезах. При этом широта и глубина обследования процессов в системе определяется самим разработчиком, что позволяет не перегружать создаваемую модель излишними данными. В настоящий момент к семейству IDEF можно отнести следующие стандарты: IDEF 0 — Function Modeling — методология функционального моделирования. С помощью наглядного графического языка IDEF 0 изучаемая система предстает перед разработчиками и аналитиками в виде набора взаимосвязанных функций (функциональных блоков — в терминах IDEF 0). Как правило, моделирование средствами IDEF 0 является первым этапом изучения любой системы. Методологию IDEF 0 можно считать следующим этапом развития хорошо известного графического языка описания функциональных систем SADT (Structured Analysis and Design Technique); IDEF 1 — Information Modeling — методология моделирования информационных потоков внутри системы, позволяющая отображать и анализировать их структуру и взаимосвязи; IDEF 1 X (IDEF 1 Extended) — Data Modeling — методология построения реляционных структур (баз данных), относится к типу методологий «Сущность-взаимосвязь» (ER — Entity-Relationship) и, как правило, используется для моделирования реляционных баз данных, имеющих отношение к рассматриваемой системе; IDEF 2 — Simulation Model Design — методология динамического моделирования развития систем. В связи с весьма серьезными сложностями анализа динамических систем от этого стандарта практически отказались, и его развитие приостановилось на самом начальном этапе. В настоящее время присутствуют алгоритмы и их компьютерные реализации, позволяющие превращать набор статических диаграмм IDEF 0 в динамические модели, построенные на базе «раскрашенных сетей Петри» (CPN — Color Petri Nets); IDEF 3 — Process Description Capture — документирование процессов, IDEF 3 — методология документирования процессов, происходящих в системе (например, на предприятии), описываются сценарий и последовательность операций для каждого процесса. IDEF 3 имеет прямую взаимосвязь с методологией IDEF 0 — каждая функция (функциональный блок) может быть представлена в виде отдельного процесса средствами IDEF 3; IDEF 4 — Object-Oriented Design — методология построения объектно-ориентированных систем, позволяют отображать структуру объектов и заложенные принципы их взаимодействия, тем самым позволяя анализировать и оптимизировать сложные объектно-ориентированные системы; IDEF 5 — Ontology Description Capture — Стандарт онтологического исследования сложных систем. С помощью методологии IDEF 5 онтология системы может быть описана при помощи определенного словаря терминов и правил, на основании которых могут быть сформированы достоверные утверждения о состоянии рассматриваемой системы в некоторый момент времени. На основе этих утверждений формируются выводы о дальнейшем развитии системы и производится её оптимизация; IDEF 6 — Design Rationale Capture — Обоснование проектных действий. Назначение IDEF 6 состоит в облегчении получения «знаний о способе» моделирования, их представления и использования при разработке систем управления предприятиями. Под «знаниями о способе» понимаются причины, обстоятельства, скрытые мотивы, которые обуславливают выбранные методы моделирования. Проще говоря, «знания о способе» интерпретируются как ответ на вопрос: «почему модель получилась такой, какой получилась? » Большинство методов моделирования фокусируются на собственно получаемых моделях, а не на процессе их создания. Метод IDEF 6 акцентирует внимание именно на процессе создания модели; Под робные специ фи кац ии на станд арты IDEF можно н айт и на сай те http: //www. idef. com

История. Продолжение.  IDEF 7 — Information System Auditing — Аудит информационных систем. ЭтотИстория. Продолжение. IDEF 7 — Information System Auditing — Аудит информационных систем. Этот метод определён как востребованный, однако так и не был полностью разработан; IDEF 8 — User Interface Modeling — Метод разработки интерфейсов взаимодействия оператора и системы (пользовательских интерфейсов). Современные среды разработки пользовательских интерфейсов в большей степени создают внешний вид интерфейса. IDFE 8 фокусирует внимание разработчиков интерфейса на программировании желаемого взаимного поведения интерфейса и пользователя на трех уровнях: выполняемой операции (что это за операция); сценарии взаимодействия, определяемом специфической ролью пользователя (по какому сценарию она должна выполняться тем или иным пользователем); и, наконец, на деталях интерфейса (какие элементы управления, предлагает интерфейс для выполнения операции); IDEF 9 — Scenario-Driven IS Design (Business Constraint Discovery method) — Метод исследования бизнес ограничений был разработан для облегчения обнаружения и анализа ограничений в условиях которых действует предприятие. Обычно, при построении моделей описанию ограничений, оказывающих влияние на протекание процессов на предприятии уделяется недостаточное внимание. Знания об основных ограничениях и характере их влияния, закладываемые в модели, в лучшем случае остаются неполными, несогласованными, распределенными нерационально, но часто их вовсе нет. Это не обязательно приводит к тому, что построенные модели нежизнеспособны, просто их реализация столкнется с непредвиденными трудностями, в результате чего их потенциал будет не реализован. Тем не менее в случаях, когда речь идет именно о совершенствовании структур или адаптации к предсказываемым изменениям, знания о существующих ограничениях имеют критическое значение; IDEF 10 — Implementation Architecture Modeling — Моделирование архитектуры выполнения. Этот метод определён как востребованный, однако так и не был полностью разработан; IDEF 11 — Information Artifact Modeling. Этот метод определён как востребованный, однако так и не был полностью разработан; IDEF 12 — Organization Modeling — Организационное моделирование. Этот метод определён как востребованный, однако так и не был полностью разработан; IDEF 13 — Three Schema Mapping Design — Трёхсхемное проектирование преобразования данных. Этот метод определён как востребованный, однако так и не был полностью разработан; IDEF 14 — Network Design — Метод проектирования компьютерных сетей, основанный на анализе требований, специфических сетевых компонентов, существующих конфигураций сетей. Также он обеспечивает поддержку решений, связанных с рациональным управлением материальными ресурсами, что позволяет достичь существенной экономии. Под робн ы е спец иф икац ии н а стан д арты IDEF можно найти н а сайте http: //www. idef. com

Применение IDEF для создания сложных ИС На начальных этапах создания ИС необходимо понять, какПрименение IDEF для создания сложных ИС На начальных этапах создания ИС необходимо понять, как работает организация, которую собираются автоматизировать Для описания работы предприятия необходимо построить МОДЕЛЬ. Модель должна быть адекватна предметной области , следовательно, она должна содержать в себе знания всех участников бизнес-процессов организации.

Модель системы в IDEF -модель дает полное, точное и адекватное описание системы, имеющее конкретноеМодель системы в IDEF -модель дает полное, точное и адекватное описание системы, имеющее конкретное назначение. Это назначение, называемое целью модели, вытекает из формального определения модели : М есть модель системы S , если М может быть использована для получения ответов на вопросы относительно S с точностью А

Принципы создания моделей Целью модели является получение ответов на некоторую совокупность вопросов. Эти вопросыПринципы создания моделей Целью модели является получение ответов на некоторую совокупность вопросов. Эти вопросы присутствуют ( подразумеваются) в процессе анализа. После завершения работы над моделью информация, содержащаяся в модели, будет отвечать на поставленные вопросы. Моделируемая система всегда связана с окружающей средой. В методологии IDEF подчеркивается необходимость точного определения границ системы, т. е. модель устанавливает точно, что является и что не является субъектом моделирования, описывая то, что входит в систему, и подразумевая то, что лежит за ее пределами. IDEF -модель должна иметь единственный субъект. С определением модели тесно связана позиция, с которой наблюдается система и создается ее модель. Эта позиция называется «точкой зрения» данной модели.

Принципы создания моделей (резюме) Методология IDEF создана специально для представления сложных систем путем построенияПринципы создания моделей (резюме) Методология IDEF создана специально для представления сложных систем путем построения моделей. IDEF -модель — это описание системы, у которого есть единственный субъект, цель и одна точка зрения. Целью служит набор вопросов, на которые должна ответить модель. Точка зрения — позиция, с которой описывается система. Цель и точка зрения — это основополагающие понятия IDEF. Описание модели IDEF организовано в виде иерархии взаимосвязанных диаграмм. Вершина этой древовидной структуры представляет собой самое общее описание системы, а ее основание состоит из наиболее детализированных описаний.

Моделирование бизнес процессов лежит в основе проектирования информационной системы Этапы проектирования АС 1. ОбследованиеМоделирование бизнес процессов лежит в основе проектирования информационной системы Этапы проектирования АС 1. Обследование деятельности предприятия 2. Разработка системного проекта 3. Разработка предложений по автоматизации предприятия 4. Разработка технического проекта

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

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

Функциональное моделирования 1. Функциональное моделирование – процесс создания функциональной модели 2. Цель моделирования -Функциональное моделирования 1. Функциональное моделирование – процесс создания функциональной модели 2. Цель моделирования — ускорение и удешевление разработки АС и / или совершенствования функционирования (реинжиниринга) систем 3. Функциональная модель предназначена для описания существующих бизнес-процессов на предприятии (модель «как есть» ) и идеальных, к которым нужно стремиться (модели «как будет» )

Функциональное моделирования. US ED AT: AUTHOR:  Д убе йковский В. И. DATE: REV:Функциональное моделирования. US ED AT: AUTHOR: Д убе йковский В. И. DATE: REV: PROJECT: Исполь зование BPWin 03. 10. 01 NOTES : 1 2 3 4 5 6 7 8 9 10 WORKING DRAFT RECOMMENDED PUBLICATION READERDATECONTEXT: A-0 NODE: TITLE: NUMBER: Функциональное моделирование систем — технология двойного назначения. A 0 1 Функциональное мод елирование 2 Осуществление BPR 3 Под д ержка CASE — технологий Файлы *. BPX ERWin. СУБД Функциональная мод ель «TO BE» BPWin Проект ная поддержка BPR SADT, IDEF 0 , IDEF 3, нотация Гейна — Сарсона ППП Инновацио нный замысел Реорганизованное производство Материальные и финансовые ресурсы Техническое зад ание

Принципы моделирования В IDEF 0 моделируемая СИСТЕМА представляется как СОВОКУПНОСТЬ взаимодействующих РАБОТ или ФУНКЦИЙ.Принципы моделирования В IDEF 0 моделируемая СИСТЕМА представляется как СОВОКУПНОСТЬ взаимодействующих РАБОТ или ФУНКЦИЙ. Такая чисто функциональная ориентация является принципиальной — функции системы анализируются независимо от объектов, которыми они оперируют. Это позволяет более четко смоделировать логику и взаимодействие процессов организации.

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

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

Граница – Вход – Выход – Управление - Механизм Система имеет ГРАНИЦУ , котораяГраница – Вход – Выход – Управление — Механизм Система имеет ГРАНИЦУ , которая отделяет ее от « внешней среды » . Взаимодействие системы с окружающим миром описывается как ВХОД (нечто, что перерабатывается системой), ВЫХОД (результат деятельности системы), УПРАВЛЕНИЕ (стратегии и процедуры, под управлением которых производится работа) МЕХАНИЗМ (ресурсы, необходимые для проведения работы).

Типы стрелок в IDEF 0 Вход (input)  Управление (Control)  Выход (Output) Типы стрелок в IDEF 0 Вход (input) Управление (Control) Выход (Output) Механизм (Mechanism) Вызов (Call) Control Mechanism. In p u t O u tp u t

Вход – Выход – Управление - Механизм. US ED AT: AUTHOR:  DATE: REV:Вход – Выход – Управление — Механизм. US ED AT: AUTHOR: DATE: REV: PROJECT: Дуглас Т. Росс. Понятие блока ид е композиции. 30 Octobe r 2001 г. NOTES : 1 2 3 4 5 6 7 8 9 10 WORKING DRAFT RECOMMENDED PUBLICATION READERDATECONTEXT: TO P NODE: TITLE: NUMBER: Фун к ци я п р ео бр аз ов ан и я A-0 00 р. Функция преобразования Output Arrow — ст релка выход а (мат ериального, информационного или энергет ического) Mechanism Arrow — стрелка «механизм осуществления преобразования» Control Arrow — стрелка управления преобразованием. Input Arrow — ст релка вход а (материального, информационного или энергетического)

Цель моделирования (Purpose). Модель не может быть построена без четко сформулированной цели.  ЦельЦель моделирования (Purpose). Модель не может быть построена без четко сформулированной цели. Цель должна отвечать на следующие вопросы: Почему этот процесс должен быть замоделирован? Что должна показывать модель? Что может получить пользователь модели?

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

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

Контекст моделирования Процесс моделирования какой-либо системы в IDEF 0 начинается с определения КОНТЕКСТА ,Контекст моделирования Процесс моделирования какой-либо системы в IDEF 0 начинается с определения КОНТЕКСТА , т. е. наиболее абстрактного уровня описания системы в целом. В контекст входит определение субъекта моделирования , цели и точки зрения на модель.

 Основу методологии IDEF 0 составляет графический язык описания бизнес-процессов.  Модель в IDEF Основу методологии IDEF 0 составляет графический язык описания бизнес-процессов. Модель в IDEF 0 представлена совокупностью иерархически упорядоченных и логически связанных диаграмм. Ч ем выше уровень диаграммы, тем она менее детализирована. Каждая диаграмма располагается на отдельном листе. Основные типы диаграмм: контекстная диаграмма А-0 (в каждой модели может быть только одна контекстная диаграмма); диаграммы декомпозиции (в том числе диаграмма первого уровня декомпозиции А 0, раскрывающая контекстную). В состав диаграммы входят функциональные блоки, изображающие активности (функции) моделируемой системы, и стрелки, связывающие блоки вместе и изображающие взаимодействия и взаимосвязи между блоками.

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

BPwin : диаграммы FEO ( For Exposition Only)  Часто при выборе точки зренияBPwin : диаграммы FEO ( For Exposition Only) Часто при выборе точки зрения на результирующую модель важно задокументировать дополнительные альтернативные точки зрения. Для этой цели обычно используется методология IDEF 0 , диаграммы BPwin — FEO (For Exposition Only). См. www. idef. com

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

Источники информации  Параметр - Source описываются источники информации для построения модели (например, ОпросИсточники информации Параметр — Source описываются источники информации для построения модели (например, «Опрос экспертов предметной области и анализ документации»).

 Процесс проектирования АС с помощью продуктов линейки All. Fusion Modeling Suite Проектирование структуры Процесс проектирования АС с помощью продуктов линейки All. Fusion Modeling Suite Проектирование структуры данных Реализация базы данных Проектирование программного продукта Реализация программного продукта Прототипи- рование ИС Анализ проблем Обследование проблем Бизнес компании Совершенствование управления качеством БД IDEF 0, IDEF 3. BPwin DFD. BPwin UML. ACM (RR) IDEF 1 X. ERwin Инструменты : ACM – All. Fusion Component Modeler; ARIS – IDS Scheer; Rational Rose – IBM ; BPwin – Computer Associates. Методологии : IDEF 0 – функциональное моделирование IDEF 3 – моделирование потока работ DFD – моделирование потоков данных UML – обобщенный язык моделирования объектов

Process Modeler (BPwin) – инструмент системного анализа Система BPwin поможет повысить конкурентоспособность, оптимизировать процессыProcess Modeler (BPwin) – инструмент системного анализа Система BPwin поможет повысить конкурентоспособность, оптимизировать процессы управления. Результатом использования BPwin является исключение лишних и бесполезных действий, снижение затрат, повышение гибкости и эффективности всего бизнеса. BPwin — инструмент менеджеров и бизнес-аналитиков, а в руках системных аналитиков и разработчиков — еще и мощное средство моделирования процессов при создании корпоративных информационных систем BPwin — мощное средство системного анализа деловой и производственной активности, позволяющее адекватно отслеживать соответствие структуры бизнеса, документооборота, финансовых потоков жестким и динамичным требованиям экономики.

Основные характеристики BPwin Развитая методология функционального моделирования на основе IDEF 0  Мощные редакторыОсновные характеристики BPwin Развитая методология функционального моделирования на основе IDEF 0 Мощные редакторы для описания операций, связей и вычисления затрат на выполнение работ Иерархическая структура диаграмм, облегчающая последовательное уточнение элементов модели Контекстные диаграммы для описания границ системы, области действия, назначения объектов Декомпозиционные диаграммы для описания особенностей взаимодействия различных процессов Расширенные возможности по поддержанию ссылочной целостности Поддержка методологии IDEF 3 Экспорт моделей в средства имитационного моделирования Интеграция и связь со средством проектирования баз данных ERwin (методология IDEF 1 X) Поддержка свойств, определяемых пользователем. Описание моделей может быть расширено за счет свойств, определяемых пользователем, включая мультимедийные документы.

Основные достоинства BPwin помогает быстро создавать и анализировать модели с целью оптимизации деловых иОсновные достоинства BPwin помогает быстро создавать и анализировать модели с целью оптимизации деловых и производственных процессов. Применение универсальных графических языков бизнес-моделирования IDEF 0, IDEF 3 и DFD обеспечивает логическую целостность и полноту описания, необходимую для достижения точных и непротиворечивых результатов. BРwin поддерживает ссылочную целостность, не допуская определения некорректных связей и гарантируя непротиворечивость отношений между объектами при моделировании. Встроенный механизм вычисления стоимости позволяет оценивать и анализировать затраты на осуществление различных видов деловой активности. Механизм вычисления расходов на основе выполняемых действий (Activity-Based Costing, ABC) — это технология, применяемая для оценки затрат и используемых ресурсов. Она помогает распознать и выделить наиболее дорогостоящие операции для дальнейшего анализа. BPwin может генерировать отчеты непосредственно в формате MS Excel для последующей обработки и использования в других приложениях.

Создание модели в BPWin  задани е имени модели  выбор методологии описания моделиСоздание модели в BPWin задани е имени модели выбор методологии описания модели IDEF 0, IDEF 3 или DFD.

Диалог Model Properties ,  назначение и точка зрения модели В закладке  PurposeДиалог Model Properties , назначение и точка зрения модели В закладке Purpose следует внести цель (Purpose) и точку зрения (View. Point)

Диалог Model Properties ,  определение и границы модели В закладке  Definition следуетДиалог Model Properties , определение и границы модели В закладке Definition следует внести определение ( Definition ) и границы ( Scope ) модели

Диалог Model Properties , источники информации модели В закладке Source описываются источники информации. ДляДиалог Model Properties , источники информации модели В закладке Source описываются источники информации. Для построения модели (например, «Опрос экспертов предметной области и анализ документации»).

Диалог Model Properties , нумерация Служит для настройки именования и н у мер ацииДиалог Model Properties , нумерация Служит для настройки именования и н у мер ации элементов диаграммы в модели

Диалог Model Properties , настройка вида диаграмм Служит для настройки отображения элементов диаграммы вДиалог Model Properties , настройка вида диаграмм Служит для настройки отображения элементов диаграммы в модели

Диалог Model Properties , выравнивание элементов на диаграмме Служит для настройки выравнивания и подгонкиДиалог Model Properties , выравнивание элементов на диаграмме Служит для настройки выравнивания и подгонки размеров элементов диаграммы в модели

Диалог Model Properties , единицы измерения Служит для настройки единиц измерения характеристик функций иДиалог Model Properties , единицы измерения Служит для настройки единиц измерения характеристик функций и элементов диаграммы модели

Диалог Model Properties , параметры страницы Служит для настройки формата листов и размера диаграммыДиалог Model Properties , параметры страницы Служит для настройки формата листов и размера диаграммы модели

Диалог Model Properties , заголовки Служит для настройки заголовков и колонтитулов страниц листов диаграммыДиалог Model Properties , заголовки Служит для настройки заголовков и колонтитулов страниц листов диаграммы модели

Диалог Model Properties , состояние Служит для задания текущего состояния разработки диаграммы модели Диалог Model Properties , состояние Служит для задания текущего состояния разработки диаграммы модели

Диаграммы IDEF 0 контекстная диаграмма (в каждой модели может быть только одна  контекстнаяДиаграммы IDEF 0 контекстная диаграмма (в каждой модели может быть только одна контекстная диаграмма); диаграмма декомпозиции ; диаграмма дерева узлов ; диаграмма только для экспозиции (FEO).

Словарь База данных терминов предметной области Термины использованные в модели Словарь База данных терминов предметной области Термины использованные в модели

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

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

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

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

Порядок доминирования работ в диаграмме декомпозиции Порядок доминирования работ в диаграмме декомпозиции

Нумерация работ и диаграмм  Все работы модели нумеруются. Номер состоит из префикса иНумерация работ и диаграмм Все работы модели нумеруются. Номер состоит из префикса и числа. Может быть использован префикс любой длины, но обычно используют префикс А. Контекстная (корневая), работа дерева имеет номер А 0. Работы декомпозиции А 0 имеют номера A 1 , A 2, A 3 и т. д. Работы декомпозиции нижнего уровня имеют номер родительской работы и очередной порядковый номер, например работы декомпозиции A 3 будут иметь номера А 31, А 32, АЗЗ, А 34 и т. д.

Стрелки (Arrow)  Взаимодействие работ с внешним миром и между собой описывается в видеСтрелки (Arrow) Взаимодействие работ с внешним миром и между собой описывается в виде стрелок. Стрелки представляют собой некую информацию и именуются существительными , например, «Заготовка», «Изделие», «Заказ».

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

Диаграмма декомпозиции работы «Изготовление изделия»  Диаграмма декомпозиции работы «Изготовление изделия»

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

Управление (Control) - правила,  стратегии, процедуры или стандарты,  которыми руководствуется работа. КаждаяУправление (Control) — правила, стратегии, процедуры или стандарты, которыми руководствуется работа. «Каждая работа должна иметь хотя бы одну стрелку управления. Стрелка управления рисуется как входящая в верхнюю грань работы.

Выход (Output) - материал или информация,  которые производятся работой. Каждая работа должна иметьВыход (Output) — материал или информация, которые производятся работой. Каждая работа должна иметь хотя бы одну стрелку выхода. Работа без результата не имеет смысла и не должна моделироваться. Стрелка выхода рисуется как исходящая из правой грани работы.

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

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

Граничные стрелки  Граничные стрелки. Стрелки на контекстной диаграмме служат для описания взаимодействия системыГраничные стрелки Граничные стрелки. Стрелки на контекстной диаграмме служат для описания взаимодействия системы с окружающим миром. Они могут начинаться у границы диаграммы и заканчиваться у работы, или наоборот. Для внесения граничной стрелки входа надо: 1. щелкнуть по кнопке с символом стрелки в палитре инструментов следует перенести курсор к левой стороне экрана, пока не появится начальная штриховая полоска; 2. щелкнуть один раз по полоске (откуда выходит стрелка) и еще раз в левой части работы со стороны входа (где заканчивается стрелка); 3. вернуться в палитру инструментов и выбрать опцию редактирования стрелки 4. щелкнуть правой кнопкой мыши на линии стрелки, во всплывающем меню выбрать Name Editor и добавить имя стрелки в закладке Name диалога IDEF 0 Arrow Properties.

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

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

Связь по входу (output-input )  Связь по входу (output-input) ,  когда стрелкаСвязь по входу (output-input ) Связь по входу (output-input) , когда стрелка выхода вышестоящей работы (далее — просто выход) направляется на вход нижестоящей

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

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

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

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

Разветвляющиеся стрелки  Смысл разветвляющихся и сливающихся стрелок передается именованием каждой ветви стрелок Разветвляющиеся стрелки Смысл разветвляющихся и сливающихся стрелок передается именованием каждой ветви стрелок

Именование стрелок  Если стрелка именована до разветвления, а после разветвления ни одна изИменование стрелок Если стрелка именована до разветвления, а после разветвления ни одна из ветвей не именована, то подразумевается, что каждая ветвь моделирует те же объекты, что и ветвь до разветвления

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

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

Тоннелирование стрелок  Тоннелирование стрелок.  Вновь внесенные граничные стрелки на диаграмме декомпозиции нижнегоТоннелирование стрелок Тоннелирование стрелок. Вновь внесенные граничные стрелки на диаграмме декомпозиции нижнего уровня изображаются в квадратных скобках и автоматически не появляются на диаграмме верхнего уровня « Неразрешенная (unresolved) стрелка» .

Ликвидация неразрешенных стрелок Для их перетаскивания наверх нужно сначала выбрать кнопку на палитре инструментовЛиквидация неразрешенных стрелок Для их «перетаскивания» наверх нужно сначала выбрать кнопку на палитре инструментов щелкнуть по квадратным скобкам граничной стрелки. Появляется диалог Border Arrow Editor . Если щелкнуть по кнопке Resolve Border Arrow, стрелка мигрирует на диаграмму верхнего уровня, если по кнопке Change To Tunnel — стрелка будет затоннелирована и не попадет на другую диаграмму. Тоннельная стрелка изображается с круглыми скобками на конце.

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

Пример DFD- диаграммы Пример DFD- диаграммы

Диаграммы потоков данных - DFD - Data flow diagramming используются для описания документооборота иДиаграммы потоков данных — DFD — Data flow diagramming используются для описания документооборота и обработки информации. Подобно IDEF 0, DFD представляет модельную систему как сеть связанных между собой работ. DFD описывает: функции обработки информации (работы); документы (стрелки, arrow), объекты , сотрудников или отделы, которые участвуют в обработке информации; в нешние ссылки (external references) , которые обеспечивают интерфейс с внешними объектами, находящимися за границами моделируемой системы; таблицы для хранения документов (хранилище данных, data store). В BPwin для построения диаграмм потоков данных используется нотация Гейна-Сарсона.

Стрелки в DFD диаграмме В отличие от стрелок IDEF 0, которые представляют собой жесткиеСтрелки в DFD диаграмме В отличие от стрелок IDEF 0, которые представляют собой жесткие взаимосвязи, стрелки DFD показывают, как объекты (включая данные) двигаются от одной работы к другой. представление потоков совместно с хранилищами данных и внешними сущностями делает модели DFD более похожими на физические характеристики системы — движение объектов (data flow), хранение объектов (data stores), поставка и распространение объектов (external entities). Стрелки могут присоединяться к работе с любой стороны

Хранилище данных (Data store ) - добавить в диаграмму хранилище данных (Data store). Хранилище данных (Data store ) — добавить в диаграмму хранилище данных (Data store). Хранилище данных позволяет описать данные, которые необходимо сохранить в памяти прежде, чем использовать в работах; В отличие от стрелок, описывающих объекты в движении, хранилища данных изображают объекты в покое

Внешн яя ссылк а (External Reference).  - добавить в диаграмму внешнюю ссылку Внешн яя ссылк а (External Reference). — добавить в диаграмму внешнюю ссылку (External Reference). -Внешняя ссылка является источником или приемником данных извне модели Внешние сущности изображают входы в систему и/или выходы из системы. Внешние сущности изображаются в виде прямоугольника с тенью и обычно располагаются по краям диаграммы. Одна внешняя сущность может быть использована многократно на одной или нескольких диаграммах.

Функция (Работа) В отличие от IDEF 0, где система рассматривается как взаимосвязанные работы. DFDФункция (Работа) В отличие от IDEF 0, где система рассматривается как взаимосвязанные работы. DFD рассматривает систему как совокупность предметов. В DFD работы представляют собой функции системы, преобразующие входы в выходы. Хотя работы изображаются прямоугольниками со скругленными углами, смысл их совпадает со смыслом работ IDEF 0 и IDEF 3. Так же как работы IDEF 3, они имеют входы и выходы, но не поддерживают управления и механизмы, как IDEF 0.

Нумерация объектов  Нумерация объектов.  В DFD номер каждой работы может включать префикс,Нумерация объектов Нумерация объектов. В DFD номер каждой работы может включать префикс, номер родительской работы (А) и номер объекта. Номер объекта — это уникальный номер работы на диаграмме. Например, работа может иметь номер А. 12. 4. Уникальный номер имеют хранилища данных и внешние сущности независимо от их расположения на диаграмме. Каждое хранилище данных имеет префикс D и уникальный номер, например D 5. Каждая внешняя сущность имеет префикс Е и уникальный номер, например Е 5.

IDEF 3 I

Пример IDEF 3 -диаграммы Пример IDEF 3 -диаграммы

Метод описания процессов IDEF 3 ( Workflow diagramm )  Для описания логики взаимодействияМетод описания процессов IDEF 3 ( Workflow diagramm ) Для описания логики взаимодействия информационных потоков используется IDEF 3 , называемая также workflow diagramming — методологи я моделирования, использующая графическое описание информационных потоков, взаимоотношений между процессами обработки информации и объектов, являющихся частью этих процессов.

Цель IDEF 3 - это метод, имеющий основной целью дать возможность аналитикам описать ситуацию,Цель IDEF 3 — это метод, имеющий основной целью дать возможность аналитикам описать ситуацию, когда процессы выполняются в определенной последовательности, а также описать объекты , участвующие совместно в одном процессе.

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

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

Единицы  работы - Unit of Work (UOW). UOW, также называемые работами (activity), являютсяЕдиницы работы — Unit of Work (UOW). UOW, также называемые работами (activity), являются центральными компонентами модели В IDEF 3 работы изображаются прямоугольниками с прямыми углами и имеют имя, выраженное отглагольным существительным, обозначающим процесс действия, одиночным или в составе фразы, и номер (идентификатор) Идентификатор работы присваивается при создании и не меняется никогда. Даже если работа будет удалена, ее идентификатор не будет вновь использоваться для других работ.

Связи  в IDEF 3 Связи показывают взаимоотношения работ. Все связи в IDEF 3Связи в IDEF 3 Связи показывают взаимоотношения работ. Все связи в IDEF 3 однонаправлены и могут быть направлены куда угодно, но обычно диаграммы IDEF 3 стараются построить так, чтобы связи были направлены слева направо. В IDEF 3 различают три типа стрелок, изображающих связи, стиль которых устанавливается через меню Edit/Arrow Style

Связь старшая (Precedence) Сплошная линия, связывающая единицы работ (UOW),  Рисуется слева направо илиСвязь старшая (Precedence) Сплошная линия, связывающая единицы работ (UOW), Рисуется слева направо или сверху вниз. Показывает, что работа-источник должна закончиться прежде, чем работа-цель начнется.

Связь отношения (Relational Link)  Пунктирная линия,  использующаяся для изображения связей между единицамиСвязь отношения (Relational Link) Пунктирная линия, использующаяся для изображения связей между единицами работ (UOW) а также между единицами работ и объектами ссылок

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

Перекрестки (Junction) и разветвления (Fan-out Junction)  стрелок Перекрестки используются для отображения логики взаимодействияПерекрестки (Junction) и разветвления (Fan-out Junction) стрелок Перекрестки используются для отображения логики взаимодействия стрелок при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы. Перекресток не может использоваться одновременно для слияния и для разветвления. Для внесения перекрестка служит кнопка в палитре инструментов — добавить в диаграмму перекресток Junction. В диалоге Junction Type Editor необходимо указать тип перекрестка.

Перекресток асинхронное и  ( AND ) Все предшествующие процессы должны быть завершены ВсеПерекресток асинхронное и ( AND ) Все предшествующие процессы должны быть завершены Все следующие процессы должны быть запущены

Перекресток асинхронное и  ( AND ) Асинхронное  «И»  :  послеПерекресток асинхронное и ( AND ) Асинхронное «И» : после завершения работы № 10 запускаются работы № 11 № 12 Для запуска работы № 14 требуется завершение работы № 11 и №

Перекресток синхронное и  ( AND ) Все предшествующие процессы завершены одновременно Все следующиеПерекресток синхронное и ( AND ) Все предшествующие процессы завершены одновременно Все следующие процессы запускаются одновременно

Перекресток синхронное и  ( AND ) Синхронное «И» : после завершения работы №Перекресток синхронное и ( AND ) Синхронное «И» : после завершения работы № 5 одновременно запускаются работы № 6 № 8 Для запуска работы № 9 требуется одновременное завершение работы № 8 и №

Перекресток  асинхронное или  ( or ) Один или несколько предшествующих процессов должныПерекресток асинхронное или ( or ) Один или несколько предшествующих процессов должны быть завершены Один или несколько следующих процессов должны быть запущены

Перекресток асинхронное или  ( or ) Асинхронное «Или» : после завершения работы №Перекресток асинхронное или ( or ) Асинхронное «Или» : после завершения работы № 15 запускается или работа № 16 или № 17 или 18 или их сочетание причем не одновременно Для запуска работы № 19 требуется завершение любой из работ № 16, № 17, № 18.

Перекресток синхронное или  ( or ) Один или несколько предшествующих процессов завершены одновременноПерекресток синхронное или ( or ) Один или несколько предшествующих процессов завершены одновременно Один или несколько следующих процессов запускаются одновременно

Перекресток синхронное или  ( or ) Синхронное «Или» : после завершения работы №Перекресток синхронное или ( or ) Синхронное «Или» : после завершения работы № 20 запускаются работа № 21 или № 22 или 23 или их сочетание , требуется их одновременный запуск , Для запуска работы № 24 требуется завершение любой из работ № 16, № 17, № 18. Если завершается более 1 работы, то требуется их одновременное завершение

Перекресток исключающее или  (х or ) Только один предшествующий процесс завершен Только одинПерекресток исключающее или (х or ) Только один предшествующий процесс завершен Только один следующий процесс запускается

Перекресток исключающее ИЛИ После завершения Работы 1 запускается только одна работа - Работа 2Перекресток исключающее ИЛИ После завершения Работы 1 запускается только одна работа — Работа 2 или Работа 4 Для запуска работы 5 требуется завершение только одной из работ, 3 или

Правила создания перекрестков Всё перекрестки на диаграмме нумеруются,  каждый номер имеет префикс J.Правила создания перекрестков Всё перекрестки на диаграмме нумеруются, каждый номер имеет префикс J. Можно редактировать свойства перекрестка при помощи диалога Definition Editor. В отличие от IDEF 0 и DFD в IDEF 3 стрелки могут сливаться и разветвляться только через перекрестки.

Правила создания перекрестков Каждому перекрестку для слияния должен предшествовать перекресток для разветвления.  ПерекрестокПравила создания перекрестков Каждому перекрестку для слияния должен предшествовать перекресток для разветвления. Перекресток для слияния «И» не может следовать за перекрестком для разветвления «ИЛИ» Перекресток для слияния «И» не может следовать за перекрестком для разветвления типа исключающего «ИЛИ» Перекресток для слияния типа исключающего «ИЛИ» не может следовать за перекрестком для разветвления типа «И» Перекресток имеющий одну стрелку на одной стороне , должен иметь более одной стрелки на другой стороне. .

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

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

Задание:  «Прочитать»  IDEF 3 - диаграмму Задание: «Прочитать» IDEF 3 — диаграмму

Задание:  «Прочитать»  IDEF 3 - диаграмму Задание: «Прочитать» IDEF 3 — диаграмму

Задание:  «Прочитать»  IDEF 3 - диаграмму Задание: «Прочитать» IDEF 3 — диаграмму

Задание:  «Прочитать»  IDEF 3 - диаграмму Задание: «Прочитать» IDEF 3 — диаграмму

Организационные диаграммы и диаграммы Swim Lane BPwin содержит набор инструментов для моделирования организационной структурыОрганизационные диаграммы и диаграммы Swim Lane BPwin содержит набор инструментов для моделирования организационной структуры предприятия.

Словарь Role Group Dictionary ( меню Dictionary / Role Group ) позволяет создать иСловарь Role Group Dictionary ( меню Dictionary / Role Group ) позволяет создать и определить свойства групп ролей. Группы ролей могут использоваться как на организационных диаграммах, так и на диаграммах Swim Lane. В качестве значения группы ролей может быть название предприятия, отдела, цеха или название региона, города и т д.

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

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

Диаграмма распределения ролей Swim Lane Созданные в словаре Role Dictionary роли могут быть такжеДиаграмма распределения ролей Swim Lane Созданные в словаре Role Dictionary роли могут быть также использованы в диаграмме Swim Lane. Диаграмма Swim Lane является разновидностью диаграммы IDEF 3, позволяющей явно описать роли и ответственности исполнителей в конкретной технологической операции. Эта диаграмма разделена на горизонтальные полосы, с каждой полосой может быть связана роль или UDP типа Text List. Полоса может содержать объекты диаграммы IDEF 3 ( UOW , перекрестки и объекты ссылок), относящиеся к соответствующей роли. Для создания диаграммы Swim Lane следует выбрать меню Diagram/Add Swim Lane diagram. Появляется гид Swim Lane diagram Wizard. В первом диалоге следует внести название и имя автора диаграммы, выбрать имя и номер диаграммы IDEF 3, на основе которой будет построена диаграмма, и группу ролей, из которой можно будет выбрать роли, связанные с диаграммой.

Модель IDEF 0 Основным рабочим элементом при моделировании является диаграмма.  Модель IDEF 0Модель IDEF 0 Основным рабочим элементом при моделировании является диаграмма. Модель IDEF 0 объединяет и организует диаграммы в иерархические древовидные структуры, при этом, чем выше уровень диаграммы, тем она менее детализирована. Основу методологии IDEF 0 составляет графический язык описания бизнес-процессов. Модель в IDEF 0 представлена совокупностью иерархически упорядоченных и логически связанных диаграмм. Каждая диаграмма располагается на отдельном листе. Основные типы диаграмм: контекстная диаграмма А-0 (в каждой модели может быть только одна контекстная диаграмма); диаграммы декомпозиции (в том числе диаграмма первого уровня декомпозиции А 0, раскрывающая контекстную). В состав диаграммы входят функциональные блоки, изображающие активности (функции) моделируемой системы, и стрелки, связывающие блоки вместе и изображающие взаимодействия и взаимосвязи между блоками.

Стадии создания АС (ГОСТ 34. 601 -90) 1. Формирование требований к АС. Содержание ОсобенностиСтадии создания АС (ГОСТ 34. 601 -90) 1. Формирование требований к АС. Содержание Особенности реализации Мин. перечень сопутствующих документов 1. 1. Обследование объекта и обоснование необходимости создания АС. 1. 2. Формирование требований пользователя к АС. 1. 3. Оформление отчета о выполненной работе и заявки на разработку АС (тактико-технического задания) На данном этапе необходимо как можно полнее описать и разбить на категории те требования, которые предъявляются к автоматизированной экономической информационной системе (АЭИС), так как на их основании будут формироваться концепция и проект АЭИС. Целесообразно также определить приоритеты в реализации требований, что позволит более гибко сформировать проект 1. Документ, отражающий итоги проведенного обследования. 2. Общий перечень требований к АЭИС. 3. Список требований к АЭИС со стороны пользователей

Модели проектирования ПО - СММ/ CMMI CMM ( Capability Maturity Model ) – модельМодели проектирования ПО — СММ/ CMMI CMM ( Capability Maturity Model ) – модель уровня зрелости процесса разработки ПО: эволюционная модель развития способности компании разрабатывать программное обеспечение (ПО) CMMI (Capability Maturity Model Integration) – набор моделей и практик необходимых для полной реализации определенных областей деятельности. Например, в телекоммуникации e. TOM и NGOSS Международная методика и стандарт Возникла в 90–х годах В Университете Карнеги-Меллона, США «Описывает принципы и практические решения, определяющие уровень качества процесса разработки ПО и призвана помочь организациям-производителям усовершенствовать процессы разработки ПО эволюционным путем, превратив их из хаотических процессов в процессы со строгой дисциплиной» ( http: //www. sei. cmu. edu ). Деление на уровни позволяет последовательно внедрять модели, используя стандарты в качестве руководства для совершенствование процесса разработки ПО КИС.

NGOSS СПРАВОЧНАЯ ИНФОРМАЦИЯ NGOSS СПРАВОЧНАЯ ИНФОРМАЦИЯ