Эталонная модель

Эталонная модель (англ. reference model , master model ) - это абстрактное представление понятий и отношений между ними в некоторой проблемной области. На основе эталонной строятся более конкретные и детально описанные модели, в итоге воплощённые в реально существующие объекты и механизмы. Понятие эталонной модели используется в информатике .

Примеры Эталонных моделей

• Сетевая модель OSI (Open Systems Interconnection Reference Model),
• модель Открытого геопространственного консорциума (англ.) ,
• архитектура фон Неймана - модель эталонной модели с последовательными вычислениями,
• эталонная модель Архитектуры государственного предприятия (англ.) ,
• Эталонная Информационная Модель HL7 (Reference Information Model, RIM HL7),
• Эталонная Модель (Reference Model, RM) openEHR .

Wikimedia Foundation . 2010 .

Смотреть что такое "Эталонная модель" в других словарях:

эталонная модель - иерархическая модель — [Л.Г.Суменко. Англо русский словарь по информационным технологиям. М.: ГП ЦНИИС, 2003.] Тематики информационные технологии в целом Синонимы иерархическая модель EN reference model …

эталонная модель - etaloninis modelis statusas T sritis automatika atitikmenys: angl. master model; reference model vok. Referenzmodell, n rus. эталонная модель, f pranc. modèle de référence, m; modèle standard, m … Automatikos terminų žodynas

эталонная модель - 3.1.41 эталонная модель (reference model): Структурированный комплект взаимосвязанных представлений об объекте (например информационной системе), охватывающий данный объект в целом, упрощающий разбиение связей по тематике, который может быть… … Словарь-справочник терминов нормативно-технической документации

эталонная модель ВОС - Модель взаимодействия открытых систем, разработанная ISO в 1984 г. Позволяет универсальным образом описать логику информационного обмена между взаимосвязанными системами и абонентами. Полная модель содержит семь уровней. На самом нижнем… … Справочник технического переводчика

эталонная модель ISO/OSI - Семиуровневая эталонная модель протоколов передачи данных. Определяет уровни: физический, канальный, сетевой, транспортный, сеансовый, представительский и прикладной. В CAN сетях обычно реализуются только физический, канальный и прикладной уровни … Справочник технического переводчика

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

эталонная модель BOC - ЭМВОС Модель, разработанная МОС, содержащая семь уровней (слоев) протоколов и предназначенная для коммуникации между устройствами в сети. [Е.С.Алексеев, А.А.Мячев. Англо русский толковый словарь по системотехнике ЭВМ. Москва 1993] Тематики… … Справочник технического переводчика

эталонная модель взаимодействия открытых систем - — Тематики электросвязь, основные понятия EN ISO/OSI reference model … Справочник технического переводчика

эталонная модель протокола - — [Л.Г.Суменко. Англо русский словарь по информационным технологиям. М.: ГП ЦНИИС, 2003.] Тематики информационные технологии в целом EN protocol reference modulePRM … Справочник технического переводчика

эталонная модель соединения открытых систем - — [Л.Г.Суменко. Англо русский словарь по информационным технологиям. М.: ГП ЦНИИС, 2003.] Тематики информационные технологии в целом EN reference model of open systems … Справочник технического переводчика

Книги

• Компьютерные сети. В 2 томах. Том 1. Системы передачи данных , Р. Л. Смелянский. Приведены теоретические основы систем передачи данных, характеристики основных видов физических сред, способы кодирования и передачи аналоговых и цифровых данных, основы организации…

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

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

В эталонной модели OSI вводятся два понятия: протокол и интерфейс .

Протокол – это набор правил, на основе которых взаимодействуют уровни различных открытых систем.

Интерфейс – это совокупность средств и методов взаимодействия между элементами открытой системы.

Протокол определяет правила взаимодействия модулей одного уровня в разных узлах, а интерфейс – модулей соседних уровней в одном узле.

Всего существует семь уровней эталонной модели OSI. Стоит отметить, что в реальных стеках используется меньше уровней. Например, в популярном TCP/IP используется всего четыре уровня. Почему так? Объясним чуть позже. А сейчас рассмотрим каждый из семи уровней в отдельности.

Уровни модели OSI:

