Исследование двух парадигм разработки программного обеспечения

Оригинал

Аннотация. Наиболее глубокий конфликт в программной инженерии разворачивается не между позитивистскими и интерпретационистскими исследовательскими подходами или гибкими (Agile) и тяжеловесными (Heavyweight) методами разработки программного обеспечения, а между рациональной и эмпирической парадигмами проектирования.

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

Рациональная парадигма рассматривает анализ, проектирование и программирование как отдельные виды деятельности, несмотря на эмпирические исследования, показывающие, что они одновременны и неразрывно взаимосвязаны.

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

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

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

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

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

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

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

То, что можно утверждать без доказательств, можно и отвергнуть без доказательств.
— Бритва Хитченса

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

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

Здесь парадигма используется в смысле Томаса Куна как «совокупность убеждений, ценностей, методов и так далее, разделяемых членами данного сообщества» [4]. Парадигмы — это не методы; они обычно не используются практиками напрямую.

Брукс [5] выделил три «формулировки» парадигмы рационального проектирования:

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

1. взгляд на проектировщика как на «рефлексирующего практика», чередующего постановку проблемы, корректировку концепции проектирования и оценку последствий корректировки [9];
2. взгляд на проектировщика как на творческого агента, чье внимание колеблется между неопределенной концепцией проблемы и предварительной концепцией решения (коэволюция), постепенно развивая понимание обеих [10], [11], [12];
3. взгляд на проектирование как на политический процесс, характеризующийся межличностными конфликтами, разногласиями по поводу целей, политиканством и преобладанием эмоциональных соображений над эффективностью (см. [13], [14], [15]).

Конфликт между этими двумя парадигмами не получил должного внимания в литературе по программной инженерии, возможно, потому что его затушёвывают: 1) спорами между Agile и Heavyweight (также известными как традиционные или управляемые по плану) методами разработки программного обеспечения [16]; и 2) спорами между позитивистскими и интерпретивистскими эпистемологическими подходами [17]. Рациональный/эмпирический конфликт является более фундаментальным, чем любой из этих. Конфликт гибких (Agile) и тяжеловесных (Heavyweight) методов касается того, какие методы использовать; конфликт рациональные/эмпирические касается того, используются ли методы и полезны ли они. Конфликт позитивистов и интерпретистов касается того, как собирать и анализировать эмпирические данные; конфликт рационалов и эмпириков касается того, нужно ли собирать и анализировать эмпирические данные.

Хотя многие внесли свой вклад в прояснение этих двух парадигм (например, [1], [2], [3], [5], [9]), их точный состав и лежащие в их основе философские предположения остаются неоднозначными. Более того, интерпретация и последствия этих двух парадигм для контекстов программной инженерии не очень хорошо понятны. В связи с этим возникает следующий исследовательский вопрос.

Вопросы исследования: Каковы парадигмы рационального и эмпирического проектирования, их эпистемологические предположения и последствия для разработки программного обеспечения?

Здесь под проектированием понимается определение свойств объекта путем создания модели, прототипа или самого объекта [18]. Проектирование «включает в себя все виды деятельности, связанные с концептуализацией, структурированием, реализацией, вводом в эксплуатацию и, в конечном счете, модификацией сложных систем — а не только деятельность после спецификации требований и перед программированием, как это может быть переведено из стилизованного процесса программной инженерии» [19]. (Идея о том, что проектирование — это фаза разработки, является частью рациональной парадигмы; см. раздел 3). Между тем, эмпирическое относится ко всем исследованиям, которые собирают и анализируют качественные или количественные данные, и его не следует смешивать с экспериментальным или позитивистским.

Отвечая на поставленный выше исследовательский вопрос, данная статья вносит три вклада:

1. Она объясняет различия эпистемологических позиций, лежащих в основе двух парадигм (раздел 2).
2. Даётся чёткое определение рациональной и эмпирической парадигм с примерами их компонентов (раздел 3).
3. Описываются последствия двух парадигм для исследований и практики программной инженерии (Раздел 4).

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

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

В эпистемологии знание означает «обоснованное, истинное убеждение»¹. Рационалисты и эмпиристы в корне расходятся во мнениях о том, что представляет собой законное обоснование. В широком смысле эмпиризм — это мнение, что единственным источником обоснования является наблюдение. Рационализм — это мнение о том, что некоторые знания могут быть обоснованы разумом и интуицией, в качестве или вместо наблюдения. Рациональная парадигма опирается на философию рационализма [5].

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

Рационализм и эмпиризм субъективны [20]; например, можно одновременно придерживаться рационализма в математике и эмпиризма в психологии. В рамках одной предметной области рационализм и эмпиризм являются взаимоисключающими. Человек является эмпириком в предметной области S, если он принимает следующий тезис:

1. «Тезис эмпиризма: У нас нет другого источника знания в S или для понятий, которые мы используем в S, кроме чувственного опыта» [21, курсив оригинала].

Напротив, человек является рационалистом в отношении S, если он предлагает какой-либо дополнительный источник знания о S, помимо чувственного опыта. Рационалисты обычно выдвигают некую комбинацию интуиции и нашей рациональной природы, представленную следующими тремя тезисами:

2. «Тезис об интуиции/дедукции: Некоторые утверждения в ... S мы можем познать только с помощью интуиции; другие же познаются путем дедукции из интуитивных утверждений».

3. «Тезис о врожденном знании: Мы обладаем знанием некоторых истин в определённой предметной области, S, как частью нашей рациональной природы».

4. «Тезис о врожденных понятиях: Мы обладаем некоторыми понятиями, которые мы используем в определённой предметной области, S, как частью нашей рациональной природы» [21 оригинальный курсив].

Многие рационалисты также принимают два связанных между собой тезиса:

5. «Тезис о незаменимости разума: Знания, которые мы получаем в предметной области S с помощью интуиции и дедукции, а также идеи и примеры знаний в S, которые нам присущи, не могли бы быть получены нами с помощью чувственного опыта».

6. «Тезис о превосходстве разума: Знания, которые мы получаем в предметной области S с помощью интуиции и дедукции или имеем врождённый характер, превосходят любые знания, полученные с помощью чувственного опыта» [21, оригинальный курсив].

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

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

Если вышеупомянутый математик, теоретик игр или экономист утверждают, что их теории не могут возникнуть на основе эмпирических исследований, они принимают тезис о незаменимости разума. Если несогласный приводит явно противоречащие друг другу эмпирические наблюдения, а математик, теоретик игр или экономист игнорирует эмпирические данные в пользу своих логических доказательств, они принимают тезис о превосходстве разума. Хотя в современных статьях редко встречаются подобные заявления, Парнас [23] принимает как тезис о незаменимости разума, так и тезис о превосходстве разума в отношении программной инженерии. Он утверждает, что необходимо больше математических доказательств, поскольку «то, что можно узнать из эмпирических исследований, хотя и важно, но очень ограничено» (стр. 2), и отвергает экспериментальные (стр. 4) и опросные исследования (стр. 5) как ненадёжные по своей сути.

Современные примеры тезиса о врождённом знании и тезиса о врождённой концепции менее распространены. Универсальная грамматическая теория утверждает, что определённые грамматические структуры и способность к изучению грамматики заложены в человеке с рождения, но проявляются только у детей, которые подвергаются воздействию языка [24]. Некоторые считают, что это согласуется с тезисами о врождённом знании и врождённой концепции [25]. Однако предполагаемые грамматические структуры не совсем являются знаниями или концепциями в философском смысле [26].

Эмпирики считают, что знание может быть обосновано только чувственным опытом. Для эмпириков чувственный опыт (т. е. наблюдение) является окончательным арбитром истины [27]. Если здравый смысл и интуиция не согласны с наблюдениями, то здравый смысл и интуиция ошибаются. Это не означает, что эмпирики отказываются от использования логики или интерпретации теорий и доказательств. Скорее, эмпирики рассматривают результаты рассуждений, интуиции, интерпретации и так далее, как предположения или убеждения, а не как знания.

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

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

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

Очевидно, что люди сильно различаются в своих эпистемологиях. Можно одновременно придерживаться различных подходов к рационализму или эмпиризму в разных областях (например, тезис о врождённой концепции в языке и герменевтика в социологии). Аналогичным образом, отдельный человек или текст может выдвигать значимые или самопротиворечивые гибриды рационалистических и эмпирических взглядов.

Дебаты о рационализме и эмпиризме в основном велись в Древней Греции между Платоном (рационалистом) и Аристотелем (эмпириком), а также в Европе XVII-XIX веков между рационалистами, включая Декарта, Канта, Лейбница и Спинозу, и эмпириками, включая Беркли, Юма, Локка и Милля [21], [28]. Однако некоторые современные философы, в том числе Роберт Брэндом, по-прежнему принимают и защищают рационалистические позиции. Что ещё более важно, рационалистическая риторика по-прежнему используется для обоснования или нападок на теории и исследования во многих областях, включая математику, экономику и информатику. Специалисты, не занимающиеся наукой, регулярно принимают рационалистические взгляды (см. раздел 4.3); например, отвергая контринтуитивные эмпирические данные как противоречащие здравому смыслу, они неявно принимают тезис о превосходстве разума.

Прежде чем продолжить, необходимо прояснить два распространённых заблуждения. Вкратце, эмпиризм не эквивалентен логическому позитивизму, а «Тезис об эмпиризме» не является защитой анекдотических свидетельств.

Эмпиризм иногда смешивают с логическим позитивизмом (например, [29], [30]). Логический позитивизм предполагает, что теории подтверждаются однозначными фактами, обнаруженными непредвзятыми наблюдателями. Антипозитивизм и постмодернизм в более широком смысле отвергают существование однозначных фактов и предполагают, что предвзятые наблюдатели строят теории на основе наблюдений, которые они интерпретируют на основе существующей теории. Тезис эмпиризма просто утверждает, что не существует источников знания, помимо наблюдений. Эмпиризм не делает никаких утверждений о существовании однозначных фактов, предвзятости наблюдателей или о том, как факты соотносятся с теориями.

Эмпиризм предшествовал философским дебатам XX века между позитивизмом, антипозитивизмом, модернизмом, постмодернизмом, конструктивизмом и т. д. В контексте конфликта между рационализмом и эмпиризмом логический позитивизм, фальсификационизм, прагматизм, интерпретационизм, конструктивизм и байесовская эпистемология могут рассматриваться как версии эмпиризма [31], так же как тезисы об интуиции/дедукции, врожденной концепции и врожденном знании могут рассматриваться как версии рационализма.

Второе распространённое заблуждение связано с анекдотическими фактами. Предположим, что программист разрабатывает несколько сайтов электронной коммерции. Далее предположим, что программист утверждает, что знает, что эти проекты используют Ruby on Rails, основываясь на наблюдении (и написании) кода. Это вызывает тезис об эмпиризме. Наблюдения программиста обосновывают это утверждение о знании. Программисту не нужно проводить формальное исследование, чтобы узнать, какой язык используется в проекте.

Однако предположим, что программист утверждает, что сайты успешны, потому что в них используется Ruby on Rails. Это убеждение не обосновано наблюдениями программиста. Программист интуитивно понял, а не наблюдал причинно-следственную связь. Программист неявно утверждает, что интуитивно очевидно, что проекты были успешными благодаря, а не вопреки используемому языку. Это ссылается на рационализм — в частности, на тезис об интуиции/дедукции. Эмпиризм считает, что знания обосновываются только наблюдением, а не комбинацией наблюдения и интуиции.

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

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

Точное определение рациональной и эмпирической парадигм является сложной задачей. Однако мы можем пойти по пути конструирования, то есть обсудить ряд взаимосвязанных конфликтов, а затем собрать определения из этих конфликтов. Помимо эпистемологий, лежащих в их основе и рассмотренных в предыдущем разделе, очевидны по меньшей мере пять основных конфликтов: 1) модель проектирования; 2) теория действия; 3) взгляды на успех и требования; 4) модели и теории процесса; и 5) практическая цель и фокус.

