Разделы презентаций


Проектирование сложных систем связи

Содержание

ОглавлениеВведение в дисциплину. Термины, определения и описания ландшафта внедрения АСУ в РФ. Ознакомление с особенностями современных методов и средств проектирования корпоративных информационных систем управления предприятием, основанных на использовании CASE-технологий. В разделе

Слайды и текст этой презентации

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

связи.
Москва, 2010 г.

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

Слайд 2Оглавление
Введение в дисциплину. Термины, определения и описания ландшафта внедрения АСУ

в РФ.
Ознакомление с особенностями современных методов и средств проектирования

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

Слайд 3Введение в дисциплину.
Эффективное управление предприятием в современных условиях невозможно без

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

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

Слайд 4Основные термины и определения.
Классификация автоматизированных информационных систем.
Предлагается

использовать следующую классификацию систем и подсистем КИС. В зависимости от

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

Слайд 5Основные термины и определения.
Системы (подсистемы)

класса A - системы (подсистемы) контроля и управления технологическими объектами

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

Слайд 6Основные термины и определения.

Системы класса B - это системы (подсистемы) подготовки и учета

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

Слайд 7Основные термины и определения.
Классическими примерами систем класса 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 (системы управления взаимоотношениями с клиентами);
всевозможные учетные системы и т.п.
Одна из причин возникновения подобных систем - необходимость выделить отдельные задачи управления на уровне технологического подразделения предприятия.
Основные термины и определения.Классическими примерами систем класса B можно считать: MES - Manufacturing Execution Systems (системы управления

Слайд 8Основные термины и определения.
Системы класса C - это системы (подсистемы)

планирования и анализа производственной деятельности предприятия. Системы класса C предназначены

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

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

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

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

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

Слайд 11Краткое описание ландшафта ПО АСУ предприятия.
Современный

рынок финансово-экономического прикладного программного обеспечения.
Сегодняшний рынок

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

Краткое описание ландшафта ПО АСУ предприятия.    Современный рынок финансово-экономического прикладного программного обеспечения.

Слайд 12Видение состояния внедрений АС
Анализ внедрений АС

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

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

Видение состояния внедрений АС    Анализ внедрений АС предприятий, осуществленных на сегодняшний день, выявляет несколько

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

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

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

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

Слайд 15Корпоративная информационная система управления предприятием (КИСУ)

Многослойная

модель программно-технических средств КИСУ:
Комплекс разнородных (по производителям, функциональности) прикладных АС;
Системные

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

Корпоративная информационная система управления предприятием (КИСУ)    Многослойная модель программно-технических средств КИСУ:Комплекс разнородных (по производителям,

Слайд 16Общая классификация АС предприятия.
По масштабам применения
Настольные - для работы одного

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

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

Слайд 17Платформенные (функционально интегрированные) информационные системы
Наиболее востребованные универсальные КИСУ в России

в 2000 - 2010 г.

Российские*
система «1C»
система «Галактика»
система «Парус»
система «Флагман»
система БОСС

«Корпорация»
другие
Зарубежные*
MS «Axapta»
SAP R/3
BaaN IV
Oracle Application
другие.

* Перечисленные АС обеспечивают обработку внешних и внутренних данных предприятия (Enterprise Resource and Relationship Processing, или, другими словами, являются дальнейшим расширением системы ERP - ERPII).
Платформенные (функционально интегрированные) информационные системыНаиболее востребованные универсальные КИСУ в России в 2000 - 2010 г.Российские*система «1C»система «Галактика»система

Слайд 18Интегрированные системы (продолжение). Пример интеграции данных АС «Галактика»
Общая схема

возможных вариантов организации взаимодействия «Галактики» с другими программными системами
Источник:http://atlants.dp.ua/integration.htm
Возможные области

интеграции с др. системами:

Функции, специфичные для отдельных предприятий,
взаимодействие с унаследованными программами,
обеспечение специальных интерфейсов доступа к данным для конкретных специалистов предприятия,
нестандартные (для «тиражной» функциональности системы) способы представления информации

Интегрированные системы (продолжение).   Пример интеграции данных АС «Галактика»Общая схема возможных вариантов организации взаимодействия «Галактики» с

Слайд 19Интеграция. Компоненты интегрированных АС
iBUS, WORKFLOW - системы автоматизации и описания

потока работ на предприятии
GROUPWARE - системы автоматизации и обеспечения выполнения

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

Слайд 20WORKFLOW - системы автоматизации и описания процессов организации
Технология автоматизации потока

работ (workflow) - это технология компьютеризированной поддержки процессов управления предприятием

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

Слайд 21Workflow, BPM – интеграционные платформы автоматизации и описания бизнес процессов

предприятия
Наиболее известны:
Oracle Fusion Middleware, корпорация Oracle
TIBCO Software.
IBM, WebSphere и

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

Слайд 22GROUPWARE - системы автоматизации и обеспечения выполнения работы группы специалистов
Пример

- TMU GroupWare (TMU Consulting Inc., Япония)
Единая информационная среда

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

Слайд 23DocFLOW - системы автоматизации документооборота организации
контроль и учет расходование денежных

средств
регистрация корреспонденции (входящие, исходящие)
электронный архив документов
система согласования договоров


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

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

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

Слайд 24Виртуальное предприятие
Виртуальное предприятие – предприятие, состоящее из сообщества географически разделенных

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

коммуникаций
(словарь http://www.bb2.ru/lexicon/)

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

Слайд 25CALS-технология
Вся информация представлена в электронном виде;
ЕИП охватывает всю информацию,

созданную об изделии;
ЕИП является единственным источником данных об изделии

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

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

CALS-технологияВся информация представлена в электронном виде; ЕИП охватывает всю информацию, созданную об изделии; ЕИП является единственным источником

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

подготовки документации

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

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

обеспечение
Метрологическое обеспечение
Правовое обеспечение

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

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

ПО

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

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

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

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

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

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

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

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

Слайд 32Основы методологии проектирования АС
Жизненный цикл АС

Жизненный цикл (ЖЦ) АС -

это непрерывный процесс, который начинается с момента принятия решения о

необходимости его создания и заканчивается в момент его полного изъятия из эксплуатации.

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

Слайд 33Стадии и этапы создания АС (ГОСТ 34.601-90)
Формирование требований к автоматизированной системе

(АС)
Разработка концепции АС
Техническое задание
Эскизный проект
Технический проект
Рабочая документация
Ввод в действие
Сопровождение АС

Стадии и этапы создания АС (ГОСТ 34.601-90)Формирование требований к автоматизированной системе (АС)Разработка концепции АСТехническое заданиеЭскизный проектТехнический проектРабочая

Слайд 34ЖЦ АС и международный стандарт ISO/IEC 12207
Основной нормативный документ, регламентирующий

ЖЦ АС, = международный стандарт ISO/IEC 12207

( ISO -

International Organization of Standardization - Международная организация по стандартизации, IEC - International Electrotechnical Commission –
Международная комиссия по электротехнике).

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

ЖЦ АС и международный стандарт ISO/IEC 12207Основной нормативный документ, регламентирующий ЖЦ АС, = международный стандарт ISO/IEC 12207

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

12207 )

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

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

12207 )
Основные процессы ЖЦ (приобретение, поставка, разработка, эксплуатация, сопровождение);
Вспомогательные процессы,

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

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

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

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

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

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

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

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

Слайд 40Стадии создания ПО
1. Формирование требований к ПО.
2. Проектирование.
3. Реализация.
4. Тестирование.
5.

Ввод в действие.
6. Эксплуатация и сопровождение.
7. Снятие с эксплуатации.

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

Слайд 41Стадии создания ПО
1. Формирование требований к ПО.
Планирование работ
Обследование деятельности

автоматизируемого объекта (организации)
Построение моделей деятельности организации
2. Проектирование.
3. Закупка или

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

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

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

Слайд 43Стадии выбора или разработки ПО
1. Формирование требований к ПО.
2. Проектирование.
Разработка

системного проекта, результат - Технические требования, Техническое задание
Разработка Технического проекта

(собственно проектирование)
3. Реализация (закупка или разработка).
4. Тестирование.
5. Ввод в действие.
6. Эксплуатация и сопровождение.
7. Завершение эксплуатации.

Стадии выбора или разработки ПО1. Формирование требований к ПО.2. Проектирование.Разработка системного проекта, результат - Технические требования, Техническое

Слайд 44Модель 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)
Помогает предприятию усовершенствовать свои бизнес процессы
Модель CMM/CMMICMM (Capability Maturity Model) – модель зрелости процессов организацииCMMI (CMM Integration) - интеграция CMMСтандарт в области

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

