Реферат Калиманов, Василян. Методология idef 6

• Название: Методология idef 6
• Дата: 14.11.2021
• Размер: 26.19 Kb.
• Имя файла: Реферат Калиманов, Василян.docx
• Тип: Реферат; #272079

МИНИСТЕРСТВО ОБРАЗОВАНИЯ, НАУКИ И МОЛОДЕЖНОЙ ПОЛИТИКИ КРАСНОДАРСКОГО КРАЯ

ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ ПРОФЕССИОНАЛЬНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ КРАСНОДАРСКОГО КРАЯ
«КРАСНОДАРСКИЙ ГУМАНИТАРНО-ТЕХНОЛОГИЧЕСКИЙ КОЛЛЕДЖ»

РЕФЕРАТ ПО МДК 02.02 «РАБОТА С БАЗАМИ ДАННЫХ»

НА ТЕМУ «МЕТОДОЛОГИЯ IDEF - 6»

Выполнили:

Студенты группы 22-26

Калиманов Вячеслав

Василян Григорий

Краснодар, 2021 г.

Оглавление

Введение 3

Понятие 4

Обзор 5

IDEF6 темы 8

Введение

IDEF (I-CAM DEFinition или Integrated DEFinition) — методологии семейства ICAM (Integrated Computer-Aided Manufacturing) для решения задач моделирования сложных систем, позволяют отображать и анализировать модели деятельности широкого спектра сложных систем в различных разрезах. При этом широта и глубина обследования процессов в системе определяется самим разработчиком, что позволяет не перегружать создаваемую модель излишними данными.

IDEF-методологии создавались в рамках предложенной ВВС США программы компьютеризации промышленности — ICAM, в ходе реализации которой выявилась потребность в разработке методов анализа процессов взаимодействия в производственных (промышленных) системах. Принципиальным требованием при разработке рассматриваемого семейства методологий была возможность эффективного обмена информацией между всеми специалистами — участниками программы ICAM (отсюда название: Icam DEFinition — IDEF; другой вариант — Integrated DEFinition). После опубликования стандарта он был успешно применён в самых различных областях бизнеса, показав себя эффективным средством анализа, конструирования и отображения бизнес-процессов. Более того, собственно с широким применением IDEF (и предшествующей методологии — SADT) и связано возникновение основных идей популярного ныне понятия BPR (бизнес-процесс реинжиниринг).

Понятие

IDEF6 или Integrated Definition for Design Rationale Capture - это метод, упрощающий получение, представление и манипулирование обоснованием дизайна, используемым при разработке корпоративных систем. Этот метод, который пытается определить мотивы, управляющие процессом принятия решений, все еще находится в разработке. Обоснование - это причина, обоснование, основная мотивация или отговорка, которые побудили дизайнера выбрать конкретную стратегию или конструктивную особенность. Проще говоря, логическое обоснование интерпретируется как ответ на вопрос: «Почему этот дизайн выполняется таким образом?» Большинство методов проектирования сосредоточены на том, что представляет собой дизайн (т. Е. На конечном продукте, а не на том, почему дизайн такой, какой он есть). IDEF6 является частью семейства языков моделирования IDEF в области системной и программной инженерии.

Design Rationale Capture — Обоснование проектных действий. Назначение IDEF6 состоит в облегчении получения «знаний о способе» моделирования, их представления и использования при разработке систем управления предприятиями. Под «знаниями о способе» понимаются причины, обстоятельства, скрытые мотивы, которые обуславливают выбранные методы моделирования. Проще говоря, «знания о способе» интерпретируются как ответ на вопрос: «Почему модель получилась такой, какой получилась?» Большинство методов моделирования фокусируются на собственно получаемых моделях, а не на процессе их создания. Метод IDEF6 акцентирует внимание именно на процессе создания модели.

Обзор

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

• 
  ПОЧЕМУ дизайн такой, какой он есть
  
• 
  ПОЧЕМУ это не проявляется в какой-либо другой форме
  
• 
  КАК была достигнута окончательная конфигурация проекта.
  

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

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

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

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

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

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

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

IDEF6 темы

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

• 
  Феномены обоснования дизайна: общую характеристику логического обоснования дизайна можно дать следующим образом: «Верования и факты, а также их организация, которые человек использует для принятия (или обоснования) обязательств по дизайну и для распространения этих обязательств».
  
• 
  Обоснование дизайна Проблемы захвата: одна из причин потери обоснования кроется в большом временном лаге между спецификацией программного артефакта и завершением артефакта. Также есть проблемы с выработкой общего понимания того, что должно составлять явно зафиксированное обоснование дизайна. То есть заметная трудность с выражением обоснования дизайна заключается в том, что сама концепция не понимается единообразно. Он разделяет эту характеристику со всеми другими формами «объяснения», с которыми продолжают бороться исследователи искусственного интеллекта (ИИ). IDEF6
  

Разработка процедур

В IDEF6 процедура захвата обоснования включает в себя операции по разделению, классификации / спецификации, сборке, моделированию / выполнению и повторному разделению. Процедура обоснования, обычно применяемая при моделировании / выполнении развивающегося проекта, использует две фазы: на этапе I описывается проблема, а на этапе II разрабатывается стратегия решения.

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

Выявить проблемы

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

Определить ограничения

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

Определить потребности

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

Сформулируйте цели и требования

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

Сформулируйте стратегии решения

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

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

1. 
   Дизайн, управляемый внешними ограничениями. Проектирование выполняется в ситуациях, когда цели, намерения и требования недостаточно хорошо охарактеризованы, а тем более определены. Эти ситуации часто возникают, когда дизайнер слишком рано вовлекается в процесс разработки продукта.
   
2. 
   Дизайн, основанный на характеристиках - проектирование в строго контролируемой ситуации, когда строго соблюдаются строгая подотчетность и доказательство соответствия. Эти проектные ситуации часто связаны с потенциально опасными для жизни ситуациями.
   
3. 
   Дизайн с переносом - иногда называется «рутинным» дизайном.
   

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