Понимание сложности модели процесса разработки: анализ протокола подход

РЕЗЮМЕ

Формулировка модели предполагает организацию некоторых элементов реальности в абстрактные структуры, которая имеет черты и характеристики реальности. Процесс разработки является сложной, и данная статья исследует, что сложность, глядя на пять ранее проанализированы проблемные ситуации в управленческой области. Это делается в несколько этапов. Во-первых, существующие содействия в разработке модели (MFS) архитектуры анализировали с помощью структур-механизмов-политики (SMP) модели для извлечения характерных атрибутов модели процесса разработки. Именно тогда утверждали, что интеграция этих атрибутов в архитектуре, называемого интегрированного моделирования архитектуры CMA), были бы полезны в деле поддержки сложности модели процесса разработки. Срок действия такой архитектуры является также изучены с помощью вербализации стенограмм пять проблем, упомянутых выше. Наши протокола анализ показывает, что IMA атрибуты могут объяснить сложные модели процесса разработки. Предметные области: систем поддержки принятия решений, разработки моделей, а также протокол анализа.

Понимание сложности модели процесса разработки: Анализ протокола подхода *

ВВЕДЕНИЕ

Проблем, рассмотренных в управленческих домена часто очень сложны, и эти сложности, хорошо запечатлен в разных статьях (Бауман, 1984; Боуман, 1983; Дхар

Утилита моделирования хорошо документирована. Серьезные причины для построения моделей, можно резюмировать (Уильямс, 1990):

А. Содействие более глубокому пониманию этого сценария моделируемого достигнута. Часто говорится о том, что фактическое осуществление построения модели часто показывает, что отношения не являются очевидными для многих людей.

B. Развитие более полного набора альтернатив осуществляется. После построения модели, как правило, можно проанализировать его, чтобы найти различные варианты действий, которые иначе могли бы не быть очевидной.

C. Управление сложность ситуации это возможно. Эксперименты можно сделать с помощью модели, а это часто невозможно экспериментировать с сценарию.

В данной работе мы следуем растущий интерес к изучению процесса разработки моделей в управленческой области (Binbasioglu

Мы также последовать примеру когнитивных ученых и сосредоточить внимание на процессе разработки модели, приближаясь к его как человека решения задач деятельности. Проблема, по мнению Рейтман (1985), может быть представлена тройкой (XY =), где X является существующее положение, Y желаемое состояние, и> преобразований или шагов, которые могут применяться к государствам, с тем чтобы переход от одного состояния к другому. В соответствии с рамках Рейтман, модель процесса разработки в данной работе рассматривается как частный случай решения проблем деятельности, где X представляет собой описание проблемы и Y представляет собой набор алгебраических уравнений. Признание того, что "разрыв" между существующим положением и желаемое состояние (Маккриммон

Управленческих домена предоставляет богатый район для изучения познавательной деятельности модель процесса разработки. В качестве первого шага, существующих подходов, используемых для создания модели разработка поддержки (MFS) инструменты (Bonczek и др.., 1980; Федорович

Эти verbalizations затем вновь использует протокол анализа. Схемы кодирования на основе IMA используется для анализа протоколов. Наш анализ этих исследований на совместной основе свидетельствует о полезности IMA атрибуты объяснения важных аспектов человеческой процесс разработки модели управленческой домена ..

ОБЗОР MFS АРХИТЕКТУРА

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

А. Поиск в разработке пространстве,

B. Моделирование разработки задач,

C. Контроль процесса разработки,

D. Использование ранее построенных моделей, а также

Е. Обращая особое внимание на интеграцию.

Поиск разработка пространства

Такой подход предполагает, что модель процесса разработки включает в себя языковой подсистемы, подсистемы обработки проблемы, и знание подсистемы. Подсистема языка приобретает проблема описания пользователей. Эти описания, то анализ и выводы взяты в подсистеме проблема обработки с помощью поиска (Dolk

В этой категории, модель процесса разработки определяется как совокупность нескольких модели постановка задачи такие категории, как контексте определения, разработки структуры модели, модель синтеза (опционально), и модель экземпляра. Такой подход (Binbasioglu

Контроль процесса разработки

Усилия по улучшению задачи интенсивные подходы вызвало введение иерархического управления (Raghunathan, 1990, 1992; Raghunathan, Кришнан

Использование ранее построенные модели

В этой категории, представление модели играет важную роль, поскольку знание модели разработки фиксируется как структура (Бланнинг, 1985; Dolk постоянного Konsynski, 1984; Элам и др.., 1980; Элам, 1979; Geoffrion, 1987) . Преимущественная направленность на структуру в конструкции МФС проявляется в случае подхода, основанного на поддержке Лян (1989). Согласно этому подходу, случае структуры хранятся вместо сохранения внутреннего представления математической модели. В последующее время хранится случаях используются для разработки новой модели с использованием случае рассуждений на основе подхода.

Обращая особое внимание на интеграции

В рамках этого подхода предполагается, что процесс разработки является сложной и нуждается интеграцию различных парадигм. Главной темой этого подхода является обеспечение "общения" различных элементов, составляющих системы MFS. Некоторые архитектуры MFS были разработаны с помощью этого подхода. Мы делим эти архитектур на две категории: федерации и союза.

В федерации архитектуры, личность каждого из компонентов для включения сохраняется. Преимуществом данного подхода является возможность использования существующих систем. Мы считаем, что доказательств этой архитектуры в модели разработки, как усилия GMIS (Donovan, 1976), GPLAN (Haseman

В союз архитектуры, компоненты (как правило, основаны на различных парадигм) от МФС являются "тесно интегрирован" в поддержку процесса разработки модели. Союз категории, однако, не основывается на файлы или базы данных, но вместо этого использует "внутреннее представление". Наше исследование показывает, что архитектур союз категорию обычно используется для интеграции различных парадигм три модели процесса разработки, как показано ниже. Исследования в этой категории является достаточно новым и до сих пор подчеркнул следующих вариантов:

Мета-Control интенсивно. Можно просто продлить интенсивный контроль архитектуры, позволяя оппортунистических политики управления взаимодействия с мета-задач управления, таких как "тактический контроль" (Sen и др.., 1994; Vinze и др.., 1993). Тактического управления необходимо определить, какие направления разработки MFS должны в любой момент в процессе разработки. Эти меры контроля помочь процессу разработки.

Причины интенсивного обслуживания. Еще один пример альянс архитектуру можно видеть путем расширения контроля интенсивной архитектуры включить "причина-технического обслуживания" политики (Bharadwaj, 1993; Митра

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

ПОЛУЧЕНИЯ МФУ ATTRIBUTES

В предыдущем разделе мы описали различные виды архитектуры предлагается модель поддержки усилий формулировки. Они варьируются от простых интерфейсов добавляются в существующие программные средства комплекса архитектуры, которые охватывают процессы для создания математических моделей, аналогичных специалистов. В попытке охарактеризовать модель процесса разработки, мы фокусируем наше внимание на этих подходов MFS и получать от них атрибуты, которые описывают модель процесса разработки. Этот вывод попытку с помощью модели SMP Перри и "Кайзер" (1991). Эта модель была с успехом использована для описания компонентов среды разработки программного обеспечения.

Модель SMP

Модель SMP (Perry

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

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

Механизмы, инструменты и инструментальные фрагменты, которые действуют на структуры среды разработки программного обеспечения и осуществлять, совместно со структурами, политика, поддерживаемая и обеспечивается окружающей среды. Иногда механизмы видны пользователям. Например, UNIX предоставляет инструменты явного для пользователей. Иногда механизмы скрыты, как и в случае Smile (Perry

Политики требованиям, предъявляемым к пользователю окружающую среду в процессе разработки программного обеспечения. Политики могут быть поддержаны и подкреплены окружающей среды. Если эта политика поддерживается, то механизмы и структуры, обеспечить средства удовлетворения этой политики. Например, если сверху вниз развития поддерживали политику, мы должны ожидать, чтобы найти средства и структуры, которые позволяют программисту создавать системы сверху вниз.

Перри и "Кайзер" (1991) дал обширные рассуждения для поддержки их SMP модели. Чрезвычайно важное значение имеет тесную взаимосвязь всех трех компонентов. Решения о 1 компонент может иметь серьезные последствия для других компонентов, а также 2 место серьезные ограничения на них.

Использование модели SMP

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

Структура атрибуты, связанные с

Структурных компонентов (внутреннее представление и представление случае), подчеркивают основные объекты модели процесса разработки. Три атрибута, определены в качестве заменителей являются: лица, объяснения, и особенность.

Сущность определяется как понятие, которое используется в процессе разработки моделей. Термин был заимствован из Entity Relationship (ER) модели данных, а также средства концепция, которая имеет множество функций как атрибуты. Например, в области производственной задачи, важные понятия "производство", "горизонт планирования" и "рабочей силы". Это может быть обозначена как лиц.

Объяснение определяется как средство, с помощью которых специалисты описывают различные аспекты модели процесса разработки. Например, в производственных проблем, модельер означает "мы не можем делать оба (нанимать и увольнять работников) из них.. Но мы должны иметь как там ...." Это объяснение, поскольку он рассматривается настроения модельер в отношении работников организации.

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

Механизм атрибуты, связанные с

В модели процесса разработки, важным компонентом является постановка задачи. Эти действия, делать элементарные задачи разработки, такие, как получить атрибуты этой проблемы, получить атрибуты инструмента, создание алгебраических компонентов, а также проблемы изменения атрибутов. Есть много таких задач в процессе разработки. Для краткости, мы разработали пять категорий, которые можно сгруппировать эти задачи. Эти категории затем переведен на пять механизм связанных атрибутов.

Сначала определим контексте определение как категории постановка задачи, которая участвует в определении масштабов проблемы области. Некоторые примеры разработки задач в этой категории относятся поиск проблемной области, находя проблемы атрибут, найти тип проблемы, найти тип проблемы, находя проблемы образования, поиск инструмент типа и другие.

Разработка структуры является второй категории задачей формулировку, которая принимает участие в разработке компонентов модели, что тема создания. Для разработки сложных моделей, разработка структуры иногда может включать меры для синтеза (модель синтез) модели от базовых моделей. Например задача разработки в данной категории включает в себя создание алгебраических компонентов.

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

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

Предметом постоянно оценивает своих частичного плана по разработке модели (см. мета-контроля определено ниже). Эта оценка частичной разработки (называемый также разработки и оценки проблемы перепланировки) требует коррекции. Коррекция необходима, чтобы избежать неудачи в процессе разработки. Мы определим "провал коррекции" (суррогатной для поддержания разума и перепланировка), а категории постановка задачи, в которых субъект вносит поправку в существующий план действий, чтобы избежать неудачи.

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

Политика атрибуты, связанные с

Политики компонента модели SMP подчеркивает, требования, предъявляемые в общий процесс разработки модели в выполнении задач разработки. Два суррогатных меры вытекают из подходов, описанных выше: стратегическое управление и тактического управления.

Мы определим стратегического управления как общей политики модель процесса разработки. Эта политика отвечает за управление связи между формулированием задач (сгруппированных в качестве механизмов) в течение всего эпизода разработки (Sen и др.., 1994). Стратегический контроль включает в себя два вида политики как правило, используется в модели процесса разработки: оппортунистических случае основе и оппортунистических первого принципа. Политика первого принципа, если формулировка сделать с нуля, в противном случае это дело основе. Оппортунизм подразумевает, что временные решения, может привести к последующим решениям, при произвольных точек в разработке пространства (Hayes-Рот

Тактического управления (или мета-контроль) является программой, которая направляет как формулировка задачи, или задачи категорий должны быть запланированы в разработке эпизод (Sen и др.., 1994). Элементы тактического управления разработки планирование, создание разработки цели, структурного компонента допустив, разработки оценки, задача разложения, определение граничной задачи, проблемы перепланировки, исходя направлении, и в разработке компонентов фокусировки. Эти элементы были широко определены и обсуждены др. Сена и др. (1994) и др. Vinze. (1993).

Эти атрибуты описывают коллективные структуры, механизм, и политические аспекты модели процесса разработки в управленческой области. В таблице 1, они используются в качестве критерия 8 архитектур обсуждали до сих пор. Беглый обзор таблицы видно, что ни одна из архитектур рассмотрел охватывать все SMP атрибутов. Это свидетельствует о необходимости комплексного моделирования архитектуры, которая описана в следующем разделе.

Предложение Integrated Architecture моделирования

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

Мы называем это единый подход комплексного моделирования архитектуры (IMA). Из двух интеграции подходов, описанных выше, федерации несколько проще, в своем представлении модели процесса разработки. Обе федерации и союза являются предшественниками IMA. Но почему мы должны стремиться к IMA? Причина в том, IMA будет объединить нашему нынешнему представлению о модели процесса разработки. Он не будет совершенно новую архитектуру, которая заменяет все текущие работы. Скорее, это будут сведены воедино и обобщить то, что мы уже знаем о модели процесса разработки.

Это необходимо интегрировать несколько представлений в модели разработки связано с желанием понять "формулирование поведения" экспертов. Такое поведение, по мнению Ньюэлла (1990, стр. 17), "1 виду, что умы их все. Даже если ум части, модули, компоненты, или любой другой, все они сетки вместе, чтобы произвести поведения". Если архитектура охватывает только одну часть или компонент модели процесса разработки ", она заигрывает с проблемы с самого начала" (Newell, стр. 17).

Использование ранее парадигмы SMP (Perry

IMA = (внутреннее представление, или представление случае, контекст идентификации, разработка структуры, решение поиска, адаптации модели экземпляров, неспособность коррекции, стратегического управления (оппортунистических первого принципа, или оппортунистических случае основе), тактические политики управления).

На рисунке 1, мы проиллюстрируем IMA использовании схемой информационных потоков. Каждый механизм представляет процесс на диаграмме потоков данных. Поток данных от одного процесса к другому отображаются с помощью стрелки. Случае представления изображается хранилища данных на диаграмме названием "Разработка модели Дело библиотека".

Одним из способов реализации Има подражать характеристики модели процесса разработки с использованием базового языка. Такой подход требует значительных усилий, как все функции модели разработки должны быть переписана в исходном языке. Производительность может страдать все функции не удастся выполнить в исходном языке. Верховая езда на текущих исследований по комплексной когнитивной архитектуры моделирование (SIGART бюллетень, 1991; VanLehn, 1991), Кришнан и др.., (1992) недавно использовали Сор (Laird, Ньюэлл,

Тем не менее, неясно, будет ли эмуляция MFS использованием имеющихся в настоящее время комплексного когнитивных архитектурах правильный путь. Ни один из комплексных когнитивных архитектур действительно поддерживают все функции МФУ. Они призваны подчеркнуть различных аспектов "человеческого обучения". Например, Сор (Лэрд и др.., 1987) подчеркивает, обучение решать проблемы через "неуклюжий". Тео (VanLehn, 1991) и Prodigy (VanLehn) были созданы в целях интеграции и опробовать различные стратегии обучения. Guardian (VanLehn), с другой стороны, был создан, чтобы фактор "реальном времени" в процессе рассуждения эксперта. Это указывает на необходимость тщательного рассмотрения в собирание любой комплексной когнитивной архитектуры (SIGART бюллетень, 1991; VanLehn) и эмуляции модели процесса разработки. Создание программного обеспечения является важным, но не должно быть единственной целью исследования MFS. Важно, чтобы мы смогли понять различные атрибуты модели процесса разработки; эти знания могут быть использованы для создания условий, способствующих разработке процесса.

Испытания ЖИЗНЕСПОСОБНОСТЬ IMA

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

Создание Исследование критерии выбора

Первый шаг в испытании жизнеспособности IMA состоит в определении видов модельных исследований формулировку, которая бы целесообразно изучить концепции IMA. Как модель разработки является сложным процесс решения задачи, мы должны исследований, которые используют словесные данных (Newell

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

Определение модели исследований Разработка

В общей сложности шесть исследований были определены как соответствующие для тестирования IMA. Все шесть исследований использовали метод думать вслух, чтобы собирать словесный данных, а затем проанализировать протоколы. Соответствующих исследователей из этих исследований были установлены контакты. Из этого исходного набора 6, мы смогли получить копию verbalizations из 5. Выдержки из протоколов с кратким описанием проблемы можно увидеть в приложении.

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

А. Планирование производства исследование

Это исследование (Raghunathan, 1990, 1992; Raghunathan и др.., 1993) пытается понять процесс разработки математической модели домена. Эксперимент проводился по четырем предметам: три профессора, каждая из которых имеет более чем 10-летним опытом в области обучения, исследований и консалтинга, четвертая тема практик с более чем 20-летний производственный опыт. Все они кандидат в науке управления. В общей сложности четыре проблемы были использованы в эксперименте. Проблемы варьировались от учебника планирования производства проблем случае Гарвардской школе бизнеса, и колебалось от простых стандартных смешивания проблема сложных многоступенчатых нескольких период производственных проблем с различными ограничениями. Verbalizations экспертов разработке множества проблем, попали в плен. За исключением одного вопроса, который опыт работы в словесных экспериментов протокола, а остальные были заряжены с разминки проблемы до эксперимента. Предметов только запрос, если они молчали более чем за минуту. В общей сложности 16 протоколов были собраны в результате проведения эксперимента.

B. преференциальной Исследование выбор

Целью данного исследования (Todd

C. Риск Аудит исследований

Протоколов в этом исследовании (Каран и др.., 1996) были частью больших эксперимент, чтобы увидеть, если аудиторы демонстрируют поляризации в принятии решений, когда они собираются вместе в группе. Понятие является то, что условия работы аудитора становится все более нестабильной и сложной, заставляя их тратить большое количество времени в настройках групп прийти к оценке "аудиторский риск" для клиента, который, в свою очередь, определяет аудиторских процедур, будет выполняться для этого силы. Субъектов состояла из 80 учащихся на высоком уровне аудита конечно. Задача включала в себя определение уровня приемлемого риска аудита для гипотетического клиента. Субъектов попытка эта задача первого лица, как, в следующем они пытались задача лицом к лицу совещание группы и, наконец, они попытались задачи с использованием технологии ГСР. Verbalizations были от лица к лицу совещание группы. Была предпринята попытка извлечь отдельные данные протокола в этой обстановке. Однако, учитывая, что это была группа решения проблем настройки отдельных данных протокола, не в достаточной степени охватывает модели деятельности формулировки. Как люди были вовлечены в совместное решение этой проблемы на руку, мы использовали группу, как наш блок анализа.

D. Исследование прогнозов

Это исследование (Vinze и др.., 1993) была создана, чтобы увидеть, если предметы выставки оппортунистического поведения в разработке прогнозных моделей для данного набора данных. Испытуемых 3 модельеры эксперт. Все трое были профессорами с различной степенью опыт, начиная с 2-10 лет. Каждый из этих предметов был кандидат степень оперативного управления от известных университетов. В начале этого процесса, каждый участник получил несколько простых упражнений, чтобы сделать их удобными в процесс, думая вслух. По окончании тренировки, испытуемые были ознакомлены с проблемами, которые они будут пытаться. Три набора временных рядов данных без четкого указания на окружающую среду проблемы и проблемы класса были выбраны для исследования. В общей сложности девять verbalizations были получены и проанализированы.

Е. катетеризации Лаборатория планирования исследования

Это исследование (Bharadwaj, 1993) пытался понять процесс планирования катетеризации лабораторий. В качестве основных направлений исследований в планировании пока сосредоточены на проблеме график разработки, это исследование изучить вопрос о пересмотре или пересмотра графика динамически в ответ на различные изменения, которые происходят в лаборатории катетеризации. График обычно означает уступки пациента с врачом процедуры в определенной лаборатории и обеспечивает начала и окончания периода процедуры. Предмет оказывается весьма специализированных медсестра-планировщик в большой юго-западной больницы в США центр является самым крупным и самым передовым в мире филиал за выполнение сердечной процедур. Предметом также ранее работал в течение нескольких лет, как медсестра катетеризации лабораторий. Параллельное словесные протоколов verbalizations вопросу были собраны в течение 4 циклов планирования и анализа.

Пересмотр Protocol Data

Verbalizations по своей природе данных богатых, и эта процедура преподносится как соответствующую методологию для исследования усилия были направлены на "процесс отслеживания" (Todd постоянного Benbasat, 1987). Снова, цитируя Ньюэлл и Саймон (1972):

Это трудно проверить теории динамических, историко-зависимых систем. Насыщенности содержания с различными значимых символических структур только усугубляет. Существует даже не хорошо себя евклидово пространство численных измерений в которой сюжет и сравнить поведение человека с теорией. Таким образом. . он делает очень мало использование стандартных статистических аппарата. Теория и сопоставлении данных, а некоторые делаются попытки меры в табличной форме таких сравнений. Но наши методы анализа данных, напоминающие биохимиков и археолог больше, чем сельское хозяйство экспериментатора. (Стр. 13)

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

Наши повторного протокола данные основаны на Боуман в (1984, 1983) наблюдения, которые определены четыре категории для проведения анализа протоколов: Scanningexamining протоколов непроверенной информации, что помогает при интерпретации других количественных данных; Скоринг-подсчете частоты некоторых ключевых пунктов интересов; Глобальное моделирование, вырабатывающих схемы и алгоритмы для захвата процесс принятия решения, и Компьютерное моделирование-шаг за шагом воспроизведение процесса.

Боуман (1984, 1983) также отметил, что при изучении результатов агрегирования среди ряда исследований, как в нашем случае, целесообразно использовать как сканирование и забил шаги. Это делает исследование не зависит от начальной забил протоколов. Следуя этому подходу, мы создали собственный свод правил и исполнили свой собственный сканирование и озвучивание 5 словесных наборов данных.

Подход к анализу данных протокола

Как правило, материалы из вербализации сегментированы в форме протоколов (Ван Someren и др.., 1994). Сегментация производится отметив паузы в вербализации лент. Анализ протокола данных можно рассматривать как трехэтапный процесс: создание схемы кодирования, проверки схемы кодирования, применяя схемы кодирования с полным набором данных протоколов.

Создание схемы кодирования,

Для этого протокола анализа словесных данных 5 модели процессов разработки, мы в первую очередь необходимо схемы кодирования. Схемы кодирования определяет, как элементы когнитивной модели могут быть определены в данных. Использование архитектуры IMA, мы выбираем в качестве суррогатных атрибуты меры модель процесса разработки. Для каждого такого атрибута, мы создаем правила, что подчеркивает атрибута. После предварительного усилия, как Аль-Сена и др. (1994) и др. Vinze. (1993), мы создали правила маркировки на основе SMP-атрибутов (табл. 2). Эти правила маркировки которые затем используются для проверки и оценки протоколов, описанных в следующем разделе.

Схемы кодирования содержит описание шагов рассуждения появляются в архитектуре IMA. Схемы кодирования не настроен для покрытия всех протоколов. Иными словами, протоколов, которые не могут быть закодированы соответствуют некоторым подпроцессы, которые не объясняются архитектуры.

Проверка схемы кодирования,

Процедура кодирования означает, что процесс присвоения метки протокол или набор протоколов, основанных на вышеупомянутых 11 правил кодирования из таблицы 2. Два кодировщиков были использованы для обозначения протоколов для каждого из 5 исследований. Оба были кодировщиков докторантов в информационных системах. Эти студенты были предыдущий опыт по содержанию протокола кодирования данных для других исследований. Эти кодеры получили правила кодирования (табл. 2), прошли подготовку по использованию этих правил. Кодировщиков первоначально заданного множества протоколов. По окончании первоначального набора стенограммы, руководители проекта (авторов) оценили закодированные протоколы точность кодирования подхода. То же самое кодировщиков были использованы для полного набора протоколов. Intercoder надежность была рассчитана на этом первоначальный набор протоколов. Intercoder надежности была вычислена путем принятия доля соглашения между кодировщиков, деленная на общее число возможных пар (Kerlinger, 1986). Общей надежности intercoder было 89%, что, в соответствии с Kerlinger (стр. 503), указывает на существенные и надлежащую степень согласованности. Это свидетельствует о том, что правила маркировки используется для классификации словесного данные были хорошо понимал и последовательно применяемые экспертами.

Применение схемы кодирования, чтобы Комплект Protocol Data

Получив степень уверенности в нашей схемы кодирования, рейтинговых агентств были рядом спросил код до всей совокупности данных протоколов. В следующем разделе представлены наши выводы.

Выводы Анализ протокола

Анализ данных, собранных протокол носит описательный характер, но и интересные идеи к модели процесса разработки. В этом разделе мы приводим результаты. Понимание процесса разработки модели попытка, сосредоточив внимание на освещение IMA атрибуты, которые были определены.

Полнота IMA Атрибуты

Мы определяем охват как процент от протоколов, которые учитываются, то есть те, которые могут быть закодированы с точки зрения ИМА-атрибуты, используя правила маркировки. Степень охвата MFP-атрибутов даст нам ключ, определяющий, как объяснить модель процесса разработки. Это означает, что покрытие будет показать полноту IMA в описании модели процесса разработки. Мы описываем эти данные в таблице 3. Все исследования, за исключением исследования аудиторского риска, показывают очень высокий уровень охвата протоколов вышеуказанных правил. Исследование аудиторского риска показывает охват 34,83%, в основном за счет установления группы проекта, как говорилось ранее.

Наблюдения над использованием МФУ IMA Атрибуты-Count данных

Мы предлагаем этот анализ, чтобы конкретно ориентированы на использование ИМА-атрибутов для описания модели усилия разработки в актуальном состоянии. Результаты классификации представлены в таблице 4.

Кол-во баллов в каждой из категорий, структуры, механизма и политики отражают относительную частоту использования. Даже несмотря на относительную частоту не означает, значение атрибута, он дает представление о конкретном аспекте процесса разработки, как модельер проходит процесс разработки. Изменение количества протоколов рассчитывали для каждого из различных случаев является отражением сложности задачи. Интересно, что предметы сбалансировать свои усилия разработке поровну между структуру, механизм, и политики в один из пяти проблем (проблема). В политике категории субъектов, и достаточно последовательно использовать оппортунистических подход к постановке. Существовал никаких доказательств использования субъектами иерархической (или сверху вниз) контроля. Это в отличие от результатов, представленных в (Raghunathan, 1990, 1992; Raghunathan и др.., 1993). Это правда, что в соответствии иерархического контроля, модель процесса разработки является систематической и вопрос можно было ограничить свое внимание на одной области иерархии. С другой стороны, при оппортунистических контроля, предмет не ограничен для поддержания структурно комплексной разработке на каждом этапе принятия решений. Вместо этого, вопрос можно сформулировать и проводить перспективные частичное формулировками, как возможность предложили.

Однако после Hayes-Рот и HayesRoth (1979), мы считаем, что непоследовательность не так реально, как это звучит. Одна резолюция видимого конфликта между двумя исследования "будет просто включить сверху-вниз (иерархическое) модель как частный случай оппортунистических модель" (Hayes-Рот

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

На рисунке 2, атрибуты, описывающие "структура" (структуры) и "механизма" (мех) приведены для каждого из 5 ситуаций дела. Это кросс-сравнение показывает некоторые интересные тенденции. Первый и, пожалуй, самым очевидным наблюдением является то, что использование структурных атрибутов в модели процесса разработки отличается среди различных областях проблемы. Это означает, что способность к структуре описания проблемы разнообразны. Например, на рисунке 2, атрибуты функции и лица играют важную роль в качестве модельера попытки математически представляют проблемы планирования производства ситуации (A). С другой стороны, для льготных проблема выбора (B), функция выбора доминирует модель процесса разработки, поскольку ситуация решается очень субъективный характер. Еще один пример на рисунке 2 показывает, что для аудиторского риска планирования задач (C) существует много субъективности, который требует соответствующего объяснения для выбора функции в соответствии с понятием аудита.

Как и выше замечания, мы видим тенденцию, механизм атрибуты, связанные с а (рис. 2). Для задачи планирования производства (A), разработка структуры и ее экземпляра доминируют модели процесса разработки. Для сравнения, для задачи аудиторского риска (C), выявляя связи с проблемой приходится самая большая кол-во механизм связанных атрибутов. Это можно объяснить процесс аудита оценки риска быть в первую очередь работе по определению компании и ее окружения. Таким образом, в контексте взаимодействия является предметом первостепенного внимания для аудитора.

Наблюдения над использованием МФУ IMA Атрибуты - Подробная информация о процессе

В дополнение к количеству данных, мы приведем примеры из протоколов, чтобы показать некоторые ключевые выводы о процессе разработки моделей. Целью здесь является понять, существует ли определенную схожесть в разработке типовых подходов по проблеме доменов. Каждый из ключевых выводов, которые были помечены с примерами (см. Приложение, проблемы, 1-5) от verbalizations. 4 Основные выводы заключаются в следующем:

1. Оппортунизм: Это означает, что в ходе разработки процесса разработки problemsolver в решения и замечания, предложить различные возможности для разработки развития. последующие решения эксперта следить за отдельные возможности. Иногда эти решения последовательности последующей упорядоченного пути и произвести аккуратный иерархии. Тем не менее, некоторые решения не могут следовать таким упорядоченно. В ходе разработки модели процесса, эксперты изменили свои сосредоточить внимание на выполнении задач, разработке альтернативных, когда они пришли в тупик. Это также вторит Hayes-Рот и Hayes-Рот (1979) в своем исследовании "поручение планирования" деятельности. Они называют этот упор на сборку модели оппортунизма компонентов.

2. Рассуждая по-первый принцип: Как правило, рассуждения первого принцип применяется, когда мы пытаемся постепенно трансформировать описание проблемы в целевой структуры. Это преобразование осуществляется с помощью последовательного уточнения постановки задачи до модель полностью сформулирована.

В задаче 1 (протоколы

3. Дело рассуждений на основе: попытка экспертов связать текущую ситуацию на прошлый опыт. Как правило, модельеры напоминают об аналогичных дел прошлых лет, если они имеют опыт работы в решении аналогичных проблем. Напомним процесса в случаях, мы посмотрели был основан на поверхность проблемы, наблюдавшиеся (например, ввод / вывод, транспорт и т.д.). Использование имеющихся знаний в виде случаев также наблюдается.

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

В задаче 5 (протоколы

РЕЗЮМЕ И ВЫВОДЫ

Результате нашего исследования показывают, что модель процесса разработки, действительно сложной задачей. Чтобы понять эту задачу, мы представляем набор суррогатных атрибуты, которые вытекают из существующих архитектур MFS. Эти атрибуты разделить модель процесса разработки в структуру, механизм и политика категорий. Эти категории позволяют предположить, что модель процесса разработки можно разложить на множество операций (изображается механизм атрибутов), который работает на данных, хранящихся в структуру (как показано структурных атрибутов). Эти операции находятся под контролем набор политик, который руководит процессом разработки модели к завершению. Мы представляем эти атрибуты в архитектуре называется комплексной архитектуры моделирования.

Чтобы увидеть ли такое утверждение справедливо, мы должны проверить выше архитектуры. Это делается с помощью техники анализа протоколов. Результат нашего анализа показывают, что субъекты распространять свои разработки усилий структурных, механизм, и политики атрибутов. В целом, мы обнаружили, что модель процесса разработки различных предметов выставлены некоторые общие черты, как оппортунизм, рассуждения первого принципа, или на индивидуальной основе и причина технического обслуживания.

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

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

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

Современные исследования ведутся продлить нахождение данного исследования в области программного обеспечения повторного использования. Программное обеспечение повторного использования представляется столь же сложна, как и модели процесса разработки. Следовательно, есть необходимость проверить последствия IMA провести для повторного процесса разработки программного обеспечения. Два исследования продолжаются. Первые испытания изучить наличие оппортунистического поведения в процессе повторного использования программного обеспечения. Во втором исследовании, применение всего комплекса IMA атрибуты объяснить сложность повторного процесса разработки программного обеспечения ведется расследование. [В редакцию: 30 января 1995. Принято редколлегией: 5 мая 1996.]

* Авторы хотели бы поблагодарить помощника редактора и анонимные отзывы за великолепную понимание и указания, содержащиеся в работе принятия более читабельным. Спасибо также исследовательские группы, которые способствовали их словесные данных нам для этого исследования. В частности, авторы хотели бы поблагодарить Izak Benbasat, С. Raghunathan и Anandhi Bharadwaj.

Ссылки

Акофф, Р. (1981). Наука и искусство управления беспорядок. Интерфейсы, 11, 20-26. Балакришнан А.,

Информация системных исследований, 2 (4), 263-286.

Bharadwaj, A. (1993). , Основанной на знаниях подхода к реактивной планирования. Неопубликованные докторской диссертации, Колледж управления бизнесом, штат Техас

Bonczek, Р. Х., Холсапл, К. В.,

Бауман, М. (1983). Человек диагностических рассуждений с помощью компьютера: иллюстрации из финансового анализа. Управление науки, 29 (6), 653-672. Бауман, М. (1984). Экспертов против начинающих решений в области бухгалтерского учета: резюме. Учет организаций и общества, 9, 325-327. Кондор (Комитет по Следующее десятилетие в области исследования операций). (1987). Операции

исследований: в следующем десятилетии. Исследование операций, 36, 619-637. Дхар В., Dc Попл, Е. П. (1987). На основе правил против структуры основе моделей для объяснения и создания экспертов поведения. Сообщения ACM, 30 (6), 542-555.

Dolk Д.,

Элам, J. J., Хендерсон, J. C.,

Первый ICIS конференции, Philadelphia, PA, 98-110.

Ericsson, К. А.,

Cambridge, MA: MIT Press

Федорович, J.,

Haseman, В. Д.,

Hayes-Рот, Б. де Hayes-Рот, Ф. (1979). Когнитивная модель планирования. Когнитивная наука, 3, 275-310.

Каран В., Керр, Д. С., Мурти, У. С.,

Кимбро, С. О.,

Konsynki, B.,

Krishnan, Р. (1990). Язык логического моделирования для автоматизированного построения моделей. Системы поддержки принятия решений: International Journal, 6, 123-152. Krishnan, Р. Ли, X., Bc Steier, D. (1992). , Основанной на знаниях математической системы разработки модели. Сообщения ACM, 35 (9), 138-146. Laird, J., Ньюэлл А.,

Лян, титульный лист (1989). Моделирование по аналогии: дело подход к модели строительства. Рабочий документ 89-1524, Университет штата Иллинойс в Урбана-Шампейн. Лян, Т. П.,

Маккриммон, К. Р.,

У Е. Марвин

Митра, С.,

Ньюэлл, A. (1990). Единой теории познания. Cambridge, MA: Harvard University Press.

Ньюэлл А.,

Перри, Д. Е.,

Raghunathan, С. (1992). Планирование помощи: интеллектуальная система моделирования для планирования задач, основанных на ограничение удовлетворения. IEEE Transactions на данных инженерия, 4 (4), 317-335.

Raghunathan, S., Krishnan Р.,

Рейтман, В. Р. (1985). Эвристической процедуры открытого ограничений, а также структуры жестокого определенных задач. В W.M. Шелли-II (ред.), правам решений и оптимальности. Нью-Йорк: Wiley, 282-315.

Сен А., MMU, А.,

Сен А., Vinze А.,

Sivasankaran, T.,

Смит, Г. Ф. (1988). На пути к теории эвристического задачи структурирования. Управление науки, 34 (12), 1489-1506.

Специальный доклад AAIMS развития, истории и возврат на инвестиции. (1972). Time-Sharing Сегодня, 3, Time Sharing Information Services, Philadelphia, PA: 4-5.

Штер, Е. А.,

Международный научный журнал "Анализ политики и информационных систем, 4 (1), 105-121. Тодд П.,

исследования: изучение "черного ящика". MIS Quarterly, LL (4), 493-512. Тодд П.,

VanLehn, К. (1991). Архитектуры для разведки. Хилсдейл, Нью-Джерси: Лоуренс Erlbaum Associates.

Ван Someren, М. В., Барнард, Ю. F.,

Веллор, Р. C., Сен А.,

Веллор, Р. C., Vinze, А. С.,

Vinze А.,

Vinze, А. С., Сен А.,

Уильямс, Х. П. (1990). Модель потенциала в области математического программирования. Нью-Йорк: John Wiley.

Arun Сена и Ajay С. Vinze департамента бизнес-анализа и исследований, Колледж управления бизнесом, штат Техас