Технологии информационной поддержки жизненного цикла объектов аэрокосмической

105
Каратанов Александр Владимирович

(информационных систем по управлению данными) на базе PLM-технологий;
проведение обследований, анализ

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

Специалист по внедрению PLM/PDM

Приветствуется:
наличие сертификатов по работе и администрированию PLM/PDM систем;
опыт настройки и тестирования интеграции между различными информационными системами;
знание методологий (например, IDEF0/IDEF3/IDEF1X) и владение инструментами моделирования (ARIS);
знание основ программирования на Java.

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

продукции от начала исследования и обоснования разработки до прекращения эксплуатации изделия, применения (хранения) материала [Р 5.605.80-93, ДСТУ 3278-95].

Альтернативное определение
Жизненный цикл изделия — совокупность процессов, выполняемых от момента выявления потребностей общества в определенной продукции до момента удовлетворения этих потребностей и утилизации продукта [Стандарт ИСО 9004-1-94. Управление качеством и элементы системы качества (п.5.1.1)].

*ОАКТ – объекты аэрокосмической техники

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

представлена спиралью качества.

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

Эти виды деятельности (см. рис.):
1 - маркетинг и изучение рынка; 2 - разработка технических требований и проектирование продукции;
3 - технологическая подготовка производства;
4 - материально-техническое снабжение;
5 - производство;
6 - контроль и испытания;
7 - упаковка и хранение;
8 - реализация и распределение (поставка) продукции;
9 - монтаж и эксплуатация;
10 - техническое обслуживание; 11 - утилизация после использования.

Фазы 2, 3, 5, 6, 9, 10 относятся к сфере инженерной деятельности (Engineering);
фазы 1, 4, 7, 8, 11 - к управленческой деятельности (Management).
Engineering – это процесс практической реализации результатов научной деятельности.

входов, выходов, управлений и механизмов реализации функций и задач, т.е.

представлен функциональными схемами стандарта IDEF0 как композиция ICOM-блоков.

В правом нижнем углу блока указывается его имя.
Имя состоит из буквы и числа, которое обозначает положение блока в модели. Например: А21 – означает, что это первый блок декомпозиции второго блока.

Для концептуальной модели имя будет обозначаться так: А-0.

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

А-0

Пример концептуальной модели для процесса проектирования ОАКТ.

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

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

В соответствии со стандартами ДСТУ 3278-95 и ГОСТ Р 15.000-94 необходимо выделить следующие стадии жизненного цикла АТ:
1. Исследование и обоснование разработки – стадия ЖЦ от возникновения замысла до обоснования возможности
и целесообразности создания изделий и материалов.

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

еще не существующего объекта на основе первичного описания этого объекта, или алгоритма его функционирования, или алгоритма процесса.
В процессе разработки при затрате максимум 20..25% времени от всей работы и не более 5..10% средств принимается 75..80% основных решений по проекту (технических и организационных).
В соответствии со стандартами ГОСТ 2.103-68, ДСТУ 3974-2000 и ГОСТ Р 15.201-2000, а также работой Егера «Проектирование самолетов» можем выделить ряд работ, проводимых на стадиях «исследование и обоснование разработки» и «разработка».

Исследование и обоснование разработки – стадия, результатом которой является техническое задание, формулирующее требования к объекту проектирования. Разработку ТЗ предваряют предпроектные исследования, в ходе которых проводятся научно-исследовательские работы (НИР). Этот комплекс работ обычно называют «внешним проектированием».

Разработка включает в себя:
1. Предварительное проектирование – стадия разработки технического предложения , в котором содержатся уточненные требования к объекту проектирования.
2. Эскизное проектирование, на котором происходит определение схемных и конструктивных решений изделия, дающих общее представление о его устройстве и принципах работы, результат – эскизный проект.
3. Техническое проектирование – стадия, позволяющая определить окончательные конструктивные решения, дающие полное представление о конструкции изделия, результат технический проект.

4. Рабочее проектирование – последняя стадия проектирования: разработка полного комплекта конструкторской документации для изготовления и испытания изделия, называемого рабочей конструкторской документацией.
Стадию разработки обычно называют «внутренним проектированием», а вместе с внешним они образуют цикл опытно-конструкторских работ.

определенного КБ.

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

технологию выполнения установленных функций [ГОСТ 34.003-90. Автоматизированные системы. Термины и определения].

Отдельные фазы жизненного цикла продукции обеспечиваются различными автоматизированными системами. Эти системы можно подразделить на два обширных класса:
– системы автоматизации проектирования (САПР, или по определению международных стандартов ECSS «technical information systems - CAD/CAM, analysis packages»);
– системы автоматизации управления (АСУ, или по определению ECSS «management information systems - finance, planning etc.») [ECSS-E-40A, p.7].

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

[ДСТУ 2226-93. Автоматизовані системи. Терміни]:
АСНИ (автоматизированные системы научных исследований) - АС, предназначенная для проведения научных исследований и экспериментов и управления ими.
САПР - АС, предназначенная для автоматизации процесса проектирования изделия, конечным результатом которого является комплект проектно-конструкторской документации, достаточной для изготовления и последующей эксплуатации объекта проектирования.
АСТПП - АС, предназначенная для автоматизации проектирования технологических процессов и подготовки производства.

классификация САПР (рис. выше). Такая классификация является отчасти устаревшей, актуальным

на данный момент является лишь разделение САПР по типам объекта проектирования

В соответствии с классификацией задач проектирования различают программные средства САПР, ориентированные на решение отдельных задач – системы CAE, CAD, CAPP, CAM.

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

(управления предприятиями – АСУП), которые используются на уровнях цеха и

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

обеспечение для управления жизненным циклом продукции.
CAD (Computer Aided Design) –

САПР, предназначенная для создания геометрической модели и конструкторской документации.

CAE (Computer-Aided Engineering) – система автоматизации инженерных расчётов (анализа и симуляции физических процессов, моделирования и оптимизации изделия).

CAM (Computer-Aided Manufacturing) – система технологической подготовки производства изделий, обеспечивающая автоматизацию программирования и управления оборудованием с ЧПУ (числовым программным управлением) или ГАПС (гибких автоматизированных производственных систем).
Русским аналогом термина является АСТПП (автоматизированная система технологической подготовки производства).

Управление цепями поставок (англ. supply chain management, SCM) — управленческая концепция и организационная стратегия, заключающаяся в интегрированном подходе к планированию и управлению всем потоком информации о сырье, материалах, продуктах, услугах, возникающих и преобразующихся в логистических и производственных процессах предприятия, нацеленном на измеримый совокупный экономический эффект (снижение издержек, удовлетворение спроса на конечную продукцию).

жизненного цикла (Continuous Acquisition and Life-Cycle Support).
ERP – система планирования

и управления ресурсами предприятия (Enterprise Resource Planning).

MRP – система планирования производства и требований к материалам (Manufacturing Requirement Planning).

MES – производственные исполнительные системы (Manufacturing Executive System).

PDM – система управления проектными данными (Product Data Management).

S&SM – Sales and Service Management, системы управления реализацией и послепродажным обслуживанием.
SCADA – Supervisory Control And Data Acquisition, АСУТП.
CNC – Computer Numerical Control, ЧПУ.
CPC – Collaborative Product Commerce.

MES, SCM, CRM, ERP, MRP-II – автоматизированные системы управления производством.

SCADA, CNC – автоматизированные системы управления оборудованием и технологическими процессами.

цикла продукции на всех его стадиях, основанная на использовании ЕИП,

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

CALS

analysis and reengineering);
безбумажный обмен данными (paperless data interchange) с использованием электронно-цифровой

подписи (ЭЦП);
системная информационная поддержка ЖЦИ на основе использования единого информационного пространства (ЕИП), обеспечивающая минимизацию затрат в ходе ЖЦ;
информационная интеграция за счет стандартизации информационного описания объектов управления;
разделение программ и данных на основе стандартизации структур данных и интерфейсов доступа к ним, ориентация на готовые коммерческие программно-технические решения (commercial of the shelf), соответствующие требованиям стандартов;
параллельное проектирование (concurrent engineering – параллельный инжиниринг).