• Физический уровень. Определяет вид среды передачи данных, физические и электрические характеристики интерфейсов, вид сигнала. Этот уровень имеет дело с битами информации. Примеры протоколов физического уровня: Ethernet, ISDN, Wi-Fi.
• Канальный уровень. Отвечает за доступ к среде передачи, исправление ошибок, надежную передачу данных. На приеме полученные с физического уровня данные упаковываются в кадры после чего проверяется их целостность. Если ошибок нет, то данные передаются на сетевой уровень. Если ошибки есть, то кадр отбрасывается и формируется запрос на повторную передачу. Канальный уровень подразделяется на два подуровня: MAC (Media Access Control) и LLC (Locical Link Control). MAC регулирует доступ к разделяемой физической среде. LLC обеспечивает обслуживание сетевого уровня. На канальном уровне работают коммутаторы. Примеры протоколов: Ethernet, PPP.
• Сетевой уровень. Его основными задачами являются маршрутизация – определение оптимального пути передачи данных, логическая адресация узлов. Кроме того, на этот уровень могут быть возложены задачи по поиску неполадок в сети (протокол ICMP). Сетевой уровень работает с пакетами. Примеры протоколов: IP, ICMP, IGMP, BGP, OSPF).
• Транспортный уровень. Предназначен для доставки данных без ошибок, потерь и дублирования в той последовательности, как они были переданы. Выполняет сквозной контроль передачи данных от отправителя до получателя. Примеры протоколов: TCP, UDP.
• Сеансовый уровень. Управляет созданием/поддержанием/завершением сеанса связи. Примеры протоколов: L2TP, RTCP.
• Представительский уровень. Осуществляет преобразование данных в нужную форму, шифрование/кодирование, сжатие.
• Прикладной уровень. Осуществляет взаимодействие между пользователем и сетью. Взаимодействует с приложениями на стороне клиента. Примеры протоколов: HTTP, FTP, Telnet, SSH, SNMP.

После знакомства со эталонной моделью, рассмотрим стек протоколов TCP/IP.

В модели TCP/IP определено четыре уровня. Как видно из рисунка выше – один уровень TCP/IP может соответствовать нескольким уровням модели OSI.

Уровни модели TCP/IP:

• Уровень сетевых интерфейсов. Соответствует двум нижним уровням модели OSI: канальному и физическому. Исходя из этого, понятно, что данный уровень определяет характеристики среды передачи (витая пара, оптическое волокно, радиоэфир), вид сигнала, способ кодирования, доступ к среде передачи, исправление ошибок, физическую адресацию (MAC-адреса). В модели TCP/IP на этом уровне работает протокол Ethrnet и его производные (Fast Ethernet, Gigabit Ethernet).
• Уровень межсетевого взаимодействия. Соответствует сетевому уровню модели OSI. Берет на себя все его функции: маршрутизацию, логическую адресация (IP-адреса). На данном уровне работает протокол IP.
• Транспортный уровень. Соответствует транспортному уровню модели OSI. Отвечает за доставку пакетов от источника до получателя. На данному уровне задействуется два протокола: TCP и UDP. TCP является более надежным, чем UDP за счет создания предварительного соединения, запросов на повторную передачу при возникновении ошибок. Однако, в то же время, TCP более медленный, чем UDP.
• Прикладной уровень. Его главная задача – взаимодействие с приложениями и процессами на хостах. Примеры протоколов: HTTP, FTP, POP3, SNMP, NTP, DNS, DHCP.

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

Рассмотрим на конкретном примере. Пусть мы хотим попасть с компьютера на сайт. Для этого наш компьютер должен подготовить http-запрос на получение ресурсов веб-сервера, на котором хранится нужная нам страница сайта. На прикладном уровне к данным (Data) браузера добавляется HTTP-заголовок. Далее на транспортном уровне к нашему пакету прибавляется TCP-заголовок, содержащий номера портов отправителя и получателя (80 порт – для HTTP). На сетевом уровне формируется IP-заголовок, содержащий IP-адреса отправителя и получателя. Непосредственно перед передачей, на канальном уровне добавляется Ethrnet-заголовок, который содержит физические (MAC-адреса) отправителя и получателя. После всех этих процедур пакет в виде битов информации передается по сети. На приеме происходит обратная процедура. Web-сервер на каждом уровне будет проверять соответствующий заголовок. Если проверка прошла удачно, то заголовок отбрасывается и пакет переходит на верхний уровень. В противном случае весь пакет отбрасывается.