Как в рациональной, так и в эмпирической парадигмах проектирование в широком смысле означает определение свойств артефакта. Однако обе парадигмы имеют разные «модели проектирования», то есть взгляды на то, кто и как определяет свойства артефакта. Модель проектирования рациональной парадигмы иногда называют технической рациональностью, а модель проектирования эмпирической парадигмы — рефлексией в действии.

Техническая рациональность была независимо разработана в информатике Гербертом Саймоном, Алленом Ньюэллом и их соавторами (см. [7], [32]) и в инженерии Герхардом Палем, Вольфгангом Бейцем и их соавторами (см. [6]). Специалисты по проектированию моделируются как рациональные агенты, пытающиеся оптимизировать кандидата на проектирование с учётом известных ограничений и целей. Когда проблемное пространство достаточно велико, чтобы сделать оптимизацию неразрешимой, учитывая ограниченную вычислительную мощность проектировщика, проектировщик будет «удовлетворять» или «находить решения, которые достаточно хороши», используя эвристический поиск [7]. Шён [9] назвал эту точку зрения «технической рациональностью».

Рефлексия в действии явно представлена как альтернатива технической рациональности [9]. Рефлексия в действии моделирует проектирование как рефлексивный разговор, в котором проектировщик чередует фрейминг (концептуализацию проблемы), совершение шагов (шаг — это реальное или смоделированное действие, направленное на улучшение ситуации) и оценку этих шагов [9]. Шён не говорил, что техническая рациональность неправильна или неэффективна; он говорил, что обычно ограничения и цели неизвестны, поэтому проектировщикам приходится конструировать проблему и решение вместе. Более поздние исследования показали, что поиск не является хорошим способом описания проектного мышления [33], а проектировщики не могут надёжно оценить качество кандидата на решение на бумаге (см. [5]).

В программной инженерии техническая рациональность согласуется с представлением о том, что в проектах есть проектная деятельность или фаза, которая отделена от требований, анализа, программирования и тестирования. Эта фаза проектирования иногда ассоциируется с архитектурой программного обеспечения и рассматривается как определяющая большинство или все важные свойства программного артефакта. Рефлексия в действии согласуется с идеей о том, что анализ ситуации и проектирование системы — это единый, неразрывный процесс. Более того, многочисленные исследования показали, что разработчики принимают проектные решения в процессе кодирования (ср. [34], [35]), а рефакторинг уже давно понимается как разновидность проектирования [36]. Другими словами, проектирование пронизывает программный проект, а свойства артефакта определяются на протяжении всей его разработки; например:

• продавцами, продающими предлагаемое решение
• аналитиками во время постановки задачи
• переговорщиками во время обсуждения контракта
• менеджером проекта или владельцем продукта во время совещания по планированию
• разработчиком программного обеспечения во время программирования, рефакторинга или исправления ошибок

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

Техническая рациональность и рефлексия в действии различаются по своему эпистемическому обоснованию. Рефлексия в действии коренится в прагматизме [9], который является формой эмпиризма [37]. Для обоснования рефлексии в действии Шён ссылается на обширные наблюдения за профессиональными проектировщиками. Расширения рефлексии в действии также основаны на эмпирических исследованиях (например, [14]). В отличие от этого, техническая рациональность ссылается на тезис об интуиции/дедукции, полагаясь на рационалистическое обоснование. Саймон не приводит никаких наблюдательных исследований для обоснования точности утверждений «технической рациональности» о том, как думают и ведут себя реальные проектировщики. Например, Саймон утверждает, что «системы решения проблем и процедуры проектирования в реальном мире ... должны искать подходящие узлы» [7, курсив оригинала]. Он не приводит никаких эмпирических доказательств в поддержку этого утверждения, которое впоследствии было опровергнуто эмпирическими исследованиями [38], [39].

Саймон также считает, что проектировщики проявляют «процедурную рациональность». «Поведение процедурно рационально, когда оно является результатом соответствующего обдумывания» [40]; то есть, хотя они могут и не найти оптимального решения, они действуют рационально, учитывая ограниченность их вычислительной мощности. И снова не приводится никаких эмпирических данных, подтверждающих предположение о том, что проектировщики процедурно рациональны на практике, и оно не согласуется с эмпирическими наблюдениями [34], [35].

Для ясности, «техническая рациональность» и «рефлексия в действии» — это научные описания того, как профессионалы действуют на месте. Они не являются методами. Никто не утверждает, что «рефлексия в действии» и «техническая рациональность» могут быть приняты по желанию, или что их принятие улучшит производительность. Критика технической рациональности Шёном заключается в том, что люди не действуют так в реальной жизни, а не действовать так — неэффективно.

Эти две парадигмы также используют различные модели человеческого действия. В рациональной парадигме широко распространено предположение, что человеческое действие — это преимущественно план-исполнение. Эта «модель планирования» человеческого действия подразумевает три предположения: 1) планирование является предпосылкой для действия, 2) акторы понимают свои действия и прогресс с точки зрения плана, и 3) хорошее планирование является основным фактором успеха [41]. В эмпирической парадигме широко распространено предположение, что человеческое действие — это преимущественно импровизация. Эта «импровизационная модель» человеческого действия утверждает, что «организация расположенных действий является эмерджентным свойством мгновенных взаимодействий между акторами, между акторами и средой их действий», в то время как «планы — это репрезентации или абстракции над действиями» [42].

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

Сторонники модели планирования склонны апеллировать к здравому смыслу или другим интуитивным обоснованиям того, что человеческие действия ориентированы на план (например, [43]), неявно принимая тезис об интуиции/дедукции. Напротив, сторонники импровизационной модели (например, [41], [44]) склонны принимать тезис об эмпиризме, ссылаясь на эмпирические исследования и приводя эмпирические наблюдения для его обоснования. Эмпирические исследования показывают, что человеческие действия — это не просто план-исполнение, поскольку люди часто отклоняются от детальных планов, планирование часто происходит по касательной к действиям, а некоторые действия вообще не планируются (см. обзор в [41]). Проектировщики будут утверждать, что следуют плану, даже явно отклоняясь от него [45]. Как и Шён [9] с «рефлексией в действии», Сучман [41], [42] деконструирует мировоззрение, которое интуитивно привлекательно, но противоречит эмпирическим наблюдениям.

Опровержение модели планирования является крайне противоречивым. Ученые обычно выдвигают как минимум два возражения:

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

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

Второе возражение смешивает планирование с перспективным смыслообразованием. Смыслообразование — это процесс осмысления или придания значения опыту [46]. Осмысление прошлого опыта называется ретроспективным смыслообразованием. Исследование и интерпретация воображаемого будущего, включая разработку стратегии и планирование (то есть смыслообразование проектировщиков [47]), называется перспективным смыслообразованием. Другими словами, «как можно создавать сложное программное обеспечение без хорошего планирования?» смешивает планирование с подготовкой. Планирование — это только один из способов подготовки, а большая часть подготовки в программных проектах, включая написание историй и сценариев, лучше понимать как перспективное смыслообразование [48]. Опять же, импровизационная модель не оправдывает и не поощряет ковбойское программирование или отношение «просто сделай без подготовки».

В программной инженерии модель планирования лежит в основе представления стадий или жизненного цикла на процесс проектирования [49], планирования и производительности в методах Agile и Heavyweight (ниже) и исследований по контролю (например, [50], [51]). В то же время Импровизационная модель лежит в основе телеологических взглядов на процессы проектирования [10], [52], неметодической разработки (ниже) и исследований по вопросам возникновения, сложности и парадоксальности (например, [44], [53], [54]).

Кроме того, техническая рациональность и многие методы разработки программного обеспечения представляют проектирование как вид планирования; в частности, преобразование спецификации требований в план создания артефакта (см. [55], [56], [57]). Это снова смешивает планирование с перспективным смыслообразованием. Рефлексия в действии, напротив, рассматривает проектирование как своего рода импровизацию, в которой проектировщик одновременно уточняет проблему и кандидата на решение (см. [9], [10], [58]). Таким образом, проект рассматривается как система исследований, в которой проектировщики совместно с заинтересованными сторонами конструируют желаемое и генерируют решения, создавая артефакты в мире, а не планируя их в уме.

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

Исследования в рамках рациональной парадигмы, как правило, моделируют успех на основе треугольника проекта (также называемого железным треугольником). То есть успех означает выполнение согласованных требований (объема) в рамках бюджета, в срок и с приемлемым уровнем качества [59]. Исследования в рамках эмпирической парадигмы, напротив, склонны моделировать успех на основе влияния системы на заинтересованные стороны [60], [61]. Эти взгляды существенно различаются по эпистемическому обоснованию. Треугольник проектов не является научной теорией — его происхождение неясно, и ни одно эмпирическое исследование не подтверждает его пригодность в качестве теории для понимания успеха.

Пользователи проектного треугольника склонны просто ссылаться на него без обоснования или просто утверждать, что он очевиден (т. е. ссылаться на гипотезу интуиции-дедукции). Сторонники взгляда «заинтересованные стороны — влияние» обычно проводят или рассматривают эмпирические исследования, подтверждающие их модели (например, [60], [61]). Они склонны приводить примеры систем, которые широко считаются успешными несмотря на то, что они были поставлены с опозданием, превысили бюджет или не соответствовали спецификации [62].

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

• дезидераты (далее — «пожелания»): свойства реальной или воображаемой системы, которые желают получить или в которых нуждаются одна или несколько заинтересованных сторон [5]; и
• требования: свойства, которыми должна обладать реальная или воображаемая система [18].

Другими словами, «пожелания» включают в себя все свойства системы, которые хочет или в которых нуждается одна или несколько заинтересованных сторон, а требования — это подмножество желаемых параметров, необходимых для успеха. В разделе 2 мы рассмотрели, как рационалисты и эмпирики различаются во взглядах на то, что оправдывает убеждения. Точно так же исследования в рамках рациональной и эмпирической парадигм различаются в своих взглядах на то, что оправдывает называние дезидератов «необходимостью успеха», то есть требованием.

Например, предположим, что мы разрабатываем систему расчёта заработной платы. Далее предположим, что организация-заказчик требует, чтобы система использовала надёжные пароли, и мы добавляем эквивалентное условие в контракт. Предположим, никто не спорит с тем, что надёжные пароли — это обязательное условие.

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

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

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

Исследования в области разработки требований пытались признать эти виды возражений, вводя «необязательные требования», уровни приоритета (например, [63]) и уровни уверенности (например, [64]). В эмпирической парадигме все требования, кроме некоторых из наиболее приоритетных и высокодостоверных, будут рассматриваться как предпочтения и предположения.

Более того, разная философия приводит к тому, что терминология и допущения в двух парадигмах сильно отличаются. В рамках рациональной парадигмы аналитики «выясняют» требования, опрашивая заинтересованные стороны, или «обнаруживают» их, изучая унаследованные системы и анализируя дискурс [65]. Затем аналитик стремится создать «однозначную», «последовательную», «полную», «выполнимую», «прослеживаемую» и «верифицируемую» спецификацию требований [66]. Такие термины, как «выявить» и «обнаружить», свидетельствуют о предположении, что требования существуют в независимой от наблюдателя объективной реальности. Это предположение пронизывает отраслевые стандарты (например, [66]), методы разработки программного обеспечения (например, [67], [68]) и учебные программы по моделированию (например, [69], [70]).

Напротив, исследования в эмпирической парадигме обычно предполагают, что социальная реальность субъективна. Все знания, включая требования, рассматриваются как сконструированные, а не обнаруженные [71]. Более того, «одной из основных тем, возникших в поведенческих исследованиях принятия решений за последние три десятилетия, является мнение о том, что предпочтения людей часто конструируются в процессе их выявления» ([72], п. i). Поэтому разработка требований — это творческий процесс [73], в котором аналитики и заинтересованные стороны совместно осмысливают текущую ситуацию и строят общую ментальную модель возможной системы [74]. Это не означает, что эмпирическая парадигма противоречит проектированию требований или даже большому предварительному проектированию. Это означает, что большинство результатов разработки требований рассматриваются как «пожелания», идеи или предположения, а не требования как таковые.