создании ЕИП
б

возможностям («по мощности») предполагает выделение трех классов систем – «легких»,

«средних» и «тяжелых».

технической документации – чертежей и технологических карт, или подготовку управляющих

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

Примеры: CAD-системы – AutoCAD (до версии 13), ADEM/CAD (до версии 3), T-FLEX CAD 2D, КОМПАС-График (2D), SprutCAD 2D и др., в последнее время - MechaniCS, ElectriCS, TechnologiCS; CAM-системы – NC Tool, ADEM/NC (до версии 3), T-FLEX ЧПУ 2D и др. CAE-системы – Working Model 2D (анализ механизмов).

Условия эффективного применения:
• несложная продукция;
• разработки в отдельных подразделениях ведутся независимо (т.е. нет необходимости в системе PDM);
• используется традиционная схема документооборота (т.е. нет необходимости в автоматизации делопроизводства);
• документирование производится главным образом на бумажных носителях.

средства как функционального проектирования (CAE), так и конструкторской (CAD) и

технологической (CAM) подготовки производства.
Могут быть реализованы либо как интегрированные пакеты, либо как функционально-независимые программные продукты на основе единой структуры данных (в том числе - в виде набора модулей, разработанных партнерами разработчика головного модуля).
Примеры: CAD-системы – SolidWorks, SolidEdge, Autodesk Mechanical Desktop, ADEM/CAD (от версии 3), T-FLEX CAD 3D, КОМПАС 3D; CAM-системы – SolidCAM, EdgeCAM, ADEM/NC (от версии 3), Гемма 3D, T-FLEX ЧПУ 3D, SprutCAM и др. CAE-системы – Design Space (ANSYS AutoFEA), Visual NASTRAN, CosmosWorks, Dynamic Designer (Motion, Thermal, ...), T-FLEX / ИСПА и др. К системам среднего класса относятся также разработанные в конце 90-х гг. «облегченные» версии мощных систем – Prelude (EUCLID), PT/Products (Pro/Engineer), UG/Creator (Unigraphics).
Условия эффективного применения:
высокотехнологичная продукция средней сложности (например, современная бытовая техника);
предусмотрена постепенная реорганизация системы управления предприятием (т.е. возможна автоматизация делопроизводства и использование систем PDM/TDM);
планируется поэтапное финансирование (т.е. требуется постепенное расширение функций системы).
Системы этой группы по своим возможностям непрерывно приближаются к системам высокой мощности.

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

комплексы инженерного анализа (CAE). Некоторые модули этих систем также являются партнерскими разработками (например, встроенные модули анализа часто являются сокращенными версиями автономных CAE-систем).

Примеры: Интегрированные CAE/CAD/CAM-системы – Unigraphics, Pro/Engineer, CATIA, Euclid (ныне развитие системы прекращено), CADDS-5 (в 1998 г. поглощена PTC), I-DEAS (в 2001 г. поглощена UG). Примыкают к этой группе системы Cimatron, MicroStation. Автономные CAE-системы – ANSYS, NASTRAN, ABAQUS, LS-Dyna, MARC, Star-CD и др.

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

системных сред САПР машиностроения – системы PDM объединяют функции управления

данными и управления процессом проектирования (DesPM).

Система управления проектными данными (PDM – Product/Project Data Management) обеспечивает хранение данных, доступ к ним, защиту информации, управление конфигурацией изделия (ведение версий проекта и внесение изменений), создание спецификаций и т.п. Может быть интегрирована с системой управления процессом проектирования DesPM.

Система управления процессом проектирования (DesPM – Design Process Management) обеспечивает слежение за состоянием проекта, координацию и синхронизацию параллельной работы исполнителей. Обычно включает средства маршрутизации (Workflow) – построения маршрутов прохождения проектных документов (согласование, утверждение и т.п.).

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

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

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

Сложность управления проектными данными обусловлена следующими особенностями САПР [Норенков И.П., Основы автоматизированного проектирования, 2002]:

сборки) требует около 8 Гбайт ОЗУ (для вывода неполной модели

– фюзеляж, одна консоль крыла с двигателем, авионика, шасси – потребовалось 3,6 Гбайт). 32-разрядная архитектура допускает адресацию лишь до 4 Гбайт. Т.е. назрел переход на 64-разрядную архитектуру – версия CATIA для такой техники уже выпущена.
Среди всех PDM-систем только три способны работать с объектом такой сложности, как самолет – ENOVIA, TeamCenter и Windchill. АНТК вынужден вести проект машины сразу в трех CAD-системах: CADDS-5, CATIA (собственные) и Unigraphics (Воронежский завод). К тому же приходится обеспечивать синхронизацию данных между двумя PDM – ENOVIA и Optegra.

[Долгих И.В., АНТК, сентябрь 2005 г.] : модель самолета Ан-148 состоит из 3,5 млн. деталей, из них 65 тыс. оригинальных, в т.ч. 50 тыс. механообрабатываемых.

САПР [Норенков И.П., Основы автоматизированного проектирования, 2002]:

использование систем управления документацией Technical Document Management (TDM) –

документо-ориентированных систем (т.е. базирующихся на структуре документа).
В отличие от них, системы Product Data Management (PDM) базируются на составе изделия, хотя одновременно обеспечивают и управление документацией. Состав функций этих систем постоянно расширяется, появляются их новые подклассы с новыми наименованиями, например:
cPDM – Collaborative Product Definition Management;
cPLM – Collaborative Product Lifecycle Management;
cPLS – Collaborative Product Lifecycle Support;
Это системы, «производные от PDM», но с дополнительными функциями – управление данными в течение всего жизненного цикла изделия при совместной работе разнопрофильных групп пользователей.

Предприятия России, Беларуси, Украины и других стран СНГ используют также следующие системы:

Search компании Интермех (Минск),
T-FLEX DOCs компании Топ Системы,
ЛОЦМАН:PLM компании АСКОН,
Lotsia PDM Plus компании Лоция Софт,
SWR-PDM компании SolidWorks-Russia,
PDM STEP Suite Центра прикладной логистики,
APPIUS PDM компании APPIUS
и некоторые другие.

К числу наиболее распространенных PDM-систем относятся:
ENOVIA – разработка компаний IBM и Dassault Systemes,
Teamcenter компании Unigraphics Solutions, ныне Siemens PLM,
Windchill и Pro/Intralink компании Parametric Technology Corp.,
SmarTeam компании Smart Solutions (дочернее предприятие компании Dassault Systemes)
PDMWorks компании SolidWorks

(Configuration Management):
1.1) генерация спецификаций (аналогична функциям генераторов спецификаций CAD-систем);
1.2)

синхронизация данных CAD-PDM, т.е. поддержание соответствия межу данными CAD и PDM (отслеживание ссылок), что означает:
1.2.1) доступ к данным CAD из PDM и к данным PDM из CAD;
1.2.2) синхронизация атрибутов (установление соответствия: например, если в CAD задано «M =   V», то после изменения размеров модели в CAD-системе должно автоматически измениться значение атрибута «масса» в PDM).
1.3) формирование состава изделия (исполнений, версий):

а) выбор свойства в CAD-системе;

Синхронизация атрибутов SmarTeam–SolidWorks

б) выбор ответного атрибута в PDM-системе.

Пример: Search – отображение состава версий (исполнений) изделия

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

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

Желтые кружки – изделия, для которых указаны допустимые заменители, зеленые кружки – сами допустимые заменители. Управление заменами может быть выполнено непосредственно из схемы.

пример: система APPIUS-PDM, модуль Конфигуратор: правила управления структурой экземпляра изделия на основе И-ИЛИ-графа; если модель содержит вычисляемые переменные, для них можно задать выражения или формулы; возможна фильтрация списка значений переменных – например, исключить значение «ткань» для абажура, если
мощность лампочки
более 100 Вт.

Пример: Search обеспечивает работу с допустимыми заменами составных частей изделия в режимах: один-на-один; один-на-много; много-на-один и много-на-много.

