Рамках DEA для оценки эффективности программного обеспечения для сбора требований и анализа процесса

DEA основой для оценки эффективности захвата Требования к программному обеспечению и анализу процесса *

РЕЗЮМЕ

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

Предметные области: Анализ среды, требования захвата и анализа и разработки программного обеспечения.

ВВЕДЕНИЕ

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

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

Ряд исследований, посвященных эффективности разработки программного обеспечения, были представлены в литературе (Banker, данные,

В этой статье мы предлагаем методику изучения эффективности процесса RCA в разработке программного обеспечения. В статье 4 делает взносы. Во-первых, она предлагает теоретическую основу для оценки эффективности RCA. Во-вторых, она развивается Анализ среды (DEA) модели для осуществления предлагаемой структурой. DEA, современное состояние методологии бенчмаркинга (Charnes, Купер,

Остальные бумаги организовано следующим образом. Во-первых, мы представляем краткий обзор литературы по производительности программного обеспечения и развития процесса RCA, а также разработать теоретические основы для оценки эффективности RCA. Далее, краткое описание Анализ среды (DEA) методологии, которая использовалась в данном документе и подход, используемый для изоляции внешних факторов, представлены. Затем, разведочных расследования предлагаемой системы описывается, после чего состоялось обсуждение на управленческие последствия. Заключительные замечания и будущие направления исследований следовать в предыдущем разделе.

Обзор литературы

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

Разработка программного обеспечения производительности

Разработка программного обеспечения может рассматриваться как экономический процесс производства (Banker и др.., 1994), в которой ресурсы (например, усилия по разработке систем профессионалов) преобразуются в выходы (системы результаты), часто определяется как размер и сложность поставленной системы с помощью таких показателей, как строк кода (Кемирр, 1987; Cusumano

Тем не менее, предыдущие исследования исследования производительности эффекты различного программного обеспечения управления инженерными переменных с участием однородных наборов данных (например, данные из аналогичных типов проектов на той же фирмы), как правило, представили результаты с низким уровнем статистической значимости. Например, Кемирр (1987) сообщили, что добавление большого количества факторов производительности, не способствовало улучшению отношений между размером и усилий на набор из 15 однородных проектов MIS-типа. Банкир и др.. (1991) также высказали предположение, что относительно небольшого числа важнейших факторов может объяснить большое количество различий в производительности труда на конкретном сайте.

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

Управление процессом RCA

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

Трудности и недостатки, требования были определены в качестве важного фактора в информационных системах на отказ (Бем, 1981). Несмотря на растущий интерес к требованиям захвата и анализа со стороны разработчиков программного обеспечения на международном уровне (Jarke, Bubenko, Роллан, Сатклифф,

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

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

Кроме того, важность участия пользователей в процессе разработки системы была широко признана в литературе (Айвз

РАЗВИТИЕ концептуальных рамок

Далее мы разработать теоретические основы, которая описывает производственного характера процесса RCA. Поскольку практически не существует литературы, касающимся производства RCA, программа развития будет опираться в основном из литературы по общей разработке программного обеспечения. Схема рамках показан на рисунке 1. Предлагаемая система отличается от других моделей производства программного обеспечения, которые были зарегистрированы в литературе, по крайней мере два основных пути. Во-первых, основное внимание уделяется процессу RCA, а во-вторых, она включает поведенческих и управленческих факторов на входе установлено, что может сильно повлиять на эффективность. В последующих разделах мы практической реализации этой основы использования моделей DEA.

Входы RCA процесса

Большая часть программ, производство моделей, которые появляются в литературе сосредоточиться на рентабельности: насколько эффективно проектов перевод имеющихся у них ресурсов на некоторые соответствующие результаты. Большинство моделей включают труда или в рабочее время или стоимость ($) в качестве главного входа (см., например, банкир и др.., 1991). Как показано на рисунке 1, предложенный входной набор характерных для процесса RCA состоит из шести факторов. Первые два ссылаются на опыт членов команды с развитием системы и установления требований, и их знания предметной области. Ряд исследователей (Бем, 1981; Уолстон

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

Один фактор технологии ссылаясь на наличие и качество инструментов, используемых также входит в входной набор. Технологические факторы (методологии, методы и инструменты), по сообщениям, влияние на производительность, надежность, полноту, качество и другие меры, результат (Tha

Включения поведенческих и управленческих факторов при оценке эффективности RCA подкрепляется и Али и Seiford (1993), который также подчеркнул важность таких факторов в процессе производства. Другие исследования (Марко

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

Результаты RCA процесса

Как уже упоминалось в предыдущем разделе (Software Development производительности), выход набора большинство моделей производства обычно включает в себя такие переменные, как строк кода или функции точек. Это, однако, не являются непосредственно применимыми в процессе RCA. Выходной набор предлагаемой продукции RCA рамках показано на рисунке 1 состоит из двух переменных. Во-первых, прошло время процесса RCA считается. RCA прошло времени, или продолжительности или времени до завершения является мерой календарного времени от начала цикла разработки продукта до завершения процесса RCA. Вторая мера выхода считается, является качество (с точки зрения требований захватили) процесса RCA. Их включение поддерживает выводы, что на рабочем месте, три основных типа "жесткой" или объективные показатели результатов может быть использована для индекса производительности (Локк

Контроль за прошедшее время рассматривается как важный конкурентной стратегии продукта. В большинстве случаев, "рынок" накладывает определенные требования на производителей программного обеспечения, в отношении длительности проекта. Это может варьироваться в зависимости от применения. Преимущества наличия малых прошло время получить от первых на рынке (например, в разработке программного обеспечения), или первым, кто применил специальную технологию для улучшения продукта или услуги компания предоставляет своим клиентам (например, в промышленных разработчиков). Это, в свою очередь, переводит потенциально увеличения доходов, создания лояльности клиентов, и расширение доли рынка (карты и др.., 1987). В одном из исследований (Дамейн, 1989) сообщили, что продукция задерживается на шесть месяцев будет получать в среднем на 33% меньше прибыли.

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

Есть много исследований, в литературе, изучение факторов, которые могут быть использованы для уменьшения времени прошло (Милсон, Рай,

Ведение Факторы

Другими участниками проекта и экологические факторы должны быть рассмотрены при оценке производительности проекта (Рук

Eсть данные в литературе, в поддержку включения этих переменных, как модератора переменных в этих рамках. Чтобы быть более конкретным, теория развития продукта предполагает, что продукт сложности увеличивает время разработки. Кармел (1995) обнаружили, что продукт сложности является одной из наиболее важных факторов, которые влияют на прошедшее время. Многие меры, программного обеспечения сложности были предложены, но лишь немногие могут быть эффективно измерять в широком спектре образца. Наиболее актуальных сложности меры в RCA является требований волатильность, или структуры предметной области (Rasch

Кроме того, размер процесса RCA входит потому что, как различные исследования показали, хотя размер проектной группы также влияет на производительность, прошлый опыт показал, что "бросать больше людей в проект", не обязательно иметь положительное влияние на время разработки (Иордания

Методология исследования

Краткое описание Анализ среды (DEA) методология, мы используем в данном документе и подход, используемый для изоляции внешних факторов представлены в следующих двух подразделах.

Анализ среды (DEA)

Мы практической основы, представленные в предыдущем разделе, используя непараметрические линейного программирования методологии широко известный как Анализ среды (DEA). DEA был введен в 1978 году Charnes, Купер, и Родос. Методология, которая используется понятие "относительная эффективность", как было первоначально представленные Фаррелл (1957), был успешно применяются для оценки эффективности принятия решений единиц (DMUs), которые используют несколько входов для производства несколькими выходами. С момента своего появления, DEA была успешно применена для оценки производительности в различных отраслях промышленности, особенно при учете и финансовой отношения имеют мало или вообще не ценность (Чарнс и др.., 1994, Норман

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

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

никакой функциональной связи между входами и выходами должна быть заданной,

несколько входов и выходов можно рассматривать одновременно, неэффективные проекты могут быть идентифицированы,

источники и размеры неэффективности для каждого неэффективного проекта могут быть определены, и

конкретные недостатки, не могут быть обнаружены с помощью других методов, таких как коэффициент регрессии или анализа может быть обнаружен (Epstein

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

Подход изолировать воздействия внешних факторов на эффективность

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

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

Подход, который мы предлагаем для сравнения фазы RCA разработки программного обеспечения в два или более однородных групп на основе подхода, представленные др. Чарнс и др. (1981) и происходит следующим образом. Во-первых, DEA применяется для каждой группы отдельно, с тем чтобы изучить эффективность разногласия внутри группы. Управленческая неэффективность в каждой группе могут быть идентифицированы, и пути улучшения может быть предложено на основе рекомендаций модели. Во-вторых, неэффективность управленческих RCA наблюдается в группах будут удалены. Это может быть сделано путем проецирования неэффективные проекты на их эффективной границы. Набор виртуальных и эффективных проектов затем построить для каждой группы. В-третьих, DEA применяется для объединения данных, состоящая из всех эффективных и виртуальных проектов из обеих групп находятся на рассмотрении. Различия между группами теперь можно определить путем изучения ли различия эффективности распределения существуют в разных группах. Информация о том, как проекты могут воспользоваться методами управления наблюдается в проектах, работающих в различных групп могут быть получены.

Мы опишем области исследования, проведенного продемонстрировать применимость как теоретических рамках описанной ранее, и подход DEA описано здесь.

Ознакомительная эмпирическое исследование

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

Сбор данных

Процесс сбора данных со стороны другого исследования, которое сосредоточено на более глубокое понимание требований сбор и анализ процесса. Данные были собраны с помощью обследования, который состоялся между 1991 и 1993 годах. Целевых групп населения включены британских коммерческих программных проектов, проведенных в ходе этого периода. Четыре источники были использованы для определения обследования выборки: (а) Альви изданий программы, которые публикуются правительством Великобритании и включать соответствующую информацию о производстве программного обеспечения фирмы и конкретных проектов; (б) журналы (Вычислительный решений, программного обеспечения пользователя Год книги и т.д.), которые публикуют информацию о таких фирм, разработка программного обеспечения; (с) литературе определения конкретных компаний или проектов, а также (г) список с именами людей, вовлеченных в процесс разработки системы, которые также участвовали в предыдущих опросах, проводимых членами сотрудников отдела вычислений UMIST (Манчестерский университет, Институт науки и технологии, Манчестер, Великобритания).

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

Пропорционального стратификации процедуры отбора образцов, последовало, в зависимости от типа программного обеспечения разработчика (Software House, промышленных, консультации). Обзор инструментов, а также сопроводительное письмо, как правило, направлен начальник отдела ИС, с инструкциями для введения руководитель проекта. Ответ ставки в размере 40% на первом этапе и 24% в течение второго этапа были достигнуты, в результате чего в общей сложности 107 полезная анкет, из 107 коммерческих проектов, созданных из 74 различных организаций на территории Великобритании. Чтобы быть более конкретным, 51% респондентов были руководители проектов, 30% были системных аналитиков и проектировщиков систем, а 19% были консультантами. Кроме того, 27% респондентов были из программного обеспечения дома, 31% в промышленности, 27% из консалтинговых компаний, а 15% были учеными. Кроме того, 47% проектов были программных проектов, 28% были системы проектов, а остальные 25% были аппаратных проектов. ЛОНО смещения оценивали путем изучения различий между неполучением ответа и характеристик в отношении размера и типа проекта (оборудование, программное обеспечение и системы). Нет значимых различий (р

Большинство из этих проектов были завершены в течение 3 лет, занятых до 30 человек, были общие расходы более чем 100 тысяч, а с общих усилий менее 192 человеко-месяцев. Что касается стоимости проекта, то следует отметить, что лишь немногие из проектов, как сообщается, больше, чем стоимость 500000.

В большинстве проектов, 4:59 людей, занятых в процессе RCA, на долю которых приходится более 15% от общего затраченного времени и от 5 до 15% от их общей стоимости. Наконец, почти во всех проектах усилия, приложенные в RCA было до 36 человеко-месяцев.

DEA Модели

Три различные модели DEA были разработаны, каждая из которых с учетом различных показателей выпуска, как показано в таблице 1. Модель 1 анализирует эффективность проектов с точки зрения прошло время процесса RCA, в то время как модель 2 фокусируется на эффективности процесса RCA с точки зрения качества. Качество процесса RCA определяется в данном документе как сумма требования, собранные в рамках процесса. Наконец, модель 3 анализ эффективности процесса RCA с учетом как прошло время и качество.

Результаты

Сначала приведем результаты от применения DEA рамках каждой из проектных групп в отдельности (в пределах группового анализа). Далее мы приводим результаты воздействия внешних факторов на эффективность проекта в соответствии с подходом, изложенным выше (по-групповой анализ).

В-групповой анализ

Для того, чтобы оценить эффективность RCA различных проектов, мы должны применить DEA групп проектов, которые являются однородными. Мы использовали перечень модераторам переменных рис 1 в качестве основы для этого. Для б точнее, проекты были сгруппированы в зависимости от типа дома разработчиком программного обеспечения, промышленности, консультанты, академические), типа проекта (программного обеспечения, оборудования и систем), размер проекта (маленький, средний, большой), а также наконец, сложности проекта, как указано в менеджера проекта (хорошо, средне, плохо определены). Когда DEA применяется для результирующего однородных групп, местных неэффективности в каждой группе может быть идентифицирован. После этого мы можем применить подход, описанный ранее (подход к изолировать влияние внешних факторов на эффективность), чтобы выполнить межгрупповых сравнений для сравнения внешних факторов.

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

1. Разработчик: Software House; Тип продукта: программное обеспечение; Сложность: умеренная (17 проектов)

2. Разработчик: промышленные; Тип продукта: программное обеспечение; Сложность: умеренная (23 проектов)

3. Разработчик: консультант; Тип продукта: программное обеспечение; Сложность: умеренная (21 проектов)

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

Рейтинги эффективности таблицы 2 показывают, что различия между эффективностью распределения различных производителей. Шапиро-Уилк тест был запущен для проверки нормальности в результате распределения эффективности. Потому что в результате распределения эффективности не являются нормальными (р

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

По всей группы анализа

Как отмечалось выше, оценки эффективности RCA может дать полезную информацию о состоянии выполнения в каждой группе. Перейдем теперь к оценке между группами RCA эффективность, которая может дать полезную информацию о влиянии экзогенных переменных на эффективности RCA. Мы следуем трехэтапный подход, представленный в предыдущем разделе, чтобы изолировать и удалить управленческих недостатков. Затем объединить все эффективные и виртуальных единиц вместе и запустите анализ DEA. Таблицы 4 и 5 настоящей информации о результате оценки эффективности. Манна-Уитни испытаний вновь используется для проверки гипотезы, что в результате распределения из трех различных групп разработчик identical.These результаты отличаются от результатов предыдущего параграфа. Средняя эффективность процесса RCA промышленных проектов во всех моделях значительно выше, чем у программного обеспечения дома и / или группы консультантов. Эти различия, которые можно объяснить только общим различия между группами, так как все управленческой неэффективности были удалены в первом этапе подход, представленный в "подход к изолировать влияние на внешних факторов на эффективность" данной статьи. Обсуждение

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

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

Чтобы быть более конкретным, когда проекты оценивались отдельно по каждому виду разработчика (промышленность, разработке программного обеспечения, и консультантов), программное обеспечение дома и консалтинговых проектов были найдены, чтобы быть ближе, в среднем, с соответствующими им эффективной границы. Именно так обстоит дело во всех трех моделей мы использовали, независимо от вида продукции считается. Принимая во внимание развитие прошло время, сообщил (Дамейн, 1989), что продукция задерживается на шесть месяцев (будет введено на рынке) будет получать в среднем на 33% меньше прибыли. В случае разработке программного обеспечения, организационные стимулы могут существовать мотивации членов команды закончить RCA, и весь процесс развития как можно скорее. Кроме того, может быть институционального давления (а в некоторых случаях, исполнения наказаний) за затягивание работы над проектами, так что проекты могут быть пакетном. Аналогичные требования есть и в консультации, так как они обычно контракты подписывать со своими клиентами, часто включают в себя условия, которые предусматривают либо для специальных бонусов (для отделки во времени) или денежного штрафа (в случае их задержки в осуществлении проекта). В большинстве случаев оплата также получил после завершения проекта в целом или конкретных материальных частей.

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

Помимо этих различий, Существуют различия в самом процессе производства. Недавно проведенное исследование (Chatzoglou, 1997) сообщает, что является статистически значимой разницы в количестве итераций процесса RCA в проектах, разработанных различных отраслей промышленности. Программное обеспечение дома и консультации, в среднем, потребляют меньше итераций (1 или 2) процесса RCA, чем проектов, разработанных по отраслям (3 и более). Кроме того, применение (или нет) методологий разработки, могут также предоставлять частичные объяснения этих различий. В частности, в большинстве проектов, разработанных по разработке программного обеспечения и консультации, разработка методологии, используемые в процессе RCA, в то время очень мало проектов, разрабатываемых промышленностью использования 1.

Следует отметить, что в нашей выборке не только средний коэффициент полезного действия значительно отличается в проектах, разработанных различными организациями, а также ряд проектов в каждой шкале классификации эффективности меняется (табл. 3 и 5). Таким образом, в то время как более 80% проектов, разработанных по разработке программного обеспечения и консалтинговые фирмы имеют эффективность ставка от 90% -100%, более 50% промышленных объектов имеют КПД ставка от 65% -90%.

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

Одно из возможных объяснений является то, что Есть некоторые внутренние характеристики, которые (если использовать правильно) может сделать процесс производства в промышленности более effcient. Что может быть эти характеристики? Один из них, вероятно, лучшее знание предметной области, что члены команды могут получить. Таким образом, они не должны тратить много времени на взаимодействие с другими людьми (пользователей) для того, чтобы "мое" информацию о конкретном проекте. Это, вероятно, может объяснить, почему уровень переменных о пользователях и их связь с членами рабочей группы было установлено, что ниже проектов, разработанных по отраслям (Chatzoglou, 1997). Этот вывод согласуется также с тем, что сообщалось в других местах (Lee, Trauth, постоянного Фаруэлл, 1995), что люди в этой отрасли рассмотрения технических знаний специальностей будет менее важным фактором в разработке программного обеспечения, по сравнению с бизнес функциональные знания и межличностных / управление навыки, которые считаются одними из самых важных.

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

ЗАКЛЮЧЕНИЕ И БУДУЩИЕ НАПРАВЛЕНИЯ ИССЛЕДОВАНИЯ

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

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

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

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

Другой вопрос, представляющий интерес связан с характером используемых данных. В нашем исследовании восприятия основе "мягких" данных, полученных по результатам обследования были использованы, а не "жесткой" данных, полученных из программных проектов, как показано, например, "Аль-Махмуд и др. (1996). Хотя "объективные" показатели деятельности или управления оценки, как правило, желательно показателей, что есть доказательства того, что сами сообщили производительность также может быть полезно для исследования типа представлены в этой статье. В одном из исследований, например, на точность самостоятельной оценки, сообщает, что они как интеллектуального, как другие методы оценки, такие как психологические тесты, прошлой деятельности и обмен опытом по рейтингам (Shrauger

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

Несмотря на некоторые из указанных выше ограничений признал, что может дать пищу для будущих исследований, результаты данного исследования могут также оказаться полезными для управленческой практики. Важность процесса RCA в общем развитии программного обеспечения, не следует недооценивать. Предлагаемый процесс RCA рамках эффективности и DEA моделей, используемых для его в действие может предоставить конкретные руководящие принципы по улучшению руководитель проекта. Наконец, этот подход DEA выделить влияние внешних факторов на эффективность процесса RCA могут предоставить важную информацию относительно RCA эффективности процессов в различных отраслях промышленности. [В редакцию: 14 июля 1997. Принято: 28 июля 1998.]

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

Ссылки

Али, А. И.,

Athanassopoulos, А. Д., Soteriou, А. C.,

Athanassopoulos, А. Д.,

Banker, Р. D. (1984). Оценка наиболее продуктивных шкале размеров с использованием данных конверте

Мент анализа. Европейский журнал по исследованию операций, 17 (1), 35-44. Banker, RD, Chang, H., постоянного Кемирр, К. F (1994). Данные о эффекта масштаба в разработке программного обеспечения. Информация и технологии программного обеспечения, 36 (5), 275-282.

Banker, Р. Д., данных, С. М.,

Banker, Р. Д.,

ального Развития ". IEEE Transactions по разработке программного обеспечения, 15 (10), 416-429. Banker, Р. Д.,

opment анализа. Европейский журнал исследования операций, 17, 74-84. Барки, H.,

и пользовательские отношения. MIS Quarterly, марта, 59-82. Барки, H.,

Бем, Б. В. (1981). экономика программной инженерии. Englewood Cliffs, NJ: Prentice-Hall.

Бем, Б. В. (1990). Спиральная модель разработки ПО и аксессуарам. В Тайер Р. H.

Bubenko, J. A. (1995). Проблемы требованиям. Второй Международный симпозиум IEEE по требованиям. Йорке, Англия. Бэрд, TA, Cossick, Куала-Лумпур, постоянного Zmud, RW (1992). Синтез исследований анализ требований и методов приобретения знаний. MIS Quarterly, 16, 117-138.

Бернс, PE, Фрейзер, TP, постоянного Галледж, TR (1993). Возврат к масштаба в программном обеспечении

производство: сравнение подходов. В Галледж Т. Р.

Карты, Д. Н., Джерри, Ф. Е.,

Чарнс А. Купер, В. В.,

Чарнс А. Купер, В. В.,

Chatzoglou, П. (1997). Факторы, влияющие на завершение требования этап

проектов с различными характеристиками. Информация и технологии программного обеспечения журнал, 39 (9), 627-640.

Chatzoglou П.,

Костелло, Р. J.,

Cuelenaere, А. М. Е. ван Genuchten, М. J. I. М.,

Кушинг, Б. Е. (1990). Рамочные, парадигм и научных исследований в системах управления информацией. Журнал информационных систем, 4, 38-59. Cusumano, М.,

Дарк П.,

Делоне, В. Х.,

для зависимой переменной. Информация системных исследований, 3, 60-95. Марко, T.,

Нью-Йорк: Издательство Дорсет Ко

Дамейн, B. (1989). Как руководители могут добиться успеха с помощью скорости. Fortune, 11 (4), 54-59.

Эпштейн, М. К.,

Флинн, D. J.,

Фокс, С.,

Гальегос, A. (1991). Стратегических и экономических показателей государственных

предприятий на примере Латинской Америки индустрии авиаперевозок. Неопубликованные докторская диссертация, Техасский университет, Высшая школа бизнеса.

Стекло, Р. Л. (1994). Кризис программного обеспечения научных исследований. Журнале IEEE Software, 11 (6), 42-49. Гриффин, A. (1993). Метрики для измерения развития продукта время цикла. Jour

NAL продукта Управление инновациями, 10, 112-125.

Хартвик, J.,

Ives, Б.,

Jarke, М., Bubenko, J., Роллан, C., Сатклифф, А.,

Jarke, М.,

ING смены программного обеспечения действительности. Разработка программного обеспечения Journal, 9 (6), 257-266. Иордания, Е. В.,

Кайзер, К.,

Кемирр, C. F. (1987). Эмпирической проверки моделей программного обеспечения сметных расходов.

Сообщения ACM, 30 (5), 416-429.

Кемирр, C. F. (1993). Надежность измерения функции пунктов: полевой эксперимент. Сообщения ACM, 36 (2), 85-97.

Кирш, Л. J. (1997). Портфели контроля режимов и IS управления проектами. Информация системных исследований, 8 (3), 215-239.

Лоуренс, М.,

Литлпаж, Г. Е. (1991). Воздействие размер группы и задачи характеристик на эффективность группы: испытания модели Штайнера. Личность и социальная психология бюллетень, 17 (4), 449-456.

Локк, Е. А.,

Низкий, Г. C.,

Макала, Р. Р., Стаки, Л. Д.,

Мак-Кин, J. D.,

Мак-Кин, J. D., Guimaraes, T.,

Милсон, М. Р., Радж, С. П.,

Меллер, К. Х.,

Норман, М.,

Раш, Р. Х.,

Родригес, А. Г.,

Сенгупта, J. К.,

Shrauger, J.,

Симпсон, В. D. (1987). Новые технологии в программное обеспечение по управлению проектами. Нью-Йорк: John Wiley постоянного сыновья.

Штокман, С. Г.,

Мент. IBM Systems Journal, 23, 19-35.

Thanassoulis Е.,

Уолстон, К. Е.,

Вальц, Д. Б., Элам, J. J.,

Витроу, C. (1990). Ошибка плотности и размеров программного обеспечения Аде. IEEE Software, 7 (1), 26-30.

Wrigley, К. Д.,

Zenios, К. В., Zenios, С. А., Агатоклеус К.

Продромос D. Chatzoglou

Департамент делового администрирования Школы бизнеса и экономики, TE.L Кавала, Агиос Лукас, PO. Box 1194, 65404 Кавала, Греция, <a href="mailto:pdchatz@kavala.teikav.edujgr"> pdchatz@kavala.teikav.edujgr </ A> Андреас C. Soteriou

Департамент общественной и делового администрирования, Университет Кипра, PO. Box 537, Никосия, Кипр, <a <href="mailto:basotir@cy.ac.cy"> basotir@cy.ac.cy />

Продромос D. Chatzoglou является доцентом в Департамент предпринимательства администрации Технологического института образования Кавала Греция. Он получил степень бакалавра по экономике в Высшей промышленной школе в Салониках в Греции, MSc в управлении науки и докторскую степень в области инженерной информации, как из UMIST, Великобритания. Его исследовательские интересы включают такое управление проектом, требования техники, программного обеспечения и показателями. Его работа в этих областях, публикуются в таких журналах, как информационные системы Journal, инженерии программного обеспечения автоматизированной Journal, Европейский журнал по информационным системам, Международный научный журнал "Управление проектами, и информационно-программного обеспечения Technology Journal.

Андреас C. Soteriou является доцентом в Департаменте общественных и бизнес-администрирования Университета Кипра. Он имеет ученую степень кандидата наук в области делового администрирования в Университете Южной Калифорнии. Его основные научные интересы внимание в области качества и повышения производительности труда в секторе услуг. Его работы были опубликованы или предстоящих в таких журналах, как менеджмент, журнал операций управления Европейского журнала оперативных исследований, Международный журнал производства и оперативного управления, а также интерфейсы. В 1995 году он был удостоен Лучшее использование бумаги награду 24-го ежегодного совещания Западного института Decision Sciences.

Hosted by uCoz