В рациональной парадигме аналитик рассматривается как обнаруживающий требования в объективной реальности. Поэтому результаты «извлечения» с готовностью принимаются как требования. В эмпирической парадигме, напротив, аналитик рассматривается как со-конструирующий предпочтения вместе с заинтересованными сторонами, и успех кандидата на разработку можно определить только путём его конструирования (см. [5]). Поэтому результаты интервью с заинтересованными сторонами, фокус-групп, предварительных анализов и переговоров по контракту рассматриваются в основном как дезидераты и предположения. Для того чтобы пожелание d стало требованием, оно должно удовлетворять двум условиям:

1. d необходимо для успешной работы системы, то есть любая система без d потерпит неудачу; и
2. наша вера в условие 1 оправдана, то есть мы знаем, что любая система без d потерпит неудачу. [75]

На практике многие вещи, представленные как требования, не соответствуют этим условиям, поэтому эмпирик отвергает большинство кажущихся требований как необоснованные «пожелания» (см. [75], [76], [77]). Это подкрепляет мнение о том, что проектирование больше похоже на импровизацию, чем на планирование (см. [39], [78]), и что постановка проблемы и генерация решения являются одновременными и взаимосвязанными [9]. Рационалист, напротив, может провести чёткие дедуктивные линии между заданными проблемами, чёткими, выявленными требованиями и в значительной степени независимой, ориентированной на планирование фазой проектирования.

Разработчики программного обеспечения занимаются огромным количеством видов деятельности, включая абстрагирование, ассоциирование, принятие решений, сбор информации, моделирование, поиск, выбор и синтез [79]. Многие исследователи организовали эти низкоуровневые виды деятельности в более высокоуровневые категории, чтобы управлять когнитивной нагрузкой и понимать процесс разработки. В результате появилось множество моделей и теорий процессов. Для целей данной статьи модель процесса — это «абстрактное описание реального или предлагаемого процесса, представляющее выбранные элементы процесса, которые считаются важными для целей модели и могут быть реализованы человеком или машиной» [80]. Между тем, теория процесса — это объяснение того, как и почему изменяется и развивается объект [81].

Мы можем классифицировать модели и теории процессов в зависимости от того, какая парадигма лучше отражает их предположения (табл. 1). Неудивительно, что модели, отнесенные в Таблице 1 к эмпирической парадигме, преимущественно создаются на основе эмпирических наблюдений [10], [82], [83], [84], [85] или обосновываются ими. Напротив, те, что отнесены к рациональной парадигме, в основном генерируются и обосновываются с помощью аргументации, интуиции, дедукции и анекдотических свидетельств [8], [55], [86], [87], [88], [89].

Помимо эпистемологии, эти модели различаются как минимум по трем направлениям:

1. Модели эмпирической парадигмы являются преимущественно описательными или объяснительными, что очевидно из их соответствующих текстов. Модели рациональной парадигмы все прескриптивные. Это очевидно из текстов, представляющих модели Spiral, V, Pull и Essence. Ройс явно утверждал, что модель Waterfall, ориентированная только на перспективу, неэффективна; однако многие другие отстаивали Waterfall, и более итеративная модель, предложенная Ройсом, также является частью рациональной парадигмы. Геро был менее очевидным предписателем, но более поздний анализ показывает, что его модель была одновременно описательной и предписывающей [90]. Конечно, тексты, предлагающие модели эмпирической парадигмы, иногда дают предложения, а тексты, предлагающие модели рациональной парадигмы, иногда описывают и объясняют — это вопрос степени.
2. Модели и теории процессов бывают четырех основных видов [91]: жизненный цикл (последовательность фаз), эволюционный (развивающиеся популяции), диалектический (конфликт между несколькими сущностями) и телеологический (агент, ориентированный на достижение цели и выбирающий действия). Все Рациональные модели, кроме фреймворка функции-поведения-структуры, представлены в виде жизненных циклов. Ни одна из эмпирических моделей не представлена как жизненный цикл — теория расстояний и теория Сабхервала и Ньюмана являются диалектическими теориями, остальные — телеологическими. Это поразительно, поскольку подходы, основанные на жизненных циклах, критиковались как слишком негибкие для теоретизирования человеческого поведения [92].
3. Эти две категории моделей используют существенно различную терминологию. Рациональные модели склонны организовывать деятельность по разработке в небольшие вариации требований, анализа, проектирования, кодирования и тестирования — здесь они называются таксономией Ройса из-за их сходства с моделью водопада. Все эмпирические модели существенно отклоняются от таксономии Ройса.

Таксономия Ройса — а не какая-то конкретная последовательность — была неявно принята в качестве доминирующей теории процесса разработки программного обеспечения [5]. То есть многие исследовательские статьи, учебники и стандарты предполагают:

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

Например, Фицджеральд [93] утверждает, что «в традиционной разработке программного обеспечения жизненный цикл разработки в его наиболее общей форме состоит из четырёх широких фаз: планирование, анализ, проектирование и реализация» (стр. 3). Аналогично, Эвуси-Менсах [94] говорит, что «независимо от конкретной модели процесса ... каждый проект программного обеспечения будет включать: (1) этап определения требований и функциональной спецификации; (2) этап проектирования; ... (3) этап реализации; ... и (4) этап установки, эксплуатации и сопровождения» (стр. 51). Кроме того, Лаудон и другие [95] утверждают, что «разработка систем ... состоит из системного анализа, системного проектирования, программирования, тестирования, преобразования, производства и обслуживания ... которые обычно происходят в последовательном порядке». Более того, таксономия Ройса отражена в Руководстве IEEE по своду знаний по программной инженерии [96] и неявно принята во многих стандартах (например, [66], [89], [97]).

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

Таксономия Ройса является проблематичной классификацией, поскольку она не упорядочивает подобное с подобным. Рассмотрим, например, этап проектирования. Некоторые проектные решения принимаются «аналитиками» во время, казалось бы, «выяснения требований», другие — «проектировщиками» во время «совещания по проектированию», третьи — «программистами» во время «разработки» или даже «тестирования». Это означает, что категория «проектирование» не обладает ни высокой сплоченностью, ни свободной связью. Аналогично, рассмотрим этап «тестирование». Некоторые виды тестирования часто выполняются «программистами» на этапе якобы «разработки» (например, статический анализ кода, исправление ошибок компиляции), а другие — «аналитиками» во время, казалось бы, «выяснения требований» (например, приёмочное тестирование). Юнит-тестирование, тем временем, включает в себя разработку и написание юнит-тестов.

Поскольку таксономия Ройса не объединяет похожие виды деятельности, она не позволяет делать множество полезных выводов. Например, предположим, мы знаем, что деятельность A относится к классу «тестирование». Что ещё мы можем заключить об А? Поскольку тестирование включает в себя столь разнообразные виды деятельности, мы не можем сделать вывод о том, кто в них участвует (программисты? аналитики? пользователи?), какие навыки необходимы (межличностные? технические?) или когда происходит тестирование (в начале проекта? в конце? на протяжении всего проекта?).

Поэтому не стоит удивляться, что модели и теории, основанные на эмпирических наблюдениях, предлагают терминологию и организацию, значительно отличающиеся от таксономии Ройса. Например, диалектическая теория Сабхервала и Ньюмана [83] в основном рассматривает отношения между постоянством и изменениями, а не анализ и проектирование или кодирование и тестирование. Бумеранг игрового тестирования [84] утверждает, что разработка цифровых игр в первую очередь определяется непрерывным игровым тестированием. Под плейтестингом понимается процесс, когда разработчик играет в игру, чтобы оценить качественные характеристики, включая погружение, баланс и сложность [100]. Плейтестинг принципиально отличается от тестирования в Таксономии Ройса или даже Test Driven Development [101] тем, что делает акцент на динамике и эстетике системы, а не на её производительности, возможностях и ошибках.

Между тем, теория смыслообразование-коэволюция-реализация [10], [102] явно реорганизует деятельность по разработке, чтобы улучшить согласованность и взаимосвязь. Смыслообразование объединяет анализ, ориентированный на домен или среду (например, разработку персон [103]), с тестированием, ориентированным на пользователя (например, приемочным тестированием). Реализация объединяет низкоуровневые проектные решения (например, между циклом for и циклом while) с кодированием и техническим тестированием (например, юнит, интеграция, система, производительность). Коэволюция объединяет высокоуровневые проектные решения (например, архитектурные паттерны) с анализом, ориентированным на решение (например, анализом кандидатов на проектирование).

В целом, модели и теории процессов, связанные с рациональной парадигмой:

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

Напротив, модели и теории, связанные с эмпирической парадигмой:

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

Метод разработки систем, или просто метод, обозначает набор взаимосвязанных предписаний для эффективного построения систем и подразумевает упорядоченные, предсказуемые подходы, применимые в различных условиях [104]. Методы часто делят на две группы (см. [16]) — Agile-методы, включая Scrum [105], Extreme Programming [88] и Lean [106], и Heavyweight-методы, включая The Rational Unified Process [107], PRINCE2 [108] и водопадную модель [8]. На первый взгляд, Agile-методы больше соответствуют эмпирической парадигме, в то время как тяжеловесные методы — рациональной парадигме. Однако в более фундаментальном плане ситуация неоднозначна.

Что касается эпистемологии, то эффективность методов обычно обосновывается с помощью комбинации анекдотических свидетельств, аргументов, интуиции и дедукции. Как объясняется в разделе 2.3, использование анекдотических свидетельств для обоснования ненаблюдаемых свойств, таких как эффективность, относится к рационализму. В инженерных исследованиях от создателей новых артефактов, включая методы, обычно ожидают демонстрации того, что предлагаемый артефакт превосходит существующий базовый артефакт [109], [110], [111]. Ни в одной из книг, где предлагается какой-либо из методов, обсуждаемых в этой статье, нет такой эмпирической демонстрации. Более того, мне неизвестно ни одно достоверное исследование, демонстрирующее, что какой-либо метод превосходит любой другой метод по какому-либо измеряемому параметру (см. [58], [112]).

Сторонники методов иногда ссылаются на эмпирические исследования, которые поддерживают некоторые аспекты метода, но не сам метод. В частности, сообщество Agile предложило множество якобы Agile-практик, ни разу не продемонстрировав, что какая-либо из этих практик сделала конкретную команду разработчиков более гибкой. Вместо этого они тонко переопределяют гибкость как степень, в которой команда придерживается их рекомендаций (циклический аргумент), а не как степень, в которой практика делает команду более проворной и отзывчивой (см. [113], [114]). В итоге, хотя литература по методам не принимает рационализм в явном виде, она неявно ссылается на него, опираясь на интуитивные аргументы и анекдотические свидетельства.

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

Agile-методы иногда представляют анализ и проектирование как взаимосвязанные, что соответствует принципу «отражение в действии», но это не всегда очевидно. И Scrum, и XP начинают каждый спринт с совещания по планированию, которое ограничено по времени, что предполагает чёткое разграничение между проектированием и разработкой. Аналогично, процесс пополнения бэклога (постановка задачи) часто представляется как в значительной степени оторванный от процесса определения того, как реализовать элементы бэклога (решение задачи).

Всё осложняется тем, что в литературе по Agile редко используются такие термины, как постановка задачи, генерация концепции проектирования или коэволюция. Фактически, в основополагающих книгах по XP [88], Scrum [105], [115] и Lean [106] мало что говорится о том, как команды разработчиков программного обеспечения генерируют и оценивают высокоуровневые проектные альтернативы или принимают низкоуровневые проектные решения. В общем, если тяжелые методы обычно используют техническую рациональность, то Agile-методы не имеют чёткой или последовательной модели проектирования.

