Рекомендация: Положениенормативного документа, содержащее совет

основная часть (нормативного документа): Совокупность положений, составляющих содержание нормативного документа.

срок действия (нормативного документа): Интервал времени, в течение которого действует нормативный документ, начиная от даты введения его в действие в соответствии с решением ответственного за это органа до момента его замены, отмены или прекращения его применения в одностороннем порядке.

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

пользователь стандарта: Юридическое или физическое лицо, применяющее стандарт в своей деятельности.

Лекция № 8. Лекция № 8. Общие сведения о функциональной стандартизации. Примеры функциональных профилей

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

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

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

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

 интероперабельность - обеспечивается способность к взаимодействию данной ИС с другими ИС;

 дружественность к пользователю.

Новым направление в стандартизации ИТ является использование «функциональной стандартизации».

 "функциональная стандартизация" охватывает:

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

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

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

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

 компоненты служб и сервисов, предоставляемых средой для функционирования приложений, такие, например, как оконные оболочки, утилиты, системы программирования и системы управления базами данных (OSE - Open System Environment);

 компоненты операционных систем (операционной среды) (OS - Operating System);

 аппаратура - функциональные блоки и модули средств вычислительной техники и передачи данных (HW - Hardware).
Функциональные группы в данной модели составляют компоненты:

 обслуживающие интерфейс с пользователем (User);

 обеспечивающие системные функции среды - организацию процессов обработки данных (System);

 обеспечивающие представление и хранение данных (Information);

 среды телекоммуникаций (Communication).

Методология "функциональной стандартизации" включает в себя пять основных этапов.
Этап 1. Разработка базовых стандартов. Базовые стандарты образуют массив, который может быть использован для выполнения широкого круга функций.
Этап 2. Разработка функциональных стандартов. Основу функциональных стандартов образуют профили, представляющие собой подмножества базовых стандартов, ориентированных на работу в конкретных конфигурациях реальных объектов и конкретных применениях. Функциональные стандарты (ФС) представляют собой нормативные документы по стандартизации, каждый из которых содержит определение одного или нескольких профилей. Таким образом, обобщенно можно определить, что ФС является "справочником-путеводителем" по применимости базовых стандартов к конкретным приложениям и реальным системам.
Одной из наиболее важных функций ФС является создание основы для построения комплектов аттестационных тестов, предназначенных для определения соответствия систем реальным стандартам.
Этап 3. Формализованное описание протоколов, их тестирование. Данный этап связан с необходимостью тестирования (верификации) стандартов ввиду их сложности и возможности неоднозначной интерпретации. Результатом этого этапа является обратная связь с первым этапом для коррекции базовых стандартов.
Этап 4. Реализация - это применение стандартов в конкретных технических и технологических решениях.
Этап 5. Проверка реализации на соответствие стандартам. Этот этап включает в себя аттестационное тестирование, являющееся проверкой конкретных реализаций, позволяющее оценить правильность реализации требований стандартов.

Таким образом, придание конкретной ИС перечисленных свойств открытых систем реализуется с помощью разработки ее профиля. В соответствии с этим открытые системы определяются IEEE как системы, в которых реализован «исчерпывающий и согласованный набор базовых международных стандартов информационных технологий и профилей функциональных стандартов, которые специфицируют интерфейсы, службы и поддерживающие форматы [данных], чтобы обеспечить интероперабельность и мобильность приложений, данных и персонала».

. Вопрос о том, какие программные средства следует использовать для интеграции приложений в ИС, является центральным при проектировании таких систем. По оценке аналитиков GartnerGroup, за счет рационального использования средств интеграции можно сократить расходы предприятия на создание и эксплуатацию прикладного программного обеспечения уровня предприятия примерно на одну треть. Исследования GartnerGroup показали также, что предприятия тратят около 35-40% своего бюджета, отводимого на поддержку информационных технологий, на работы по организации обмена данными между приложениями и СУБД. Столь высокий процент этой доли затрат объясняется несовместимостью форматов данных между унаследованными приложениями и стандартами применяемых СУБД.

Под средствами интеграции приложений уровня предприятия (Enterprise Application Integration — EAI) понимается комбинация процессов, программных средств, стандартов и аппаратуры, благодаря которой обеспечивается «бесшовная» интеграция приложений в пределах одной или нескольких ИС уровня предприятия, позволяющая им функционировать как единой системе. Хотя средства EAI, как правило, рассматриваются применительно к построению ИС для одного предприятия, в настоящее время они требуются и для интеграции ИС, принадлежащих нескольким предприятиям. Например, они нужны при создании систем класса business-to-business, когда необходимо обеспечить единые бизнес-транзакции, реализуемые цепочками приложений, которые выполняются в нескольких системах.

Примерами функциональных профилей служат ЕСКД, ЕСПД, ЕСТД

Лекция №9. Стандартизация анализа бизнес процессов. Метрологическое обеспечение АСУ

В настоящий момент к семейству 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 акцентирует внимание именно на процессе создания модели;

