Методология - Method engineering
Методическая инженерия в «области информационных систем - это дисциплина для создания новых методов из существующих». Он фокусируется на «проектировании, построении и оценке методов, приемов и вспомогательных инструментов для разработки информационных систем ».
Кроме того, разработка методов «стремится повысить полезность методов разработки систем путем создания основы адаптации, посредством которой методы создаются для соответствия конкретным организационным ситуациям».
Типы
Компьютерная разработка методов
Моделирование меты-процесс процесс часто поддерживается с помощью программных средств, называемого компьютеризированного инженерного метода (CAME) инструментов или инструментов MetaCASE (метауровна Computer Assisted Software Engineering инструментов). Часто техника создания экземпляров «использовалась для создания репозитория сред компьютерной разработки методов». Есть много инструментов для моделирования метапроцессов.
Адаптация метода
В литературе различные термины относятся к понятию адаптации метода, включая «адаптацию метода», «адаптацию фрагмента метода» и «разработку ситуационного метода». Адаптация метода определяется как:
Процесс или способность, в которых человеческие агенты посредством ответных изменений и динамического взаимодействия между контекстами, намерениями и фрагментами методов определяют подход к разработке системы для конкретной ситуации проекта.
Потенциально почти все гибкие методы подходят для адаптации методов. Для этой цели используется даже метод DSDM, который был успешно адаптирован в контексте CMM . Приемлемость ситуации можно рассматривать как отличительную характеристику между гибкими методами и традиционными методами разработки программного обеспечения, причем последние являются относительно более жесткими и предписывающими. Практическое значение состоит в том, что гибкие методы позволяют проектным группам адаптировать методы работы в соответствии с потребностями отдельных проектов. Практики - это конкретные действия и продукты, которые являются частью структуры метода. На более крайнем уровне философия, лежащая в основе метода, состоящая из ряда принципов , может быть адаптирована.
Ситуационная методология разработки
Ситуационная методология разработки - это создание методов, адаптированных к конкретным ситуациям проектов развития. Это можно охарактеризовать как создание нового метода
- выбор соответствующих компонентов метода из репозитория повторно используемых компонентов метода,
- адаптация этих компонентов метода по мере необходимости, и
- интеграция этих адаптированных компонентов метода для формирования нового метода, учитывающего конкретную ситуацию.
Это позволяет создавать методы разработки, подходящие для любой ситуации разработки. Затем начинается разработка каждой системы с этапа определения метода, на котором метод разработки создается на месте.
В случае развития мобильного бизнеса существуют методы, доступные для определенных частей процесса разработки бизнес-модели и разработки ИКТ. Ситуационная методология может использоваться для объединения этих методов в один унифицированный метод, который принимает характеристики услуг мобильных ИКТ.
Процесс разработки метода
Разработчики языков моделирования IDEF Ричард Дж. Майер и др. (1995), разработали ранний подход к разработке методов на основе изучения общепринятой практики разработки методов и опыта разработки других методов анализа и проектирования . На следующем рисунке представлен процессно-ориентированный взгляд на этот подход. В этом изображении для описания этого процесса используется метод IDEF3 Process Description Capture, где блоки с глагольными фразами представляют действия, стрелки представляют отношения приоритета, а условия «исключающее ИЛИ» среди возможных путей представлены соединительными блоками, помеченными знаком «X».
В соответствии с этим подходом в методологии есть три основных стратегии:
- Повторное использование : одна из основных стратегий разработки методов - это повторное использование. По возможности принимаются существующие методы.
- Индивидуальный подход : найдите методы, которые могут удовлетворить выявленные потребности с небольшими изменениями. Этот вариант является привлекательным, если модификация не требует кардинального изменения основных концепций или целей разработки метода.
- Новая разработка : разработчики методов должны стремиться разработать новый метод только тогда, когда ни один из этих вариантов не является жизнеспособным.
Эти базовые стратегии могут быть разработаны в аналогичном процессе разработки концепции.
Инженерный подход к знаниям
Подход инженерии знаний является преобладающим механизмом для улучшения методов и разработки новых методов. Другими словами, за очень немногими исключениями, разработка метода включает в себя изоляцию, документирование и упаковку существующей практики для данной задачи в форме, которая способствует надежному успеху практикующих специалистов. Настройки экспертов сначала описываются в форме базовых интуиций и концепций методов. Часто они изначально выявляются путем анализа методов, диаграмм и выражений, используемых экспертами. Эти открытия помогают в поиске существующих методов, которые можно использовать для поддержки начинающих практиков в приобретении тех же настроек и навыков.
Разработка нового метода достигается путем определения области применения метода, уточнения характеристик концепций метода и интуиции, разработки процедуры, которая обеспечивает как выполнение задач, так и базовую поддержку ученичества для начинающих практиков, а также разработки языка (ов) выражения. Затем разрабатываются методы применения методов с изложением руководящих принципов для использования в автономном режиме и в сочетании с другими методами. Затем каждый элемент метода подвергается итеративному уточнению как в лабораторных, так и в полевых условиях.
Процесс разработки языка методов
Процесс разработки языка методов носит итеративный и экспериментальный характер. В отличие от разработки процедур, где набор эвристик и методов из существующей практики может быть идентифицирован, объединен и уточнен, разработчики языков редко сталкиваются с хорошо развитыми механизмами графического отображения или сбора текстовой информации. Когда можно найти потенциально повторно используемые языковые структуры, они часто плохо определены или лишь частично соответствуют потребностям метода.
Решающим фактором при разработке языка метода является четкое определение цели и области применения метода. Цель метода устанавливает потребности, которые метод должен удовлетворить. Это используется для определения выразительной силы, необходимой для поддерживающего языка. Объем метода устанавливает диапазон и глубину охвата, которые также должны быть установлены, прежде чем можно будет разработать соответствующую стратегию языкового дизайна. Определение объема также включает решение, какие познавательные действия будут поддерживаться посредством применения метода. Например, языковая разработка может быть ограничена отображением только окончательных результатов применения метода (как при предоставлении IDEF9 графических и текстовых языковых средств, которые фиксируют логику и структуру ограничений). В качестве альтернативы может потребоваться внутрипроцессная языковая поддержка, облегчающая сбор и анализ информации. В таких ситуациях могут быть разработаны конкретные языковые конструкции, чтобы помочь практикующим методам организовать, классифицировать и представить информацию, которая позже будет синтезирована в дополнительные структуры представления, предназначенные для отображения.
Имея это основание, разработчики языка начинают процесс решения, что нужно выразить в языке и как это должно быть выражено. Языковой дизайн может начаться с разработки текстового языка, способного отображать весь спектр информации, которую необходимо адресовать. Затем могут быть разработаны графические языковые структуры, предназначенные для отображения выбранных частей текстового языка. В качестве альтернативы, структуры графического языка могут развиваться до или параллельно с развитием текстового языка. Последовательность этих действий во многом зависит от степени понимания языковых требований, предъявляемых разработчиками языка. Это может стать ясным только после нескольких итераций дизайна как графического, так и текстового языков.
Графический язык дизайна
Проектирование графического языка начинается с определения предварительного набора схем и цели или задач каждой с точки зрения того, где и как они будут поддерживать процесс применения метода. Для каждой схемы определяется центральный элемент фокуса. Например, в экспериментах с альтернативными конструкциями графического языка для IDEF9 контекстная схема рассматривалась как механизм для классификации различных контекстов среды, в которых могут применяться ограничения. В центре внимания этой схемы был контекст. После принятия решения о центральном фокусе схемы определяется дополнительная информация (концепции и отношения), которая должна быть зафиксирована или передана.
До этого момента в процессе проектирования языка основное внимание уделялось информации, которая должна отображаться в данной схеме для достижения целей схемы. Здесь разработчик языка должен определить, какие элементы, идентифицированные для возможного включения в схему, поддаются графическому представлению и будут служить для удержания внимания пользователя на желаемом информационном содержании. При таком общем понимании ранее разработанные структуры графического языка исследуются для выявления потенциальных возможностей повторного использования. При изучении возможных дизайнов графических языков для новых методов IDEF был выявлен и исследован широкий спектр диаграмм. Довольно часто даже некоторые из центральных концепций метода не содержат элементов графического языка в методе.
Например, метод информационного моделирования IDEF1 включает понятие объекта, но не имеет синтаксического элемента для объекта на графическом языке. Когда разработчик языка решает, что синтаксический элемент должен быть включен в концепцию метода, символы-кандидаты разрабатываются и оцениваются. На протяжении всего процесса проектирования графического языка разработчик языка применяет ряд руководящих принципов, чтобы помочь в разработке высококачественного дизайна. Среди них разработчик языка избегает перекрывающихся концептуальных классов или плохо определенных. Они также стремятся установить интуитивно понятные механизмы, чтобы передать направление чтения схем.
Например, схемы могут быть разработаны для чтения слева направо, снизу вверх или по центру. Также учитывается возможность беспорядка или чрезмерно большого количества информации на одной схеме, поскольку любое из этих условий чрезвычайно затрудняет чтение и понимание схемы.
Тестирование метода
Затем каждый проект-кандидат тестируется с помощью разработки широкого диапазона примеров для изучения полезности проектов по отношению к назначению для каждой схемы. Первоначальные попытки разработки методов и, в частности, развития поддерживающих языковых структур обычно бывают сложными. Последовательные итерации дизайна устраняют ненужные и сложные языковые структуры.
По мере того, как дизайн графического языка приближается к уровню зрелости, внимание переключается на текстовый язык. Цели, которым служат текстовые языки, варьируются от предоставления механизма для выражения информации, которая явно исключена из графического языка, до предоставления механизма для стандартного обмена данными и автоматической интерпретации модели. Таким образом, текстовый язык, поддерживающий метод, может быть простым и неструктурированным (с точки зрения компьютерной интерпретируемости), или он может возникать как сильно структурированный и сложный язык. Цель метода во многом определяет, какой уровень структуры потребуется от текстового языка.
Формализация и приемы применения
По мере того, как язык методов приближается к зрелости, используются методы математической формализации, поэтому возникающий язык имеет четкий синтаксис и семантику. Процесс формализации метода часто помогает выявить двусмысленность, выявить неудобные языковые структуры и упростить язык.
Эти общие действия завершаются языком, который помогает сосредоточить внимание пользователя на информации, которая должна быть обнаружена, проанализирована, преобразована или передана в ходе выполнения задачи, для которой был разработан метод. Как процедура, так и языковые компоненты метода также помогают пользователям развить необходимые навыки и настройку, необходимые для достижения неизменно высокого качества результатов для поставленной задачи.
После того, как метод будет разработан, будут разработаны прикладные методы для успешного применения метода в автономном режиме, а также вместе с другими методами. Прикладные методы представляют собой «используемый» компонент метода, который продолжает развиваться и расти на протяжении всего срока службы метода. Процедура метода, языковые конструкции и методы применения проверяются и тестируются для итеративного уточнения метода.
Смотрите также
Рекомендации
- Атрибуция
Эта статья содержит текст из ВВС США , информационной интеграции для Concurrent Engineering (IICE) Сборник методов отчета по Richard J. Mayer и др., 1995, публикация в настоящее время в общественном достоянии.
дальнейшее чтение
- Сяак Бринккемпер , Калле Лютинен, Ричард Дж. Велке (1996). Разработка методов: принципы построения методов и поддержка инструментов: материалы Рабочей конференции IFIP TC8, WG8.1 / 8.2 по разработке методов, 26–28 августа 1996 г., Атланта, США . Springer. ISBN 041279750X дои : 10.1007 / 978-0-387-35080-6
- Sjaak Brinkkemper , Saeki и Harmsen (1998). Техника сборки для методической инженерии. Передовая инженерия информационных систем, Труды CaiSE'98 . Нью-Йорк: Спрингер. DOI : 10.1007 / BFb0054236
- Аджанта Даханаяке (2001). Инженерия автоматизированных методов: проектирование репозиториев CASE для 21 века . Херши, Пенсильвания: Idea Group Inc (IGI), 2001. ISBN 1878289942
- Брайан Хендерсон-Селлерс , Джолита Ралити, Пар Дж. Агерфальк и Матти Росси (2014). Ситуационная методология разработки . Берлин: Springer. 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 г.