Отношения между конфликтом импровизации/планирования и конфликтом Agile/Heavyweight также сложны. Тяжеловесные методы чётко соответствуют модели планирования, но Agile-методы не соответствуют ни одной из моделей. С одной стороны:

• В Манифесте Agile чётко выражена ценность «реагирования на изменения, а не следования плану» [116].
• Agile-методы, очевидно, не предполагают такого большого количества планирования, как Heavyweight-методы.

С другой стороны:

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

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

Более того, конфликт планирования/импровизации — это не спектр с серединой, которую можно занять. Модели планирования и импровизации делают противоречивые предсказания о когнитивных процессах, лежащих в основе человеческих действий. Либо когниция разработчика преимущественно расположена к импровизации, либо к планированию-исполнению; у нас нет теоретической основы для гипотезы об их сочетании. Предполагая, что истина лежит между ними, мы заблуждаемся.

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

Тексты эмпирической парадигмы, как правило, описывают и объясняют, как действуют профессионалы в области программного обеспечения. Значительная часть эмпирической парадигмы включает в себя качественные исследования, которые генерируют концепции, темы, таксономии или теории процессов (см. раздел 3.4). Если в текстах эмпирической парадигмы и даются рекомендации, то они, как правило, касаются отдельных практик и инструментов, а не комплексных методов. В отличие от методов, многие исследования эмпирически сравнивают конкретные практики по измеряемым параметрам. Например, Ханней и др. рекомендуют «парное программирование либо при низкой сложности задачи и важности времени, либо при высокой сложности задачи и важности корректности» [117] на основе мета-анализа экспериментов по парному программированию. Ханней и др. ссылаются на «Тезис эмпиризма», обосновывая свои предложения на основе эмпирических исследований.

Тексты в рамках рациональной парадигмы склонны предписывать как конкретные методы, так и методичность в целом. Хотя не все методы разработки программного обеспечения однозначно соответствуют рациональной парадигме, рациональная парадигма явно охватывает методы в той мере, в какой эмпирическая парадигма этого не делает. Рациональная парадигма включает в себя множество текстов, призывающих разработчиков действовать методично и рационально (например, [32], [118], [119], [120]). Даже когда эти тексты признают, что идеально рациональная разработка невозможна, они утверждают, что рациональность и методичность желательны и должны быть максимизированы [119]. С этим связано утверждение, что большинство или все проекты следуют одной и той же последовательности фаз или жизненному циклу [8], [67], [68] — см. выше. В этих текстах часто делаются допущения, схожие с допущениями Технической рациональности; например, Ройс [8], Крухтен [107] и Якобсон и другие [121] представляют решение проблемы и постановку задачи как слабо связанные между собой.

Эмпирическая парадигма, напротив, склонна отвергать универсальность и признавать, что более систематический подход может быть лучше в одних контекстах (см. [122]), а менее систематический подход — в других (см. [44]). Неметодическое развитие «подразумевает управление и оркестровку развития систем без заранее определённой последовательности, контроля, рациональности или претензий на универсальность» [104] и подразумевает деятельность, которая является уникальной и непредсказуемой, но не хаотичной.

Эмпирическая парадигма уважает реальность, в которой методы не используются ни широко, ни эффективно [123], [124], [125], [126], методы не могут быть использованы напрямую [127], разработчики тратят время на симулирование использования методов [128], [129], импровизация является основой большей части деятельности по разработке [44], [52], [130], [131] и «неметодическая разработка может быть нормальным способом, которым создание этих систем происходит в реальности» [104].

Подобно Шену [9] и Сучману [41], Труэкс и другие [104] выделяют интуитивно привлекательный нарратив, отмечают, что сторонники этого нарратива не предоставили эмпирических доказательств в поддержку своих утверждений, и перечисляют множество исследований, которые поддерживают другое мировоззрение. Чтобы было понятно, эти ученые не утверждают, что методы и методичность всегда вредны или что разработчики никогда не применяют методы. Они просто указывают на то, что эмпирические исследования не подтверждают ни эффективность методов, ни их широкое распространение. Как и планы, они рассматривают методы как слабые ресурсы для информирования и объяснения человеческого поведения.

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

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

Кун определил парадигму как «совокупность убеждений, ценностей, методов и так далее, разделяемых членами данного сообщества» [4]. Предшествующее обсуждение показывает, что в научной литературе по проектированию и разработке программного обеспечения представлены две совершенно разные совокупности убеждений, ценностей и методов. Одна группа преимущественно использует эмпирические исследования для обоснования описаний того, как разрабатывается программное обеспечение. Другая преимущественно использует рациональную аргументацию, интуицию, дедукцию и анекдотические свидетельства для обоснования рецептов того, как должно разрабатываться программное обеспечение. Эмпирическая и рациональная парадигмы — это мировоззрения, лежащие в основе каждой из этих групп. Сами мировоззрения состоят из множества взаимосвязанных компонентов, обобщенных в таблице 2. Более формально эти две парадигмы можно определить следующим образом.

Выяснение двух парадигм, приведённое выше, поднимает три фундаментальных вопроса:

1) как различные мировоззрения влияют на то, как учёные концептуализируют разработку программного обеспечения;

2) какая парадигма более полезна для понимания и улучшения разработки программного обеспечения; и

3) как рациональная парадигма может выжить в исследовательском сообществе, которое всё больше и больше обращается к эмпирическим данным?

В этом разделе мы рассмотрим каждый из этих вопросов.

Эмпирическая и рациональная парадигмы охватывают противоречивые метанарративы (вставка 1). Эти метанарративы включают в себя множество противоречивых позиций (табл. 3).

Примечание: ссылки, приведённые в этой таблице, являются примерами текстов, в которых принимается (а не доказывается) каждая из соответствующих позиций.

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

Такой взгляд на развитие в целом привлекателен по многим причинам. Он был разработан широко уважаемыми и влиятельными учёными. Он относительно прост и легко объясняется студентам. Он узаконивает разработку программного обеспечения, представляя её как инженерную деятельность. Он хорошо согласуется с существующими исследованиями в области искусственного интеллекта и теории полезности (например, [137]). Более того, его язык и допущения согласуются со многими методами и моделями процессов, включая PRINCE2 [108] и Интеграцию модели зрелости возможностей (Capability Maturity Model Integration) [138]. Она совместима с современными подходами к управлению, финансовому менеджменту и аутсорсингу [5]. Более того, будучи статус-кво, она пользуется преимуществами различных психологических предубеждений, которые препятствуют изменениям [139], [140].

Неудивительно поэтому, что рациональная парадигма является доминирующей в программной инженерии (а также в информационных системах, управлении проектами и некоторых других областях, но это выходит за рамки данной статьи), что видно из учебников [например, 95], типовых учебных программ [70], [141], стандартов (например, [66], [89], [97]), официальных сводов знаний (например, [96]), Википедии (см. [96]), статьях Википедии (например, вездесущий шаблон процесса разработки программного обеспечения), руководстве для исследований в области науки о проектировании [110], возведении таксономии Ройса в ранг фактической теории процессов (обсуждалось выше) и даже популярных концепциях научного процесса (например, [142], [143], [144]).

Однако уже в 1970-х годах исследователи начали указывать на то, что эта история не соответствует их наблюдениям:

1976: Организация делает то, что она делает, благодаря планам, намеренному выбору средств, которые позволяют организации согласовать цели, и все это достигается с помощью таких рационализированных процедур, как анализ затрат и выгод, разделение труда, определенные области свободы действий, полномочия, переданные в управление, должностные инструкции и последовательная система оценки и вознаграждения. Единственная проблема с этим портретом заключается в том, что он редко встречается в природе. Люди в организациях, в том числе образовательных, с трудом находят реальные примеры таких рациональных практик, или находят рационализированные практики, результаты которых были столь же благотворны, как и предсказывалось, или считают, что эти рациональные случаи объясняют большую часть того, что происходит в организации. Части некоторых организаций в значительной степени рационализированы, но многие части также оказываются неподдающимися анализу с помощью рациональных предположений. [145]

1983: Согласно модели технической рациональности — взгляду на профессиональное знание, который наиболее сильно сформировал как наше мышление о профессиях, так и институциональные отношения исследований, образования и практики — профессиональная деятельность состоит в инструментальном решении проблем, строгом применении научной теории и техники… Техническая рациональность зависит от согласия относительно целей… но когда цели запутаны и конфликтуют, ещё нет «проблемы», которую нужно решить… Точно так же, когда существуют конфликтующие парадигмы профессиональной практики… нет чётко установленного контекста для использования техники... и когда практики разрешают конфликтующие ролевые рамки, это происходит посредством своего рода исследования, которое выходит за рамки модели Технической Рациональности. [9]

1987: Поскольку обстоятельства наших действий никогда не могут быть полностью предвидены и постоянно меняются вокруг нас... наши действия, хотя и являются систематическими, никогда не планируются в том сильном смысле, в каком это было бы принято в когнитивной науке. Скорее, планы лучше рассматривать как слабый ресурс для того, что в основном является ситуативной деятельностью. Только когда нам приходится объяснять рациональность наших действий, учитывая предубеждения европейской культуры, мы прибегаем к руководству плана. Заранее сформулированные, планы неизбежно расплывчаты, поскольку должны учитывать непредвиденные обстоятельства конкретных ситуаций. Реконструированные в ретроспективе, планы систематически отсеивают именно те детали, которые характеризуют конкретные действия, в пользу тех аспектов действий, которые можно рассматривать как согласующиеся с планом. [42]

1992: Обычные представления о решении проблем часто опровергаются поведением проектировщиков-экспертов. Но проектирование имеет много отличий от обычного решения проблем [146]. Например, при проектировании «решение» не возникает непосредственно из «проблемы»; внимание проектировщика колеблется, или переключается, между ними, и постепенно развивается понимание обоих. [12]

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

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

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

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

• Как разработчики должны и как они на самом деле разрабатывают системы?
• Что является причиной успеха или неудачи программных проектов?
• Как конкретные инструменты, методы, поведение и условия влияют на программные проекты?

Техническая рациональность и рефлексия в действии используются для понимания проектной деятельности. В разных обстоятельствах каждый из них может быть использован для описания проектирования [1]. Суть аргумента Шёна в пользу рефлексии в действии заключается в том, что, когда проектировщик не только решает проблему, но и ставит её, «техническая рациональность оказывается радикально неполной» [9]. Другими словами, техническая рациональность бесполезна для понимания проектной деятельности в реальном мире, когда проблемы или цели проектирования неоднозначны, спорны или просто неизвестны (ср. [15]). В таких ситуациях проектировщики ставят проблемы и генерируют кандидатуры решений одновременно [9], [11], [12] — поведение, несопоставимое с технической рациональностью.

Аналогично, для понимания поведения используются модели планирования и импровизации действий. Сучман [42] делает вывод, что принятие модели планирования затушёвывает импровизацию и влияние контекста на интерпретацию действий. Она предрасполагает исследователя к более простым, post hoc рационализациям человеческого поведения [53]. Например, модель планирования затушёвывает эмпирический вопрос о том, помогает или мешает планирование в данной ситуации. Импровизационная модель более полезна, поскольку она способствует более тонким, менее предвзятым интерпретациям действий. Если говорить конкретно о разработке программного обеспечения, то эмпирические данные о главенстве импровизации (см. [44], [52], [131], [147]) свидетельствуют о том, что модель планирования будет особенно вводящей в заблуждение.

