CC BY
76
РНП.3.2.3.5788 • РАЗРАБОТКА ТЕХНОЛОГИИ СОГЛАСОВАННОГО УПРАВЛЕНИЯ ...
УДК 378.14:004.78
М.Б.ГУЗАИРОВ, В. В. МАРТЫНОВ, В. И. РЫКОВ
КОНЦЕПЦИЯ КОМПЛЕКСНОЙ ПОДГОТОВКИ СПЕЦИАЛИСТОВ ПО CALS-ТЕХНОЛОГИЯМ И ЕЕ АПРОБАЦИЯ НА БАЗЕ УГАТУ
Описывается концепция управления содержательной составляющей научных программ и процесса обучения специалистов в области технологий CALS (ИПИ). В ее основе лежит принцип инструментального управления информационными процессами в рамках объектного подхода. Концепция реализована в методологии средств управления проектами Rational Unified Process (RUP) фирмы IBM Rational. Используется набор программных средств, поддерживающих указанную методологию. Управление проектами; подготовка специалистов;
технологии CALS (ИПИ)
Задачей CALS является обеспечение информационного обмена между процессами, реализующими жизненный цикл (ЖЦ) продукции. Каждый из этапов ЖЦ сложной наукоемкой продукции имеет специфический набор операций и тезаурус, которые отражают профессиональные (социальные, технические, технологические и т.д.) особенности конкретной профессиональной среды. На многих этапах ЖЦ указанной продукции используются специализированные программные и программно-технические комплексы (CAD / CAM / CAE / PDM / ERP ... ). Сложные изделия имеют профессиональносмысловое деление и внутри основных этапов ЖЦ, в большей степени это касается этапов проектирования и производства.
Назовем отдельную описанную выше локальную информационно-технологическую область ЖЦ-подсистемой. С информационной точки зрения каждая ЖЦ-подсистема имеет границу, отделяющую одну подсистему от другой, собственные информационные ресурсы (в том числе язык предметной области) и технологию документооборота, отражающего технологические операции данной предметной области. Примером служит процесс проектирования и производства газотурбинного двигателя, где специалисты по воздухозаборнику, компрессору, камере сгорания, турбине и соплу общаются со специалистами-смежниками на специализированных (внеш-
них) языках документов. Указанные особенности ЖЦ-подсистемы позволяют рассматривать ее как объект сферы информационных технологий.
Представление ЖЦ-подсистемы как объекта, позволяет уточнить исходную парадигму СЛЬБ:
• «Идеальной основой для решения поставленной задачи является использование единой интегрированной модели продукта и его жизненного цикла, описывающей объект настолько полно, что выступает в роли единого источника информации для любых выполняемых в ходе жизненного цикла процессов» [1];
• «В отличие от концепции ИАСУП (интегрированная автоматизированная система управления производством) концепция СЛЬБ охватывает не только производство, но и все остальные этапы жизненного цикла, но не касается технологии решения прикладных задач (проектирования, планирования и т. д.)» [там же].
Формат информационного взаимодействия между ЖЦ-подсистемами существенно зависит от технологии решения прикладных задач в каждой из подсистем. Действительно, структуру данных определяет получающая сторона, обработку и выдачу данных в нужном формате обеспечивает, в силу своих возможностей, подсистема, выдающая информацию. Реально мы наблюдаем типичную
Работа выполняется в рамках ведомственной научной программы «Развитие научного потенциала высшей школы» в 2005-2006 гг., проекты: «Разработка концепции комплексной подготовки специалистов в области СЛЬ8-технологий и ее апробация на базе УГАТУ» и «Разработка технологии согласованного управления информационными ресурсами сферы образования и науки на базе информационных моделей в области ИПИ-(САЬ8-)технологий».
контрактную технологию информационного взаимодействия ЖЦ-подсистем как объектов [2]. Ответственность за качество информации в рамках контракта несет генерирующая подсистема, ответственность за правильность запроса несет принимающая информацию подсистема. Источником/приемником данных может быть человек или информационно-техническая система. Естественно, что форматы данных информационного обмена подсистем должны максимально придерживаться стандартов, если таковые существуют (концепция единого информационного пространства, ЕИП).
В рамках объектного подхода взаимодействие между подсистемами осуществляется активными объектами — Актерами (Actors). В качестве актера может выступать человек, например, при работе с интерактивным электронным техническим руководством, или технологическая система, например PDM.
Методика формирования надежного информационного взаимодействия между подсистемами в рамках RUP подхода сводится к выделению актеров указанных подсистем, определению потребностей актеров и описанию вида запросов к соответствующим бизнес-процессам подсистемы, которые данные потребности удовлетворяют. В языке UML (Unified Modeling Language), принятом в RUP, указанные запросы носят название «варианты использования» системы (Use Case).
Комплекс актеров и связанных с ними вариантов использования является информационной моделью (Use Case модель) процессов информационного обмена между подсистемами, т. е. информационной моделью ИПИ.
Таким образом, информационный обмен между ЖЦ-подсистемами, рассматриваемыми как объекты, сводится к выполнению некоторого контракта. Получающая сторона формулирует задачу, сторона-исполнитель реализует требуемую задачу информационного обмена в рамках заранее установленного контракта (варианта использования системы — Use Case).
В зависимости от типа Use Case, в методологии и реализующей ее технологии ИПИ можно выделить три уровня деятельности: научная — определение общей методологии построения новых Use Case контрактов в рамках ЕИП и разработка принципов реализации для конкретного набора ЖЦ-подсистем;
технологическая — реализация Use Case для данного набора объектов. Например, программирование задач информационного обмена в PSS системе на базе существующих принципов или стандартов;
обучающая — подготовка специалиста в области ИПИ-технологий для конкретного вида производства.
Характерной особенностью ИПИ задач является их нечеткая постановка. Данное обстоятельство связано с проблемами в области семиотики и вызвано различиями в концептуальных базах отправителя и приемника информации [3]. Представители разных предметных областей обычно имеют несовпадающие взгляды на один и тот же объект. Проблемы возникают на нескольких уровнях. Сравнительно простой является ситуация, когда различается лишь лингвистическая компонента концепта, а содержание концепта, обозначающего объект реального мира, совпадает в обеих предметных областях. Данная ситуация типична при передаче данных от одной к другой PDM- или САПР-системе, и проблема решается построением требуемого транслятора (рис. 1).
Требования к выходным данным этапа А Требования к входным данным этапа В
Реализация транслятора
Рис.1
В случае несовпадения концептуального взгляда на один и тот же объект получатель не может воспринять информацию, содержащуюся в сообщении по причине отсутствия в его тезаурусе соответствующих концептов. Полноценный информационный обмен между ЖЦ -подсистемами может быть установлен только как результат процесса обмена знаниями. Итерационный характер технологии ИиР имеет принципиальное значение для решения научных ИПИ задач. Проект в ИиР
рассматривается как последовательность итераций, каждая из которых улучшает сопоставимость семантики концептов участников информационного обмена, необходимых для понимания вопросов и правильного истолкования ответов.
Реализация RUP имеет гибкий характер и может быть использована для решения ИПИ задач различного объема и уровня сложности. Таким же образом возможно использование данной технологии на разных уровнях формализации документооборота решаемой задачи.
Центральное место в методологии занимает система управления требованиями Requisite Pro. Use Case требования анализируются средствами системы и сопоставляются перечню научных задач или перечню дисциплин обучения, если это требования к знаниям обучаемого. Каждой теме научного исследования или дисциплине обучения можно сопоставить диаграмму Ганта системы Microsoft Project и выполнить анализ системы требований (научной программы, учебного плана) на временные ограничения или критичность при использовании исследовательских, дидактических, временных или лабораторных ресурсов. Комплекс Use Case требований, хранящийся в базе проекта, используется двояким образом. Формируется текстовый документ специального вида — «Концепция проекта» (Vision). Документ содержит формализованный набор сведений о проекте как коммерческом предложении. Цель документа — согласовать взгляды участников информационного обмена на пользователей, задачи, методы и средства решения проблемы информационного обмена.
Те же требования служат основой для построения средствами языка UML информационной модели проекта. Для построения модели служит система Rational Rose. Средствами указанной системы участники, требования и протоколы решаемой задачи информационного обмена могут быть описаны с требуемой степенью наглядности и подробности, вплоть до структуры алгоритмов.
Программы Rational Rose, Requisite Pro и документ концепции проекта Vision взаимосвязаны и изменения в номенклатуре, содержании или статусе требований Use Case, выполненные в одной из программных систем, отражаются в остальных системах. Документирование задач проекта может быть реализовано на основе программы SoDa, генерирующей Word-документ, или же непосредственным обращением к базе проекта, хранящей
в прозрачном режиме все основные данные проекта, средствами VBA или Delphi.
Предлагаемая концепция и реализующая ее технология описываются диаграммой Use Case (рис. 2). Диаграмма содержит объекты и варианты использования — Use Case.
Концепция комплексной подготовки специалистов
в области CALS-технологий________________________
Q
Область CALS-технологий
Q"
Производственная Q Q
CALS-модрль Научная CALS-модель Дидактическая
Потребности производства в CALS-обслуживани!
Потребности процесса обучения в области CALS-технологий
Q
Модель специалиста в области CALS-технологий
Рис. 2
Не уменьшая общности, опишем технологию применения указанной концепции в сфере обучения. Задачи сферы научных исследований и задачи взаимодействия указанных областей решаются аналогичным образом.
Рассмотрим содержание этапов (рис. 3):
1. Формирование Use Case модели специалиста в области CALS-технологий. На
данном этапе формируется весь объем знаний и умений, необходимый специалисту, работающему в конкретной области CALS-технологий. Отметим, что требования указанного этапа обновляются достаточно быстро (Business Use Case Model в терминах Rational Rose).
2. Формирование Use Case модели выпускника в области CALS-технологий. Определяется и формируется учебная модель знаний и умений. Данный объем должен быть достаточен для начала работы выпускника на производстве (ограничение снизу), а сверху объем ограничивается возможностями обучаемого к получению знаний (Use Case Model в терминах Rational Rose).
3. Формирование Use Case модели абитуриента. Знания абитуриента существенно определяют вид и объем дальнейшей подготовки. Знания зависят от состояния средней школы, конкурса, а для целей переподготовки и индивидуального обучения нуждаются в
дополнительном определении (Start Use Case Model в терминах Rational Rose).
Этапы реализации концепции комплексной подготовки специалистов в области ОДЬБ-технологий
Формирование модели абитуриента Формирование требований к процессу обучения выпускника в области ОДЬБ-технологий
Формирование комплекса Формирование структуры учебных программ обучающих модулей
Рис. 3
4. Формирование требований к процессу обучения выпускника в области CALS-технологий. Данные требования и есть тот объем умений и знаний, который должен дополнить исходные знания абитуриента для достижения им модели выпускника (Use Case Model в терминах Requisite Pro).
5. Формирование комплекса учебных программ. Данный процесс состоит в разноске требований к процессу обучения по конкретным дисциплинам. Основной проблемой этапа является решение задачи достижимости и равномерности процесса обучения. Решаются задачи качества учебного процесса. Для этого вводятся метрики учебного процесса и показатели (ограничения) по каждой из метрик. Например, метрикой служит количество внеаудиторных часов, которые студент должен потратить на освоение данного учебного требования. Показателем может служить качество освоения требования в стандартных терминах [4], а ограничением — количество рабочих часов в сутках (Features Model в терминах Requisite Pro).
6. Формирование структуры обучающих модулей. Предлагается формализация процесса обучения с точки зрения объектного подхода. Единицей процесса обучения является учебная дисциплина. Программа учебной дисциплины содержит перечень знаний, навыков и умений, достаточный для использования результатов обучения в практической или теоретической деятельности или при изучении последующих дисциплин. В свою очередь, каждый компонент учебной дисциплины реализуется некоторым набором учебных приемов и технологий (блоков), не
обязательно уникальных для данного компонента. Учебные блоки содержат дидактические методы и технологии, объединенные внутренним содержанием. Так, методика информационного моделирования может быть применена в совершенно не сходных по своему назначению учебных дисциплинах. В благоприятных условиях дисциплина обучения не изобретается заново во всех своих компонентах, а собирается из заранее подготовленных и опробованных учебных элементов (темы лекций, конкретные лабораторные работы и т. д.). Обучающий модуль играет роль класса в объектном программировании. (Business Object Model в терминах Rational Rose).
Основой предлагаемой технологии является методика управления требованиями к знаниям специалиста. Комплекс требований формируется в процессе построения информационной модели проекта обучения. Требования могут быть ранжированы и описаны с различных точек зрения (дидактической, научной, ресурсной, ). Имеется возможность сопоставить учебные требования дисциплинам учебного плана и оценить информационную нагрузку каждого предмета в реальном времени. Использование CASE возможностей для управления требованиями позволяет варьировать план обучения в зависимости от исходных знаний обучаемого, потребностей промышленности или науки.
Перенос комплекса требований или дисциплин обучения в среду системы Microsoft Project и представление информационного компонента процесса обучения в виде диаграмм Ганта дает возможность оценить реализуемость процесса обучения в плане ресурсных нагрузок, провести исследование дидактических характеристик указанного процесса.
Концептуальные, дидактические, технологические и инструментальные средства формирования процесса обучения реализуются в виде референтных моделей или описываются в виде методологий в рамках обучающего CALS-центра. CALS-центр содержит референтные Use Case и Requisite Pro модели обучения в области CALS-технологий по направлениям, методики построения Microsoft Project моделей учебных планов и средства настройки указанных моделей на требования конкретной специальности.
Основной дидактической единицей обучающего CALS-центра является модель процесса обучения. Модель состоит из информационной Use Case модели, выполненной средствами Rational Rose на языке UML, проек-
i Описание ЖЦ изделия_01
- CD Use Case View
О 01 Подразделения заказчика О02_Подразделения предприятия
□ 03_Потребности в CALS обслуживании (ЭТАПЫ ЖИЗНЕННОГО ЦИКЛА)
□ 04_Иерархия управления
□ 05_3адачи управления
□ 06_Ресурсы предприятия D 07_Документы
D Производственная CALS модель (прецедентная)
В 01_Последовательности CALS задач В 02_Управление предприятием В 03_Планирование производства В 04.1_0своение производства нового изделия В 04_06еспечение технологической подготовки производства В ОБ_Обеспечение МТО производства В 06_Контроль выполнения производственного плана В 07_Управление качеством В 08._ИЛП продукции
В 08.1_Выполнение логистического анализа В 08.2_0беспечение МТО в эксплуатации
В 08.3 Разработка интерактивной электронной технической документации В 0Э.1_Информационное сопровождение производства (инженерное направление)
В ОЭ_Информационное сопровождение производства (управленческое направление) В 10_Управление сбытом продукции
В 11_0беспечение конструкторской подготовки производства 12_0беспечение послепродажного сервисного обслуживания В 13_0беспечение выполнения капитального ремонта изделий В 99_06общенная CALS модель продукции машиностроительного предприятия
Рис. 4
Точка зрения - Генеральный конструктор
13 ИЗ ИЗ ИЗ ЕЗЕЗ
НТД на НТЗ НТД на ОКР НТД на пр. НТД на экс. НТД на рем. НТД н;
Требования к д
Ресурсы исследовани
Ресурсы утилизаци
Двиг. на утил.
Разработчик ГТД
Рис. 5
Рис. б
та управления требованиями в Requisite Pro, проекта в Microsoft Project и Word документа Vision. Документ Vision представляет собой стандартный текстовый документ технологии RUP и играет роль ТЗ проекта.
В случае, когда основой информационной модели служит государственный образовательный стандарт или другой текстовый документ, информационная модель строится на основе документа Vision. Требования стандарта копируются в Word документ Vision,
описываются и погружаются в среду Requisite Pro. На основе требований проекта Requisite Pro формируется модель управления проектом Microsoft Project, далее формируются требования Use Case в системе Rational Rose и строится полноценная информационная модель с использованием средств языка UML.
Модели проектов обучения, не имеющие аналогов, например «CALS-технологии в авиадвигателестроении», изначально строятся выразительными средствами языка UML в
и Автоматизированные технологии и производства
- С 2110ОО «Автоматизированное управление жизненным циклом продукции»
0 211000 - Дисциплины специализации - С: 211000 - Іребования к выпускнику
* Автоматизация управления жизненным циклом продукции ■>? Ии I сі риронлннля мої исі ичоокля поллсржк.ч продукции
- Автоматизация логистического анализа И иСУівіоп.УІБ
* АСУ оксплул і .чции и ідопия
* База данных и отчеты логистического анализа
* Влияние ИЛП на стоимость ЖЦ продукции
■ Интогрироплннля погистичоскля поллоржкл продукции
* Информационное обеспечение ИЛП
* Комплексная система материально технического обеспечения эксплуатации изделия
* Логистический анализ: цели и методы
Рис. ?
Relationships: - direct only FEAT45: Детали машин и основы конструирования FEAT46: Материаловедение FEAT47: Технология конструкционных материалов FEAT48: Электротехника и электроника FEAT49: Метрология, стандартизация и сертификация FEAT50: Безопасность жизнедеятельности FEAT51: Экономика и организация промышленности FEAT52: Термодинамика FEAT53: Теплопередача FEAT54: Механика жидкости и газа FEAT56: Теория, расчёт и проектирование авиационных... FEAT57: Основы конструирования изделий FEAT58: Системы автоматизированного проектирования... FEAT59: Автоматика и регулирование изделий FEAT60: Испытания и обеспечение надежности изделий
UC64.4.10: Надзор и контроль за состоянием и эксплуатацией... а А а а А
UC64.4.11: Установление причин недостатков и неисправностей в... а А А а А А
UC64.7: Управление_ЖЦ_ продукции
- UC65: Знания
UC65.1: Постановления, распоряжения вышестоящих и других... А А А А- А- А А А А
UC65.2: Знание методик, НТД и РТМ, касающихся выполняемой... А А А А А А А А А
UC65.3: Перспективы технического развития и особенности... А А А А А А А А
UC65.5; Методы исследования, правила и условия выполнения... А А А А А А А А
UC65.6; Основные требования, предъявляемые к технической... А А А А А А
UC65.7: етоды проведения технических расчетов и определения... А А
UC65.8: Достижения науки и техники, передовой и зарубежный опыт.. А а А а А А А А А а А А А А
Рис. 8
рамках системы Rational Rose. Далее модель и оценить реализуемость соответствующего
переносится в среду Requisite Pro/Microsoft учебного плана. Верхний уровень Use Case
Project/Vision. модели предприятия представлен на рис. 4.
Задачей Use Case модели является согла- В модели указывается структура предпри-
сование точек зрения промышленности — за- ятия, и в терминах Use Case диаграмм описы-
казчика специалистов и потребителя резуль- ваются потребности предприятия в области
татов научных исследований в области CALS- CALS технологий.
технологий и вуза — исполнителя проекта. Use Case диаграмма верхнего уровня, отра-
С точки зрения промышленного предприя- жающая, например, точку зрения Генерально-
тия, модель описывает потребности произ- го конструктора, представлена на рис. 5.
водственного требующие участия Жизненный цикл двигателя описывается
специалистов с конкретными функциями и диаграммой (рис. 6).
навыками. С точки зрения вуза, модель слу- Требования к специалисту отражаются в
жит для формирования списка требований виде списка (рис 7)
к специалисту, позволяющего сформировать
Согласованные между участниками проекта требования к специалисту копируются параллельно в документ Vision и программу Requisite Pro. Средствами программы требования ранжируются по требуемым в дидактике параметрам и сопоставляются дисциплинам обучения.
Данная диаграмма (рис.8) описывает информационную составляющую учебного плана.
Реализуемость учебного плана и оценку его качества по использованию педагогических ресурсов — загруженность студентов, наличие лабораторий и т. д. — проверяется средствами системы Microsoft Project. Представление последовательности требований или дисциплин в виде диаграмм Ганта позволяет определить критические точки учебного плана.
При необходимости, учебный план корректируется на уровне информационной Use Case модели, согласовывается, и измененный план утверждается в виде документа Vision. Заметим, что изменение требований в любом из документов автоматически находит свое отражение в остальных (исключая Microsoft Project).
В рамках указанной технологии была решена задача построения центров обучения в области CALS-технологий по направлениям
на ряде кафедр технического университета (УГАТУ). Разработаны референтные модели по каждому из направлений обучения. Средства применяемой технологии позволяют использовать настраиваемую референтную модель процесса обучения для гибкого управления содержательной составляющей учебного плана в зависимости от целей обучения, исходного уровня обучаемых и потребностей промышленности. Средства WEB публикации проекта позволяют обеспечить доступ к информации всем заинтересованным лицам.
Методология управления разверткой, запуском и развитием средств обучающего CALS-центра представлена в виде программно-методического CALS-комплекса.
СПИСОК ЛИТЕРАТУРЫ
1. CALS — Основные понятия и определения (Сервер НИЦ CALS технологий) [Электронный ресурс]. (http://www.cals.ru).
2. Кролл, П. Rational Unified Process — это легко: руководство по RUP / П. Кролл, М. Кратчен. М. : КУДИЦ-ОБРАЗ, 2004. 432 с.
3. Тамм, Б. Г. Анализ и моделирование производственных систем / Б. Г. Тамм [и др.]. М.: Финансы и статистика, 1987.
4. Краевский, В. В. Теоретические основы содержания общего среднего образования / под ред. В. В. Краевского, И. Я. Лернера. М. : Педагогика, 1983. 352 с.
