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

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

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

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

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

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

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

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

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

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

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

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

MES - Manufacturing Execution Systems (системы управления производством);
MRP -

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

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

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

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

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

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

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

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

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

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

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

в 2000 - 2010 г.

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

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

* Перечисленные АС обеспечивают обработку внешних и внутренних данных предприятия (Enterprise Resource and Relationship Processing, или, другими словами, являются дальнейшим расширением системы ERP - ERPII).

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

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

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

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

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

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

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

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

др.

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

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

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

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

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

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

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

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

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

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

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

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

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

ПО

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

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

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

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

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

( ISO -

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

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

12207 )

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

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

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

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

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

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

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

(CMM Integration) - интеграция CMM
Стандарт в области менеджмента качества
Цель разработки

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

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

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

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

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

г.г.).

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

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

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

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

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

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

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

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

Итерация

...

Итерация

Итерация

...

Итерация

...

Итерация

...

Начало

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

Разработка

Переход

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

Iter. #m+1

Размещение

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

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

Проектир

Переход

Начало

Построение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

взаимосвязей между ними.
Описание системы с помощью SADT называется моделью.
Под термином "моделирование" понимается процесс создания точного описания системы.
В SADT-моделях используются как естественный, так и графический языки. Для передачи информации о конкретной системе источником естественного языка служат люди, описывающие систему, а источником графического языка - сама методология 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

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

полностью разработан;
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

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

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

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

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

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

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

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

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

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

проекта

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(Mechanism)
Вызов (Call)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

См. www.idef.com

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

в дальнейшем автоматически по системной дате).

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

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

IBM;
BPwin – Computer Associates.

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

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

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

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

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

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

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

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

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

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

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

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

анализ документации").

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

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

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

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

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

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

модели

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

для экспозиции (FEO).

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

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

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

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

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

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

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

по кнопке.

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

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

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

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

именуются существительными, например, "Заготовка", "Изделие", "Заказ".

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

нижестоящей

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

доминирование вышестоящей работы. Данные или объекты выхода вышестоящей работы не меняются в нижестоящей.

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

Такая связь, как правило, используется для описания циклов.

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

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

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

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

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

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

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

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

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

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

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

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

.

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

диалог Border Arrow Editor

.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

объектами ссылок

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

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

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

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

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

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

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

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

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

одновременное завершение работы №8 и №7

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

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

их сочетание причем не одновременно
Для запуска работы №19 требуется завершение любой из работ №16,№17,№18.

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

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

сочетание , требуется их одновременный запуск ,
Для запуска работы №24 требуется завершение любой из работ №16,№17,№18. Если завершается более 1 работы, то требуется их одновременное завершение

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

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

завершение только одной из работ, 3 или 4

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

Editor.
В отличие от IDEF0 и DFD в IDEF3 стрелки могут сливаться и разветвляться только через перекрестки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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