Хотя методы могут быть практически полезны для разработчиков и менеджеров [122], [148], [149], полезны ли они для решения научных головоломок? Очевидно, что если изучать команду, на которую сильно влияет определённый метод, то понимание метода может помочь нам понять команду. Тем не менее, значительные данные свидетельствуют о том, что методы не используются ни эффективно, ни широко [123], [124], [125], [126], [128], а когда используются, то не по назначению [125], [127], [150]. Скорее, «методологии рассматриваются в основном как необходимая фикция для создания образа контроля или обеспечения символического статуса, и они слишком механистичны, чтобы быть полезными в детальной, повседневной организации деятельности разработчиков систем» [151]. Поэтому анализ поведения разработчиков через призму методов, скорее всего, будет способствовать чрезмерно упрощенному и рационализированному взгляду на разработку, который затушёвывает сложность, парадоксы и врождённые противоречия [53]. Анализ успехов и неудач через призму методов также может зациклить исследователей на методичности [104] и фиктивных характеристиках метода (например, соответствие методу), а не на характеристиках команды (например, сплоченность команды) [152].

Аналогично, хотя модели и теории рациональных процессов могут быть полезны для разработчиков и менеджеров в некоторых ситуациях [153], они могут быть менее полезны для решения научных головоломок. Все описанные выше модели и теории рациональных процессов носят предписывающий характер. Как объясняют Вермаас и Дорст [90]: «Описательные модели... одинаково применимы как к успешным, так и к менее успешным проектам. Таким образом, прескриптивная модель явно не может быть описательной, поскольку в этом случае менее успешные случаи проектирования также соответствуют модели» (стр. 152). Поэтому анализ поведения, хода или результатов разработки с помощью моделей рациональных процессов побуждает исследователей игнорировать, преуменьшать или воспринимать как отклонение не предписанные модели поведения, независимо от их эффективности [154]. Это также может способствовать чрезмерному упрощению тесно взаимосвязанных видов деятельности до дискретных фаз, одновременных видов деятельности до последовательных фаз или сложных комбинаций прогрессии и регресса до неуклонного улучшения.

Например, предположим, что мы берём интервью у разработчиков. Используя концепции и предположения рациональной парадигмы, мы можем спросить: «Какую проблему вы пытаетесь решить?». Это нагруженный вопрос — он предполагает наличие единственной, чёткой, согласованной цели, что побуждает интервьюируемого назвать потенциальную проблему [155]. Используя концепции и допущения эмпирической парадигмы, мы, напротив, можем спросить: «Кто является заинтересованными сторонами в этом проекте?» и «В какой степени они согласны с его целями и задачами?». Не предполагая согласия, постановка этих вопросов побуждает участника задуматься об эпистемическом статусе потенциальных формулировок проблем.

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

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

Некоторые авторитетные журналы (например, Requirements Engineering) и конференции (например, Fundamental Approaches to Software Engineering) до сих пор публикуют исследования с небольшой эмпирической оценкой, а некоторые исследовательские сообщества (например, языки программирования) продолжают принимать анекдотические данные в технических исследованиях [156]. Тем не менее, сообщество исследователей программной инженерии, очевидно, добилось большого прогресса в методологии и научной строгости. Многие ведущие издания, включая International Conference on Software Engineering и IEEE Transactions on Software Engineering, все более скептически относятся к работам без эмпирических данных [157]. У нас есть хорошие журналы (например, Empirical Software Engineering) и конференции (например, Empirical Software Engineering and Measurement), посвящённые эмпирическим исследованиям. Кроме того, были опубликованы эмпирические руководства для нескольких типов исследований (например, [158], [159], [160]).

Тем не менее, многие исследования программной инженерии являются лишь поверхностными эмпирическими. Как объясняют Ко и другие [161]: «Эмпирические исследования, часто в форме контролируемых экспериментов, были широко распространены в исследованиях программной инженерии как способ оценки достоинств новых инструментов программной инженерии. Однако контролируемые эксперименты с участием людей, реально использующих новые инструменты, всё ещё редки, а когда они проводятся, некоторые из них вызывают серьёзные сомнения в достоверности» (стр. 110).

Предположим, мы разрабатываем инструмент, который генерирует примеры из моделей UML, чтобы помочь пользователям понять синтаксис и семантику UML. Одним из хороших способов оценки инструмента является контролируемый эксперимент, в котором некоторые потенциальные пользователи рандомизируются на две группы. Люди из контрольной группы изучают некоторые модели UML и отвечают на некоторые вопросы. Люди из экспериментальной группы изучают некоторые UML-модели с помощью инструмента и отвечают на некоторые вопросы. Мы предполагаем, что экспериментальная группа ответит на большее количество вопросов правильно, чем контрольная группа. Это напрямую связано с интересующей нас зависимой переменной — пониманием пользователя.

Многие исследования программной инженерии избегают такого рода прямой оценки. Общие стратегии включают следующее.

• Исследователи сообщают данные о технической производительности (например, количество семантически корректных примеров, сгенерированных из стандартного корпуса UML-моделей; время обработки). Это просто описание инструмента. Зависимая переменная, представляющая интерес, не измеряется.
• Исследователи применяют инструмент — сами — в реальном контексте и показывают, что он генерирует приемлемые примеры. Это демонстрирует, что инструмент может быть использован экспертами-исследователями, а не то, что он улучшает понимание у неэкспертных специалистов.
• Исследователи просят некоторых пользователей попробовать инструмент и высказать свое мнение о его полезности, удобстве использования и так далее. Это не является убедительной демонстрацией, поскольку предубеждение социальной желательности будет завышать положительные ответы.

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

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

Специалисты и исследователи в области программной инженерии часто отвергают эмпирические данные, если они противоречат их убеждениям. Специалисты по программному обеспечению «похоже, игнорируют эмпирические данные в пользу местного мнения» [162]. Деванбу и другие [163] обнаружили, что разработчики часто придерживаются сильных мнений «по идеологическим причинам (или из корыстных побуждений), даже перед лицом доказательств обратного»; следовательно, «убеждения практиков могут не совпадать с данными проекта». В то же время исследование Шарпа и др. по системам управления качеством программного обеспечения «показало, что у практиков было сильное чувство принадлежности к сообществам... где индивидуалист и его (редко её) мнения высоко ценятся, независимо от того, подкреплены они доказательствами или нет»; другими словами, «эмпирические данные в значительной степени игнорировались в пользу позиции и мнения» [164].

Между тем, рецензирование предвзято относится к новым идеям [165], и «рецензенты [сильно] предвзяты к рукописям, которые [сообщают] результаты, противоречащие их теоретическим взглядам» [166]. В моем ограниченном опыте автора, рецензента, члена ПК и редактора строгие эмпирические исследования часто критикуются или отвергаются за противоречие концепциям, для которых никогда не существовало эмпирических доказательств. Это очень важно, поскольку фундаментальное различие между наукой и псевдонаукой заключается в том, что наука разрешает споры, используя эмпирические данные, а псевдонаука подавляет противоречивые результаты [167]. Таким образом, эмпирические данные, противоречащие широко распространённым неэмпирическим представлениям, являются своего рода лакмусовой бумажкой для научного сообщества: если побеждают эмпирические данные, то программная инженерия — это прикладная наука; если побеждают анекдоты и неэмпирические концепции, то программная инженерия — это псевдонаука и шарлатанство. Однако у нас нет количественных оценок того, как часто игнорируются эмпирические данные и насколько это пагубно сказывается на практике.

Основываясь на предыдущем обсуждении, мы можем предложить приблизительную шкалу, иллюстрирующую возможный диапазон принятия эмпиризма (рис. 1).

На первом уровне находятся псевдонаучные сообщества, такие как натуропатическая медицина: доказательства не имеют значения; лечение безопасно, потому что оно «натуральное», и оно работает, потому что я говорю, что оно работает для моих пациентов и меня. Программная инженерия явно превзошла первый уровень. На противоположном конце, четвертом уровне, находятся зрелые эмпирические области, такие как медицина. В медицине эмпирические данные требуют все авторитетные журналы, а не только The BMJ и The Lancet. Более того, исследования должны продемонстрировать, что артефакты действительно достигают своих целей; недостаточно дать нескольким людям лекарство и спросить, нравится ли оно им, или поверить, что оно помогло. Наследие, неэмпирические концепции (например, френология) рассматриваются не нейтрально, а как угроза авторитету медицинского истеблишмента. Программная инженерия явно не находится на четвертом уровне.

Я думаю, что программная инженерия находится на втором уровне. Большинство ведущих организаций ожидают эмпирических данных; однако эти данные часто не касаются непосредственно эффективности. Эмпирические выводы и тщательные исследования конкурируют с неэмпирическими концепциями и анекдотическими свидетельствами. Например, в некоторых рецензиях на недавнюю статью об отходах разработки программного обеспечения [168] её критиковали за ограниченный вклад в сравнение с предыдущей работой [169], хотя предыдущая работа была основана исключительно на анекдотических данных, а новая — на строгом эмпирическом исследовании. Между тем, многие специализированные и второразрядные площадки вообще не требуют эмпирических данных.

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

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

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

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

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

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

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

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

Изменение истории, которую исследователи рассказывают себе и друг другу о том, как создаётся программное обеспечение, имеет множество последствий для исследований, практики и образования:

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

2. Наличие двух парадигм в одном академическом сообществе приводит к недопониманию [4], что подрывает консенсус и препятствует научному прогрессу [171]. Фундаментальная рационалистическая критика эмпирической парадигмы заключается в том, что совершенно очевидно, что использование более систематического, методичного, логичного процесса должно улучшить результаты [7], [23], [119], [172], [173]. Фундаментальная эмпирическая критика рациональной парадигмы заключается в том, что нет убедительных доказательств того, что следование более систематическим, методичным, логичным процессам полезно или даже возможно [3], [5], [9], [12]. Поскольку Рациональная парадигма основана на рационалистической эпистемологии, её приверженцы скептически относятся к эмпирическим доказательствам [23]; аналогично, поскольку эмпирическая парадигма основана на эмпирицистской эпистемологии, её приверженцы скептически относятся к апелляции к интуиции и здравому смыслу [5]. Другими словами, учёные разных парадигм обходят друг друга стороной и с трудом общаются или находят общий язык.

3. Многие разумные профессионалы, которые никогда бы не купили гомеопатическое лекарство (потому что несколько отзывов, очевидно, не являются надёжным доказательством эффективности), примут программный метод или практику, основываясь лишь на нескольких отзывах [174], [175]. Как практикам, так и исследователям следует требовать прямой эмпирической оценки эффективности всех предлагаемых методов, инструментов, моделей, стандартов и техник (см. [111], [176]). Когда кто-то утверждает, что основные стандарты доказательности не должны применяться к его исследованиям, называйте это так, как есть: особое послание [177]. Тем временем рецензенты должны избегать критики или отклонения эмпирических работ за то, что они противоречат неэмпирическим унаследованным концепциям.

4. Рациональная парадигма заставляет профессионалов «требовать предварительного изложения требований к проекту» и «заключать контракты друг с другом на этой основе», что увеличивает риск [5]. Эмпирическая парадигма объясняет, почему: по мере того как цели и требования эволюционируют вместе с появляющимся программным продуктом, многие проекты отклоняются от своих контрактов. Такой отход создаёт парадокс для разработчиков: выполнить в точности то, что указано в контракте, с ограниченной выгодой для заинтересованных сторон (и возможным ущербом), или максимизировать выгоду для заинтересованных сторон и рисковать судебными разбирательствами о нарушении контракта. Поэтому фирмам следует рассмотреть альтернативные варианты, включая разработку собственными силами или заключение текущих контрактов.

5. Рациональная парадигма способствует возникновению хорошо известной напряженности между менеджерами, пытающимися управлять проектами через оценку затрат, и специалистами по программному обеспечению, которые не могут точно оценить затраты [88]. Разработчики недооценивают усилия в среднем на 30-40% [178], поскольку редко обладают достаточной информацией для оценки сложности проекта [18]. Эмпирическая парадигма показывает, что проектирование — это непредсказуемый, творческий процесс, для которого контроль на основе бухгалтерского учета неэффективен.