Поддержите проект

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

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

Архитектура эталонной модели искусственно включает два измерения:

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

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

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

Начальные процессы жизненного цикла состоят из категорий процессов поставщик - заказчик и инжиниринга.

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

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

Поддерживающие процессы жизненного цикла состоят из категории процесса поддержки.

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

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

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

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

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

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

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

Есть шесть уровней возможности в эталонной модели.

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

Уровень 1 : Выполняемый. Цель процесса, в общем, достигнута. Достижение не может строго планироваться и отслеживаться. Персонал организации осознает, что процесс должен выполняться, и имеется общее согласие, что этот процесс выполняется, как требуется и когда требуется. Имеются определенные рабочие продукты процесса, и они свидетельствуют в пользу достижения цели.

Уровень 2 : Управляемый . Процесс вырабатывает рабочие продукты согласно определенным процедурам, планируется и отслеживается. Рабочие продукты соответствуют конкретным стандартам и требованиям. Основное различие от Выполняемого уровня в том, что при выполнении процесса теперь вырабатываются рабочие продукты, которые полностью требования к качеству в пределах определенного промежутка времени и выделенного ресурса.

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

Уровень 4 : Предсказуемый. Определенный процесс, на практике, последовательно выполняется в пределах определенных ограничений и достигает определенных целей. Подробные меры выполнения процесса собраны и проанализированы. Это ведет к количественному пониманию возможности процесса и улучшенной способности предсказать выполнение. Выполнение процесса объективно управляется. Качество рабочих продуктов количественно известно. Основное отличие от Установленного уровня в том, что определенный процесс теперь выполняется последовательно внутри определенных ограничений, чтобы достигнуть своих определенных выходов.

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

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

Измерение процесса

В этом подразделе приводиться классификация процессов, принятых в организациях, занимающихся разработкой, эксплуатацией, приобретением, поставкой и поддержкой функционирования ПО. Классификация распознает пять категорий процессов, которые содержат все процессы. Категории и их процессы сопоставимы с теми процессами, которые определены в проекте стандарта ИСО/МЭК 12207, Информационная технология – Жизненный цикл процесса ПО, рассмотренного нами в разделе 2.

Как было отмечено выше, в эталонной модели процессы объединяются в три группы и пять категорий процессов:

начальные процессы жизненного цикла включают категории процесса инжиниринга и поставщик - заказчик;

поддерживающие процессы жизненного цикла включают категории процесса поддержки;

организационные процессы жизненного цикла включают категории процесса управления и организации.

Индивидуальные процессы описаны в терминах шести компонентов.

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

Имя процесса. Описательная фраза, которая выделяет принципиальное свойство процесса (например, Выбор Поставщика).

Тип процесса. Имеется 3 типа процессов верхнего уровня (базисный, расширенный, новый) и 2 процесса второго уровня (компонентный, расширенный), которые имеют следующее отношение к процессам ИСО/МЭК 12207. Новые процессы дополнительны к тем, что определены в ИСО/МЭК 12207. Базисные процессы идентичны в предназначении процессам ИСО/МЭК 12207. Расширенные процессы дополняются на существующем процессе ИСО/МЭК 12207. Компонентные процессы группирует одно или большее количество действий ИСО/МЭК 12207 из того же самого процесса. Расширенные компонентные процессы группируют одно или большее количество действий ИСО/МЭК 12207 из того же самого процесса и включают дополнительный материал.

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

Результаты процесса. Список описаний результатов процесса.

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

Для примера, приведем несколько процессов из каждой категории процесса.

CUS.1 Процесс Приобретения

Базисный процесс

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

Будет разработан контракт, который ясно выражает ожидания, обязанности и обязательства, как заказчика, так и поставщика;

Будет произведен продукт и/или услуга, что удовлетворит установленную потребность заказчика;

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

CUS.1.1 Процесс Подготовки Приобретения

Компонентный процесс CUS.1 – Процесса Приобретения

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

Будет установлена потребность в приобретении, разработке или расширении системы, программного продукта или процесса разработки ПО;

Будут сформулированы системные требования;