уровня зрелости, характеризуются хаотичностью, реактивностью, непредсказуемостью. Несмотря на это, очень

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

Слайд 46Модели жизненного цикла ПО
Под моделью ЖЦ понимается структура, определяющая последовательность

выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении

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

Модели жизненного цикла ПО Под моделью ЖЦ понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и

Слайд 47Основные модели ЖЦ АС

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

г.г.).

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

Слайд 48Каскадная модель проектирования АС
Характеристики
Переход с одного этапа на следующий происходит

только после того, как будет полностью завершена работа на текущем.


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

Слайд 49Недостатки каскадной модели проектирования АС
Реальный процесс создания ПО никогда полностью

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

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

Слайд 50Спиральная модель ЖЦ проектирования АС
Разработка итерациями отражает объективно существующий

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

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

Слайд 51Фазы и итерации проектирования АС
Итерации являются последовательностью работ в сооветствие

с планом работ при достижении определенного уровня установленного критерия, на

каждой итерации достигается результат в виде работающей версии системы

Итерация

...

Итерация

Итерация

...

Итерация

...

Итерация

...

Начало

Проектирование

Разработка

Переход

Фазы и итерации проектирования АСИтерации являются последовательностью работ в сооветствие с планом работ при достижении определенного уровня

Слайд 52Структура унифицированного процесса проектирования ИС, КИСУ
Управление проектом
Внешняя среда
Бизнес-моделирование
Детализация
Тестирование
Анализ и проектирование
Preliminary