6. Допущения рациональной парадигмы пронизывают IS2010 [70] и SE2014 [179], типовые учебные программы для бакалавров по информационным системам и программной инженерии, соответственно. В обоих учебных планах подробно обсуждаются требования и жизненные циклы; ни в одном из них не упоминаются отражение в действии, коэволюция, неметодическая разработка или какие-либо теории программной инженерии или проектирования (см. [180]). Неэмпирические унаследованные концепции, включая модель водопада и треугольник проекта, должны быть исключены из учебных программ, чтобы освободить место для концепций, моделей и теорий, основанных на доказательствах, как и во всех других социальных и прикладных науках.

Приведенные выше рекомендации следует рассматривать с учетом ряда ограничений. Очевидно, что это не эмпирическая статья. Мы не можем опровергнуть рационализм с помощью эмпирического исследования из-за тезиса о превосходстве разума. Скорее, в данной работе используется философская деконструкция для понимания мировоззрения и литературы. Анализ, лежащий в основе статьи, может быть предвзятым из-за эмпирических взглядов автора. Однако его утверждения относительно литературы поддаются прямой проверке. Например, любой может проверить утверждение о том, что Шён [9] представляет эмпирические доказательства в поддержку своего взгляда на проектировщиков, а Саймон [7] — нет, просто ознакомившись с соответствующими книгами.

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

Сильная критика рациональной парадигмы в этой статье может вызвать несколько возражений:

Эти материалы и ограничения предлагают пять направлений для будущих исследований:

1. Наблюдательные исследования экспертов-разработчиков. Во многих эмпирических исследованиях экспертов-разработчиков, рассмотренных в данной статье, изучались архитекторы, промышленные проектировщики, проектировщики продуктов и (не программные) инженеры. Для выявления важнейших явлений, характерных для более податливых артефактов, необходимы более длительные наблюдательные исследования профессионалов в области программного обеспечения (например, [182], [183]).
2. Теории процессов разработки. Наше понимание процессов разработки программного обеспечения в настоящее время основано на неэмпирических методах [104]. Мы можем решить эту проблему, разработав теории различных процессов, участвующих в создании программных систем [92], включая процесс формирования команд программной инженерии, процесс, благодаря которому возникает гибкость [113], процесс поиска ошибки и процесс разработки программного обеспечения в целом [10].
3. Теории практик разработки. Несмотря на то, что некоторые практики (например, парное программирование) получили широкое подтверждение [117], у нас нет теории, которая могла бы сказать нам, когда использовать те или иные практики или как взаимодействуют различные практики. Например, как анализ сценариев использования взаимодействует с анализом персон?
4. Практика, основанная на доказательствах. Практика, основанная на доказательствах, — это форма профессиональной деятельности, в которой ученые исследуют практически значимые проблемы, а профессиональная деятельность направляется систематическими обзорами литературы. Она представляет собой интенсивную приверженность эмпиризму и могла бы облегчить многие из проблем, рассмотренных выше. Хотя программная инженерия, основанная на доказательствах, получила широкую известность [184], для поддержки более полезных обзоров необходимы более строгие, первичные исследования.
5. Учет последних философских достижений. Современные достижения в эпистемологии, онтологии и философии науки, включая критический реализм [185], байесовскую эпистемологию [186] и процессы, приводящие к научному консенсусу [187], могут иметь важные последствия для программной инженерии. Освещая влияние рационализма на дискурс программной инженерии, эта статья должна способствовать дальнейшему анализу этих и смежных тем.

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

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

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

[1] K. Dorst, J. Dijkhuis, Comparing paradigms for describing design activity, Des. Stud. 16 (1995) 261–274.
[2] K. Dorst, Design problems and design paradoxes, Des. Issues 22 (2006) 4–17, https://doi.org/10.1162/desi.2006.22.3.4.
[3] K. Dorst, Describing Design: A Comparison of Paradigms, PhD Dissertation, Delft University of Technology, 1997.
[4] T.S. Kuhn, The Structure of Scientific Revolutions, 2nd ed., University of Chicago Press, 1996.
[5] F.P. Brooks, The Design of Design: Essays from a Computer Scientist, Addison-Wesley Professional, 2010.
[6] G. Pahl, W. Beitz, Engineering Design: A Systematic Approach, Springer-Verlag, London, 1996.
[7] H.A. Simon, The Sciences of the Artificial, 3rd ed., MIT Press, Cambridge, MA, USA, 1996.
[8] W. Royce, Managing the development of large software systems, in: Proceedings of WESCON, IEEE, Los Angeles, USA, 1970, pp.1–9.
[9] D.A. Schön, The Reflective Practitioner: How Professionals Think in Action, Basic Books, USA, 1983.
[10] P. Ralph, The sensemaking–coevolution–implementation theory of software design, Sci. Comput. Program. 101 (2015) 21–41, https://doi.org/10.1016/j.scico.2014.11.007.
[11] K. Dorst, N. Cross, Creativity in the design process: co-evolution of problem–solution, Des. Stud. 22 (2001) 425–437, https://doi.org/10.1016/S0142-694X(01)00009-6.
[12] N. Cross, K. Dorst, N. Roozenburg, Research in Design Thinking, Delft University Press, 1992.
[13] R. Kling, Social analyses of computing: theoretical perspectives in recent empirical research, ACM Comput. Surv. 12 (1980) 61–110, https://doi.org/10.1145/356802.356806.
[14] N. Levina, Collaborating on multiparty information systems development projects: a collective reflection-in-action view, Inf. Syst. Res. 16 (2005) 109–130, https://doi.org/10.1287/isre.1050.0055.
[15] P. Checkland, Systems Thinking, Systems Practice, Wiley, Chichester, 1999.
[16] V. Rajlich, Changing the paradigm of software engineering, Commun. ACM 49 (2006) 67–70, https://doi.org/10.1145/1145287.1145289.
[17] R. Weber, The rhetoric of positivism versus interpretivism: a personal view, MIS Q. 28 (2004) iii–xii.
[18] P. Ralph, Y. Wand, A proposal for a formal definition of the design concept, in: K. Lyytinen, P. Loucopoulos, J. Mylopoulos, W. Robinson (Eds.), Design Requirements Engineering: a Ten-Year Perspective, Springer-Verlag, Cleveland, OH, USA, 2009, pp.103–136.
[19] P. Freeman, D. Hart, A science of design for software-intensive systems, Commun. ACM 47 (2004) 19–21.
[20] W. Demopoulos, On applying learnability theory to the rationalism-empiricism controversy, in: Learnability and Linguistic Theory, Springer, Dordrecht, Netherlands, 1989, pp.77–88.
[21] P. Markie, Rationalism vs. empiricism, in: Stanford Encyclopedia of Philosophy, Stanford University, 2013, https://plato.stanford.edu/entries/rationalism-empiricism/.
[22] R. Hoffmann, Mixed strategies in the mugging game, Ration. Soc. 13 (2001) 205–212, https://doi.org/10.1177/104346301013002003.
[23] D.L. Parnas, The limits of empirical studies of software engineering, in: Proceedings of the 2003 International Symposium on Empirical Software Engineering, 2003, pp.2–5.
[24] V.J. Cook, M. Newson, Chomsky’s Universal Grammar: An Introduction, 3rd ed., Wiley-Blackwell, Oxford, UK, 1996.
[25] N. Chomsky, R.S. Cohen, M.W. Wartofsky, Recent contributions to the theory of innate ideas: summary of oral presentation, Synthese 17 (1967) 2–11.
[26] J. Cottingham, Rationalism, Paladin, London, UK, 1984.
[27] W. James, Essays in Radical Empiricism, Harvard University Press, 1976.
[28] T. McGrew, M. Alspector-Kelly, F. Allhoff, Philosophy of Science: An Historical Anthology, Wiley, 2009.
[29] J. Mingers, Realizing information systems: critical realism as an underpinning philosophy for information systems, Inf. Organ. 14 (2004) 87–103, https://doi.org/10.1016/j.infoandorg.2003.06.001.
[30] A.F. Chalmers, What Is This Thing Called Science, 3rd ed., Hackett Publishing, Indianapolis, 1999.

[31] T. Lähdesmäki, P. Hurme, R. Koskimaa, L. Mikkola, T. Himberg, Philosophy of science, mapping research methods, https://koppa.jyu.fi/avoimet/hum/menetelmapolkuja/en/methodmap/philosophy-of-science/philosophy-of-science?set_language=en&cl=en, 2010. (Accessed5 January 2015).
[32] A. Newell, H. Simon, Human Problem Solving, Prentice-Hall, Inc., 1972.
[33] N. Cross, Design cognition: results from protocol and other empirical studies of design activity, in: Design Knowing and Learning: Cognition in Design Education, 2001, pp.9–103, chap. 7.
[34] C. Zannier, M. Chiasson, F. Maurer, A model of design decision making based on empirical results of interviews with software designers, Inf. Softw. Technol. 49 (2007) 637–653, https://doi.org/10.1016/j.infsof.2007.02.010.
[35] P. Ralph, E. Tempero, Characteristics of decision-making during coding, in: Proceedings of the International Conference on Evaluation and Assessment in Software Engineering, ACM, Limerick, Ireland, 2016.
[36] T. Mens, T. Tourwé, A survey of software refactoring, IEEE Trans. Softw. Eng. 30 (2004) 126–139, https://doi.org/10.1109/TSE.2004.1265817.
[37] C. Hookway, Pragmatism, in: Stanford Encyclopedia of Philosophy, Stanford Encyclopedia of Philosophy, 2013.
[38] N. Cross, Descriptive models of creative design: application to an example, Des. Stud. 18 (1997) 427–440.
[39] N. Cross, Design cognition: results from protocol and other empirical studies of design activity, in: C. Eastman, W.C. Newstetter, M. McCracken (Eds.), Design Knowing and Learning: Cognition in Design Education, Elsevier Science, Oxford, UK, 2001, pp.79–103.
[40] H.A. Simon, From substantive to procedural rationality, in: 25 Years of Economic Theory, Springer US, Boston, MA, 1976, pp.65–86.
[41] L. Suchman, Human–Machine Reconfigurations: Plans and Situated Actions, Cambridge University Press, 2007.
[42] L. Suchman, Plans and Situated Actions: The Problem of Human–Machine Communication, Cambridge University Press, 1987.
[43] G. Polya, How to Solve It: A New Aspect of Mathematical Method, 2nd ed., Princeton University Press, Princeton, New Jersey, USA, 1957.
[44] Y. Zheng, W. Venters, T. Cornford, Collective agility, paradox and organizational improvisation: the development of a particle physics grid, Inf. Syst. J. 21 (2011) 303–333, https://doi.org/10.1111/j.1365-2575.2010.00360.x.
[45] W. Visser, More or less following a plan during design: opportunistic deviations in specification, Int. J. Man-Mach. Stud. 33 (1990) 247–278, https://doi.org/10.1016/S0020-7373(05)80119-1.
[46] K. Weick, Sensemaking in Organizations, Sage, Thousand Oaks, CA, USA, 1995.
[47] I. Stigliani, D. Ravasi, Organizing thoughts and connecting brains: material practices and the transition from individual to group-level prospective sensemaking, Acad. Manag. J. 55 (2012) 1232–1259, https://doi.org/10.5465/amj.2010.0890.
[48] A. Wright, The role of scenarios as prospective sensemaking devices, Manag. Decis. 43 (2012) 86–101, https://doi.org/10.1108/00251740510572506.
[49] L.C. Rodriguez, M. Mora, M.V. Martin, R. O’Connor, F. Alvarez, Process models of SDLCs: comparison and evolution, in: M.R. Syed, S.N. Syed (Eds.), Handbook of Research on Modern Systems Analysis and Design Technologies and Applications, 2009, pp.76–89.
[50] A. Tiwana, M. Keil, Control in internal and outsourced software projects, J. Manag. Inf. Syst. 26 (2009) 9–44.
[51] L.J. Kirsch, V. Sambamurthy, D.-G. Ko, R.L. Purvis, Controlling information systems development projects: the view from the client, Manag. Sci. 48 (2002) 484–498.
[52] P. Stacey, J. Nandhakumar, A temporal perspective of the computer game development process, Inf. Syst. J. 19 (2009) 479–497, https://doi.org/10.1111/j.1365-2575.2007.00273.x.
[53] M.W. Lewis, Exploring paradox: toward a more comprehensive guide, Acad. Manag. Rev. 25 (2000) 760–776.
[54] C.F. Kurtz, D.J. Snowden, The new dynamics of strategy: sense-making in a complex and complicated world, IBM Syst. J. 42 (2003) 462–483.
[55] J.S. Gero, Design prototypes: a knowledge representation schema for design, AI Mag. 11 (1990) 26–36.
[56] P. Kruchten, Casting software design in the function–behavior–structure framework, IEEE Softw. 22 (2005) 52–58.
[57] J.S. Gero, U. Kannengiesser, An ontological model of emergent design in software engineering, in: Proceedings of the 16th International Conference on Engineering Design, Paris, France, 2007.
[58] P. Ralph, Fundamentals of Software Design Science, PhD Dissertation, University of British Columbia, 2010.
[59] R. Atkinson, Project management: cost, time and quality, two best guesses and a phenomenon, it’s time to accept other success criteria, Int. J. Proj. Manag. 17 (1999) 337–342.
[60] W.H. DeLone, E.R. McLean, The DeLone and McLean model of information systems success: a ten-year update, J. Manag. Inf. Syst. 19 (2003) 9–30.
[61] P. Ralph, P. Kelly, The dimensions of software engineering success, in: Proceedings of the International Conference on Software Engineering, ACM, Hyderabad, India, 2014, pp.24–35.
[62] B. Flyvbjerg, Design by deception: the politics of major project approval, Harv. Des. Mag. 22 (2005) 50–59.
[63] A. Herrmann, B. Paech, Practical challenges of requirements prioritization based on risk estimation, Empir. Softw. Eng. 14 (2009) 644–684, https://doi.org/10.1007/s10664-009-9105-0.
[64] J. Marchant, C. Tjortjis, M. Turega, A metric of confidence in requirements gathered from legacy systems: two industrial case studies, in: Proceedings of the 10th Conference on Software Maintenance and Reengineering, IEEE, 2006.
[65] J.A. Goguen, C. Linde, Techniques for requirements elicitation, in: Proceedings of the IEEE International Symposium on Requirements Engineering, 1993, pp.152–164.

