WikiDer > IDEF6

IDEF6
IDEF6 модель IDEF4 Проектная деятельность[1]

IDEF6 или же Интегрированное определение для фиксации обоснования дизайна это метод облегчения получения, представления и манипулирования обоснование дизайна используется в разработке корпоративные системы. Этот метод, который пытается определить мотивы, движущие принимать решение процесс, все еще находится в разработке.[2]Обоснование это причина, оправдание, лежащий в основе мотивация, или оправдание, которое переместило дизайнер выбрать конкретный стратегия или же дизайн особенность. Проще говоря, логическое обоснование интерпретируется как ответ на вопрос: «Почему этот проект делается таким образом?» Большинство методов проектирования сосредоточены на том, что собой представляет дизайн (то есть на конечном продукте, а не на том, почему дизайн такой, какой он есть).[1]

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

Обзор

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

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

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

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

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

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

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

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

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

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

IDEF6 темы

Базовые концепты

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

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

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

Раздел проекта под названием Sys, показывающий составляющие его статические и динамические модели, а также связанную с ним модель требований. Модель требований содержит IDEF0 функциональная модель, деятельность которой вызывает IDEF3 сценарии процесса.
Сопоставление между анализами функция модели и сценарии использования а также требования и формулировки целей. Когда проект не может адекватно поддерживать действия и сценарии использования, модель требований позволяет разработчику легко идентифицировать ограничения требований или формулировки целей, которые были нарушены.

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

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

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

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

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

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

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

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

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

Как только потребности в переходе к дизайну определены, дизайнер формулирует[1]

  1. требования, которым должно удовлетворять решение, и
  2. цели, которые решение должно стремиться удовлетворить.

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

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

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

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

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

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

Рекомендации

  1. ^ а б c d е ж грамм час я j k Ричард Дж. Майер (1995) и др. Отчет "Интеграция информации для параллельной разработки" (IICE) "Компендиум методов". База ВВС Райт-Паттерсон, Огайо, 45433-7604.
  2. ^ Эндрю П. Сейдж, Уильям Б. Роуз (2009). Справочник по системной инженерии и менеджменту Джон Уайли и сыновья. ISBN 0-470-08353-0, п. 427.
  3. ^ а б IDEF6: Обоснование дизайна Концептуальный документ метода захвата Аннотация. Доступ 17 июля 2009 г.
  4. ^ а б Ричард Дж. Майер, Патрисия А. Гриффит и Кристофер П. Мензель (1990-91) «IDEF6: Концептуальный документ метода захвата обоснования дизайна» В архиве 2007-04-02 в Wayback Machine Центр оборонной технической информации
  5. ^ Ивар Якобсон, М. Эрикссон и А. Якобсон (1994). Преимущество объекта: реинжиниринг бизнес-процессов с помощью объектной технологии (ACM Press). Эддисон-Уэсли, ISBN 0-201-42289-1

внешняя ссылка