(например, подсборка АХ.101.7 с № от … до … входит

в сборку АХ.101 с № от … до …).

SmarTeam – навигация с отображением дерева структуры, моделей и чертежей

Teamcenter Engineering – применяемость по дате

1.4) навигация по структуре изделия.

Search – навигация с отображением структуры в виде схемы; из схемы возможно открытие моделей и чертежей

сравнение по дереву структуры (в отчете сопоставление количества компонентов для

разных исполнений)

Teamcenter Engineering – сравнение вариантов состава изделия

1.6) управление изменениями:
1.6.1) автоматизация процессов внесения изменений;
правила (алгоритмы) проведения изменений могут быть описаны с различной степенью детализации – см. примеры:

б) «графическая история» версий

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

3 типа документов об изменениях по ГОСТ – предложение об изменении, предварительное извещение, извещение об изменении; ведется история изменений

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

PDM STEP Suite – автоматическое уведомление об изменении

Teamcenter Engineering – типовые опции визуализации

(в том числе с помощью средств их автоматического распознавания), их

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

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

Lotsia PDM, модуль LS Flow – шаблон утверждения договора

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

документов и содержащихся в них директивах и рекомендациях;
В различных

PDM-системах состав статусов и их наименования могут несколько различаться, например: рабочий, принятый, архивный, готов к выпуску и др. Например, в системе SmarTeam документ может находиться в одном из пяти состояний: “У автора”, “У руководителя”, “На изменении”, “Утвержден” и “В хранилище”.

SmarTeam – настройка взаимодействия с ERP-системой SAP R/3 (Integration Manager, Attribute Manager)

Lotsia PLM – контроль исполнения и присвоение статуса документам

2.7) контроль исполнения предписываемых документами действий (функция может быть реализована общей подсистемой Workflow);

2.8) разграничение прав доступа к документам;
 2.9) автоматическое архивирование чертежей и связанных с ними документов;
2.10) интерфейсы к системам ERP (АСУП).

Пример: изменение статуса документа в системе SmarTeam

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

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

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

Шаблоны процессов в модуле SmartFlow системы SmarTeam

Особенность проектирования и производства сложной техники – кооперация большого числа предприятий-изготовителей, деятельность которых должна быть строго согласована. Например, в изготовлении самолета F22 Raptor участвовали три основных подрядчика (Boeing, Pratt & Whitney, Lockheed Martin Aeronautics) и около 1000 субподрядчиков и поставщиков из 44 штатов. В этих условиях жизненный цикл изделия рассматривается как совокупность ЖЦ конечного продукта и ЖЦ входящих в его состав компонентов.

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

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

Teamcenter – пример цепочки поставок и календарного графика

4. Взаимодействие с поставщиками (управление цепочками поставок – Supply Chain Management, SCM):
4.1) оптимизация комплектации: выбор состава комплектующих изделий (например, по минимальной стоимости при ограничениях на уровень качества либо по наивысшему качеству при ограничениях на стоимость и т.п.); выбор поставщиков; планирование закупок;
4.2) поддержка совместной работы с поставщиками и партнерами по обеспечению изделия комплектующими: разработка и контроль календарных планов разработки, изготовления и поставки; оценка уровня запасов по всем комплектующим изделиям; принятие решений о необходимости пополнения запасов; подготовка заявок; контроль качества поставок.

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

5.1) обеспечение удовлетворения требований заказчиков по каждому экземпляру изделия;

содержание и объем этих работ определяется так называемыми стратегиями позиционирования изделий, в частности, такими как:
сборка на заказ (ATO – Assembly-To-Order) из типовых компонентов: изготовление продукции начинается только после получения заказа.
разработка на заказ (ETO – Engineering-To-Order): производственный цикл начинается после получения заказа с конструкторской подготовки производства.
5.2) поддержка взаимодействия с заказчиками: сведения о клиентах, история отношений с ними, маркетинг, реклама (семинары, мастер-классы, тест-драйвы), продажа, доставка, обслуживание продукции и др.
5.3) управление сервисом: обработка жалоб, работа с обращениями клиентов и др.
К этой группе функций иногда относят аналитические задачи поиска статистических закономерностей в данных о клиентах для выработки наиболее эффективной стратегии маркетинга, продаж, обслуживания клиентов и т. д.

6. Управление жизненным циклом (Lifecycle Management):
6.1) создание банка формализованных описаний этапов жизненного цикла изделий;
6.2) разграничение полномочий и уровней доступа исполнителей по этапам ЖЦ изделия;
6.3) мониторинг с детализацией до этапа, как правило, во взаимодействии с Workflow.

Формат JT как основа единой интероперабельной платформы разработки // CAD/CAM/CAE

Observer, 2006, # 6, 7]:
«Современные технологии позволяют осуществлять проектирование и поддержку изделий в глобальном масштабе. Но для того, чтобы делать это, им нужны эффективные средства для обмена проектными данными между существенно отличающимися друг от друга программными системами. Проблему интероперабельности многие крупные производители стараются решить, заставляя своих поставщиков применять те же системы проектирования, что и у них. Это ограничивает свободу поставщиков выбирать инструменты, наиболее удобные для их вида деятельности… Вместе с тем, когда все пользуются разными системами, это потенциально увеличивает затраты всех сторон.
Современная тенденция – использование стандартов обмена информацией, позволяющих компаниям управлять всеми аспектами ЖЦИ независимо от конкретных программных решений, применяемых ими».

/См. выше/ Системы проектирования, созданные разными разработчиками, используют свои собственные форматы данных – например, в системе Unigraphics версии 14 было предусмотрено свыше 100 различных форматов, из них геометрических и графических – около 20. Поэтому в машиностроительных САПР основное внимание уделяется обмену геометрическими данными.

В качестве форматов обмена используются:
– собственные форматы САПР;
– форматы «геометрических ядер» САПР (систем геометрического моделирования);
– стандартные («нейтральные») форматы.

https://en.wikipedia.org/wiki/Comparison_of_computer-aided_design_editors - сравнение различных САПР.

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

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

Сравнение объемов – одна и та же модель Body(Sprinkler).sldprt сохранена в различных форматах:
*.sldprt - 537,088 байт
*.x_t (Parasolid) - 279,092
*.sat (ACIS) - 809,638
*.iges - 1,920,276
*.step - 1,347,952
*.stl (bin) - 912,284
*.stl (ASCII) - 4,863,985

Этот способ обмена подвергается критике с момента появления первых САПР за «неэкономность», но сохраняется в современных CAD/CAM-системах из-за популярности ряда форматов.

Примеры
DWG (от англ. drawing — чертеж) — бинарный формат файла, используемый для хранения двухмерных (2D) и трёхмерных (3D) проектных данных и метаданных (AutoCAD, nanoCAD, IntelliCAD, Caddie). Форматы .dws («drawing standards» — стандарты чертежа), .dwt («drawing template» — шаблон чертежа) также являются форматом DWG.
SLDPRT – 3D формат изображения, используемый CAD программным обеспечением SolidWorks, содержит 3D-объект или «часть», которые могут быть объединены с другими частями в единую сборку (.SLDASM файл). 

ACIS – разработка компании Spatial Technologies. Формат SAT первоначально предназначался

для внутреннего представления данных в системах, основанных на ядре ACIS, но по мере роста популярности этих систем превратился в «фактический стандарт» межсистемного обмена.
Формат представляет как геометрию, так и топологию объекта, однако не содержит специальных средств передачи инженерных данных. Тип файла - текстовый.

● Формат XMT (моделлер Parasolid)
Геометрический моделлер Parasolid – разработка компании Shape Data, ныне собственность Unigraphics Solutions. Считается наиболее быстродействующим ядром.
Типы файлов геометрических моделей - текстовый XMT_TXT (.x_t) и двоичный XMT_BIN (.x_b). Двоичный компактнее, но поддерживается не всеми системами.
Структура обменного файла подобна файлу формата *.SAT, но вместо наименований объектов используются их коды.

Наиболее распространенные моделлеры – ACIS и Parasolid, на базе которых создано большое число CAD/CAM/CAE-систем.