[66] IEEE, ISO/IEC/IEEE Standard 29148-2011: Systems and software engineering – Life cycle processes – Requirements engineering, 2011, https://doi.org/10.1109/IEEESTD.2011.6146379.
[67] I. Jacobson, G. Booch, J. Rumbaugh, The Unified Software Development Process, Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 1999.
[68] P. Kruchten, The Rational Unified Process: An Introduction, 3rd ed., Addison-Wesley Professional, 2004.
[69] M. Ardis, D. Budgen, G. Hislop, J. Offutt, M. Sebern, W. Visser, Software Engineering 2014: Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering, IEEE/ACM, 2015.
[70] H. Topi, J.S. Valacich, R.T. Wright, K.M. Kaiser, J.F. Nunamaker, J.C. Sipior, et al., IS 2010: curriculum guidelines for undergraduate degree programs in information systems, Commun. Assoc. Inf. Syst. 26 (2010) 18.
[71] P. Berger, T. Luckmann, The Social Construction of Reality: A Treatise in the Sociology of Knowledge, Penguin, London, 1966.
[72] S. Lichtenstein, P. Slovic, The Construction of Preference, Cambridge University Press, 2006.
[73] N. Maiden, S. Jones, K. Karlsen, R. Neill, K. Zachos, A. Milne, Requirements engineering as creative problem solving: a research agenda for idea finding, in: Proceedings of the 18th IEEE International Requirements Engineering Conference, IEEE, 2010, pp.57–66.
[74] S. Chakraborty, S. Sarker, S. Sarker, An exploration into the process of requirements elicitation: a grounded approach, J. Assoc. Inf. Syst. 11 (2010) 1.
[75] P. Ralph, The illusion of requirements in software development, Requir. Eng. 18 (2013) 293–296, https://doi.org/10.1007/s00766-012-0161-4.
[76] R. Mohanani, P. Ralph, B. Shreeve, Requirements fixation, in: Proceedings of the International Conference on Software Engineering, IEEE, Hyderabad, India, 2014, pp.895–906.
[77] P. Ralph, R. Mohanani, Is requirements engineering inherently counterproductive?, in: Proceedings of the 5th International Workshop on the Twin Peaks of Requirements and Architecture, Florence, Italy, 2015, pp.20–23.
[78] N. Cross, Design Thinking: Understanding How Designers Think and Work, Berg, Oxford, UK, 2011.
[79] S.K. Sim, A.H.B. Duffy, Towards an ontology of generic engineering design activities, Res. Eng. Des. 14 (2003) 200–223.
[80] B. Curtis, M.I. Kellner, J. Over, Process modeling, Comm. ACM 35 (1992) 75–90.
[81] A.H. Van de Ven, Engaged Scholarship: A Guide for Organizational and Social Research, Oxford University Press, Oxford, UK, 2007.

[82] C.W. Alexander, Notes on the Synthesis of Form, Harvard University Press, 1964.
[83] R. Sabherwal, M. Newman, Persistence and change in system development: a dialectical view, J. Inf. Technol. 18 (2003) 69–92, https://doi.org/10.1080/0268396032000101144.
[84] P. Stacey, J. Nandhakumar, Opening up to agile games development, Commun. ACM 51 (2008) 143–146, https://doi.org/10.1145/1409360.1409387.
[85] E. Bjarnason, K. Smolander, E. Engström, P. Runeson, Alignment practices affect distances in software development: a theory and a model, in: Pro-ceedings of the 3rd SEMAT Workshop on General Theories of Software Engineering, ACM, 2014, pp.21–31.
[86] B. Boehm, A spiral model of software development and enhancement, Computer 21 (1988) 61–72.
[87] K. Forsberg, H. Mooz, The relationship of system engineering to the project cycle, Engin. Manag. J. 4 (1992) 36–43.
[88] K. Beck, Extreme Programming eXplained: Embrace Change, 2nd ed., Addison Wesley, Boston, MA, USA, 2005.
[89] OMG, Essence – Kernel and Language for Software Engineering Methods, 1st ed., Object Management Group, 2014, http://www.omg.org/cgi-bin/doc?ad/2012-11-01.
[90] P.E. Vermaas, K. Dorst, On the conceptual framework of John Gero’s FBS-model and the prescriptive aims of design methodology, Des. Stud. 28 (2007) 133–157.
[91] A.H. Van de Ven, M.S. Poole, Explaining development and change in organizations, Acad. Manag. Rev. 20 (1995) 510–540.
[92] P. Ralph, Developing and evaluating software engineering process theories, in: Proceedings of the International Conference on Software Engineering, IEEE Press, Florence, Italy, 2015, pp.20–31.
[93] B. Fitzgerald, The transformation of open source software, MIS Q. 30 (2006) 587–598.
[94] K. Ewusi-Mensah, Software Development Failures, MIT Press, Cambridge, MA, USA, 2003.
[95] K. Laudon, J. Laudon, M. Brabston, Management Information Systems: Managing the Digital Firm, fourth Canadian ed., Pearson, Prentice Hall, Toronto, 2009.
[96] P. Bourque, R.E. Fairley (Eds.), Guide to the Software Engineering Body of Knowledge, Version 3.0, IEEE Computer Society, 2014, www.swebok.org.
[97] IEEE, IEEE Standard 830-1998: Recommended Practice for Software Requirements Specifications, 1998.
[98] J. Parsons, Y. Wand, Using cognitive principles to guide classification in information systems modeling, MIS Q. 32 (2008) 839–868.

[99] W.P. Stevens, G.J. Myers, L.L. Constantine, Structured design, IBM Syst. J. 13 (1974) 115–139.[100] T. Fullerton, C. Swain, S. Hoffman, Game Design Workshop: Designing, Prototyping, & Playtesting Games, Taylor & Francis, 2004.
[101] K. Beck, Test Driven Development: By Example, Addison-Wesley Professional, Boston, MA, USA, 2002.
[102] P. Ralph, Software engineering process theory: a multi-method comparison of sensemaking–coevolution–implementation theory and function–behavior–structure theory, Inf. Softw. Technol. 70 (2016) 232–250, https://doi.org/10.1016/j.infsof.2015.06.010.
[103] J. Grudin, J. Pruitt, Personas, participatory design and product development: an infrastructure for engagement, in: Proceedings of the Participatory Design Conference, 2002, pp.141–161.
[104] D.P. Truex, R. Baskerville, J. Travis, Amethodical systems development: the deferred meaning of systems development methods, Account. Manag. Inf. Technol. 10 (2000) 53–79.
[105] K. Schwaber, M. Beedle, Agile Software Development with Scrum, Prentice Hall, 2001.
[106] M. Poppendieck, T. Poppendieck, Lean Software Development: An Agile Toolkit, Addison-Wesley Professional, 2003.
[107] P. Kruchten, The Rational Unified Process: An Introduction, Addison-Wesley Professional, 2004.
[108] Great Britain Office of Government Commerce, Managing Successful Projects with PRINCE2, Stationery Office Books, 2009.
[109] A. Hevner, S. Chatterjee, Design Research in Information Systems: Theory and Practice, Springer, 2010.
[110] A. Hevner, S.T. March, J. Park, S. Ram, Design science in information systems research, MIS Q. 28 (2004) 75–105.
[111] S.T. March, G.F. Smith, Design and natural science research on information technology, Decis. Support Syst. 15 (1995) 251–266.
[112] J. Wynekoop, N. Russo, Studying system development methodologies: an examination of research methods, Inf. Syst. J. 7 (1997) 47–65.
[113] M. Wufka, P. Ralph, Explaining agility with a process theory of change, in: Proceedings of the Agile Conference, Washington, DC, USA, 2015, pp.60–64.
[114] K. Conboy, Agility from first principles: reconstructing the concept of agility in information systems development, Inf. Syst. Res. 20 (2009) 329–354.
[115] K. Schwaber, J. Sutherland, The scrum guide, http://www.scrum.org/scrumguides/, 2010 (Accessed2 July 2012).
[116] K. Beck, M. Beedle, A. van Bennekum, A. Cockburn, W. Cunningham, M. Fowler, et al., Manifesto for agile software development, http://www.agilemanifesto.org/, 2001 (Accessed2 July 2012).

