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

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

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

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

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

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

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

Основные термины и определения. Классическими примерами систем класса 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 (автоматизированные системы управления данными); § CRM Customer Relationship Management (системы управления взаимоотношениями с клиентами); § всевозможные учетные системы и т. п. Одна из причин возникновения подобных систем необходимость выделить отдельные задачи управления на уровне технологического подразделения предприятия.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ЖЦ АС и международный стандарт 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 12207: 1995) § § § Приобретение Поставка Разработка Эксплуатация Сопровождение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SADT (Structured Analysis and Design Technique) - методология структурного анализа и проектирования систем 1. Под термином "система" понимается совокупность взаимодействующих компонент и взаимосвязей между ними. 2. Описание системы с помощью SADT называется моделью. 3. Под термином "моделирование" понимается процесс создания точного описания системы. 4. В SADT моделях используются как естественный, так и графический языки. Для передачи информации о конкретной системе источником естественного языка служат люди, описывающие систему, а источником графического языка сама методология 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 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 модель дает полное, точное и адекватное описание системы, имеющее конкретное назначение. Это назначение, называемое целью модели, вытекает из формального определения модели : М есть модель системы S, если М может быть использована для получения ответов на вопросы относительно S с точностью А

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

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

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

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

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

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

Функциональное моделирования

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

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

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

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

Типы стрелок в IDEF 0 Output Input Control Mechanism § Вход (input) § Управление (Control) § Выход (Output) § Механизм (Mechanism) § Вызов (Call)

Вход – Выход – Управление Механизм

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

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

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

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

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

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

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

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

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

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

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

Основные характеристики 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 § задание имени модели § выбор методологии описания модели IDEF 0, IDEF 3 или DFD.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Словарь стрелок (Arrow Dictionary). n § Словарь стрелок редактируется при помощи специального редактора 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

IDEF 3

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Диаграмма распределения ролей 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 представлена совокупностью иерархически упорядоченных и логически связанных диаграмм. Каждая диаграмма располагается на отдельном листе. Основные типы диаграмм: § контекстная диаграмма А 0 (в каждой модели может быть только одна контекстная диаграмма); § диаграммы декомпозиции (в том числе диаграмма первого уровня декомпозиции А 0, раскрывающая контекстную). § В состав диаграммы входят функциональные блоки, изображающие активности (функции) моделируемой системы, и стрелки, связывающие блоки вместе и изображающие взаимодействия и взаимосвязи между блоками.

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

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

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