Iteration(s)
Iter. #1
Фазы
Стадии основного процесса
Итерации
Работы поддержки
Iter. #2
Iter. #n
Iter. #n+1
Iter. #n+2
Iter. #m

Iter. #m+1

Размещение

Управление конфигурацией

Установление требований

Проектир

Переход

Начало

Построение

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

Слайд 53Методология RAD (Rapid Application Development).
Rapid Application Development (RAD) –

средства разработки программных продуктов.
Примеры RAD-систем:
Borland Delphi,
Borland C++
MS Visual C++
др.

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

Слайд 54Методология RAD (Rapid Application Development).
Небольшая! команда программистов (от 2

до 10 человек)
Короткий производственный график (от 2 до 6

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

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

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

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

Слайд 56Преимущества RAD технологии
Преимущества модели RAD:
Использование концепции создания средств разработки программных

продуктов - модели RAD при проектировании информационных систем в определенных

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

Слайд 57Содержание этапов RAD технологии
Недостатки модели RAD
В случае ошибочного выбора модели

RAD при реализации проекта могут проявиться следующие недостатки:
низкое качество программного

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

Слайд 58Требования RAD технологии
При использовании данного метода Заказчик

участвует во всех фазах жизненного цикла проекта - определение требований,

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

Требования RAD технологии   При использовании данного метода Заказчик участвует во всех фазах жизненного цикла проекта

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

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

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

Слайд 60CASE-технология обеспечивает структурный подход к проектированию АС
Сущность структурного подхода к

разработке АС заключается в ее декомпозиции (разбиении) на автоматизируемые функции:

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

Слайд 61SADT (Structured Analysis and Design Technique) - методология структурного анализа

и проектирования систем
Под термином "система" понимается совокупность взаимодействующих компонент и

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

Слайд 62История
В начале 70-х годов вооруженные силы США применили подмножество SADT,

касающееся моделирования процессов, для реализации проектов в рамках программы ICAM

(Integrated Computer-Aided Manufacturing).
В дальнейшем это подмножество SADT было принято в качестве федерального стандарта США под наименованием IDEF:

IDEF — методологии семейства ICAM (Integrated Computer-Aided Manufacturing) для решения задач моделирования сложных систем, позволяет отображать и анализировать модели деятельности широкого спектра сложных систем в различных разрезах. При этом широта и глубина обследования процессов в системе определяется самим разработчиком, что позволяет не перегружать создаваемую модель излишними данными.
В настоящий момент к семейству IDEF можно отнести следующие стандарты:
IDEF0 — Function Modeling — методология функционального моделирования. С помощью наглядного графического языка IDEF0 изучаемая система предстает перед разработчиками и аналитиками в виде набора взаимосвязанных функций (функциональных блоков — в терминах IDEF0). Как правило, моделирование средствами IDEF0 является первым этапом изучения любой системы. Методологию IDEF0 можно считать следующим этапом развития хорошо известного графического языка описания функциональных систем SADT (Structured Analysis and Design Technique);
IDEF1 — Information Modeling — методология моделирования информационных потоков внутри системы, позволяющая отображать и анализировать их структуру и взаимосвязи;
IDEF1X (IDEF1 Extended) — Data Modeling — методология построения реляционных структур (баз данных), относится к типу методологий «Сущность-взаимосвязь» (ER — Entity-Relationship) и, как правило, используется для моделирования реляционных баз данных, имеющих отношение к рассматриваемой системе;
IDEF2 — Simulation Model Design — методология динамического моделирования развития систем. В связи с весьма серьезными сложностями анализа динамических систем от этого стандарта практически отказались, и его развитие приостановилось на самом начальном этапе. В настоящее время присутствуют алгоритмы и их компьютерные реализации, позволяющие превращать набор статических диаграмм IDEF0 в динамические модели, построенные на базе «раскрашенных сетей Петри» (CPN — Color Petri Nets);
IDEF3 — Process Description Capture — документирование процессов,
IDEF3 — методология документирования процессов, происходящих в системе (например, на предприятии), описываются сценарий и последовательность операций для каждого процесса. IDEF3 имеет прямую взаимосвязь с методологией IDEF0 — каждая функция (функциональный блок) может быть представлена в виде отдельного процесса средствами IDEF3;
IDEF4 — Object-Oriented Design — методология построения объектно-ориентированных систем, позволяют отображать структуру объектов и заложенные принципы их взаимодействия, тем самым позволяя анализировать и оптимизировать сложные объектно-ориентированные системы;
IDEF5 — Ontology Description Capture — Стандарт онтологического исследования сложных систем. С помощью методологии IDEF5 онтология системы может быть описана при помощи определенного словаря терминов и правил, на основании которых могут быть сформированы достоверные утверждения о состоянии рассматриваемой системы в некоторый момент времени. На основе этих утверждений формируются выводы о дальнейшем развитии системы и производится её оптимизация;
IDEF6 — Design Rationale Capture — Обоснование проектных действий. Назначение IDEF6 состоит в облегчении получения «знаний о способе» моделирования, их представления и использования при разработке систем управления предприятиями. Под «знаниями о способе» понимаются причины, обстоятельства, скрытые мотивы, которые обуславливают выбранные методы моделирования. Проще говоря, «знания о способе» интерпретируются как ответ на вопрос: «почему модель получилась такой, какой получилась?» Большинство методов моделирования фокусируются на собственно получаемых моделях, а не на процессе их создания. Метод IDEF6 акцентирует внимание именно на процессе создания модели;


Подробные спецификации на стандарты IDEF можно найти на сайте http://www.idef.com
ИсторияВ начале 70-х годов вооруженные силы США применили подмножество SADT, касающееся моделирования процессов, для реализации проектов в

Слайд 63История. Продолжение.

IDEF7 — Information System Auditing — Аудит информационных систем.

Этот метод определён как востребованный, однако так и не был

полностью разработан;
IDEF8 — User Interface Modeling — Метод разработки интерфейсов взаимодействия оператора и системы (пользовательских интерфейсов). Современные среды разработки пользовательских интерфейсов в большей степени создают внешний вид интерфейса. IDFE8 фокусирует внимание разработчиков интерфейса на программировании желаемого взаимного поведения интерфейса и пользователя на трех уровнях: выполняемой операции (что это за операция); сценарии взаимодействия, определяемом специфической ролью пользователя (по какому сценарию она должна выполняться тем или иным пользователем); и, наконец, на деталях интерфейса (какие элементы управления, предлагает интерфейс для выполнения операции);
IDEF9 — Scenario-Driven IS Design (Business Constraint Discovery method) — Метод исследования бизнес ограничений был разработан для облегчения обнаружения и анализа ограничений в условиях которых действует предприятие. Обычно, при построении моделей описанию ограничений, оказывающих влияние на протекание процессов на предприятии уделяется недостаточное внимание. Знания об основных ограничениях и характере их влияния, закладываемые в модели, в лучшем случае остаются неполными, несогласованными, распределенными нерационально, но часто их вовсе нет. Это не обязательно приводит к тому, что построенные модели нежизнеспособны, просто их реализация столкнется с непредвиденными трудностями, в результате чего их потенциал будет не реализован. Тем не менее в случаях, когда речь идет именно о совершенствовании структур или адаптации к предсказываемым изменениям, знания о существующих ограничениях имеют критическое значение;
IDEF10 — Implementation Architecture Modeling — Моделирование архитектуры выполнения. Этот метод определён как востребованный, однако так и не был полностью разработан;
IDEF11 — Information Artifact Modeling. Этот метод определён как востребованный, однако так и не был полностью разработан;
IDEF12 — Organization Modeling — Организационное моделирование. Этот метод определён как востребованный, однако так и не был полностью разработан;
IDEF13 — Three Schema Mapping Design — Трёхсхемное проектирование преобразования данных. Этот метод определён как востребованный, однако так и не был полностью разработан;
IDEF14 — Network Design — Метод проектирования компьютерных сетей, основанный на анализе требований, специфических сетевых компонентов, существующих конфигураций сетей. Также он обеспечивает поддержку решений, связанных с рациональным управлением материальными ресурсами, что позволяет достичь существенной экономии.

Подробные спецификации на стандарты IDEF можно найти на сайте http://www.idef.com

История. Продолжение.IDEF7 — Information System Auditing — Аудит информационных систем. Этот метод определён как востребованный, однако так

Слайд 64Применение IDEF для создания сложных ИС
На начальных этапах создания ИС необходимо

понять, как работает организация, которую собираются автоматизировать
Для описания работы

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

Слайд 65Модель системы в IDEF
IDEF-модель дает полное, точное и адекватное описание

системы, имеющее конкретное назначение. Это назначение, называемое целью модели, вытекает

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

Модель системы в IDEFIDEF-модель дает полное, точное и адекватное описание системы, имеющее конкретное назначение. Это назначение, называемое

Слайд 66Принципы создания моделей
Целью модели является получение ответов на некоторую совокупность

вопросов. Эти вопросы присутствуют (подразумеваются) в процессе анализа.
После завершения

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

Слайд 67Принципы создания моделей (резюме)
Методология IDEF создана специально для представления сложных

систем путем построения моделей.
IDEF-модель - это описание системы, у

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

Слайд 68Моделирование бизнес процессов лежит в основе проектирования информационной системы
Этапы проектирования

АС
Обследование деятельности предприятия
Разработка системного проекта
Разработка предложений по автоматизации предприятия
Разработка технического

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

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

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

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

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

Слайд 70Разработка системного проекта

Системный проект (модель требований к будущей системе) строится

на основе модели "как будет" и включает:
полную функциональную модель

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

Слайд 71Функциональное моделирования
Функциональное моделирование – процесс создания функциональной модели
Цель моделирования

- ускорение и удешевление разработки АС и/или совершенствования функционирования (реинжиниринга)

систем
Функциональная модель предназначена для описания существующих бизнес-процессов на предприятии (модель «как есть») и идеальных, к которым нужно стремиться (модели «как будет»)

Функциональное моделированияФункциональное моделирование – процесс создания функциональной модели Цель моделирования - ускорение и удешевление разработки АС и/или

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

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

Слайд 73Принципы моделирования
В IDEF0 моделируемая СИСТЕМА представляется как СОВОКУПНОСТЬ взаимодействующих РАБОТ

или ФУНКЦИЙ.
Такая чисто функциональная ориентация является принципиальной - функции

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

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

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

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

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

Слайд 75Субъект моделирования
Под субъектом моделирования понимается сама система, при этом

необходимо точно установить, что входит в систему, а что лежит

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

Слайд 76Граница – Вход – Выход – Управление - Механизм
Система имеет

ГРАНИЦУ, которая отделяет ее от «внешней среды».
Взаимодействие системы с

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

Слайд 77Типы стрелок в IDEF0
Вход (input)
Управление (Control)
Выход (Output)
Механизм

(Mechanism)
Вызов (Call)

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

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

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

Слайд 79Цель моделирования (Purpose).
Модель не может быть построена без четко сформулированной

цели.
Цель должна отвечать на следующие вопросы:
Почему этот

процесс должен быть замоделирован?
Что должна показывать модель?
Что может получить пользователь модели?

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

Слайд 80Формулировка цели позволяет команде аналитиков сфокусировать усилия в нужном направлении.



Примерами формулирования цели могут быть следующие утверждения:
"Идентифицировать и определить

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

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

Слайд 81Широта и глубина модели
При формулировании области необходимо учитывать - широту

и глубину моделирования системы в рамках решения задачи.
Широта подразумевает

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

Слайд 82Контекст моделирования
Процесс моделирования какой-либо системы в IDEF0 начинается с определения

КОНТЕКСТА, т. е. наиболее абстрактного уровня описания системы в целом.


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

Слайд 83
Основу методологии IDEF0 составляет графический язык описания бизнес-процессов.

Модель в

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

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

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

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

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

должна строиться с единой точки зрения.
Точку зрения можно представить

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

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

Слайд 85BPwin: диаграммы FEO ( For Exposition Only)
Часто при выборе

точки зрения на результирующую модель важно задокументировать дополнительные альтернативные точки

зрения. Для этой цели обычно используется методология IDEF0, диаграммы BPwin - FEO (For Exposition Only).

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

Слайд 86Статус модели
В параметрах модели можно описать статус модели (черновой вариант,

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

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

Слайд 87Источники информации
Параметр - Source описываются источники информации для построения

модели (например, "Опрос экспертов предметной области и анализ документации").

Источники информации Параметр - Source описываются источники информации для построения модели (например,

Слайд 88 Процесс проектирования АС с помощью продуктов линейки AllFusion Modeling

Suite
Инструменты:
ACM – AllFusion Component Modeler;
ARIS – IDS Scheer;
Rational Rose –

IBM;
BPwin – Computer Associates.

Методологии:
IDEF0 – функциональное
моделирование
IDEF3 – моделирование
потока работ
DFD – моделирование
потоков данных
UML – обобщенный язык моделирования объектов

Процесс проектирования АС с помощью продуктов линейки AllFusion Modeling SuiteИнструменты:ACM – AllFusion Component Modeler;ARIS – IDS

Слайд 89Process Modeler (BPwin) – инструмент системного анализа
Система BPwin поможет повысить

конкурентоспособность, оптимизировать процессы управления. Результатом использования BPwin является исключение лишних

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

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

Process Modeler (BPwin) – инструмент системного анализаСистема BPwin поможет повысить конкурентоспособность, оптимизировать процессы управления. Результатом использования BPwin

Слайд 90Основные характеристики BPwin
Развитая методология функционального моделирования на основе IDEF0
Мощные

редакторы для описания операций, связей и вычисления затрат на выполнение

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

Слайд 91Основные достоинства BPwin
BPwin помогает быстро создавать и анализировать модели с

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

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

Слайд 92Создание модели в BPWin
задание имени модели
выбор методологии описания

модели IDEF0, IDEF3 или DFD.

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

Слайд 93Диалог Model Properties, назначение и точка зрения модели
В закладке Purpose

следует внести цель (Purpose) и точку зрения (ViewPoint)


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

Слайд 94Диалог Model Properties, определение и границы модели
В закладке Definition следует

внести определение (Definition ) и границы (Scope) модели

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

Слайд 95Диалог Model Properties, источники информации модели
В закладке Source описываются источники

информации. Для построения модели (например, "Опрос экспертов предметной области и

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

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

диаграммы в модели

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

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

диаграммы в модели в модели

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

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

и подгонки размеров элементов диаграммы в модели в модели

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

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

функций и элементов диаграммы модели

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

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

размера диаграммы модели

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

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

листов диаграммы модели

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

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

модели

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

Слайд 103Диаграммы IDEF0
 контекстная диаграмма (в каждой модели может быть только

одна контекстная диаграмма);
диаграмма декомпозиции;
диаграмма дерева узлов;
диаграмма только

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

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

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

Слайд 105Контекстная диаграмма
Контекстная диаграмма является вершиной древовидной структуры диаграмм и

представляет собой самое общее описание системы и ее взаимодействия с

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

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

не взаимосвязи между работами.
Диаграмм деревьев узлов может быть в

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

Слайд 107Работы (Activity)
Работы обозначают поименованные процессы, функции или задачи,

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

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

Слайд 108Диаграммы декомпозиции
Диаграммы декомпозиции содержат родственные работы, т.е. дочерние работы,

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

по кнопке.

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

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

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

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

Слайд 110Нумерация работ и диаграмм
Все работы модели нумеруются. Номер состоит

из префикса и числа. Может быть использован префикс любой длины,

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

Слайд 111Стрелки (Arrow)
Взаимодействие работ с внешним миром и между собой

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

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

Слайд 112Словарь стрелок (Arrow Dictionary).
Словарь стрелок редактируется при помощи специального

редактора Arrow Dictionary Editor, в котором определяется стрелка и вносится

относящийся к ней комментарий.

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

Словарь стрелок (Arrow Dictionary). Словарь стрелок редактируется при помощи специального редактора Arrow Dictionary Editor, в котором определяется

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

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

Слайд 114Вход (input)
Вход (input) - материал или информация, которые используются

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

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

Слайд 115Управление (Control)
Управление (Control)- правила, стратегии, процедуры или стандарты, которыми

руководствуется работа. "Каждая работа должна иметь хотя бы одну стрелку

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

Слайд 116Выход (Output)
Выход (Output) - материал или информация, которые производятся

работой. Каждая работа должна иметь хотя бы одну стрелку выхода.

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

Слайд 117Механизм (Mechanism)
Механизм (Mechanism)- ресурсы, которые выполняют работу, например персонал

предприятия, станки, устройства и т. д. Стрелка механизма рисуется как

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

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

Слайд 118Вызов (Call)
Вызов (Call) - специальная стрелка, указывающая на другую

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

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

Слайд 119Граничные стрелки
Граничные стрелки. Стрелки на контекстной диаграмме служат для

описания взаимодействия системы с окружающим миром. Они могут начинаться у

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

Граничные стрелки Граничные стрелки. Стрелки на контекстной диаграмме служат для описания взаимодействия системы с окружающим миром. Они

Слайд 120Несвязанные граничные стрелки
Несвязанные граничные стрелки (unconnected border arrow). При

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

(кроме стрелки вызова) автоматически появляются на диаграмме декомпозиции (миграция стрелок), но при этом не касаются работ.

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

Несвязанные граничные стрелки Несвязанные граничные стрелки (unconnected border arrow). При декомпозиции работы входящие в нее и исходящие

Слайд 121Внутренние стрелки.
Внутренние стрелки. Для связи работ между собой используются

внутренние стрелки, т.е. стрелки, которые не касаются границы диаграммы, начинаются

у одной и кончаются у другой работы.

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

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

Слайд 122Связь по входу (output-input)
Связь по входу (output-input), когда стрелка

выхода вышестоящей работы (далее - просто выход) направляется на вход

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

Слайд 123Связь по управлению (output-control)
Связь по управлению (output-control), когда выход

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

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

Слайд 124Обратная связь по входу (output-input feedback)
Обратная связь по входу

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

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

Слайд 125Связь выход-механизм (output-mechanism)
Связь выход-механизм (output-mechanism), когда выход одной работы

направляется на механизм другой. Эта взаимосвязь используется реже остальных и

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

Слайд 126Разветвляющиеся и сливающиеся стрелки
Разветвляющиеся и сливающиеся стрелки. Одни и

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

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

Разветвляющиеся и сливающиеся стрелки Разветвляющиеся и сливающиеся стрелки. Одни и те же данные или объекты, порожденные одной

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

ветви стрелок

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

Слайд 128Именование стрелок
Если стрелка именована до разветвления, а после разветвления

ни одна из ветвей не именована, то подразумевается, что каждая

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

Слайд 129Именование стрелок
Если стрелка именована до разветвления, а после разветвления

какая-либо из ветвей не именована, то подразумевается, что эти ветви

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

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

а после разветвления не именована какая-либо из ветвей
.

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

Слайд 131Тоннелирование стрелок
Тоннелирование стрелок. Вновь внесенные граничные стрелки на диаграмме

декомпозиции нижнего уровня изображаются в квадратных скобках и автоматически не

появляются на диаграмме верхнего уровня «Неразрешенная (unresolved) стрелка»

.

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

Слайд 132Ликвидация неразрешенных стрелок
Для их "перетаскивания" наверх нужно сначала выбрать кнопку

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

диалог Border Arrow Editor

.

Если щелкнуть по кнопке Resolve Border Arrow, стрелка мигрирует на диаграмму верхнего уровня, если по кнопке Change To Tunnel - стрелка будет затоннелирована и не попадет на другую диаграмму. Тоннельная стрелка изображается с круглыми скобками на конце .

Ликвидация неразрешенных стрелокДля их

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

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

Слайд 134Пример DFD-диаграммы

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

Слайд 135Диаграммы потоков данных - DFD
DFD - Data flow diagramming
используются для

описания документооборота и обработки информации.
Подобно IDEF0, DFD представляет модельную

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

Слайд 136Стрелки в DFD диаграмме
В отличие от стрелок IDEF0, которые представляют

собой жесткие взаимосвязи, стрелки DFD показывают, как объекты (включая данные)

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

Стрелки в DFD диаграммеВ отличие от стрелок IDEF0, которые представляют собой жесткие взаимосвязи, стрелки DFD показывают, как

Слайд 137Хранилище данных (Data store )
- добавить в диаграмму хранилище данных

(Data store).
Хранилище данных позволяет описать данные, которые необходимо сохранить

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

Слайд 138Внешняя ссылка (External Reference).
- добавить в диаграмму внешнюю ссылку (External

Reference).
-Внешняя ссылка является источником или приемником данных извне модели
Внешние

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

Слайд 139Функция (Работа)
В отличие от IDEF0, где система рассматривается как взаимосвязанные

работы. DFD рассматривает систему как совокупность предметов.
В DFD работы

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

Слайд 140Нумерация объектов
Нумерация объектов. В DFD номер каждой работы может

включать префикс, номер родительской работы (А) и номер объекта.
Номер

объекта - это уникальный номер работы на диаграмме. Например, работа может иметь номер А.12.4. Уникальный номер имеют хранилища данных и внешние сущности независимо от их расположения на диаграмме.
Каждое хранилище данных имеет префикс D и уникальный номер, например D5. Каждая внешняя сущность имеет префикс Е и уникальный номер, например Е5.

Нумерация объектов Нумерация объектов. В DFD номер каждой работы может включать префикс, номер родительской работы (А) и

Слайд 142Пример IDEF3-диаграммы

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

Слайд 143Метод описания процессов IDEF3 (Workflow diagramm)
Для описания логики взаимодействия

информационных потоков используется IDEF3, называемая также workflow diagramming - методология

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

Слайд 144Цель IDEF3
IDEF3 - это метод, имеющий основной целью дать возможность

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

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

Слайд 145Метод описания процессов IDEF3 (Workflow diagramm)
Диаграммы Workflow могут быть

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

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

Слайд 146Работы в IDEF3
Каждая работа в IDEF3 описывает какой-либо сценарий

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

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

Слайд 147Единицы работы - Unit of Work (UOW).
UOW, также называемые

работами (activity), являются центральными компонентами модели
В IDEF3 работы изображаются прямоугольниками

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

Слайд 148Связи в IDEF3
Связи. Связи показывают взаимоотношения работ. Все связи в

IDEF3 однонаправлены и могут быть направлены куда угодно, но обычно

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

Слайд 149Связь старшая (Precedence)
Сплошная линия, связывающая единицы работ (UOW),
Рисуется слева

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

чем работа-цель начнется.

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

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

между единицами работ (UOW) а также между единицами работ и

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

Слайд 151Связь Потоки объектов (Object Flow)
Стрелка с двумя наконечниками, применяется

для описания того факта, что объект используется в двух или

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

Слайд 152Перекрестки (Junction) и разветвления (Fan-out Junction) стрелок
Перекрестки используются для отображения

логики взаимодействия стрелок при слиянии и разветвлении или для отображения

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

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

следующие процессы должны быть запущены

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

Слайд 154Перекресток асинхронное и (AND )
Асинхронное «И» : после завершения работы

№10 запускаются работы №11 №12
Для запуска работы №14 требуется

завершение работы №11 и №13

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

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

процессы запускаются одновременно

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

Слайд 156Перекресток синхронное и (AND )
Синхронное «И» : после завершения работы

№5 одновременно запускаются работы №6 №8
Для запуска работы №9 требуется

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

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

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

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

Слайд 158Перекресток асинхронное или (or )
Асинхронное «Или» : после завершения работы

№15 запускается или работа №16 или №17 или 18 или

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

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

одновременно
Один или несколько следующих процессов запускаются одновременно

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

Слайд 160Перекресток синхронное или (or )
Синхронное «Или» : после завершения работы

№20 запускаются работа №21 или №22 или 23 или их

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

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

следующий процесс запускается

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

Слайд 162Перекресток исключающее ИЛИ
После завершения Работы 1 запускается только одна работа

- Работа 2 или Работа 4
Для запуска работы 5 требуется

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

Слайд 163Правила создания перекрестков
Всё перекрестки на диаграмме нумеруются, каждый номер имеет

префикс J.
Можно редактировать свойства перекрестка при помощи диалога Definition

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

Слайд 164Правила создания перекрестков
Каждому перекрестку для слияния должен предшествовать перекресток для

разветвления.
Перекресток для слияния «И» не может следовать за перекрестком

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

Слайд 165Объект ссылки.
Объект ссылки в IDEF3 выражает некую идею, концепцию

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


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

Слайд 166Декомпозиция работ.
В IDEF3 декомпозиция используется для детализации работ. Методология

IDEF3 позволяет декомпозировать работу многократно, т.е. работа может иметь множество

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

Слайд 167Задание: «Прочитать» IDEF3-диаграмму

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

Слайд 168Задание: «Прочитать» IDEF3-диаграмму

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

Слайд 169Задание: «Прочитать» IDEF3-диаграмму

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

Слайд 170Задание: «Прочитать» IDEF3-диаграмму

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

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

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

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

Слайд 172Словарь Role Group Dictionary
Словарь Role Group Dictionary (меню Dictionary/Role

Group) позволяет создать и определить свойства групп ролей. Группы ролей

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

Слайд 173Словарь ролей
Словарь ролей. Ролью может быть должность или позиция конкретного

исполнителя. Каждой роли может соответствовать одна или несколько групп ролей.

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

Слайд 174Словарь ресурсов
Словарь ресурсов (меню Dictionary/Resource) позволяет создать ресурс и

связать его с комбинацией "группа ролей/роль" Ресурсом для роли может

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

Слайд 175Диаграмма распределения ролей Swim Lane
Созданные в словаре Role Dictionary роли

могут быть также использованы в диаграмме Swim Lane. Диаграмма Swim

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

Слайд 176Модель IDEF0
Основным рабочим элементом при моделировании является диаграмма. Модель IDEF0

объединяет и организует диаграммы в иерархические древовидные структуры, при этом,

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

Модель IDEF0Основным рабочим элементом при моделировании является диаграмма. Модель IDEF0 объединяет и организует диаграммы в иерархические древовидные

Слайд 177Стадии создания АС (ГОСТ 34.601-90) 1. Формирование требований к АС.

Стадии создания АС (ГОСТ 34.601-90) 1. Формирование требований к АС.

Слайд 178Модели проектирования ПО - СММ/CMMI
CMM (Capability Maturity Model) – модель

уровня зрелости процесса разработки ПО: эволюционная модель развития способности компании

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

Слайд 180NGOSS
СПРАВОЧНАЯ ИНФОРМАЦИЯ

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

Обратная связь

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

Email: Нажмите что бы посмотреть 

Что такое TheSlide.ru?

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


Для правообладателей

Яндекс.Метрика