Будет разработана стратегия приобретения;

Будут определены приемочные критерии.

ENG.1 Процесс Разработки

Базисный процесс

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

Будет разработан программный продукт или программная система;

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

Будет установлена непротиворечивость между требованиями программного обеспечения и проектами программного обеспечения;

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

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

ПРИМЕЧАНИЕ: Согласованные требования можно обеспечивать операцией процесса Приобретения (CUS. 1) или Процесса Установления Требований (CUS. 3).

ENG.1.1 Процесс Разработки и Анализа Системных Требований

Компонентный процесс ENG.1 – Процесса Разработки

Цель Процесса Разработки и Анализа Системных Требований состоит в том, чтобы установить системные требования (функциональные и нефункциональные) и архитектуру, идентифицируя, какие системные требования должны быть распределены к каким элементам системы и в какой версии. В результате успешной реализации процесса:

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

Будет предложено решение, идентифицирующее основные элементы системы;

Согласованные требования будут распределены каждому из основных элементов системы;

Будет разработана стратегия версии, определяющая приоритет для выполнения системных требований;

Системные требования будут одобрены и модифицированы, как и требуется;

Требования, предложенное решение и их связи будут сообщены всем заинтересованным сторонам.

SUP.1 Процесс Документирования

Расширенный Процесс

Цель Процесса Разработки Документации состоит в том, чтобы разработать и поддержать документы, которые записывают информацию, произведенную процессом или действием. В результате успешной реализации процесса:

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

Будут определены стандарты, к которые должны обращаться за разработка документов;

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

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

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

ПРИМЕЧАНИЕ - процесс поддерживает исполнение атрибута процесса 2.2 в тех примерах, где он введен.

MAN.1.1 Процесс Управления Проектом

Компонентный процесс MAN.1 – процесса Управления

Цель Процесса Управления Проектом состоит в том, чтобы идентифицировать, устанавливать, координировать и контролировать действия, задачи и ресурсы, необходимые для проекта создания продукта и/или встречи услуги согласованным требованиям. В результате успешной реализации процесса:

Будет определена область работ проекта;

Будет оценена выполнимость достижения целей проекта с доступными ресурсами и ограничениями;

Будут измерены и оценены задачи и ресурсы, необходимые для завершения работы;

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

Будут разработаны и выполняться планы выполнения проекта;

Будет проверен и сообщаться прогресс проекта;

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

ПРИМЕЧАНИЕ - Этот процесс поддерживает исполнение атрибута процесса 2.1 в тех примерах, где он введен.

ORG.2 Процесс Усовершенствования

Базисный Процесс

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

Набор организационных активов процесса будет разработан и сделан доступным;

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

Измерение возможности

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

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

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

AП 3.1 Атрибут определение и преобразование процесса

До какой степени ведется выполнение процесса в виде преобразованного экземпляра стандартного определения процесса. Стандартный процесс отвечает определенным бизнес - целям организации. Преобразование выполняется для соответствия специфическим целям экземпляра процесса. В результате полного достижения этого атрибута:

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

Выполнение процесса будет проводиться в соответствии с выбранной и/или приспособленной стандартной документацией процесса;

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

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

Таблица 4.1.

Номер	Название
Уровень 1	Выполняемый процесс
АП 1.1	Атрибут выполнения процесса
Уровень 2	Управляемый процесс
AП 2.1	Атрибут управления выполнением
AП 2.2	Атрибут управления рабочим продуктом
Уровень 3	Установленный процесс
АП 3.1	Атрибут определения и преобразования процесса
АП 3.2	Атрибут ресурса процесса
Уровень 4	Предсказуемый процесс
AП 4.1	Атрибут измерения процесса
AП 4.2	Атрибут контроля процесса
Уровень 5	Оптимизирующий процесс
AП 5.1	Атрибут изменения (верификации) процесса
AП 5.2	Атрибут возможности дальнейшего улучшения

Атрибут процесса представляет измеримую характеристику любого процесса, как определено выше.

N Не достигнутый:

0 % - 15 % - есть маленькое или нет вообще подтверждения достижения определенного атрибута.

P Частично достигнутый:

16 % - 50 % - есть подтверждение надежного систематического метода к достижению определенного атрибута. Некоторые аспекты достижения могут быть непредсказуемы.