• 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 — Метод проектирования компьютерных сетей, основанный на анализе требований, специфических сетевых компонентов, существующих конфигураций сетей. Также он обеспечивает поддержку решений,

Лекция № 10 Стандарты IDEF0, IDEF3, IDEF5

На их базе в РФ выпущен нормативный документ Р50. 1.028-2001, Процесс построения модели IDEFO (SADT) включает следующие этапы.

1. Определение целей построения модели. Для этого формируется набор вопросов, на которые должна ответить модель.

2. Определение границ моделирования. Обосновывается ширина охвата и глубина детализации предметной области (степень детальности ответов на поставленные вопросы).

3. Указание “целевой аудитории ”, для потребностей которой создаётся модель. Какие сведения об объекте уже известны, какие дополнительные материалы и документация, какие языки и стиль изложения являются наиболее подходящими. Формируется точка зрения, с которой наблюдалась система при построении модели. Однажды выбранная точка зрения остаётся неизменной для всех элементов модели (клиент, поставщик, владелец и т.д.).

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

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

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

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

Любая диаграмма может быть декомпозирована на составляющие её блоки (5-6 блоков). Каждая диаграмма (блок) имеет “вход” (левая сторона); “выход” (правая сторона); ”управление ” (верхняя сторона); ”исполняющий механизм ” (нижняя сторона).

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

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

В IDEF существует 5 основных видов комбинированных стрелок (связей): выход-вход; выход-управление; выход-механизм исполнения; выход-обратная связь на вход. Подробное назначение стрелок рассматривается в лекционном курсе и в [1].

Все функциональные диаграммы (блоки) нумеруются. Контекстный блок всегда имеет номер А0. Блок А0 декомпозируется в блоки А1, А2, и А3 и т.д. При декомпозиции блока полезно рассматривать его жизненный цикл. Блоки “ дети” – это одни и те же объекты, что и их родители только показанные с большей детализацией.

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

- число уравнений декомпозиции не должно превышать установленной ранее глубины детализации модели;

- моделирование должно продолжаться до тех пор, пока стрелки предшествования (вход-выход) преобладают на диаграммах. Указанные рекомендации в [1] раскрываются следующими определениями:

1. Деятельность (синонимы: дело, бизнес) — совокупность процессов, выполняемых (протекаю­щих) последовательно или/и параллельно, преобразующих множество материальных или/и инфор­мационных потоков во множество материальных или/и информационных потоков с другими свойствами. Деятельность осуществляется в соответствии с заранее определенной и постоянно корректируемой целью, с потреблением финансовых, энергетических, трудовых и материальных ресурсов, при выполнении ограничений со стороны внешней среды. В модели IDEF0 деятельность описывается блоком АО на основной контекстной диа­грамме А—0. При моделировании крупных, многопрофильных структур (фирм, организаций, предприятий), которые по своему статусу занимаются различными видами деятельности, последние представляют собой различные экземпляры класса «деятельность» и могут найти отражение в дополнительной контекстной диаграмме А—1. В этом случае общая модель сложной структуры будет состоять из ряда частных моделей, каждая из которых относится к конкретному виду деятельности.

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

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

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

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

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

Управление деятельностью — процесс, состоящий как минимум из следующих операций:

- формулирование целей деятельности;

- оценивание ресурсов, необходимых для осуществления деятельности, и их сопоставление с имеющимися ресурсами;

- сбор информации об условиях протекания и фактическом состоянии деятельности («гло­бальная» обратная связь);

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

- оформление решений в виде директив на управление процессами;

- реализация решений (исполнение директив) и оценка их результатов («локальная обратная связь»);

- корректировка (в случае необходимости, например при нехватке ресурсов) ранее сформули­рованных целей (самонастройка, адаптация).

Управление процессом — операция, состоящая как минимум из следующих действий:

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

- сбор (прием по каналам связи) информации о ходе выполнения операций, ее обобщение и формирование сведений о состоянии процесса;

- передача данных в подсистему управления деятель­ностью;

- сопоставление информации о ходе операций с данными директив и выработка локальных решений, направленных на устранение отклонений;

- корректировка (в случае необходимости) директив на выполнение операций.

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

Блоки управления должны присутствовать на каждой IDEFO-диаграмме (кроме тех, которые являются декомпозициями самих таких блоков). Через них осуществляются управляющие воздей­ствия на остальные блоки диаграммы. Именно эти блоки воспринимают ограничивающую и предписывающую информацию и преобразуют ее в соответствующие директивы и команды. Имена блоков управления, как правило, содержат глагол «Управлять...». Стрелки, исходящие из блока с именем «Управлять...», описывают централизованную схему управления (управленческую «вертикаль»). Возможны варианты структур, в которых выходная информация одного из блоков является управляющей для другого. Это отображает децентрализацию управления («горизонтальные» связи).

В соответствие с методологией сначала строится модель существующей организации работы – AS – IS (как есть). Анализ функциональной модели позволяет понять, где находятся слабые места. Найденные в модели AS – IS недостатки можно исправить при создании модели IO – BE (как будет).

Дата добавления: 2014-01-15