WikiDer > Методология

Method engineering
Не путать с Методы инженерии, по специальности «Промышленная инженерия».
Пример процесса разработки метода. Этот рисунок дает ориентированный на процесс Посмотреть подхода к разработке прототипа IDEF9 концепций метода, процедуры и возможных элементов графического и текстового языков.[1]

Методология в области информационные системы это дисциплина создавать новые методы из существующих ».[2] Основное внимание уделяется «разработке, построению и оценке методов, приемов и вспомогательных инструментов для разработка информационных систем".[3]

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

Типы

Компьютерная разработка методов

В моделирование метапроцессов процесс часто поддерживается с помощью программных инструментов, называемых инструментами компьютерной инженерии (CAME), или Инструменты MetaCASE (Инструменты компьютерной инженерии мета-уровня). Часто метод создания экземпляров «использовался для создания репозитория сред компьютерной разработки методов».[5] Есть много инструментов для моделирования метапроцессов.[6][7][8][9][10]

Адаптация метода

В литературе различные термины относятся к понятию адаптации метода, включая «адаптацию метода», «адаптацию фрагмента метода» и «разработку ситуационного метода». Адаптация метода определяется как:

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

Потенциально почти все гибкие методы подходят для адаптации методов. Даже DSDM метод используется для этой цели и был успешно адаптирован в CMM контекст.[12] Соответствие ситуации можно рассматривать как отличительную черту между гибкими методами и традиционными методами разработки программного обеспечения, причем последние являются относительно более жесткими и предписывающими. Практическое значение состоит в том, что гибкие методы позволяют проектным командам адаптировать работу практики согласно потребностям индивидуальных проектов. Практики - это конкретные действия и продукты, которые являются частью структуры метода. На более крайнем уровне философия метода, состоящая из ряда принципы, может быть адаптирован.[11]

Ситуационная методология разработки

Ситуационная методология разработки - это создание методов, которые адаптированы к конкретным ситуациям проектов развития.[13] Это можно охарактеризовать как создание нового метода

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

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

В случае развития мобильного бизнеса есть методы, доступные для определенных частей Бизнес модель процесс проектирования и развития ИКТ. Ситуационная разработка методов может использоваться для объединения этих методов в один унифицированный метод, который принимает характеристики услуг мобильных ИКТ.

Процесс разработки метода

Разработчики IDEF языки моделирования, Ричард Дж. Майер и др. (1995), разработали ранний подход к разработке методов на основе изучения общей практики разработки методов и опыта разработки других методов анализа и методы проектирования. На следующем рисунке представлен процессно-ориентированный взгляд на этот подход. Это изображение использует IDEF3 Описание процесса Метод Capture для описания этого процесса, где блоки с глагольными фразами представляют действия, стрелки представляют отношения приоритета, а условия «исключающее ИЛИ» среди возможных путей представлены соединительными блоками, отмеченными знаком «X.».[1]

На этом изображении представлен общий обзор процесса разработки метода IDEF.

В соответствии с этим подходом существует три основных стратегии разработки методов:[1]

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

Эти базовые стратегии могут быть разработаны в аналогичном процессе разработки концепции.

Подход инженерии знаний

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

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

Процесс разработки языка методов

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

Решающим фактором при разработке языка метода является четкое определение цели и области применения метода. Цель метода устанавливает потребности, которые метод должен удовлетворить. Это используется для определения выразительной силы, необходимой для поддерживающего языка. Объем метода устанавливает диапазон и глубину охвата, которые также должны быть установлены, прежде чем можно будет разработать соответствующую стратегию языкового дизайна. Определение объема также включает решение, какие познавательные действия будут поддерживаться посредством применения метода. Например, языковая разработка может быть ограничена отображением только окончательных результатов применения метода (например, при предоставлении IDEF9 средств графического и текстового языков, которые фиксируют логику и структуру ограничений). В качестве альтернативы может потребоваться внутренняя языковая поддержка, облегчающая сбор и анализ информации. В таких ситуациях могут быть разработаны конкретные языковые конструкции, чтобы помочь практикующим методам организовать, классифицировать и представить информацию, которая позже будет синтезирована в дополнительные структуры представления, предназначенные для отображения.[1]

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