[117] J.E. Hannay, T. Dyba, E. Arisholm, D. Sjøberg, The effectiveness of pair programming: a meta-analysis, Inf. Softw. Technol. 51 (2009) 1110–1122, https://doi.org/10.1016/j.infsof.2009.02.001.
[118] H.A. Simon, Rational choice and the structure of the environment, Psychol. Rev. 63 (1956) 129.
[119] D.L. Parnas, P.C. Clements, A rational design process: how and why to fake it, IEEE Trans. Softw. Eng. 12 (1986) 251–257.
[120] D.L. Parnas, J. Madey, Functional documents for computer systems, Sci. Comput. Program. 25 (1995) 41–61, https://doi.org/10.1016/0167-6423(95)96871-j.
[121] I. Jacobson, G. Booch, J.E. Rumbaugh, The Unified Software Development Process, Addison-Wesley, 1999.
[122] J. Herbsleb, D. Goldenson, A systematic survey of CMM experience and results, in: Proceedings of the 18th International Conference on Software Engineering, 1996, pp.323–330.
[123] C. Avgerou, T. Cornford, A review of the methodologies movement, J. Inf. Technol. 8 (1993) 277–286.
[124] B. Dobing, J. Parsons, How UML is used, Commun. ACM 49 (2006) 109–113.
[125] M. Petre, UML in practice, in: Proceedings of the 2013 International Conference on Software Engineering, IEEE Press, 2013.
[126] E.A. Whitley, Method-Ism in practice: investigating the relationship between method and understanding in web page design, in: Proceedings of the International Conference on Information Systems, AIS, Helsinki, Finland, 1998, pp.68–75.
[127] L. Mathiassen, S. Purao, Educating reflective systems developers, Inf. Syst. J. 12 (2002) 81–102, https://doi.org/10.1046/j.1365-2575.2002.00122.x.
[128] J. Bansler, K. Bødker, A reappraisal of structured analysis: design in an organizational context, ACM Trans. Inf. Syst. 11 (1993) 165–193.
[129] D. Avison, G. Fitzgerald, Information systems development, in: W. Currie, R. Galliers (Eds.), Rethinking Management Information Systems: An Inter-disciplinary Perspective, Oxford University Press, Oxford, UK, 1999, pp.250–278.
[130] P. Ralph, Comparing two software design process theories, in: R. Winter, J.L. Zhao, S. Aier (Eds.), Proceedings of the International Conference on Design Science Research in Information Systems and Technology, Springer, St. Gallen, Switzerland, 2010, pp.139–153.
[131] M. Magni, L. Maruping, M. Hoegl, L. Proserpio, Improvisation and performance in software development teams: the role of geographic dispersion, in: Proceedings of the International Conference on Information Systems, AIS, Paris, France, 2008.
[132] P. Kruchten, The Rational Unified Process: An Introduction, 1st ed., Addison-Wesley Professional, 1998.

[133] A.T. Bahill, F.F. Dean, Discovering system requirements, in: A.P. Sage, W.B. Rouse (Eds.), Handbook of Systems Engineering and Management, 2nd ed., John Wiley & Sons, 2009, pp.205–266.
[134] D.M. Russell, M.J. Stefik, P. Pirolli, S.K. Card, The cost structure of sensemaking, in: Proceedings of the INTERACT and CHI Conference on Human Factors in Computing Systems, ACM, 1993, pp.269–276.
[135] A.D. Brown, P. Stacey, J. Nandhakumar, Making sense of sensemaking narratives, Hum. Relat. 61 (2008) 1035–1062, https://doi.org/10.1177/0018726708094858.
[136] M.W. Newell, M.N. Grashina, The Project Management Question and Answer Book, AMACOM Div. American Mgmt. Assn., 2004.
[137] P.C. Fishburn, Utility Theory for Decision Making, Wiley, New York, USA, 1970.
[138] M. Paulk, Capability Maturity Model for Software, Wiley Online Library, 1993.
[139] B. Shore, Systematic biases and culture in project failures, Proj. Manag. J. 39 (2008) 5–16, https://doi.org/10.1002/pmj.20082.
[140] W. Samuelson, R.J. Zeckhauser, Status quo bias in decision making, J. Risk Uncertain. 1 (1988) 7–59.
[141] J. Diaz-Herrera, T. Hillburn (Eds.), Software Engineering 2004: Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering, IEEE/ACM, 2004.
[142] D.T. Campbell, J. Stanley, Experimental and Quasi-Experimental Designs for Research, Houghton Mifflin, Boston, 1963.
[143] W. Trochim, Research Methods Knowledge Base, Atomic Dog Publishing, Cincinnati, OH, USA, 2001.
[144] R.K. Yin, Case Study Research: Design and Methods, 4 ed., Sage, California, USA, 2008, http://www.worldcat.org/title/case-study-research-design-and-methods/oclc/226984696.
[145] K.E. Weick, Educational organizations as loosely coupled systems, Adm. Sci. Q. 21 (1976) 1–19, https://doi.org/10.2307/2391875.
[146] N. Cross, Designerly Ways of Knowing, Springer, 2006.
[147] M. Arvola, H. Artman, Enactments in interaction design: how designers make sketches behave, Artifact 1 (2007) 106–119.
[148] Standish Group, Chaos Database: Chaos Surveys Conducted from 1994 to Fall 2004, 2006.
[149] E. Cardozo, J. Neto, A. Barza, A. França, F. daSilva, SCRUM and productivity in software projects: a systematic literature review, in: Proceedings of the 14th International Conference on Evaluation and Assessment in Software Engineering, EASE, Newcastle, UK, 2010.
[150] E. Stolterman, How system designers think about design and methods: some reflections based on an interview study, Scand. J. Inf. Syst. 3 (1991) 137–150.

[151] J. Nandhakumar, D. Avison, The fiction of methodological development: a field study of information systems development, Inf. Technol. People 12 (1999) 176–191.
[152] E. Whitworth, R. Biddle, Motivation and cohesion in agile teams, in: G. Concas, E. Damiani, M. Scotto, G. Succi (Eds.), Agile Processes in Software Engineering and Extreme Programming, Springer, Berlin/Heidelberg, 2007, pp.62–69.
[153] A.T. Kocatas, C. Erbas, Extending essence kernel to enact practices at the level of software modules, in: Proceedings of the 3rd SEMAT Workshop on General Theories of Software Engineering, ACM, 2014, pp.32–35, http://dl.acm.org/citation.cfm?id=2593758.
[154] E.H. Ferneley, P. Sobreperez, Resist, comply or workaround? An examination of different facets of user engagement with information systems, Eur. J. Inf. Syst. 15 (2006) 345–356, https://doi.org/10.1057/palgrave.ejis.3000629.
[155] M.J. Baker, Data collection – questionnaire design, Mark. Rev. 3 (2003) 343–370, https://doi.org/10.1362/146934703322383507.
[156] A. Stefik, S. Hanenberg, Methodological irregularities in programming-language research, Computer 50 (2017) 60–63, https://doi.org/10.1109/MC.2017.3001257.
[157] M.V. Zelkowitz, An update to experimental models for validating computer technology, J. Syst. Softw. 82 (2009) 373–376, https://doi.org/10.1016/j.jss.2008.06.040.
[158] P. Runeson, M. Höst, Guidelines for conducting and reporting case study research in software engineering, Empir. Softw. Eng. 14 (2009) 131–164, https://doi.org/10.1007/s10664-008-9102-8.
[159] K.-J. Stol, P. Ralph, B. Fitzgerald, Grounded theory in software engineering research: a critical review and guidelines, in: Proceedings of the Interna-tional Conference on Software Engineering, IEEE, Austin, TX, USA, 2016, pp.120–131.
[160] D. Sjøberg, B. Anda, E. Arisholm, T. Dyba, M. Jørgensen, A. Karahasanovic, E.F. Koren, M. Vokac, Conducting realistic experiments in software engineer-ing, in: ISESE’02 Proc. 2002 Int. Symp. on Empirical Software Engineering, IEEE Comput. Soc., Nara, Japan, 2002, pp.17–26.
[161] A.J. Ko, T.D. LaToza, M.M. Burnett, A practical guide to controlled experiments of software engineering tools with human participants, Empir. Softw. Eng. 20 (2013) 110–141, https://doi.org/10.1007/s10664-013-9279-3.
[162] A. Rainer, T. Hall, N. Baddoo, Persuading developers to “buy into” software process improvement: a local opinion and empirical evidence, in: ISESE-03, IEEE Comput. Soc., 2003, pp.326–335.
[163] P. Devanbu, T. Zimmermann, C. Bird, Belief & evidence in empirical software engineering, in: Proceedings of the International Conference on Software Engineering, IEEE, Austin, Texas, USA, 2016, pp.108–119.
[164] H. Sharp, H. Robinson, M. Woodman, Software engineering: community and culture, IEEE Softw. 17 (2000) 40–47, https://doi.org/10.1109/52.819967.
[165] J.M. Campanario, Commentary on influential books and journal articles initially rejected because of negative referees’ evaluations, Sci. Commun. 16 (1995) 304–325, https://doi.org/10.1177/1075547095016003004.
[166] M.J. Mahoney, Publication prejudices: an experimental study of confirmatory bias in the peer review system, Cogn. Ther. Res. 1 (1977) 161–175.
[167] M. Bunge, What is pseudoscience?, Skept. Inq. 9 (1984) 36–46.
[168] T. Sedano, P. Ralph, C. Péraire, Software Development Waste, IEEE Press, 2017.
[169] M. Poppendieck, Lean Software Development, IEEE Computer Society, 2007.

[170] P. Ralph, Improving coverage of design in information systems education, in: Proceedings of the 2012 International Conference on Information Sys-tems, AIS, Orlando, FL, USA, 2012.
[171] R. Collins, Why the social sciences won’t become high-consensus, rapid discovery science, in: S. Cole (Ed.), What’s Wrong with Sociology?, Transaction Publishers, 2001, pp.61–85.
[172] D.L. Parnas, Document based rational software development, Knowl.-Based Syst. 22 (2009) 132–141, https://doi.org/10.1016/j.knosys.2008.11.001.
[173] J. Herbsleb, D. Zubrow, D. Goldenson, W. Hayes, M. Paulk, Software quality and the capability maturity model, Commun. ACM 40 (1997) 30–40.
[174] I. Jacobson, B. Meyer, Methods Need Theory, 2009, DrDobbs.com.
[175] P. Johnson, M. Ekstedt, I. Jacobson, Where’s the theory for software engineering?, IEEE Softw. 29 (2012) 94–96, https://doi.org/10.1109/MS.2012.127.
[176] J. Venable, J. Pries-Heje, R. Baskerville, A comprehensive framework for evaluation in design science research, in: K. Peffers, M. Rothenberger, B. Kuech-ler (Eds.), Proceedings of Design Science Research in Information Systems and Technology, in: LNCS, vol.7286, Springer-Verlag, 2012, pp.423–438.
[177] T. Damer, Attacking Faulty Reasoning: A Practical Guide to Fallacy-Free Arguments, Cengage Learning, 2008.
[178] K. Molokken, M. Jørgensen, A review of software surveys on software effort estimation, in: Proceedings of the International Symposium on Empirical Software Engineering, ACM-IEEE, 2003, pp.223–230.
[179] Joint Task Force on Computing Curricula, Software Engineering 2014: Curriculum Guidelines for Undergraduate Degree Programs in Software Engi-neering, IEEE, ACM, 2015.
[180] P. Ralph, Improving coverage of design in information systems education, in: Proceedings of the International Conference on Software Engineering, IEEE, Orlando, Florida, USA, 2012.
[181] H. Robinson, P. Hall, F. Hovenden, J. Rachel, Postmodern software development, Comput. J. 41 (1998) 363–375, https://doi.org/10.1093/comjnl/41.6.363.
[182] T. Sedano, P. Ralph, C. Péraire, Practice and perception of team code ownership, in: Proceedings of the International Conference on Evaluation and Assessment in Software Engineering, Limerick, Ireland, 2016.
[183] T. Sedano, P. Ralph, C. Péraire, Software development waste, in: Proceedings of the International Conference on Software Engineering, IEEE, Buenos Aires, Argentina, 2017, www.researchgate.net/publication/313360479_Software_Development_Waste.
[184] B.A. Kitchenham, T. Dyba, M. Jørgensen, Evidence-based software engineering, in: ICSE-04, IEEE, 2004, pp.273–281.
[185] M. Archer, C. Decoteau, P. Gorski, D. Little, D. Porpora, T. Rutzou, et al., What is critical realism? Asatheory.org, http://www.asatheory.org/2/post/2016/12/what-is-critical-realism.html, 2016 (Accessed14 April 2017).
[186] W. Talbott, Bayesian epistemology, in: Stanford Encyclopedia of Philosophy, Stanford, USA, 2008, https://plato.stanford.edu/entries/epistemology-bayesian/.
[187] B. Latour, Science in Action: How to Follow Scientists and Engineers Through Society, Harvard University Press, 1987.