Метод инженерии
Методическая инженерия в «области информационных систем - это дисциплина , позволяющая создавать новые методы на основе существующих». [2] Основное внимание уделяется «проектированию, созданию и оценке методов, приемов и вспомогательных инструментов для разработки информационных систем ». [3]
Более того, методическая инженерия «хочет повысить полезность методов разработки систем путем создания структуры адаптации, посредством которой методы создаются для соответствия конкретным организационным ситуациям». [4]
Типы [ править ]
Компьютерная разработка методов [ править ]
Процесс моделирования метапроцессов часто не поддерживается с помощью программных инструментов, называемых инструментами компьютерной разработки методов (CAME) или инструментами MetaCASE (инструменты компьютерной разработки программного обеспечения мета-уровня). Часто метод создания экземпляров «использовался для создания репозитория сред компьютерного проектирования». [5] Существует множество инструментов для моделирования метапроцессов. [6] [7] [8] [9] [10]
Адаптация метода [ править ]
В литературе к понятию адаптации метода относятся разные термины, в том числе «адаптация метода», «адаптация фрагмента метода» и «инжиниринг ситуационного метода». Адаптация метода определяется как:
Процесс или возможности, в которых человеческие агенты посредством отзывчивых изменений и динамического взаимодействия между контекстами, намерениями и фрагментами методов определяют подход к разработке системы для конкретной проектной ситуации. [11]
Потенциально почти все гибкие методы подходят для адаптации методов. даже метод DSDM Для этой цели используется , который был успешно адаптирован в контексте ШМ . [12] Соответствие ситуации можно рассматривать как отличительную характеристику гибких методов и традиционных методов разработки программного обеспечения, причем последние являются относительно гораздо более жесткими и предписывающими. Практический смысл заключается в том, что гибкие методы позволяют проектным командам адаптировать методы работы в соответствии с потребностями отдельных проектов. Практики — это конкретные действия и продукты, являющиеся частью методологической структуры. На более экстремальном уровне можно адаптировать философию, лежащую в основе метода, состоящую из ряда принципов . [11]
Ситуационный инженерии метод
Ситуационная методология разработки — это разработка методов, адаптированных к конкретным ситуациям проектов разработки. [13] Это можно охарактеризовать как создание нового метода
- выбор соответствующих компонентов метода из репозитория повторно используемых компонентов метода,
- адаптация этих компонентов метода по мере необходимости, и
- интеграция этих адаптированных компонентов метода для формирования нового метода, специфичного для конкретной ситуации.
Это позволяет создавать методы разработки, подходящие для любой ситуации разработки. Разработка каждой системы начинается с этапа определения метода, на котором метод разработки создается на месте. [4]
В случае развития мобильного бизнеса существуют методы, доступные для конкретных частей процесса проектирования бизнес-модели и развития ИКТ. Ситуационную методологию можно использовать для объединения этих методов в один унифицированный метод, учитывающий характеристики услуг мобильных ИКТ.
Процесс метода разработки
Разработчики языков моделирования IDEF Ричард Дж. Майер и др. (1995) разработали ранний подход к разработке методов на основе изучения общей практики разработки методов и опыта разработки других методов анализа и проектирования . На следующем рисунке представлен процессно-ориентированный взгляд на этот подход. На этом изображении используется метод захвата описания процесса IDEF3 для описания этого процесса, где поля с глагольными фразами представляют действия, стрелки представляют отношения приоритета, а условия «исключающее или» среди возможных путей представлены соединительными блоками, помеченными знаком «X.». [1]
Согласно этому подходу существует три основные стратегии разработки методов: [1]
- Повторное использование : одной из основных стратегий разработки методов является повторное использование. По возможности используются существующие методы.
- Сделано на заказ : найдите методы, которые могут удовлетворить выявленные потребности с небольшими изменениями. Этот вариант является привлекательным, если модификация не требует фундаментального изменения основных концепций или целей разработки метода.
- Новая разработка : только если ни один из этих вариантов не является жизнеспособным, разработчики методов должны стремиться разработать новый метод.
Эти базовые стратегии могут быть разработаны в аналогичном процессе разработки концепции.
знаний инженерии к Подход
Подход к инженерии знаний является преобладающим механизмом совершенствования методов и разработки новых методов. Другими словами, за очень немногими исключениями, разработка метода включает в себя выделение, документирование и упаковывание существующей практики для конкретной задачи в форму, которая способствует надежному успеху среди практиков. Экспертные настройки сначала характеризуются в форме основных интуиций и концепций методов. Зачастую они первоначально выявляются посредством анализа методов, диаграмм и выражений, используемых экспертами. Эти открытия помогают в поиске существующих методов, которые можно использовать для поддержки начинающих практиков в приобретении тех же настроек и навыков. [1]
Разработка нового метода осуществляется путем определения области применения метода, уточнения характеристик концепций метода и интуиции, разработки процедуры, которая обеспечивает как выполнение задач, так и базовую поддержку обучения для начинающих практиков, а также разработки языка (языков) выражения. Затем разрабатываются методы применения методов с изложением руководящих принципов для использования в автономном режиме и в сочетании с другими методами. Затем каждый элемент метода подвергается итеративной доработке посредством лабораторных и полевых испытаний. [1]
Процесс разработки языка метода [ править ]
Процесс разработки языка метода является весьма итеративным и экспериментальным по своей природе. В отличие от разработки процедур, где можно идентифицировать, объединить и уточнить набор эвристик и методов из существующей практики, разработчики языков редко сталкиваются с хорошо развитыми механизмами графического отображения или сбора текстовой информации. Когда можно найти потенциально повторно используемые языковые структуры, они часто плохо определены или лишь частично соответствуют потребностям метода. [1]
Критическим фактором при разработке языка метода является четкое определение цели и области применения метода. Цель метода определяет потребности, которые метод должен удовлетворить. Это используется для определения выразительной силы, необходимой для поддерживающего языка. Область применения метода определяет диапазон и глубину охвата, которые также необходимо установить, прежде чем можно будет разработать соответствующую стратегию языкового проектирования. Определение объема также включает в себя принятие решения о том, какая когнитивная деятельность будет поддерживаться посредством применения метода. Например, языковой дизайн может ограничиваться отображением только окончательных результатов применения метода (как при предоставлении IDEF9 графических и текстовых языковых средств, которые отражают логику и структуру ограничений). В качестве альтернативы может возникнуть необходимость в языковой поддержке процесса, облегчающей сбор и анализ информации. В таких ситуациях могут быть разработаны специальные языковые конструкции, которые помогут практикующим специалистам организовывать, классифицировать и представлять информацию, которая позже будет синтезирована в дополнительные структуры представления, предназначенные для отображения. [1]
Имея эту основу, разработчики языка начинают процесс принятия решения о том, что и как должно быть выражено в языке. Языковой дизайн может начаться с разработки текстового языка, способного представлять весь спектр обрабатываемой информации. Затем могут быть разработаны графические языковые структуры, предназначенные для отображения выбранных частей текстового языка. Альтернативно, структуры графического языка могут развиваться до или параллельно с развитием текстового языка. Последовательность этих действий во многом зависит от степени понимания языковых требований среди разработчиков языка. Они могут стать ясными только после нескольких итераций как графического, так и текстового языкового дизайна. [1]
Графический язык дизайна [ править ]
Разработка графического языка начинается с определения предварительного набора схем и назначения или задач каждой из них с точки зрения того, где и как они будут поддерживать процесс применения метода. Для каждой схемы определяется центральный объект внимания. Например, при экспериментировании с альтернативными проектами графического языка для IDEF9 была задумана схема контекста как механизм классификации различных контекстов окружающей среды, в которых могут применяться ограничения. В центре внимания этой схемы был контекст. После принятия решения о центральном фокусе схемы определяется дополнительная информация (концепции и связи), которую следует зафиксировать или передать. [1]
До этого момента в процессе разработки языка основное внимание уделялось информации, которая должна быть отображена в данной схеме для достижения целей схемы. Здесь разработчик языка должен определить, какие элементы, определенные для возможного включения в схему, поддаются графическому представлению и будут способствовать сосредоточению внимания пользователя на желаемом информационном содержании. При таком общем понимании исследуются ранее разработанные структуры графического языка для выявления потенциальных возможностей повторного использования. При изучении вариантов дизайна графического языка для новых методов IDEF был выявлен и исследован широкий спектр диаграмм. Довольно часто даже некоторые из центральных концепций метода не содержат в себе элементов графического языка. [1]
Например, метод информационного моделирования IDEF1 включает понятие объекта, но не имеет синтаксического элемента для объекта на графическом языке.8. Когда разработчик языка решает, что синтаксический элемент должен быть включен в концепцию метода, разрабатываются и оцениваются возможные символы. На протяжении всего процесса разработки графического языка разработчик языка применяет ряд руководящих принципов, помогающих разрабатывать высококачественные проекты. Среди них разработчик языка избегает дублирования концептуальных классов или плохо определенных классов. Они также стремятся создать интуитивные механизмы, передающие направление чтения схем. [1]
Например, схемы могут быть спроектированы так, чтобы их можно было читать слева направо, снизу вверх или по центру. Также учитывается возможность загромождения или слишком большого количества информации на одной схеме, поскольку любое из этих условий чрезвычайно затрудняет чтение и понимание схемы. [1]
Тестирование метода [ править ]
Затем каждый проект-кандидат тестируется путем разработки широкого спектра примеров для изучения полезности проектов в соответствии с назначением каждой схемы. Первоначальные попытки разработки методов и, в частности, разработки поддерживающих языковых структур обычно сложны. При последовательных итерациях дизайна устраняются ненужные и сложные языковые структуры. [1]
По мере того, как графический язык дизайна приближается к уровню зрелости, внимание переключается на текстовый язык. Цели, которым служат текстовые языки, варьируются от предоставления механизма выражения информации, которая явно была исключена из графического языка, до обеспечения механизма стандартного обмена данными и автоматизированной интерпретации моделей. Таким образом, текстовый язык, поддерживающий метод, может быть простым и неструктурированным (с точки зрения компьютерной интерпретации) или может представлять собой высокоструктурированный и сложный язык. Цель метода во многом определяет, какой уровень структуры потребуется от текстового языка. [1]
Методы формализации и применения [ править ]
По мере того, как язык методов начинает приближаться к зрелости, используются методы математической формализации, поэтому новый язык имеет ясный синтаксис и семантику. Процесс формализации метода часто помогает выявить двусмысленности, выявить неуклюжие языковые структуры и упростить язык. [1]
Эти общие действия завершаются языком, который помогает сосредоточить внимание пользователя на информации, которую необходимо обнаружить, проанализировать, преобразовать или передать в ходе выполнения задачи, для которой был разработан метод. И процедурная, и языковая составляющие метода также помогают пользователям развивать необходимые навыки и настройки, необходимые для достижения стабильно высокого качества результатов для поставленной задачи. [1]
После разработки метода будут разработаны методы его применения, позволяющие успешно применять метод как в автономном режиме, так и вместе с другими методами. Техники применения составляют компонент «использования» метода, который продолжает развиваться и расти на протяжении всего срока службы метода. Процедура метода, языковые конструкции и методы применения рассматриваются и тестируются для итеративного усовершенствования метода. [1]
См. также [ править ]
Ссылки [ править ]
- ^ Jump up to: Перейти обратно: а б с д и ж г час я дж к л м н тот п д Ричард Дж. Майер и другие (1995). Информационная интеграция для параллельного проектирования (IICE). Сборник методов, отчет Командования материально-технического обеспечения ВВС, база ВВС Райт-Паттерсон, Огайо. стр.7-10.
- ^ Ф. Хармсен и М. Саэки (1996). «Сравнение четырех языков методической инженерии». В: Сьяак Бринккемпер и др. (ред.) Материалы рабочей конференции IFIP TC8, WG8.1/8.2 по разработке методов на тему «Инженерия методов: принципы построения методов и инструментальная поддержка: принципы построения методов и инструментальная поддержка» . Январь 1996 года, Атланта, Джорджия, США. стр.209-231
- ^ Сьяак Бринккемпер , Методическая инженерия: разработка методов и инструментов разработки информационных систем. Журнал информационных и программных технологий, том 38, № 4, стр. 275–280 (1996).
- ^ Jump up to: Перейти обратно: а б Колетт Роллан (2008) Методическая инженерия: к методам как услугам . Программная речь ICSE0. 2008.
- ^ Колетт Роллан (1998). Комплексный взгляд на процесс проектирования . Материалы 10-й Международной конференции CAiSE'98, Б. Конспекты лекций по информатике 1413, Перничи, К. Танос (редакторы), Springer. Пиза, Италия, июнь 1998 г.
- ^ С. Келли, К. Люттинен, М. Росси. Meta Edit+: полностью настраиваемая, многопользовательская и многофункциональная среда CASE и CAME, Proc. Конференция CAiSE'96, Springer Verlag, 1996 г.
- ^ Ф. Хармсен, С. Бринккемпер, Проектирование и внедрение системы управления методической базой для ситуационной среды CASE. Учеб. 2-я конференция APSEC, IEEE Computer Society Press, стр. 430–438, 1995 г.
- ^ Г. Мербет. Maestro II - интегрированная система CASE от Softlab, системы и инструменты CASE (под ред. Х. Бальцерта) BI Wissenschaftsverlag, стр. 319-336, 1991 г.
- ^ С. Си Саид. Руководство по процессам разработки требований. В: Материалы 8-й международной конференции и семинара по «применению баз данных и экспертных систем», DEXA'97, Тулуза, 1–5 сентября 1997 г.
- ^ К. Роллан . Учебник по разработке методов. Материалы конференции INFORSID (INFormatics of Organizations and Information and Decision Systems), Тулуза, Франция, 10–13 июня 1997 г.
- ^ Jump up to: Перейти обратно: а б Айдын Миннесота, Хармсен Ф., Слоотен К. В. и Стэгви Р. А. (2004). Используемый метод разработки гибких информационных систем. Турк Дж. Элек Энгин, 12(2), 127–138
- ^ Абрахамссон П., Варста Дж., Сипонен М.Т. и Ронкайнен Дж. (2003). Новые направления в гибких методах: сравнительный анализ. Труды ICSE'03 , 244-254.
- ^ Р. Дж. Вельке и К. Кумар (1992). «Методическая инженерия: предложение по разработке методологии для конкретной ситуации». В: Коттерман, Сенн (ред.) Системный анализ и проектирование: программа исследований. Уайли, Чичестер. стр. 257–268.
- Атрибуция
В эту статью включен текст из ВВС США и др. , «Информационная интеграция для параллельного проектирования (IICE) Сборника методов» отчета Ричарда Дж. Майера , 1995 г., публикации, которая сейчас находится в свободном доступе.
Дальнейшее чтение [ править ]
- Сяак Бринккемпер , Калле Лютинен, Ричард Дж. Вельке (1996). Разработка методов: принципы построения методов и инструментальная поддержка: материалы Рабочей конференции IFIP TC8, WG8.1/8.2 по разработке методов, 26–28 августа 1996 г., Атланта, США . Спрингер. ISBN 041279750X дои : 10.1007/978-0-387-35080-6
- Сьяак Бринккемпер , Саеки и Хармсен (1998). Техника сборки для метода инженерии. Разработка передовых информационных систем, Труды CaiSE'98 . Нью-Йорк: Спрингер. дои : 10.1007/BFb0054236
- Аджанта Даханаяке (2001). Компьютерный метод проектирования: проектирование CASE-хранилищ для 21 века . Херши, Пенсильвания: Idea Group Inc (IGI), 2001. ISBN 1878289942
- Брайан Хендерсон-Селлерс , Джолита Ралите, Пар Дж. Огерфальк и Матти Росси (2014). Ситуационный метод инженерии . Берлин: Шпрингер. ISBN 9783642414664 дои : 10.1007/978-3-642-41467-1
- Брайан Хендерсон-Селлерс , Джолита Ралите и Сьяак Бринккемпер , ред. (2008). Ситуационная методология: основы и опыт: материалы рабочей конференции IFIP WG 8.1, 12–14 сентября 2007 г., Женева, Швейцария . Нью-Йорк: Спрингер. ISBN 0387739467 дои : 10.1007/978-0-387-73947-2
- Брайан Хендерсон-Селлерс , К. Гонсалес-Перес и Дональд Файерсмит (2004) Разработка методов и оценка COTS в: Архив заметок по разработке программного обеспечения ACM SIGSOFT . Том 30, выпуск 4 (июль 2005 г.).
- Манфред А. Юсфельд, Маттиас Ярке и Джон Милопулос , ред. (2009). Метамоделирование для разработки методов . Кембридж, Массачусетс: MIT Press. ISBN 0262101084
Внешние ссылки [ править ]
- «Метамоделирование и методология» , 2000 г. Презентация Минны Коскинен