L В значительной степени достигнутый:

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

F Полностью достигнутый:

86 % - 100 % - есть подтверждение полного и систематического метода к полному достижению определенного атрибута. Никаких значительных недостатков не существуют в пределах определенной части организации.

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

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

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

Ниже приведены таблицы, содержащие итоговые списки процессов, которые включены в эталонная модель (таблица 4.3) и соответствие процессов эталонной модели и процессов, определенные в проекте стандарта ИСО/МЭК 12207 (таблица 4.4).

Таблица 4.2

Шкала	Атрибуты процесса	Оценка
Уровень 1	Выполнение процесса	В основном или полностью
Уровень 2	Выполнение процесса Управление выполнением Управление рабочим продуктом	Полностью В основном или полностью В основном или полностью
Уровень 3	Выполнение процесса Управление выполнением Управление рабочим продуктом Ресурс процесса	Полностью Полностью Полностью В основном или полностью В основном или полностью
Уровень 4	Выполнение процесса Управление выполнением Управление рабочим продуктом Определение и преобразование процесса Ресурс процесса Измерение процесса Контроль процесса	Полностью Полностью Полностью Полностью Полностью В основном или полностью В основном или полностью
Уровень 5	Выполнение процесса Управление выполнением Управление рабочим продуктом Определение и преобразование процесса Ресурс процесса Измерение процесса Контроль процесса Изменение процесса Возможность дальнейшего улучшения	Полностью Полностью Полностью Полностью Полностью Полностью Полностью В основном или полностью В основном или полностью

Таблица 4.3.

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