Дизайн графического языка

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

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

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

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

Метод тестирования

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

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

Формализация и техники применения

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

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

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

Смотрите также

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

  1. ^ а б c d е ж грамм час я j k л м п о п q Ричард Дж. Майер и другие (1995). Отчет "Интеграция информации для параллельной разработки" (IICE) "Компендиум методов" Материальное командование ВВС, база ВВС Райт-Паттерсон, Огайо. стр.7-10.
  2. ^ Ф. Хармсен и М. Саеки (1996). «Сравнение четырех языков методологии». В: Сяак Бринкемпер и другие. (ред.) Труды рабочей конференции IFIP TC8, WG8.1 / 8.2 по разработке методов по Методология: принципы построения методов и поддержка инструментов: принципы создания методов и поддержка инструментов. Январь 1996 года, Атланта, Джорджия, США. стр.209-231
  3. ^ Сяак Бринкемпер, Методология: инженерия методов и средств разработки информационных систем. Журнал информационных и программных технологий, том 38, номер 4, стр. 275-280 (1996)
  4. ^ а б Колетт Роллан (2008) Разработка методов: к методам как услугам. Основной доклад ICSE0. 2008 г.
  5. ^ Колетт Роллан (1998). Комплексный взгляд на технологический процесс. Материалы 10-й Международной конференции CAiSE'98, B. Конспект лекций по информатике 1413, Перничи, К. Танос (ред.), Springer. Пиза, Италия, июнь 1998 г.
  6. ^ С. Келли, К. Люттинен, М. Росси. Meta Edit +: полностью настраиваемая, многопользовательская и многофункциональная среда CASE и CAME, Proc. Конференция CAiSE'96, Springer Verlag, 1996 г.
  7. ^ Ф. Хармсен, С. Бринккемпер, Разработка и реализация системы управления базой методов для ситуационной среды CASE. Proc. 2-я конференция APSEC, издательство IEEE Computer Society Press, стр. 430-438, 1995.
  8. ^ Г. Мербет. Maestro II- das intergrierte CASE-system von Softlab, CASE systeme and Werkzeuge (Ed. H. Balzert) BI Wissenschaftsverlag, стр. 319-336, 1991
  9. ^ С. Си Саид. Руководство по процессам разработки требований. В: Материалы 8-й международной конференции и семинара «База данных и применение экспертных систем», DEXA'97, Тулуза, 1–5 сентября 1997 г.
  10. ^ К. Роллан. Учебник по методологии. Материалы конференции ИНФОРСИД (INFormatique des organization et Systemes d'Information et de Decision), Тулуза, Франция, 10–13 июня 1997 г.
  11. ^ а б Айдын, М.Н., Хармсен, Ф., Слоотен, К. в., И Стэгви, Р. А. (2004). Используемый метод разработки гибких информационных систем. Turk J Elec Engin, 12 (2), 127-138
  12. ^ Абрахамссон, П., Варста, Дж., Сипонен, М.Т., и Ронкайнен, Дж. (2003). Новые направления гибких методов: сравнительный анализ. Материалы ICSE'03, 244-254
  13. ^ Р.Дж. Велке и К. Кумар (1992). «Методология: предложение по построению методологии для конкретной ситуации». В: Коттерман, Сенн (ред.) Системный анализ и дизайн: программа исследований. Уайли, Чичестер. С. 257–268.
Атрибуция

Эта статья включает текст из ВВС США, Отчет "Интеграция информации для параллельной разработки" (IICE) "Компендиум методов" к Ричард Дж. Майер et al., 1995, публикация теперь находится в открытом доступе.

дальнейшее чтение

  • Сяак Бринкемпер, Калле Лютинен, Ричард Дж. Велке (1996). Разработка методов: принципы построения методов и поддержка инструментов: материалы Рабочей конференции IFIP TC8, WG8.1 / 8.2 по разработке методов, 26–28 августа 1996 г., Атланта, США. Springer. 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). Ситуационная методология разработки. Берлин: 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

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