Особенности реализации XT-обмена в CAD-системах
SolidWorks 2001: Импортирует только поверхности и солиды с учетом цвета, кривые и точки игнорируются. Возможно сокращение порядка построения сборки до одного уровня, т.е. без сохранения иерархии.
Пример: Передача модели из Unigraphics v.17 в SolidWorks 2003 в формате X_T (Parasolid) – структура модели не передается, в дереве модели единственный элемент «Imported1», редактирование которого невозможно.

Пример: фрагмент файла формата SAT
500 0 1 0
37 SolidWorks(1999207)-Sat-Convertor-2.0 11 ACIS 5.0 NT 24 Tue Mar 18 11:05:22 2003 1 9.9999999999999995e-007 1e-010
-0 body $-1 $1 $-1 $2 #
-1 lump $-1 $-1 $3 $0 #
-2 transform $-1 . . . no_rotate no_reflect no_shear #
-3 shell $-1 $-1 $-1 $4 $-1 $1 #
-4 face $-1 $5 $6 $3 $-1 $7 reversed single #
-5 face $-1 $8 $9 $3 $-1 $10 forward single #
-6 loop $-1 $-1 $11 $4 #
-7 torus-surface $-1 0 0.020320000000000001 0 0 1 0 0.0068580000000000004 0.00050799999999999999 0 0 1 forward_v I I I I #
-8 face $-1 $12 $13 $3 $-1 $14 forward single #
-9 loop $-1 $-1 $15 $5 #
-10 cone-surface $-1 0 0 0 0 -1 0 0 0 -0.0063500000000000006 1 I I 0 1 1 forward I I I I #
-11 coedge $-1 $16 $17 $18 $19 reversed $6 $-1 #
. . .
-4572 point $-1 0.028187878777263982 0.060237648093274997 0.012954 #
-4573 point $-1 0.025835217222116777 0.05401168498717502 0.012954 #
-4574 straight-curve $-1 0.038952950820528055 0.05876422667396719 0.012954 -0.9063077870366526 -0.422618261740694 0 I I #
-4575 ellipse-curve $-1 0 0.025654 0 0 -1 0 0 0 -0.003936999999999987 1 l l #
End-of-ACIS-data

Пример: фрагмент файла формата XMT_TXT
**ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz**************************
**PARASOLID !"#$%&'()*+,-./:;<=>?@[\]^_`{|}~0123456789**************************
**PART1;
MC=x86;
MC_MODEL=INTEL_PENTIUM;
MC_ID=unknown;
OS=unknown;
OS_RELEASE=unknown;
FRU=Top Systems, Ltd.;
APPL=T-FLEX Parametric Pro v.7.1;
SITE=Moscow, Russia;
USER=unknown;
FORMAT=text;
GUISE=transmit;
KEY=D:\T-Flex Ptoject\kulachok4_5.xmt_txt;
FILE=D:\T-Flex Ptoject\kulachok4_5.xmt_txt;
DATE=9-okt-2002;
**PART2;
SCH=SCH_1400153_14000;
USFLD_SIZE=7;
**PART3;
**END_OF_HEADER*****************************************************************
T51 : TRANSMIT FILE created by modeller version 140015317 SCH_1300000_130067 12
1 1938 0 2 0 0 0 0 1e3 1e-8 0 0 3 1 0 1 1 4 5 6 7 8 9 10 0 0 0 0 0 0 26918 70 2
0 1 0 0 4 1 20 4 11 11 1 T0 0 0 0 0 0 0 13 4 55 0 1 0 12 0 0 13 0 -1409286143 0
0 9568260 704643073 704643073 26920 50 5 54 0 14 15 0 16 +.013 -.01146812862004
59 .00803007010891465 0 -.573576436351046 -.819152044288992 0 .819152044288992 -
.573576436351046 0 0 0 0 0 0 0 31 6 1906 0 9 17 0 0 +-.014 .01532212414040495 .0
0424764779919666 1 0 0 0 0 -1 .0054 0 0 0 0 0 0 0 29 7 1885 0 10 18 0 .021 .0099
2837233231248 .003987952862028525 0 0 0 0 0 0 0 19 8 16 0 1 13 0 19 V0 0 0 0 0 0
0 16 9 1879 0 ?20 0 21 6 0 0 1 -1426063113 0 0 12582912 822083593 822083593 273
40 18 10 1883 . . .
. . .
.02100000000631975 .0002738027498727335 .02532163580
85527 .02099999999827665 -.00854789293776554 .02281559109971835 .021000000000315
55 -.01492119296906722 .01880806057999085 .02100000000009745 -.01800932737913655
.01512269086378685 .0210000000000038 -.01933612201465225 .0135392983944022 0 0
0 0 0 0 0 127 2 398 4 4 0 0 0 0 0 0 0 127 9 399 4 3 1 1 1 1 1 1 4 0 0 0 0 0 0 0
128 2 400 0 1 0 0 0 0 0 0 0 128 9 401 -.1231898174900154 0 .1141363617040468 .1
987452590214045 .2885244392781275 .47758790453496 .665737862354071 .856386687820
8 1 0 0 0 0 0 0 0 141 395 316 402 150 147 0 0 0 0 0 0 0 141 396 231 150 402 147
0 0 0 0 0 0 0 141 402 310 396 395 147 0 0 0 0 0 0 0 81 1 101 1348 403 99 0 0 88
0 0 0 0 0 0 0 0 0 80 1 403 404 405 9000 0 0 0 0 3 5 0 0 0 FFFFFFFTFFFFFF1 0 0 0
0 0 0 0 81 1 88 1342 403 86 0 0 0 101 0 0 0 0 0 0 0 0 79 14 405 TF_Start_Point0
0 0 0 0 0 0 19 13 56 0 1 0 8 4 S0 0 0 0 0 0 0 141 16 208 16 16 5 0 0 0 0 0 0 0
74 20 11 1 0 101 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0

Особенности реализации SAT-обмена в CAD-системах
Не все системы, основанные на ACIS, могут импортировать все его объекты: например, AutoCAD R14, 2000 и Autodesk Mechanical Desktop – кривые читаются как тела, поэтому сплайны требуется разбивать; Autodesk Inventor читает только солиды; SolidWorks 99 – только поверхности и солиды и т.д. Во всех вариантах узловые точки кривых и поверхностей фиксируются, замкнутые кривые рассекаются.

DXF разработан компанией Autodesk для системы AutoCAD, специально как формат

обмена, в том числе между разными версиями системы, в отличие от внутреннего формата представления данных DWG. Использовался также в прикладных программах проектирования для документирования результатов.
Официальным стандартом до последнего времени не является, но давно признан «стандартом де-факто». Первоначально включал только 2D объекты, но с переходом на ядро ACIS (с версии AutoCAD R14) дополнен объектами 3D-геометрии.

● Формат IGES – Initial Graphics Exchange Specification
Первая версия разработана в 1980 г., утверждена в качестве национального стандарта США (ANSI) в 1981 г. как предполагаемая основа CALS-технологии (военная программа Mil-D-28000A).

 Особенности реализации IGES-обмена в CAD-системах
Несмотря на стандартизацию структуры и общих правил описания объектов, каждая система имеет свои особенности импорта и экспорта файлов IGES. Для большинства объектов существует не единственная возможность описания, поэтому главное различие между реализациями формата - способы представления формы объектов.
Поэтому наиболее развитые моделлеры содержат средства настройки модулей импорта/экспорта на конкретную реализацию формата. Описание этих средств обычно приведено в разделе «Импорт/Экспорт» руководства или файла справки.
AutoCAD R13, R14: дополнительная программа IGESTRAN поддерживает только точки, кривые и поверхности.
SolidWorks 2001:
Импорт IGES – настраивается реакция системы на ошибки чтения (невозможность импорта, дефекты на поверхности и др.), например - «сшить в твердое тело», «создать справочные поверхности» и др.
Экспорт IGES – не экспортируются объекты типов Граничная поверхность, Линейчатая поверхность, Поверхность параметрического сплайна и др.; настраивается способ представления поверхностей (как отсеченные поверхности, или как B-сплайны, или как параметрические сплайны), экспорт объектов эскиза, сохранение всех компонентов сборки в одном файле.