Таблица 4.4.
	Действия и процессы 12207		Процессы 15504
	Начальные процессы жизненного цикла
	Процесс приобретение		Процесс приобретения	базисный
	Инициализация		Процесс подготовки приобретения	Компонента
	Подготовка Заявки-для-Предложения [-заявка на подряд]		Процесс выбора поставщика	Компонента
	Подготовка контракта и корректировка		Процесс выбора поставщика	Компонента
	Проверка поставщика		Процесс проверки поставщика	компонента
	Принятие и завершение		Процесс одобрения заказчика	компонента
	Процесс поставки		Процесс поставки	базисный
	Инициализация		Процесс поставки	базисный
	Подготовка ответа		Процесс поставки	базисный
	Контракт		Процесс поставки	базисный
	Планирование		Процесс поставки	базисный
	Выполнение и управление		Процесс поставки	базисный
	Обзор и оценка		Процесс поставки	базисный
	Поставка и завершение		Процесс поставки	базисный
			Процесс установления требований
	Процесс разработки		Процесс разработки	базисный
	Реализация процесса		Процесс разработки	базисный
	Анализ системных требований			компонента
	Разработка архитектуры системы		Процесс разработки и анализа системных требований	компонента
	Анализ требований ПО		Процесс анализа программных требований	компонента
	Разработка архитектуры ПО		Процесс разработки ПО	компонента
	Рабочий проект ПО		Процесс разработки ПО	компонента
	Кодирование и тестирование ПО		Процесс конструкции ПО	компонента
	Интеграция ПО		Процесс интеграции ПО	компонента
	Тестирование квалификации ПО		Процесс тестирования ПО	компонента
	Интеграция системы			компонента
	Тестирование квалификации системы		Процесс тестирования и интеграции системы	компонента
	Инсталляция ПО		Процесс поставки	базисный
	Поддержка программ		Процесс поставки	базисный
	Процесс функционирования			базисный
	Реализация процесса		Процесс функционального использования	расширенная компонента
	Функциональное тестирование		Процесс функционального использования	расширенная компонента
	Функционирование системы		Процесс функционального использования	расширенная компонента
	Поддержка пользователя		Процесс поддержки пользователя	расширенная компонента
	Процесс эксплуатации			базисный
	Реализация процесса		Процесс эксплуатации ПО и системы	базисный
	Анализ проблем и модификаций		Процесс эксплуатации ПО и системы	базисный
	Реализация модификации		Процесс эксплуатации ПО и системы	базисный
	Принятие в эксплуатацию		Процесс эксплуатации ПО и системы	базисный
	Миграция		Процесс эксплуатации ПО и системы	базисный
	Утилизация ПО		Процесс эксплуатации ПО и системы	базисный
	Вспомогательные процессы жизненного цикла
	Процесс документирования		Процесс документирования	расширенный
	Реализация процесса		Процесс документирования	расширенный
	Разработка и развитие		Процесс документирования	расширенный
	Продукция		Процесс документирования	расширенный
	Эксплуатация		Процесс документирования	расширенный
			Процесс управления конфигурацией	Базисный
	Реализация процесса		Процесс управления конфигурацией	базисный
	Идентификация конфигурации		Процесс управления конфигурацией	базисный
	Контроль конфигурации		Процесс управления конфигурацией	базисный
	Учет статуса конфигурации		Процесс управления конфигурацией	базисный
	Оценка конфигурации		Процесс управления конфигурацией	базисный
	Управление выпуском и поставкой		Процесс управления конфигурацией	базисный
	Процесс гарантии качества		Процесс гарантии качества	базисный
	Реализация процесса		Процесс гарантии качества	базисный
	Гарантия продукта		Процесс гарантии качества	базисный
	Гарантия процесса		Процесс гарантии качества	базисный
	Системы гарантии качества		Процесс гарантии качества	базисный
	Процесс верификации		Процесс верификации	базисный
	Реализация процесса		Процесс верификации	базисный
	Верификация		Процесс верификации	базисный
			Процесс проверки достоверности	базисный
	Реализация процесса		Процесс проверки достоверности	базисный
	Проверка достоверности		Процесс проверки достоверности	базисный
	Процесс совместного обзора		Процесс совместного обзора	базисный
	Реализация процесса		Процесс совместного обзора	базисный
	Обзоры управления проектом		Процесс совместного обзора	базисный
	Технические обзоры		Процесс совместного обзора	базисный
	Процесс проверки		Процесс проверки	базисный
	Реализация процесса		Процесс проверки	базисный
			Процесс проверки	базисный
	Процесс решения проблем		Процесс решения проблем	базисный
	Реализация процесса		Процесс решения проблем	базисный
	Решение проблем		Процесс решения проблем	базисный
			Процесс измерения
			Процесс повторного использования
	Организационные процессы жизненного цикла
	Процесс управления		Процесс управления	базисный
	Инициализация и определение области		Процесс управления проектом	компонента
	Планирование		Процесс управления проектом	компонента
	Выполнение и контроль		Процесс управления проектом	компонента
	Обзор и оценка		Процесс управления проектом	компонента
	Закрытие		Процесс управления проектом	компонента
			Процесс управления качеством
			Процесс управления риском
			Процесс организационного выравнивания
	Процесс инфраструктуры		Процесс инфраструктуры	базисный
	Реализация процесса		Процесс инфраструктуры	базисный
	Создание инфраструктуры		Процесс инфраструктуры	базисный
	Эксплуатация инфраструктуры		Процесс инфраструктуры	базисный
	Процесс усовершенствования		Процесс усовершенствования	базисный
	Создание процесса		Процесс создания процесса	компонента
	Оценка процесса		Процесс оценки процесса	компонента
	Усовершенствование процесса		Процесс усовершенстования	компонента
	Подготовка процесса			расширенный
	Реализация процесса		Процесс управления человескими ресурсами	расширенный
	Подготовка существенной разработки		Процесс управления человескими ресурсами	расширенный
	Подготовка реализации плана		Процесс управления человескими ресурсами	Идея управления по эталонной модели, предложенная в 1961 г. , может быть реализована при небольшой модификации схемы на рис. 11.27. Эта идея оказала большое влияние на работы по системам управления. Суть ее состоит в том, чтобы построить, синтезировать или адаптировать систему, общая импульсная характеристика которой наилучшим образом соответствует характеристике эталонной модели или характеристике некоторой идеальной модели. Предположим, например, что динамические характеристики управления самолетом существенно отличаются для скоростей до звукового барьера и сверхзвуковых. Чтобы предоставить пилоту возможность адекватно управлять самолетом независимо от его скорости, вводится автопилот, который принимает сигналы управления пилота и приводит в действие управляющие сервомеханизмы. Реакция самолета на сигналы управления пилота соответствует реакции некоторой эталонной модели, которая выбирается разработчиком системы так, чтобы снабдить самолет «чувством руля», удобным для пилотов. Многие физические системы синтезируются так, что их характеристики подобны характеристикам моделей, и многие из этих систем являются адаптивными. Реализовать описанный подход нетрудно, видоизменив схемы на рис. 11.11 или 11.27. Для этого нужно просто заменить обратную модель с задержкой на эталонную. Тогда общая характеристика системы скорее будет подобна характеристике эталонной модели, чем просто задержанному скачку. Такая модификация схемы приведена на рис. 11.28. В системах на рис. 11.11 и 11.27 задержка введена для обеспечения возможности точного обратного моделирования, соответствующего низкому уровню СКО ей. При наличии задержки можно получить хотя и задержанный, но более точный отклик. Как отмечено выше, введение задержки необходимо в тех случаях, когда имеется задержка реакции в управляемой системе или эта система не является минимально-фазовой. При замене задержки на эталонную модель в случаях, когда задержка нужна для точного обратного моделирования, как правило, ее необходимо вводить и в эталонную модель. Рис. 11.28. Управление с адаптивной обратной моделью, аналогичное рис. 11.27, но с включением эталонной модели При этом нужно формировать такую характеристику эталонной модели, которую можно реализовать при последовательном включении управляемой системы и адаптивного фильтра, если весовые коэффициенты этого фильтра соответствуют минимальной СКО. Схема на рис. 11.28 хорошо функционирует тогда, когда для адаптивной системы задаются гибкие условия. Не следует, однако, считать, что эта схема менее инерционна или имеет более точный отклик, чем это возможно для управляемой системы и ее адаптивного устройства управления с конечной импульсной характеристикой. Для примера адаптивной системы управления с применением обратного моделирования по эталонной модели рассмотрим следующую реализацию схемы на рис. 11.28: эталонная модель: весовых коэффициентов в модели весовых коэффициентов в устройстве управления итераций адаптивного процесса. На рис. 11.29 показан отклик на единичный скачок нескомпенсированной управляемой модели, а на рис. 11.30 - отклик скомпенсированной системы, наложенный на отклик эталонной системы. Очевидно, что получено очень близкое приближение. Теория адаптивных систем возникла в связи с необходимостью решения широкого класса прикладных задач, для которых неприемлемы традиционные методы, требующие знания адекватной математической модели объекта. Качество традиционных (неадаптивных) методов управления тем выше, чем больше априорной информации о самом объекте и условиях его функционирования. На практике достаточно трудно обеспечить точное математическое описание объекта управления. Например, динамические характеристики летательных аппаратов сильно зависят от режима полета, технологических разбросов, состояния атмосферы. В этих условиях традиционные методы часто оказываются неприменимыми либо не обеспечивают требуемое качество системы автоматического управления. В связи с этим уже на начальном этапе развития теории автоматического управления представлялся весьма эффективным путь построения управляющих систем, не требующих полной априорной информации об объекте и условиях его функционирования. Эффект приспособления к условиям функционирования в адаптивных системах обеспечивается за счет накопления и обработки информации о поведении объекта в процессе его функционирования, что позволяет существенно снизить влияние неопределенности на качество управления, компенсируя недостаток априорной информации на этапе проектирования систем. Система управления, автоматически определяющая требуемый закон управления посредством анализа поведения объекта при текущем управлении, называется адаптивной . Адаптивные системы можно разделить на два больших класса: самоорганизующиеся и самонастраивающиеся. В самоорганизующихся системах в процессе функционирования происходит формирование алгоритма управления (его структуры и параметров), позволяющего оптимизировать систему с точки зрения поставленной цели управления (ЦУ). Такого рода задача возникает, например, в условиях изменения структуры и параметров объекта управления в зависимости от режима функционирования, когда априорной информации недостаточно для определения текущего режима. При широком классе возможных структур объекта трудно надеяться на выбор единственной структуры алгоритма управления, способной обеспечить замкнутой системе достижение цели управления во всех режимах функционирования. Таким образом, речь идет о синтезе при свободной структуре регулятора. Очевидная сложность постановки задачи не позволяет надеяться на простые алгоритмы ее решения, а следовательно, и на широкое внедрение в настоящее время систем в практику. Задача существенно упрощается, если структура объекта управления известна и неизменна, а поведение зависит от ряда неизменных параметров. Задача решается в классе самонастраивающихся систем (СНС), в которых структура регулятора задана (заранее выбрана) и требуется определить лишь алгоритм настройки его коэффициентов (алгоритм адаптации). Самонастраивающейся системой автоматического управления называется система, самостоятельно изменяющая свои динамические характеристики в соответствии с изменением внешних условий с целью достижения оптимального выхода системы. В случае самонастраивающихся систем управления полетом таким оптимальным выходом системы будет оптимальная реакция на внешние возмущения. СНС делятся на два подкласса: поисковые и беспоисковые. В поисковых СНС минимум (или максимум) меры качества (производительность установки, расход топлива и т.д.) ищется с помощью специально организованных поисковых сигналов. Простейшими поисковыми системами являются большинство экстремальных систем, в которых недостаток априорной информации восполняется за счет текущей информации, получаемой в виде реакции объекта на искусственно вводимые поисковые (пробные, тестовые) воздействия. В беспоисковых СНС в явном или неявном виде имеется модель с желаемыми динамическими характеристиками. Задача алгоритма адаптации состоит в настройке коэффициентов регулятора таким образом, чтобы свести рассогласование между объектом управления и моделью к нулю. Такое управление называют прямым адаптивным управлением, а системы - адаптивными системами с эталонной моделью . В случае непрямого адаптивного управления сначала проводят идентификацию объекта, а затем определяют соответствующие коэффициенты регулятора. Подобные регуляторы называются самонастраивающимися. При прямом адаптивном управлении контуры адаптации работают по замкнутому циклу, что позволяет парировать изменения параметров объекта и регулятора в процессе функционирования. Однако каждый контур самонастройки повышает порядок системы как минимум на единицу, и при этом существенно влияет на общую динамику замкнутой системы. В случае непрямого адаптивного управления контуры самонастройки работают по разомкнутому циклу и, следовательно, не влияют на динамику системы. Однако все ошибки идентификации, уходы параметров объекта и регулятора существенно влияют на точность управления. В беспоисковых самонастраивающихся системах эталонная модель может быть реализована в виде реального динамического звена (явная модель) или присутствовать в виде некоторого эталонного уравнения, связывающего регулируемые переменные и их производные (неявная модель). В неявной модели коэффициенты эталонного уравнения являются параметрами алгоритма адаптации. На рисунке 1 показан один из часто используемых в исполнительных приводах вариантов адаптивного управления, где параметры регулятора настраиваются управляющим компьютером по эталонной модели. Эталонная модель показывает идеальную желаемую реакцию системы на задающий сигнал g(t). В качестве эталонной модели применяют типовые звенья систем автоматического управления (например, апериодическое звено). Параметры ПИД-регулятора (пропорционально-интегрально-дифференциальный регулятор) настраиваются так, чтобы минимизировать рассогласование между выходом модели и реальной системы. Задача контура настройки состоит в том, чтобы свести это рассогласование к нулю за определенное время с гарантией устойчивости переходного процесса. Данная проблема далеко не тривиальна – можно показать, что она не решается при линейных соотношениях «ошибка – коэффициенты регулятора». Например, в литературе предложен следующий алгоритм настройки параметров: где k – настраиваемые коэффициенты ПИД-регулятора; А – постоянный коэффициент, задающий скорость адаптации. Рис. 1. Блок-схема адаптивной системы с эталонной моделью Функция градиента определяет чувствительность ошибки c(t) к вариации коэффициентов регулятора. Абсолютная устойчивость замкнутой системы, которая является существенно нелинейной, обеспечивается подбором параметра А в программе настройки. Таким образом, управляющий компьютер для реализации адаптивного управления по данной схеме должен в реальном времени решать следующие задачи: формировать задающий сигнал для управляемой системы; рассчитывать идеальную реакцию по эталонной модели; вычислять коэффициенты регулятора в соответствии с программой настройки, определять текущую ошибку и выдавать сигнал управления на вход мехатронного модуля. Помимо рассмотренной блок-схемы с эталонной моделью известны и другие методы автоматической настройки параметров и структуры регуляторов. Я у мамы программист - Информационный портал 2024 © onlinezarabotokz.ru