Методическая инженерия в «области информационных систем — это дисциплина по созданию новых методов на основе существующих методов». [2] Она фокусируется на «проектировании, создании и оценке методов, методик и вспомогательных инструментов для разработки информационных систем ». [3]
Более того, методическая инженерия «хочет повысить полезность методов разработки систем путем создания адаптационной структуры, в рамках которой методы создаются для соответствия конкретным организационным ситуациям» [4] .
Процесс моделирования метапроцессов часто не поддерживается программными средствами, называемыми инструментами автоматизированного проектирования методов (CAME) или инструментами MetaCASE (инструменты автоматизированного проектирования программного обеспечения метауровня). Часто техника создания экземпляров «использовалась для создания репозитория сред автоматизированного проектирования методов». [5] Существует множество инструментов для моделирования метапроцессов. [6] [7] [8] [9] [10]
В литературе понятие адаптации метода обозначается разными терминами, включая «адаптацию метода», «адаптацию фрагмента метода» и «ситуационную инженерию метода». Адаптация метода определяется как:
Процесс или способность, в которых человеческие агенты посредством ответных изменений и динамических взаимодействий между контекстами, намерениями и фрагментами методов определяют подход к разработке системы для конкретной проектной ситуации. [11]
Потенциально почти все гибкие методы подходят для адаптации методов. Даже метод DSDM используется для этой цели и был успешно адаптирован в контексте CMM . [12] Соответствие ситуации можно рассматривать как отличительную характеристику между гибкими методами и традиционными методами разработки программного обеспечения, причем последние являются относительно гораздо более жесткими и предписывающими. Практический смысл заключается в том, что гибкие методы позволяют проектным группам адаптировать рабочие практики в соответствии с потребностями отдельных проектов. Практики — это конкретные действия и продукты, которые являются частью структуры метода. На более экстремальном уровне философия, лежащая в основе метода, состоящая из ряда принципов , может быть адаптирована. [11]
Ситуационная инженерия методов — это построение методов, которые настроены на конкретные ситуации проектов развития. [13] Ее можно описать как создание нового метода
Это позволяет создавать методы разработки, подходящие для любой ситуации разработки. Каждая разработка системы начинается с фазы определения метода, где метод разработки конструируется на месте. [4]
В случае развития мобильного бизнеса существуют методы, доступные для определенных частей процесса проектирования бизнес-модели и разработки ИКТ. Ситуационная инженерия методов может использоваться для объединения этих методов в один унифицированный метод, который принимает характеристики услуг мобильных ИКТ.
Разработчики языков моделирования IDEF Ричард Дж. Майер и др. (1995) разработали ранний подход к разработке методов, изучая общую практику разработки методов и опыт разработки других методов анализа и проектирования . На следующем рисунке представлено процессно-ориентированное представление этого подхода. Это изображение использует метод IDEF3 Process Description Capture для описания этого процесса, где блоки с глагольными фразами представляют действия, стрелки представляют отношения приоритета, а условия «исключающее или» среди возможных путей представлены соединительными блоками, помеченными «X.». [1]
Согласно этому подходу, существуют три основные стратегии в разработке методов: [1]
Эти базовые стратегии могут быть разработаны в аналогичном процессе разработки концепции.
Подход инженерии знаний является преобладающим механизмом для улучшения методов и разработки новых методов. Другими словами, за очень немногими исключениями, разработка методов включает в себя изоляцию, документирование и упаковку существующей практики для данной задачи в форме, которая способствует надежному успеху среди практиков. Экспертные настройки сначала характеризуются в форме основных интуиций и концепций методов. Они часто изначально определяются посредством анализа методов, диаграмм и выражений, используемых экспертами. Эти открытия помогают в поиске существующих методов, которые могут быть использованы для поддержки начинающих практиков в приобретении тех же настроек и навыков. [1]
Разработка нового метода осуществляется путем установления области применения метода, уточнения характеристик концепций и интуиций метода, разработки процедуры, которая обеспечивает как выполнение задач, так и базовую поддержку ученичества для начинающих практиков, и разработки языка(ов) выражения. Затем разрабатываются методы применения метода, описывающие руководящие принципы для использования в автономном режиме и совместно с другими методами. Затем каждый элемент метода подвергается итеративному уточнению посредством как лабораторных, так и полевых испытаний. [1]
Процесс проектирования языка метода является в высшей степени итеративным и экспериментальным по своей природе. В отличие от разработки процедур, где набор эвристик и методов из существующей практики может быть идентифицирован, объединен и уточнен, разработчики языка редко сталкиваются с хорошо разработанными графическими отображениями или механизмами сбора текстовой информации. Когда могут быть найдены потенциально повторно используемые языковые структуры, они часто плохо определены или лишь частично подходят для нужд метода. [1]
Критически важным фактором в разработке языка метода является четкое определение цели и области применения метода. Цель метода устанавливает потребности, которые должен решать метод. Это используется для определения выразительной силы, требуемой от поддерживающего языка. Область применения метода устанавливает диапазон и глубину охвата, которые также должны быть установлены до того, как можно будет разработать соответствующую стратегию проектирования языка. Определение области применения также включает в себя решение о том, какие когнитивные действия будут поддерживаться посредством применения метода. Например, разработка языка может быть ограничена только отображением конечных результатов применения метода (как при предоставлении IDEF9 графических и текстовых языковых возможностей, которые фиксируют логику и структуру ограничений). В качестве альтернативы может возникнуть необходимость в поддержке языка в процессе, облегчающей сбор и анализ информации. В таких ситуациях могут быть разработаны определенные языковые конструкции, чтобы помочь практикам метода организовывать, классифицировать и представлять информацию, которая позже будет синтезирована в дополнительные структуры представления, предназначенные для отображения. [1]
С этой основой разработчики языка начинают процесс принятия решения о том, что должно быть выражено в языке и как это должно быть выражено. Разработка языка может начаться с разработки текстового языка, способного представлять весь спектр информации, подлежащей обработке. Затем могут быть разработаны графические языковые структуры, предназначенные для отображения выбранных частей текстового языка. В качестве альтернативы графические языковые структуры могут развиваться до или параллельно с разработкой текстового языка. Последовательность этих действий во многом зависит от степени понимания языковых требований, имеющихся у разработчиков языка. Они могут стать ясными только после нескольких итераций как графического, так и текстового языкового дизайна. [1]
Графический языковой дизайн начинается с определения предварительного набора схем и цели или задач каждой из них с точки зрения того, где и как они будут поддерживать процесс применения метода. Центральный элемент фокуса определяется для каждой схемы. Например, при экспериментировании с альтернативными графическими языковыми дизайнами для IDEF9, схема контекста была задумана как механизм для классификации различных контекстов окружающей среды, в которых могут применяться ограничения. Центральным фокусом этой схемы был контекст. После принятия решения о центральном фокусе для схемы определяется дополнительная информация (концепции и отношения), которая должна быть зафиксирована или передана. [1]
До этого момента в процессе проектирования языка основное внимание уделялось информации, которая должна быть отображена в данной схеме для достижения целей схемы. Здесь разработчик языка должен определить, какие элементы, определенные для возможного включения в схему, поддаются графическому представлению и будут служить для удержания пользователя в фокусе на желаемом информационном содержании. С этим общим пониманием ранее разработанные графические языковые структуры исследуются для выявления потенциальных возможностей повторного использования. При исследовании потенциальных графических языковых конструкций для новых методов IDEF был выявлен и исследован широкий спектр диаграмм. Довольно часто даже некоторые из центральных концепций метода не будут иметь графического языкового элемента в методе. [1]
Например, метод информационного моделирования IDEF1 включает понятие сущности, но не имеет синтаксического элемента для сущности в графическом языке.8. Когда разработчик языка решает, что синтаксический элемент должен быть включен в концепцию метода, разрабатываются и оцениваются символы-кандидаты. На протяжении всего процесса проектирования графического языка разработчик языка применяет ряд руководящих принципов, помогающих разрабатывать высококачественные проекты. Среди них разработчик языка избегает перекрывающихся классов концепций или плохо определенных. Они также стремятся установить интуитивные механизмы для передачи направления для чтения схем. [1]
Например, схемы могут быть разработаны для чтения слева направо, снизу вверх или от центра к центру. Также рассматривается возможность загромождения или чрезмерно большого объема информации на одной схеме, поскольку любое из этих условий делает чтение и понимание схемы чрезвычайно сложными. [1]
Каждый проект-кандидат затем тестируется путем разработки широкого спектра примеров для изучения полезности проектов относительно цели для каждой схемы. Первоначальные попытки разработки метода и разработки поддерживающих языковых структур в частности, обычно сложны. С последовательными итерациями в проекте ненужные и сложные языковые структуры устраняются. [1]
По мере того, как графический язык дизайна достигает уровня зрелости, внимание переключается на текстовый язык. Цели, которым служат текстовые языки, варьируются от предоставления механизма для выражения информации, которая явно была исключена из графического языка, до предоставления механизма для стандартного обмена данными и автоматизированной интерпретации моделей. Таким образом, текстовый язык, поддерживающий метод, может быть простым и неструктурированным (с точки зрения компьютерной интерпретируемости), или он может оказаться высокоструктурированным и сложным языком. Цель метода во многом определяет, какой уровень структуры потребуется от текстового языка. [1]
По мере того, как язык методов начинает приближаться к зрелости, применяются математические методы формализации, чтобы появляющийся язык имел ясный синтаксис и семантику. Процесс формализации методов часто помогает обнаружить двусмысленности, определить неудобные языковые структуры и оптимизировать язык. [1]
Эти общие действия достигают кульминации в языке, который помогает сосредоточить внимание пользователя на информации, которую необходимо обнаружить, проанализировать, преобразовать или передать в ходе выполнения задачи, для которой был разработан метод. Как процедура, так и языковые компоненты метода также помогают пользователям развивать необходимые навыки и настройки, требуемые для достижения постоянно высококачественных результатов для целевой задачи. [1]
После разработки метода будут разработаны методы применения для успешного применения метода как в автономном режиме, так и вместе с другими методами. Методы применения составляют компонент «использования» метода, который продолжает развиваться и расти на протяжении всего жизненного цикла метода. Процедура метода, языковые конструкции и методы применения проверяются и тестируются для итеративного совершенствования метода. [1]
В статье использован текст из сборника методов «Интеграция информации для параллельного проектирования (IICE)» ВВС США , составленного Ричардом Дж. Майером и др. в 1995 г., который в настоящее время находится в открытом доступе.