Пример: фрагмент файла формата IGES
SolidWorks IGES FILE using analytic representation for surfaces S 1
1H,,1H;,6Hdetal1,25HC:\Проект\IGES\detal1.IGS,39HSolidWorks 99 by SolidWG 1
orks Corporation,11HVersion 3.0,32,308,15,308,15,6Hdetal1,1.,2,2HMM,50, G 2
0.125,14H1000425.041337,1E-008,500.,6HАндрей,,10,0,; G 3
314 1 0 0 0 00010200D 1
314 0 0 1 0 0D 2
128 2 0 0 0 01010000D 3
128 0 0 12 0 0D 4
Код 128 - Rational B-Spline Surface, 2 - номер 1-й строки записи раздела параметров,
3 - обратная ссылка из записи раздела параметров .
126 14 0 0 0 01010500D 5
126 0 0 2 0 0D 6
... ... ... ...
142 1981 0 0 0 00010500D 1091
142 0 0 1 0 0D 1092
144 1982 0 0 0 00000000D 1093
144 0 -1065 1 0 0D 1094
314,75.2941176470588,75.2941176470588,75.2941176470588,; 1P 1
128,3,3,3,3,0,0,0,0,0,0.,0.,0.,0.,1.,1.,1.,1.,0.,0.,0.,0.,1., 3P 2
1.,1.,1.,1.,0.804737854124365,0.804737854124365,1., 3P 3
0.804737854124363,0.647603013860686,0.647603013860686, 3P 4
0.804737854124363,0.804737854124363,0.647603013860686, 3P 5
0.647603013860686,0.804737854124363,1.,0.804737854124365, 3P 6
0.804737854124365,1.,-50.,-10.,0.,-61.715728753,-10.,0.,-70., 3P 7
-18.284271247,0.,-70.,-30.,0.,-50.,-10.,29.289321881, 3P 8
-61.715728753,-10.,36.152236891,-70.,-18.284271247, 3P 9
41.005050634,-70.,-30.,41.005050634,-29.289321881,-10.,50., 3P 10
-36.152236891,-10.,61.715728753,-41.005050634,-18.284271247, 3P 11
70.,-41.005050634,-30.,70.,0.,-10.,50.,0.,-10.,61.715728753,0., 3P 12
-18.284271247,70.,0.,-30.,70.,0.,1.,0.,1.; 3P 13
3 - номер 1-й строки записи раздела вхождений, описывающей данный объект,
2 - номер 1-й строки записи раздела параметров для данного объекта .
126,1,1,1,0,1,0,0.,0.,1.,1.,1.,1.,1.,0.,0.,1.,1.,0.,0.,1.,0., 5P 14
0.,1.; 5P 15
...
142,1,1071,1087,1089,1; 1091P 1981
144,1071,1,0,1091; 1093P 1982
S 1G 3D 1094P 1982 T 1

Популярность формата DWG, первоначально считавшегося сугубо внутренним для продуктов Autodesk и старательно оберегаемого компанией, привела к тому, что и он становится одной из популярных форм обмена проектными данными. Силами ряда софтверных компаний, объединившихся в альянс Open DWG Alliance (ныне Open Design Alliance), формат был расшифрован и стал доступен членам альянса в виде библиотеки стандартных процедур.

в системы быстрого прототипирования, однако может восприниматься некоторыми CAE/CAD/CAM-системами. В

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

● Формат STEP – Standard for Exchange of Product model data
Комплекс стандартов STEP (Standard for Exchange of Product model data, ISO 10303) разрабатывается с целью дать нейтральный механизм описания данных о продукте (изделии) на всех стадиях его ЖЦ, не зависящий от конкретной информационной системы. Некоторые стандарты комплекса STEP будут рассмотрены позже.
Область, охватываемая стандартами STEP, выходит далеко за рамки обмена геометрическими данными, однако существующие CAE/CAD/CAM-системы используют преимущественно геометрическое подмножество стандарта. Поэтому эту его часть имеет смысл рассмотреть вместе с другими стандартами обмена проектными данными.
Для обеспечения возможности единообразного описания изделий в различных прикладных областях предполагается, что информационные модели (в терминах стандарта «прикладные протоколы») создаются на базе типовых блоков («интегрированных ресурсов»). Это общие для различных приложений компоненты (building blocks), используемые в моделях приложений. Например, описания геометрических объектов в виде поверхностей Безье или B-сплайнов могут использоваться в разных приложениях, поэтому такие описания отнесены к интегрированным ресурсам. Прикладные протоколы содержат ссылки на объекты, определенные стандартами этой группы.
Одним из таких блоков служат средства описания геометрии технических объектов. Основная часть их описана в 42-м томе стандарта – ISO 10303, part 42: Geometric and topological representation (Представление геометрии и топологии).

 Особенности реализации STL-обмена
SolidWorks 99: Импорт STL – не предусмотрен. Экспорт STL – возможен для отдельных деталей и сборок; настраиваются тип файла (ASCII/Bin), необходимость проверки интерфренции для сборок, сохранение всех компонентов в одном файле, качество (точность).

Пример: фрагмент файла формата STL
solid ascii
facet normal 0.766047 -0.642784 2.00811e-008
outer loop
vertex -120.661 -24.3159 -64.719
vertex -120.661 -24.3159 -79.719
vertex -119.545 -22.9857 -79.719
endloop
endfacet
facet normal . . .
. . .
endfacet
end solid

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

них.
AutoCAD: дополнительные модули IGESTRAN и AutoCAD STEP.
SolidWorks (СГ 2-2003): Штатный транслятор – XchangeWorks.
Опциональные трансляторы:
CAD porter (CATIA, Pro/Engineer, I-DEAS).
PolyTrans (DXF, IGES, STL, 3ds, DirectX, ...) – встроенная версия автономного транслятора фирмы Okino Computer Graphics.
CADfix – встроенная версия автономного транслятора с возможностями «лечения» моделей (восстановления сбойной геометрии).
FormatWorks – трансляция и «лечение» моделей.

● Автономные конверторы.
Конверторы 2D геометрии: Пример – CAMCAD. Предназначен преимущественно для обмена между САПР электроники, но поддерживает и некоторые форматы общетехнического назначения.
Имеются функции редактирования геометрии (Edit), добавления слоев, элементов, примитивов (Add), смены шрифта и начала координат (Settings) и др.
Конверторы 3D моделей: примерами могут служить трансляторы PolyTrans, Interchange (SAT, IGES, 3ds, Softimage, Lightwave, …), 3DVision (IGES, VDA-FS, STL, STEP, CATIA, Unigraphics, CADDS5, Parasolid) и др.

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

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

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

роли автоматизированных систем распределяются следующим образом :
cPDM обеспечивает единое

информационное пространство;
CAE/CAD/CAM автоматизируют проектирование и подготовку производства;
MRP планирует ресурсы и управляет производством;
ERP управляет всей деятельностью предприятия;
CRM управляет взаимоотношениями с заказчиками;
SCM управляет цепочками поставок;
cPC (Collaborative Product Commerce) управляет ведением совместного бизнеса.

Системы управления имеют свою историю развития и свои поколения. С 1990 г. сменились несколько концепций: MRP  MRP II  ERP  ERP II.

сборочных единиц, включая возможность создания собственных библиотек элементов конструкции (из-за

ограничений в передаче параметризованной геометрии требуется подключение БД к CAD-системе до трансляции моделей);

CAE-системы нуждаются в данных о физических свойствах конструкционных материалов и рабочих сред;

Возможности обмена негеометрическими данными в современных системах проектирования весьма ограничены и представлены интерфейсами с реляционными БД общего назначения. Например, AutoCAD 2000 может взаимодействовать БД MS Access, dBase, Paradox, Oracle; SolidWorks может импортировать данные формата *.XLS; Unigraphics v.17 допускает импорт/экспорт файлов Excel, Lotus и др. Поэтому более сложные задачи взаимодействия с базами данных обычно и возлагаются на системы PDM (см. выше).

Не менее важна совместимость САПР с существующими базами данных нормативно-справочного характера:

CAPP- и CAM-системы требуют использования таблиц характеристик оборудования, инструментов и приспособлений, технологических режимов, припусков; кроме того, необходимо использование ряда характеристик объекта производства, зачастую отсутствующих в модели CAD-системы – сведений о местной термообработке, покрытиях, особых указаниях («детали … обработать совместно»).

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

задачи управления производством. Это определяет необходимость взаимодействия САПР/АСТПП с соответствующими

системами управления. Поэтому локальные системы автоматизации (АСНИ, САПР, АСТПП, АСУТП и др.) объединяются в корпоративную информационную систему (КИнС), координирующие функции в которой возлагаются на систему управления предприятием (АСУП, или согласно современной терминологии – ERP, Enterprise Resource Planning).

Взаимо- действие САПР с АСУП

. Предприятиям с оборотом менее 10 млн. долл. в год

не следует ожидать повышения эффективности производства от внедрения систем класса SAP R/3 (см. график).
Характер этой зависимости объясняется влиянием следующих факторов:
– внедрение систем такого уровня требует крупных инвестиций на начальных этапах (3.5 – 5 млн. долл.);
– на эксплуатацию и развитие ERP-системы компания не может расходовать более 5-7% от своего годового оборота;
– полное использование возможностей систем требует приобретения дополнительных программных продуктов (CAD/CAM, SCADA и др.).

Современные системы управления предприятиями ERP (Enterprise Resource Planning), в отличие от систем MRP, предназначены для интеграции всех, а не только производственных, процессов предприятия (включая его материально-техническое и финансовое обеспечение, планирование, регулирование и т.п.).

Наиболее мощные зарубежные системы (SAP R/3, BAAN) отличаются рядом особенностей, существенно снижающих их эффективность в условиях российской и украинской промышленности:
– любой подвергаемый обработке объект от материала до готовой продукции (а также средства технологического оснащения) рассматривается как самостоятельное изделие; это затрудняет структурирование информации и требует ввода больших объемов данных о фиктивных изделиях;
– при заполнении технологических маршрутов требуется указание конкретного номера станка, который технологу неизвестен, т.к. технолог не занимается распределением деталей по рабочим местам;
– отсутствует деление работ по разрядам, что не позволяет дифференцировать расценки на операции по сложности работ (такой документ, как наряд, на Западе неизвестен);
– недостаточно полно реализованы функции управления на уровне цеха.

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

жизненного цикла.

Виды моделей жизненного цикла
Каскадная модель.
V-образная модель.
Спиральная модель.
Итеративная модель

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

прошедшей в 1968 г. конференции NATO по вопросам науки и техники, где рассматривались подобные вопросы, и разделяет процесс создания ПО на последовательные этапы (рис. 1).
Каскадная модель подразумевает, что переход от одной фазы разработки к другой происходит только после полного и успешного завершения предыдущей фазы, и что переходов назад либо вперёд или перекрытия фаз – не происходит.
Каскадный модель используется при разработке ПО, для которого можно полно и четко сформулировать все требования. Учитывая современные реалии, фактически каскадная модель не используется при разработке ПО, по крайней мере, в чистом виде.

Каскадная модель (модель «Водопад») – модель жизненного цикла ПО, в которой процесс разработки выглядит как поток, последовательно проходящий стадии анализа требований, проектирования, реализации, тестирования, сопровождения (внедрения и эксплуатации).

Рисунок 1 – Стадии жизненного цикла в каскадной модели

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

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

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

Рисунок 1.2 – Стадии жизненного цикла в модифицированной каскадной модели

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

модели, а название – V-образная, или шарнирная – появилось из-за

ее специфического графического представления (рис. 2).
V-образная модель дала возможность значительно повысить качество ПО за счет своей ориентации на тестирование, а также во многом разрешила проблему соответствия созданного продукта выдвигаемым требованиям благодаря процедурам верификации и аттестации на ранних стадиях разработки.
 Однако в целом V-образная модель является всего лишь модификацией каскадной и обладает многими ее недостатками. В частности, и та и другая слабо приспособлены к возможным изменениям требований заказчика. Если процесс разработки занимает продолжительное время (иногда до нескольких лет), то полученный в результате продукт может оказаться фактически ненужным заказчику, поскольку его потребности существенно изменились.

V-Model – вариация каскадной модели жизненного цикла ПО, в которой задачи разработки идут сверху вниз по левой стороне буквы V, а задачи тестирования — вверх по правой стороне буквы V.

Dual Vee Model – вариация V-модели жизненного цикла ПО, которая используется для проектирования нескольких взаимосвязанных систем (рис 2.1).










Рис. 2.1. Dual Vee Model

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

является объединением двух моделей: каскадной и на основе создания прототипов (см. прим).

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

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

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

происходит лишь на последнем витке спирали по обычной каскадной модели,

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

Спиральная модель Боэма сфокусирована на проектировании.

цикла ПО, в которой выполнение работ осуществляется параллельно с непрерывным

анализом полученных результатов и корректировкой предыдущих этапов работы.

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

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

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

счет Министерства обороны США и является структурной единицей Университета Карнеги-Меллона.

Первая официальная версия стандарта вышла в 1993 г., хотя работы над ним начались гораздо раньше – основные его положения были опубликованы еще в 1986 г. Успех CMM предопределило несколько факторов. Этот стандарт был одним из первых, изначально учитывающих специфику создания ПО. Он оказался достаточно прост и прозрачен как для понимания, так и для использования, и регламентировал, "что", а не "как" делать, а потому подходил для различных моделей жизненного цикла, методологий разработки и не накладывал каких-либо ограничений на стандарты документирования, инструментарий, среду и языки, применяемые в проектах. И, пожалуй, основным фактором, предопределившим популярность CMM, явилось сотрудничество SEI с Министерством обороны США, что де-факто означало использование стандарта при реализации проектов по заказу этого ведомства.

Модель CMM (табл. 1) предусматривает пять уровней зрелости, каждому из которых соответствуют определенные ключевые области процессов (Key Process Areas, KPA).

Capability Maturity Model (CMM) – модель оценки уровня зрелости процессов разработки вместе с его производными.

Capability Maturity Model Integrated (CMMI) – Интегрированная модель оценки уровня

зрелости процессов разработки. Стандарт CMMI изначально создавался таким образом, чтобы объединить существующие варианты CMM и исключить какие-либо противоречия при его практическом применении в различных сферах деятельности высокотехнологичных компаний.
 
Для того чтобы устранить необходимость "выравнивания" процессов организации и быть более приспособленным к ее бизнес-потребностям, а не наоборот, стандарт CMMI имеет две формы представления – классическую, многоуровневую, соответствующую CMM, и новую, непрерывную. Непрерывная форма представления рассматривает не уровни зрелости (Maturity Levels), а уровни возможностей (Capability Levels), которые оцениваются для отдельных областей процессов (Process Areas, PA). В табл. 2 дано соответствие уровней зрелости стандарта CMM, а также уровней зрелости многоуровневого представления CMMI и уровней возможностей непрерывного представления CMMI.

SEI отказывается от CMM и взамен активно продвигает CMMI, обещая ужесточить контроль за процессом сертификации, сократить затраты на него и сделать его более привлекательным для небольших организаций; обеспечивая совместимость со стандартами ISO. Однако факт остается фактом: в современных условиях наличие сертификата определенного уровня CMM/CMMI не является таким значимым фактором, как несколько лет назад, и принимается без дополнительных вопросов разве что в проектах, выполняемых по государственному заказу.
 
Стандарт ISO/IEC 15504 предназначен для оценки процесса разработки информационных систем, в частности, ПО. Он изначально был спроектирован таким образом, чтобы в значительной степени соответствовать существующим в отрасли стандартам оценки процесса создания ПО. Именно это требование определило схожесть стандарта с основными принципами CMM/CMMI. Его текущая версия, датированная 2004 г., предусматривает шесть уровней возможностей (от нулевого до пятого), которые соответствуют уровням возможностей непрерывного представления стандарта CMMI.

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

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

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

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

Методика – это конкретное воплощение метода в виде частной его реализации при решении конкретной научной или практической задачи; совокупность конкретных практических приемов выполнения чего-либо.

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

ПО. К существующей классификации в зависимости от используемой в ней

модели жизненного цикла (см. выше) добавилась более общая классификация на прогнозируемы и адаптивные методологии.

Прогнозируемые (предикативные) методологии фокусируются на детальном планировании будущего. Известны запланированные задачи и ресурсы на весь срок проекта. Команда с трудом реагирует на возможные изменения. План оптимизирован исходя из состава работ и существующих требований. Изменение требований может привести к существенному изменению плана, а также дизайна проекта. Часто создается специальный комитет по "управлению изменениями" (change control board) чтобы в проекте учитывались только самые важные требования (ГОСТ 19, 32).
 
Адаптивные методологии или, как их чаще называют, гибкие методологии разработки (англ. Agile software development, agile-методы) – серия подходов к разработке ПО, ориентированных на использование интерактивной разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля.
Эти методологии нацелены на преодоление ожидаемой неполноты требований и их постоянного изменения. Когда меняются требования, команда разработчиков тоже меняется. Команда, участвующая в адаптивной разработке, с трудом может предсказать будущее проекта. Существует точный план лишь на ближайшее время. Более удаленные во времени планы существуют лишь как декларации о целях проекта, ожидаемых затратах и результатах.
Существует несколько методик, относящихся к классу гибких методологий разработки, в частности: Scrum, Crystal, Extreme Programming, Adaptive Software Development, DSDM, Feature Driven Development, Lean software development.
Применяется как эффективная практика организации труда небольших групп (которые делают однородную творческую работу) в объединении с их управлением комбинированным (либеральным и демократическим) методом.
Большинство гибких методологий нацелены на минимизацию рисков путём сведения разработки к серии коротких циклов, называемых итерациями, которые обычно длятся две-три недели.
Agile-методы делают упор на непосредственное общение лицом к лицу. Большинство agile-команд расположены в одном офисе. Основной метрикой agile-методов является рабочий продукт. Отдавая предпочтение непосредственному общению, agile-методы уменьшают объём письменной документации по сравнению с другими методами.

которая предполагает деление проекта на итерации (спринты) и проведение ежедневных

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

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

0. Разработка Product Baclog.
Требования к ПО разрабатывает Product Owner (представитель интересов конечного пользователя).
1. Планирование спринта (4-8 часов).
Перед каждой итерацией (обычно продолжительностью – 1 месяц) выбирается список функций системы, которые планируется реализовать в течение следующего спринта (на каждую функцию не более 12 часов / суток).
2. Ежедневное совещание (scrum (скрам), 15-20 минут).
В течение совещания каждый член команды (размер команды: 3-9 человек) отвечает на 3 вопроса:
– что я сделал с момента прошлой встречи для того, чтобы достигнуть Цели Спринта?
– что я сделаю сегодня для того, чтобы достичь Цели Спринта?
– вижу ли я препятствия, которые могли бы затруднить достижение Цели Спринта?
3. Скрам над скрамом.
Проводиться после скрама в случае распределенной разработки продукта. Объединенное совещание нескольких групп разработчиков сфокусированное на общих областях и взаимной интеграции. Вопросы те же, что и на скраме (с заменой «я» на «наша команда»), плюс еще один вопрос:
– нужно ли другой команде сделать что-то из задач вашей команды?
4. Обзор итогов спринта (до 4 часов).
Проводится в конце спринта. Команда демонстрирует прирост функциональности продукта всем заинтересованным лицам.
5. Ретроспективное совещание (1-3 часа).
Проводится в конце спринта. Члены команды высказывают своё мнение о прошедшем спринте и отвечают на два основных вопроса:
– что было сделано хорошо в прошедшем спринте?
– что надо улучшить в следующем?

разработки ПО в условиях неясных или быстро меняющихся требований для

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

разработки ПО в условиях неясных или быстро меняющихся требований для

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

Двенадцать основных приёмов экстремального программирования (по первому изданию книги Extreme programming explained) могут быть объединены в четыре группы:
Короткий цикл обратной связи (Fine-scale feedback)
Разработка через тестирование (Test-driven development)
Игра в планирование (Planning game)
Заказчик всегда рядом (Whole team, Onsite customer)
Парное программирование (Pair programming)
Непрерывный, а не пакетный процесс
Непрерывная интеграция (Continuous integration)
Рефакторинг (Design improvement, Refactoring)
Частые небольшие релизы (Small releases)
Понимание, разделяемое всеми
Простота (Simple design)
Метафора системы (System metaphor)
Коллективное владение кодом (Collective code ownership) или выбранными шаблонами проектирования (Collective patterns ownership)
Стандарт кодирования (Coding standard or Coding conventions)
Социальная защищённость программиста (Programmer welfare):
40-часовая рабочая неделя (Sustainable pace, Forty-hour week)

по сравнению со SCRUM, важнее решить качественно задачу, чем уложиться

в сроки.
Весь Канбан можно описать следующими правилами:
1. Визуализируйте разработку:
– разделите проект на задачи, каждую задачу напишите на карточке и поместите на стену или доску;
– используйте специальные отметки, чтобы показать положение задачи в разработке.
2. Ограничивайте количество параллельных процессов.
3. Опирайтесь на уже существующие методы разработки.
4. Поощряйте небольшие и эволюционные изменения, критично относитесь к революционным.
5. Уважайте существующий порядок, роли и обязанности.
6. Приветствуйте проявление инициативы.

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

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

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

Метод разработки динамических систем (Dynamic Systems Development Method, DSDM) – гибкая методология разработки ПО, основанная на концепции быстрой разработки приложений (Rapid Application Development, RAD), использует итеративную модель.

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

и принципы модели процессов MSF:
– единое видение проекта – все заинтересованные лица и просто участники проекта должны чётко представлять конечный результат, всем должна быть понятна цель проекта;
– управление компромиссами – поиск компромиссов между ресурсами проекта, календарным графиком и реализуемыми возможностями;
– гибкость – готовность к изменяющимся проектным условиям;
– концентрация на бизнес-приоритетах – сосредоточенность на той отдаче и выгоде, которую ожидает получить потребитель решения;
– поощрение свободного общения внутри проекта;
– создание базовых версии – фиксация состояния любого проектного артефакта, в том числе программного кода, плана проекта, руководства пользователя, настройки серверов и последующее эффективное управление изменениями, аналитика проекта.
 
MSF предлагает проверенные методики для планирования, проектирования, разработки и внедрения успешных IT-решений. Благодаря своей гибкости, масштабируемости и отсутствию жестких инструкций MSF способен удовлетворить нужды организации или проектной группы любого размера. Методология MSF состоит из принципов, моделей и дисциплин по управлению персоналом, процессами, технологическими элементами и связанными со всеми этими факторами вопросами, характерными для большинства проектов.

Microsoft Solutions Framework (MSF) – методология разработки ПО, предложенная корпорацией Microsoft.

реализуемая и тестируемая на ранних стадиях проекта;

– работа над проектом в

сплочённой команде, ключевая роль в которой принадлежит архитекторам;

– ранняя идентификация и непрерывное устранение возможных рисков;

– концентрация на выполнении требований заказчиков к исполняемой программе;

– ожидание изменений в требованиях, проектных решениях и реализации в процессе разработки;

– постоянное обеспечение качества на всех этапах разработки проекта.

Особенность методологии состоит в том, что степень формализации может меняться

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

моделирования) – язык графического описания для объектного моделирования в области

разработки ПО.

CASE-средства с поддержкой UML:
– Sybase Power Designer
– MS Visio
– Dia
– SmartDraw
– Enterprise Architect
– Umbrello
– ArgoUML
– UModel
– Rational Rose
– Visual Paradigm
– QReal
 

Существует достаточно большой объем CASE-средств, позволяющих разрабатывать ПО, используя диаграммы UML.

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

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

Актер (в UML) – любой объект, субъект или система, взаимодействующая с моделируемой системой извне. Это может быть человек, техническое устройство или другая система, которая может служить источником воздействия на моделируемую систему 

Например, чтобы использовать элементы такой UML-диаграммы в MS Visio следует выбрать: Дополнительные фигуры → Программы и базы данных → Программное обеспечение → Сценарий выполнения UML.

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

их. Главная цель данной процедуры – поиск ответа на вопрос: «В процессе какого поведения система обеспечит необходимую функциональность?».
В UML имеется несколько видов диаграмм, позволяющих детализировать варианты использования, – это диаграммы поведения. Первой из них мы рассмотрим диаграмму состояний.

Диаграмма состояний (State Machine diagram, диаграмма конечного автомата) – диаграмма, которая используются для описания поведения, реализуемого в рамках варианта использования.

Начальное и конечное состояния:
а – начальное состояние;
б – конечное состояние

путь изменения состояния.
Состояние (State) – это ситуация в жизни

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

 Характеристика состояния может содержать описание выполняемых операций, перед которыми указывается одна из стандартных меток:
– entry (вход) – действие при входе, выполняемое вне зависимости от того, по какому переходу был выполнен вход в состояние (например, создать соединение с базой данных: entry / createConnect());
– exit (выход) – действие при выходе, выполняемое вне зависимости от того, по какому переходу был выполнен выход из состояния (например, закрыть соединение с базой данных: exit / closeConnect());
– do (выполнять) – деятельность в состоянии: объект может бездействовать и ждать наступления некоторого события, а может выполнять длительную операцию (например, проводить расчет: do / calculate());
– newTarget (новое задание) – внутренний переход, предписывающий обработку новых событий, не покидая текущего состояния; при выполнении внутреннего перехода повторно не выполняются действия при входе или выходе из состояния (например, временная остановка (прерывание) расчета: newTarget / pauseCalculate());
– defer (отложить) – отложенное событие, обработка которого предписывается в другом состоянии, но после того, как все операции в текущем будут завершены (например, отображение на экране сообщения об ошибках в исходных данных defer / showDataError()).

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

для представления временных особенностей передачи и приема сообщений между объектами.
Графически

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

MS Visio: Дополнительные фигуры → Программы и базы данных → Программное обеспечение → Последовательности UML.

разложение некоторой деятельности на её составные части.
Решение технологом задачи выбора

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

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

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

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

Средства автоматизации разработки программ (CASE-средства) — инструменты автоматизации процессов проектирования и разработки программного обеспечения для системного аналитика, разработчика ПО и программиста.

Первоначально под CASE-средствами понимались только инструменты для упрощения наиболее трудоёмких процессов анализа и проектирования, но с приходом стандарта ISO/IEC 14102 CASE-средства стали определять как программные средства для поддержки процессов жизненного цикла ПО.

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

Для выполнения поставленной цели CASE-технологии используют два принципиально разных подхода к проектированию: структурный и объектно-ориентированный.

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

Структурный подход подразумевает использование определенных общепринятых методологий при моделировании различных информационных систем:
SADT (Structured Analysis and Design Technique);
DFD (Data Flow Diagrams);
ERD (Entity-Relationship Diagrams).

Существует три основных типа моделей, используемых при структурном подходе: функциональные, информационные и структурные.

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

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

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

В основе методологии SADT лежат два основных принципа:

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

2. Декомпозиция. Использование этой концепции позволяет разделить каждый блок, понимаемый как единое целое, на свои составляющие, описываемые на более детальной диаграмме. Процесс декомпозиции проводится до достижения нужного уровня подробности описания. Диаграмма ограничивается 3-6 блоками для того, чтобы детализация осуществлялась постепенно. Вместо одной громоздкой модели используется несколько небольших взаимосвязанных моделей, значения которых взаимно дополняют друг друга, делая понятной структуризацию сложного объекта.

Применение SADT методологии основано на формализованном процессе создания системы, при разбиении его на следующие фазы:

анализ - определение того, что система будет делать;

проектирование - определение подсистем и их взаимодействие;

реализация - разработка подсистем по отдельности;

объединение - соединение подсистем в единое целое;

тестирование - проверка работы системы;

установка - введение системы в действие;

функционирование - использование системы.

SADT = IDEFX

формализации и описания бизнес-процессов.
В IDEF0 различают 4 типа дуг:
1)

вход (Input) – материал или информация, которые используются или преобразуются блоком для получения результата (выхода). Блок может не иметь ни одной входной дуги. Данный вид дуги поступает на левую сторону блока.
2) управление (Сontrol) – условия, правила, стратегии, стандарты, которые влияют на выполнение функции. Каждый блок должен иметь хотя бы одну дугу управления. Данный вид дуг поступает на верхнюю сторону блока.
3) выход (Output) – результат выполнения функции (материал или информация). Каждая функция должна иметь хотя бы одну выходную дугу. Данный вид дуг выходит из правой стороны блока.
4) механизм (Mechanism) – ресурсы, с помощью которых выполняется работа. Это могут быть, например, денежные средства, персонал предприятия, станки. Данный вид дуг поступает на нижнюю сторону блока.

Отличительной особенностью IDEF0 является её акцент на соподчинённость объектов. В IDEF0 рассматриваются логические отношения между работами, а не их временная последовательность.

Применяется для построения информационной модели, которая представляет структуру информации, необходимой

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

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

В настоящее время на основе совершенствования методологии IDEF1 создана ее новая версия — методология IDEF1X. IDEF1X разработана с учетом таких требований, как простота изучения и возможность автоматизации. IDEF1X-диаграммы используются рядом распространённых CASE-средств (в частности, ERwin, Design/IDEF).

методология моделирования и стандарт документирования процессов, происходящих в системе.
Process Description

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

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

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

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

Диаграмма потоков данных (DFD) — один из основных инструментов структурного анализа и проектирования информационных систем, существовавших до широкого распространения UML. Несмотря на имеющее место в современных условиях смещение акцентов от структурного к объектно-ориентированному подходу к анализу и проектированию систем, «старинные» структурные нотации по-прежнему широко и эффективно используются как в бизнес-анализе, так и в анализе информационных систем.

Исторически сложилось так, что для описания диаграмм DFD используются две нотации — Йордана (Yourdon) и Гейна-Сарсона (Gane-Sarson), отличающиеся синтаксисом.

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

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

Во время проектирования баз данных происходит преобразование ER-модели в конкретную схему базы данных на основе выбранной модели данных (реляционной, объектной, сетевой или др.).

ER-модель представляет собой формальную конструкцию, которая сама по себе не предписывает никаких графических средств её визуализации. В качестве стандартной графической нотации, с помощью которой можно визуализировать ER-модель, была предложена диаграмма сущность-связь (ER-диаграмма) (entity-relationship diagram, ERD).

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

должна быть учтена в модели.
Каждая сущность должна иметь наименование,

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

Экземпляр сущности - это конкретный представитель данной сущности.
Например, представителем сущности "Сотрудник" может быть "Сотрудник Фартушный".
Экземпляры сущностей должны быть различимы, т.е. сущности должны иметь некоторые свойства, уникальные для каждого экземпляра этой сущности.

Атрибут сущности - это именованная характеристика, являющаяся некоторым свойством сущности.
Наименование атрибута должно быть выражено существительным в единственном числе (возможно, с характеризующими прилагательными).
Примерами атрибутов сущности "Сотрудник" могут быть такие атрибуты как "Табельный номер", "Фамилия", "Имя", "Отчество", "Должность", "Зарплата" и т.п.
Атрибуты изображаются в пределах прямоугольника, определяющего сущность.

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

Связь - это некоторая ассоциация между двумя сущностями.

Одна сущность может быть связана с другой сущностью или сама с собою.
Например, связи между сущностями могут выражаться следующими фразами –
"СОТРУДНИК может иметь несколько ДЕТЕЙ", "каждый СОТРУДНИК обязан числиться ровно в одном ОТДЕЛЕ".
Графически связь изображается линией, соединяющей две сущности.