Идеальная разработка ПО

Книга Идеальная разработка ПО Книга Идеальная разработка ПО. Рецепты лучших программистов.

Содержание:

Предисловие

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

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

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

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

Надеемся, что вопросы и ответы, собранные в книге, изменят ваш подход к техно-логии программирования. Также хочется верить, что когда в следующий раз кто-либо заявит, что некая схема расстановки фигурных скобок в С или Java лучше всех остальных, вы скажете: «Обоснование, пожалуйста».

Структура книги

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

на довольно высоком уровне. Надеемся, что чтение части I, «Общие принципы по-иска и использования доказательств», сформирует надежную основу для понима-ния части II, «Конкретные вопросы технологий программирования».

Условные обозначения

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

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

Эта книга написана для того, чтобы помочь вам в решении конкретных задач. В об-щем случае вы можете использовать приведенные примеры кода в своих програм-мах и документации. Связываться с авторами для получения разрешения не нужно, если только вы не воспроизводите значительный объем кода. Если ваша програм-ма использует несколько фрагментов кода из книги, обращаться за разрешением не нужно. С другой стороны, для продажи или распространения дисков CD-ROM с примерами из книг O’Reilly потребуется разрешение. Если вы отвечаете на вопрос на форуме, приводя цитату из книги с прршерами кода, обращаться за разрешением не нужно. Если значительный объем кода из примеров книги включается в доку-ментацию по вашему продукту, разрешение необходимо.

От издательства

Ваши замечания, предложения, вопросы отправляйте по адресу электронной почты comp@piter.com (издательство «Питер», компьютерная редакция).

Мы будем рады узнать ваше мнение!

На веб-сайте издательства http://www.plter.com вы найдете подробную информацию о наших книгах.

Общие принципы поиска и использования доказательств

Задача сбора убедительных доказательств

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

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

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

В начале

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

Элегантность анализа

Многие исследования в области технологии программирования учитывают субъек-тивные (человеческие) факторы, потому что эффективность многих программных технологий зависит от людей, которые ими пользуются^ Однако учет человеческого непостоянства — исключительно сложная задача. Исследования, основанные на хи-троумных методиках, сводящих к минимуму роль этих непредсказуемых аспектов, нередко вызывают восхищение у других исследователей. Например, в исследовани-ях Базили и Селби [Basili and Selby, 1987] использовался план дробного факторного эксперимента, при котором каждый разработчик использовал каждый анализируе-мый метод, а каждый метод использовался с каждым фрагментом программного кода, задействованным в эксперименте.

Статистическая достоверность

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

Воспроизводимость результатов

Результаты становятся намного более убедительными, если они обнаруживаются снова и снова во множестве разных контекстов — то есть не ограничиваются одним контекстом или набором экспериментальных условий. В других научных областях повторяемость способствует повышению достоверности; по этой причине значи-тельные усилия прилагаются к тому, чтобы эксперименты в области технологии программирования могли легко воспроизводиться другими аналитиками в других контекстах [Basili et al. 1999J. В качестве примера воспроизводимости Турхан по-казал, что системы прогнозирования сбоев программного обеспечения, прошедшие обучение на одном месте, могли успешно применяться на других местах [Turhan et al. 2009].

Как обстоят дела сегодня

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

Проблемы с элегантностью анализа

Оказалось, что элегантные методы анализа убеждают людей, обладающих хорошей теоретической подготовкой, но их бывает трудно объяснить практикам, потому что из-за присущих таким методам упрощений и ограничений контекст перестает быть характерным для реальных условий разработки. Например, в исследовании Бази-ли и Селби изучаемые методологии применялись только к «игрушечным» задачам длиной не более 400 строк кода, да еще и в искусственной среде. На это исследова-ние часто ссылаются, и хотя с тех пор оно неоднократно повторялось, ни в одном из повторных экспериментов не были использованы намного более крупные или более типичные приложения [Runeson et al. 2006]. И хотя это элегантное исследование внесло заметный вклад в наше понимание достоинств и недостатков разных мето-дов устранения дефектов программного кода, идеальным его не назовешь, потому что наши представления по этой теме в целом основаны на относительно малых сег-ментах кода.

Проблемы со статистической достоверностью

Как ни странно, по поводу того, что же считать «достоверной» статистикои в реаль-ных задачах, также не существует единого мнения. Во-первых, существует проблема внешней общезначимости: действительно ли измеряемые метрики адекватно отра-жают представляющие интерес явления реального мира? Если метрики бессодер-жательны, то и статистическая достоверность становится бесполезной. Например, у Фосса и др. показано, что метрики, часто используемые для оценки объема работ, принципиально неверны [Foss et al. 2003]. Что еще хуже, авторы утверждают, что проблема не имеет решения:

Бесполезно искать «панацею»: единственнуЮу простую в использовании, универсаль-ную метрику, которую было бы удобно применять для сравнения [разных методов].

Более того, разные авторы применяют разные методы статистического анализа, и ни один из методов не был повсеместно признан «самым достоверным»:

  • У Демсара описан широчайший спектр статистических методов, использованных докладчиками на одной важной международной конференции, посвященной ана-лизу данных [Demsar, 2006].
  • Коэн рассматривает использование стандартной проверки статистических гипотез для формулировки научных выводов. Он язвительно описывает такую проверку как «мощные, но всесокрушающие интеллектуальные грабли, которые не остав-ляют <…> жизнеспособной научной поросли» [Cohen, 1988].

В поддержку утверждения Коэна мы предлагаем следующий поучительный урок. В своих работах из области маркетинга Армстронг [Armstrong, 2007] описывает ис-следование, которое, используя метод проверки значимости, утверждает, что оцен-ки, построенные по данным из нескольких источников, оказываются не лучше оце-нок, построенных по данным одного источника. Затем он полностью разрушает этот вывод, перечисляя 31 исследование, в которых прогнозы по данным нескольких ис-точников по надежности стабильно превосходили прогнозы по данным одного ис-точника на 3,4-23,4% (в среднем 12,5%). В каждом исследовании, описанном Арм-стронгом, результаты оказывались в точности противоположными тому, что можно было прогнозировать по итогам проверки значимости.

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

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

Проблемы с воспроизводимостью результатов

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

  • Циммерманн проанализировал 629 пар проектов по разработке программного обеспечения [Zimmermann, 2009]. Только в 4% случаев модель прогнозирования дефектов, сформулированная на основе одного проекта, оказывалась полезной в парном проекте.
  • В своем исследовании Китченхэм и др. проверяли, могут ли данные одного про-екта использоваться для оценки объема работ по второму проекту [Kitchenham et al. 2007]. Обнаружилось, что существующие доказательства недостаточно убе-дительны, а часто даже противоречивы.

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

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

Пример недостаточности исследований: Мензес проанализировал 100 методов кон-троля качества программного продукта, предложенных разными группами (в числе которых были IEEE 1017 и внутренние стандарты NASA IV&V) и не обнаружил ни-каких экспериментальных подтверждений того, что какой-либо метод обладал боль-шей экономической эффективностью по сравнению с другими методами [Menzies et al.2008].

Примеры неполноты имеющихся исследований:

Занье и др. проанализировали случайную выборку из 5% статей, опубликованных ICSE — организацией, которая позиционирует себя как ведущую конференцию по технологии программирования [Zannier et al. 2006]. Как выяснилось, среди статьей, которые были заявлены как «эмпирические», лишь очень немногие (2%) содержали сравнение методов разных исследователей.

Нето и др. сообщили о своем исследовании публикаций, посвященных модельному тестированию (МВТ, Model-Based Testing). Они обнаружили 85 статей, в которых описывался 71 метод МВТ, при крайне незначительном количестве исследований с экспериментальными компонентами.

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

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

  • Всего было 68 публикаций, в 48 из которых авторы либо пыта^тись применить но-вый метод анализа к старым данным, либо выдавали результаты в стиле [Zannier, 2006] — то есть новый метод сработал для одного конкретного проекта.
  • В 9 публикациях ставилась под сомнение корректность предыдущих результатов (например, [Menzies, 2009а]).
  • В 4 публикациях утверждалось, что применение обобщенных моделей в области технологии программирования либо маловероятно, либо невозможно (например, [Briand, 2006]).
  • Крайне редко (7 из 68 публикаций) исследователи пытались обобщить результаты одного проекта на другие проекты:
    • в 4 публикациях сообщалось, что система прогнозирования качества ПО, обу-чавшаяся на одном проекте, была с пользой применена к другому проекту (на-пример, [Weyuker et al. 2008] и [Tosun et al. 2009]);
    • в 3 публикациях ограничивались утверждением о том, что такое обобщение возможно (например, [Boehm, 2009]).

Несколько обеспокоенные этими результатами, мы обсудили их с ведущими спе-циалистами в области эмпирического изучения технологии программирования в США и Европе. Краткая сводка результатов этого обсуждения:

  • Вик Базили оставался первопроходцем в области эмпирического изучения тех-нологии программирования в течение 30 лет. Высказав мнение о том, что область эмпирического анализа сейчас выглядит более благополучно, чем в 1980-х годах, он признал, что: а) результаты на данный момент неполны; б) лишь немногие методы были с пользой применены в нескольких проектах [Basili, 2009 .
  • Дэвид Баджен и Барбара Китченхэм являются ведущими европейскими сторонни-ками методологии EBSE (Evidence-Based Software Engineering). Согласно канонам EBSE, практика разработки ПО должна базироваться на методах, имеющих надеж-ное теоретическое обоснование в литературе. Баджен и Китченхэм спрашивают: «Можно ли сказать, что методология EBSE созрела для применения на уровне практики и политики?» Они отвечают на свой вопрос: «Нет, еще нет: прежде чем мы сможем показать, что результаты действительно воспроизводятся в разньгх проектах, потребуется значительная реструктуризация в области технологии программиро-вания » [Budgen et al. 2009]. Они выступают за изменение стандартов отчетности, а конкретнее, за использование «структурированных абстракций» для упрощения крупномасштабного анализа литературы в области технологии программирования.

Что может измениться

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

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

Чтобы доказательства привели к практическим изменениям, им должна поверить некая влиятельная аудитория. Одно из решений проблемы недостаточной формаль-ности сообщений о результатах применения или ситуационных исследований мо-жет быть основано на присваивании «уровня достоверности» каждому отдельному доказательству. Такая оценка должна отражать местонахождение каждого сообще-ния в спектре от единичных/сомнительных случаев до заслуживающих высокого доверия. Такие оценки являются неотъемлемой частью процесса, предложенного Китченхэм для систематического анализа и агрегирования исследований в области технологии программирования [Kitchenham, 2004]. Простая шкала, при помощи ко-торой специалисты-практики могут составить представление об уровнях достовер-ности, приведена в статье Фельдмана [Feldmann et al. 2006].

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

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

Сайт исследований в области инфраструктуры программных артефактов Универ-ситета Небраски — http://sir.unledu/.

Программные артефакты, хранящиеся в этом репозитории, могут использоваться исследователями для жестко контролируемых экспериментов с методами анализа I • и тестирования программ. Кроме того, они могут использоваться преподавателями для обучения студентов посредством контролируемых экспериментов. В репозито-рии собрано много программных систем, написанных на Java и С — в разных верси-ях и с различными вспомогательными артефактами (тестовые пакеты, данные сбо-ев, сценарии). Информация из репозитория использовалась в сотнях публикаций.

Лаборатория технологий программирования (SEL, Software Engineering Laboratory) NASA

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

CeBASE

Финансируемый Национальным научным фондом (NSF, National Scientific Foun-dation) проект по созданию репозиториев данных и аналитических выводов, кото-рые могли бы повторно использоваться и заново анализироваться другими иссле-дователями. Мы использовали опыт SEL для исследования способов повышения эффективности контекстного изучения данных — таких как пометка всех наборов данных разнообразными метаданными, описывающими источник их получения. В свою очередь, этот проект заложил основы для репозитория Университета под-готовки специалистов по военным закупкам МО США (U.S. Defense Department Defense Acquisition University) позволяющего конечным пользователям опреде-лять собственные контексты в соответствии с такими переменными, как размер проекта, критичность или предметная область, а также искать информацию о до-казательствах, полученных в ходе экспериментов в аналогичных средах.

Проект PROMISE

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

  1. Сетевой репозиторий данных, находящихся в открытом доступе^. На момент написания книги в репозитории хранился 91 набор данных. Половина набо-ров относится к прогнозированию сбоев, остальные — к прогнозированию объема работ, модельным методам технологии программирования, интеллек-туальному анализу текста в данных и другим темам.
  2. Ежегодная конференция, на которой докладчикам настоятельно рекоменду-ется не только публиковать статьи, но и сохранять в репозитории данные, на основе которых они сделали свои выводы.
  3. Публикация сборников лучших статей с конференции [Menzies, 2008].

Репозитории особенно полезны, когда в них хранится информация для связи с ис-точником данных. Необходимо понимать, что научные данные редко существуют сами по себе; для их авторов ответы на вопросы и участие в диалоге с теми, кто пытается’ интерпретировать их работу, должны быть скорее нормой, нежели от-клонением от нее. Такие контакты очень важны для изучения контекста, в котором данные были собраны; нередко они также помогают пользователям найти данные, наиболее актуальные для их конкретной темы или контекста. Например, Гунес Кору (Gunes Koru) из Мэрилендского университета округа Балтимор (UMBC, University of Maryland, Baltimore County) обнаружил систематическую ошибку в некоторых наборах данных PROMISE. Благодаря поддержке блогов в репозитории PROMISE он смог опубликовать информацию об ошибке. Более того, через блог PROMISE^ он связался с поставщиками исходных данных, которые предоставили подробные комментарии об источнике ошибок и о том, как их избежать.

Влияние контекста

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

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

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

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

А теперь начинается самое интересное. Эвристика поиска при всей ее полезности вводит систематическое смещение в результаты поиска. При изменении контек-ста и эвристического смещения алгоритмы будут находить разные «оптимальные» решения. Например, в экспериментах с эвристическим анализом моделей тех-нологических процессов программирования Грин и др. использовали две разные целевые функции [Green et al. 2009]. Одна целевая функция представляла собой правительственный проект, критичный по безопасности, в котором мы стреми-лись к минимизации как объема работ, так и количества дефектов в конечном про-дукте. Другая целевая функция представляла более стандартную ситуацию: фир-ма торопится выбросить продукт на рынок, одновременно стараясь ограничиться приемлемым количеством дефектов. В исследовании четыре разных проекта были проанализированы AI-оптимизатором. Каждый анализ повторялся для обеих целе-вых функций. Самый поразительный вывод заключался в том, что рекомендации, полученные для одной целевой функции, обычно отвергались другой целевой функ-цией. Например, AI-анализ с применением одной целевой функции рекомендовал увеличить срок разработки, тогда как другая целевая функция рекомендовала его сократить.

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

Взгляд в будущее

Несмотря на десятилетия исследований в области технологии программирования до настоящего момента мы видели относительно мало примеров убедительных дока-зательств, которые действительно приводили к изменениям в управлении программ-ными проектами. По нашим предположениям, это отчасти объясняется проблемой контекста: исследователи собирали доказательства об А, а аудиторию интересовали В, С, D и т. д. Мы рекомендуем исследователям проявить чуть больше умеренности при анализе доказательств в области технологии программирования (по крайней мере в нынешней ситуации) и желания общаться с программистами-практиками, которые помогут им лучше определить, что же собой представляют В, С и D. Веро-ятно, в нашей области стоит отказаться (хотя бы временно) от стремления к резуль-татам, относящимся ко всем проектам во всех ситуациях; поиск локальных резуль-татов, которые приведут к положительным изменениям, тоже является довольно сложной и творческой задачей.

Эндрес и Ромбах предложили свою модель накопления информации о технологии программирования и системотехнике [Endres and Rombach, 2003]:

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

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

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

На втором уровне, где происходит выделение закономерностей между проектами и/ или контекстами, иногда приходится довольствоваться абстрагированием важных факторов или базовых принципов — вместо предоставления «Решения с большой буквы», которое будет работать в целом подмножестве контекстов.

Так, Холл и др. попробовали ответить на вопрос, какие факторы обеспечивают мо-тивацию разработчиков [Hall et al. 2008]. Они рассмотрели 92 исследования, в ко-торых этот вопрос изучался в разных контекстах. Пытаясь справиться со всеми ис-следованиями и их разнообразными результатами, исследователи выбрали линию выбора факторов, мотивирующих разработчиков, несмотря на невозможность ко-личественной оценки их вклада. Таким образом, факторы, которые вносили свой вклад в мотивацию по данным нескольких исследований, включались в эту модель с определенной степенью уверенности.

Конечный итог был далеко от прогностической модели, которая утверждает, что фактор X вдвое важнее фактора Y; результат больше напоминал контрольный спи-сок важных факторов, которые менеджеры могли использовать в своем контексте, чтобы быть уверенными в том, что они ничего не забыли. Возможно, лучшее, что можно сделать при таком обилии трудных вопросов, — вооружить практиков переч-нем факторов, которые они должны учесть при самостоятельном поиске решений.

Но для этого необходимо расширить определение того, какие «доказательства» при-емлемы на первом уровне наблюдений. Некоторые исследователи давно утверж-дают, что в исследованиях в области технологии программирования проявляется склонность к количественным данным и методам анализа, но и работа качественно-го плана может оказаться столь же точно обоснованной и может предоставить по-лезные ответы на актуальные вопросы [Seaman, 2007]. Началом пути к построению более мощных доказательных баз должно стать расширение определения приемле-мых доказательств с включением в них как качественных, так и количественных ис-точников — то есть большего объема текстовых и графических данных, объясняю-щих, почему технологии работают (или не работают), наряду с количественными данными, измеряющими эффект от применения этих технологий.

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

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

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

Убедительные доказательные базы также могут способствовать изменениям за счет предоставления доказательств, ориентированных на разные типы пользователей. В аналитических работах часто упоминается модель Роджерса, описывающая рас-пределение потребителей некой инновации (скажем, результатов исследований) в виде гауссовой кривой. Левый «хвост» представляет энтузиастов, «горб» — боль-шинство, которое переходит на новинку где-то посередине, по мере того как идея получает все более широкое распространение, а правый «хвост» — «отстающих», которые сопротивляются изменениям [Rogers, 1962]. Исследователи, хорошо знаю-щие свою аудиторию, могут выбрать подходящее подмножество данных из полного набора, чтобы более эффективно изложить свои доводы.

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

Исследователи предлагали некоторые способы объединения этих разнородных до-казательств [Shull et al. 2001]. Но для нас важнее всего сам факт объединения этих двух типов источников: количественных отчетов и качественных данных. Мы часто видели, что практики лучше воспринимают наборы данных смешенных типов. На-пример, наличие расширенной информации, включающей как точные данные, так и положительные отчеты от реальных рабочих групп, способствовало распростра-нению технологий контроля программного кода между центрами NASA [Shull and Seaman, 2008].

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

Достоверность, или Почему мы настаиваем на том, чтобы нас убедили

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

Как появляются доказательства в области технологии программирования

Самым интересным моментом криминальной драмы часто оказывается момент об-наружения новых доказательств: кто-то сообщает о факте, неизвестном ранее, в ответ на что проницательный сыщик пересматривает свою теорию преступления. Иногда новые доказательства позволяют взглянуть на наши представления о мире под но-вым углом («Так значит, он все это сделал нарочно^), иногда они просто подкрепляют уже существовавшие убеждения («Она действительно не настолько внимательна, как утверждает»), а иногда полностью опровергают то, в чем мы и не сомневались («Вот это да! А я всегда думал, что он приехал через час после нее!») Драма зависит от мыс-лительных способностей сыщика. Гениальные вымышленные сыщики учитывают все доказательства до последнего бита; работают до тех пор, пока из этих доказательств не сложится логичная картина; постоянно проверяют свою теорию преступления и пересматривают ее в свете новых доказательств. А глупые полицейские постоянно спотыкаются на предвзятости мнения и продолжают цепляться за свои теории даже в том случае, если им не удается объяснить их логические нестыковки.

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

Откуда появляется эта новая информация? Из разных источников.

Опыт

Проектировщики используют различные технологии и методы, участвуют в про-ектах и попутно узнают много нового

Другие люди

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

Размыгиления

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

Литература

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

Научные (или квазинаучные) исследования

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

Далеко не все удовлетворены уровнем доказательности в области технологии про-граммирования. Некоторые специалисты призывают к научной доказательности в области технологии программирования ([Finkelstein, 2003], [Kitchenham et al. 2004]), то есть к формированию навыков, привычки и инфраструктуры для инте-грации результатов эмпирических исследований с целью поддержки принятия ре-шений. Обычно при этом используется сравнение с научно-доказательной меди-циной и ее зависимостью от точных клинических данных. Дело даже не в том, что специалисты по технологии программирования игнорируют доказательства (хотя надо признать, что предвзятость и предрассудки существуют и в этой области). Ско-рее, дисциплине в целом не хватает организационной, культурной и технической инфраструктуры, обеспечивающей накопление и интеграцию знаний из разных ис-точников. Барбара Китченхэм представляет это направление в главе 3.

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

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

Основным содержанием этой статьи является «осмысление» доказательств, то есть их оценка на предмет достоверности и целесообразности.

Достоверность и релевантность

в нашем обсуждении центральное место занимают две концепции: достоверность и релевантность.

Достоверность

Степень, в которой мы готовы (или должны быть готовы) поверить представленным доказательствам и выводам из них. Частью достоверности является валидность — степень, до которой исследование и выводы из него точно отражают интересующее нас явление. Валидность является многогранным понятием; вот лишь некоторые из его аспектов.

  • Действительно ли вы наблюдали именно то, что хотели наблюдать?
  • Действительно ли использованные метрики измеряли именно то, что предпо-лагалось?
  • Насколько адекватны объяснения причин тех или иных явлений?
  • Можно ли использовать полученные данные для других, концептуально сравни-мых условий?

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

Релевантность

Степень, в которой вас интересуют (или должны интересовать) доказательства и выводы. Как правило, нерелевантные исследования даже не рассматриваются.

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

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

Целесообразность, или Почему то, что убеждает вас, может не убедить меня

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

Оценочному исследованию, целью которого является выявление недочетов в архи-тектуре, может хватить отзывов со стороны нескольких участников. Нам известен один прототип производственной системы речевого подтверждения, работа над ко-торым была прервана, после того как первые пользователи сообщили, что они носят беруши для подавления фабричного шума. Другие цели требуют контрпримеров. Например, для опровержения слишком общего утверждения или предположения достаточно одного контрпримера. Скажем, одно из исследований поставило под со-мнение утверждения сторонников визуального программирования «графический» значит «хороший»: для этого в нем был представлен эксперимент, показавший, что вложенные структуры более эффективно воспринимаются в текстовом представле-нии [Green and Petre, 1992].

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

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

Количественные и качественные доказательства: ложная дихотомия

в обсуждениях исследования часто делятся на количественные и качественные. Проще говоря, различие определяется актуальными вопросами. Количественные исследования обьшно строятся на измерениях, и в них задаются сравнительные вопросы («Действи-тельно ли А быстрее В?»), вопросы «если» («Если изменится А, то изменится ли В?») и «сколько» («Сколько времени разработчики тратят на отладку?») С другой стороны, в качественных исследованиях на первое место выходят описания и классификации, и в них обычно задаются вопросы «почему» («Почему А проще в изучении, чем В?») и «как» («Какие методы используются разработчиками при отладке?»)

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

Бессмысленно говорить у что количественные доказательства обычно лучше каче-ственных (и наоборот).

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

Это не дихотомия у а континуум.

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

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

Количественные исследования не всегда «слабы», а качественные не всегда «сильны».

Результаты хороших исследований не являются произвольными. Хороший науч-ный метод направлен на получение воспроизводимых («сильных») результатов, потому что воспроизводимость результатов предполагает их надежность, а процесс воспроизведения открывает метод исследования для критического анализа. Воспро-изведение результата означает повторение соответствующего исследования — либо в почти полностью совпадающих условиях (близкая воспроизводимость), либо в других, но сходных (дальняя воспроизводимость). Качественные исследования почти всегда используют уникальные человеческие контексты, а это затрудняет их близкое воспроизведение. Однако это не означает, что результаты исследования не могут быть воспроизведены; часто это возможно. И с точки зрения релевантности дальняя воспроизводимость еще ценнее близкой, потому что она указывает на бо-лее общий характер результата. С другой стороны, результаты количественных ис-следований иногда оказываются невоспроизводимыми. Например, эксперименты Джона Дели с глубиной наследования повторялись в трех разных исследователь-ских группах с противоречащими результатами [Prechelt et al. 2003].

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

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

Объединение доказательств

Один из способов преодоления ограниченности доказательств основан на сочета-нии данных из разных источников: объединении результатов, полз^енных в ходе разных исследований по одному вопросу Предполагается, что если разные формы доказательств или доказательства от независимых источников согласуются (или хотя бы не противоречат друг другу), они становятся более «весомыми» и в сово-купности обладают большей достоверностью.

В области технологии программирования еще не существует консолидированной доказательной базы. Впрочем, определенные усилия по консолидации предпри-нимаются: Барбара Китченхэм и ее коллеги продвигают проект по систематизации анализа литературы, который изучают и объединяют опубликованные доказатель-ства по определенной теме с использованием системы оценок по заданным крите-риям. Например, Иоргенсен и Шепперд в работе по моделированию затрат соби-рают и объединяют доказательства, сравнивающие производр1тельность моделей и оцениваемых людей, и высказывают мнение об их приблизительной сравнимости Jorgensen and Shepperd, 2007]. Интересно заметить, что систематические обзоры — а также обзоры третьего порядка (обзоры систематизированных обзоров), выпол-няемые Китченхэм и др., — выявляют любопытные слабости в доказательной базе [Kitchenham et al. 2009]:

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

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

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

Любая методология может стать своего рода «линзой», через которую исследовате-ли рассматривают мир, однако важно понимать, что не все объекты находятся в пре-делах видимости. Слепое следование методологии приводит к разного рода непри-ятным промахам, особенно когда исследователь не смог разобраться в условностях и предположениях, на которых базируется методология. Наличие общепринятой методологии не избавляет исследователей от разумного выбора методов в контек-сте требуемых доказательств.

В качестве примера метода, результаты которого пригодны для объединения, мож-но привести эталонное тестирование (benchmarking). Метод основан на измерении характеристик в соответствии с очень точно определенной процедурой (эталон-ным тестом). Например, эталонный тест SPEC CPU измеряет общую производи-тельность процессора, подсистемы памяти, операционной системы и компилятора в приложениях с интенсивными вычислениями. Он состоит из набора исходных ко-дов программ пакетного режима и подробных инструкций, в которых указано, как их откомпилировать, ввести данные и получить результаты.

Если эталонный тест хорошо определен и корректно применяется, вы будете точ-но знать, что означают результаты измерения, сможете без лишних слов сравнить результаты для компьютеров Sun с результатами HP или Intel и т. д. Надежность и сравнимость — именно те качества, для которых изобретались эталонные тесты и которые делают их образцом достоверности.

Итак, эталонные тесты состоят из одних «плюсов»? Конечно, нет. Важнейшей про-блемой доказательств, полученных на базе эталонных тестов, является их реле-вантность: в какой степени использованные метрики пригодны для исследуемого явления? Содержимое эталонного теста всегда является делом первостепенной важности, и обычно по этому поводу нет единого мнения. Тест SPEC CPU в этом отношении довольно успешен, но другие (скажем, тест ТРС-С для измеренрш тран-закционной нагрузки на РСУБД) вызывает изрядную долю скептицизма.

Ограничения и необъективность

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

Что еще хуже, доказательства могут быть необъективными. Скольких проектиров-щиков убедят «слепые опыты» и потребительские эксперименты из старомодной рекламы бытовой химии («Наше средство отмоет больше тарелок…»)? Правила ре-гулирования рекламной деятельности требуют, чтобы такие потребительские экс-перименты соответствовали определенным стандартам, обеспечивающим сравни-мость условий: такая же грязь, такая же вода, то же количество средства и т. д. Однако рекламодатели свободны в выборе условий; они подбирают такие факто-ры, как вид грязи и температуру воды, для своего продукта. «Ха! — говорим мы. —

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

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

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

Виды доказательств, их сильные и слабые стороны

Для наглядности рассмотрим пример. Допустим, мы рассматриваем новую техно-логию программирования AWE (А Wonderfulnew Excitement), которая была раз-работана как замена технологии BURP (Boring but Usually Respected Predecessor). Какие доказательства мы можем рассмотреть для принятия решения о переходе на AWE? В следующих разделах описаны типичные виды исследований и оценивают-ся проблемы, часто возникающие в области достоверности и релевантности.

Контролируемые эксперименты и квазиэксперименты

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

который может доказать причинную зависимость: если изменения в условиях экспе-римента ограничиваются заменой BURP на AWE, то любые изменения в результатах (кроме статистических отклонений) должны быть обусловлены этим различием.

Иногда случайный выбор разработчиков невозможен, потому что в распоряжении экспериментатора имеются только готовые группы. Для примера возьмем сравне-ние языков С, С++, Java, Perl, Python, Rexx и TCL, описанное в главе 14. Сколько вам известно программистов, одинаково хорошо владеющих всеми семью языками? А для проведения рандомизированного эксперимента вам придется заполнить все семь групп!

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

Достоверность

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

Субъективное смещение

Можно ли утверждать, что участники эксперимента в равной степени компетент-ны в использовании AWE и BURP? Если нет, то эксперимент может в большей степени отражать характеристики участников, нежели характеристики техноло-гии. Хорошо замаскированные разновидности этой проблемы основаны на мо-тивационных аспектах: с BURP работать скучно, а с AWE интересно, но в долго-срочной перспективе ситуация изменится. Различия проявляются особенно ре-льефно, если экспериментатор является изобретателем AWE и соответственно относится к этой технологии с большим энтузиазмом.

Смещение выбора задачи

Задача, выбранная таким экспериментатором, скорее будет подчеркивать силь-ные стороны AWE, нежели сильные стороны BURP.

Смещение в составе групп

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

Релевантность

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

Опросы

Опрос — метод, при котором экспериментатор просто задает многим людям одинако-вые вопросы по теме, — является предпочтительным методом для оценки отношения. Чем, по вашему мнению, хороша технология AWE? А как насчет BURP? Насколько лично вам технология BURP кажется скучной? Почему? Социологи и ПСР1ХОЛОГИ разработали сложную (и дорогостояш.ую) методологрш отбора вопросов для пра-вршьной оценки отношения к определенной теме. К сожалению, в опросах из области технологии программирования эта методология обычно игнорируется.

Опросы также могут использоваться (хотя и с меньшей надежностью) для сбора информации о личных впечатлениях (назовите пять характерных проблем, часто встречаюпцихся при использовании AWE или BURP). Опросы хорошо масштабиру-ются, это самый дешевый метод сбора информации с большим количеством участ-ников. Если в опрос входят открытые вопросы с ответамр! в формате произвольного текста, он может стать основой не только для количественных, но и для качествен-ных исследований.

Достоверность

Хотя опросы дешевы и удобны, добиться высокой достоверности с ними довольно трудно. Приведем типичные проблемы с достоверностью опросов.

Ненадежные вопросы

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

Некорректные вопросы или выводы

Это особенно часто происходит, когда исследователь злоупотребляет опросами для сбора информации о сложных фактологических проблемах: «Сколько де-фектов содержит типичная трансфиксационная диаграмма AWE?» Люди про-сто недостаточно хорошо понимают, о чем идет речь, чтобы дать точный ответ. Такое непонимание не создаст особых проблем, если рассматривать ответы как то, чем они действительно являются: они раскрывают то, что думают участни-ки по данной теме, и, как было подчеркнуто в начале раздела, в них отражается отношение участников. Однако чаще ответы интерпретируются как непрелож-ные факты, соответственно и выводы из них оказываются ложными. (В таких случаях критики часто называют опросы «излишне субъективными», но ведь субъективность и составляет подлинную суть опроса! Если субъективность создает проблемы, значит, метод был выбран неверно.)

Тематическое смещение

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

Нечеткая целевая аудитория

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

Достоверное обобщение требует соблюдения двух условий. Во-первых, опрос дол-жен быть ориентирован на четко определенную, вразумительную аудиторию. «Все читатели веб-форумов X, Y и Z за период от D до Е» — четко, но невразумитель-но; мы понятия не имеем, что это за люди. Во-вторых, в опросе должна участвовать большая доля (желательно 50% и более) этой аудитории, иначе участники могут об-разовать смещенную выборку. Возможно, 4% фанатов AWE («Единственное, что не дает мне заснуть на работе») и 5% ненавистников BURP («Так скучно, что я делаю вдвое больше ошибок») из нашей аудитории просто не смогли остаться в стороне, и теперь представляют половину выборки.

Релевантность

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

Эксплуатационные отчеты и ситуационные исследования

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

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

Ситуационные исследования базируются на разных видах данных: разговорах, вы-полняемых операциях, документах и т. д., собираемых исследователями многими потенциальными способами: прямые наблюдения, собеседования, анализ докумен-тов, специализированные программы анализа данных. Ситуационные исследова-ния направлены на решение широкого круга вопросов: какие основные проблемы возникают при использовании процессов AWE? Как технология AWE влияет на деятельность по проектированию? Как она влияет на итоговую архитектуру? А на структуру процесса тестирования? И т. д.

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

Достоверность

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

  • избирательности в выборе сохраняемых данных;
  • неоднозначности интерпретации.

Следовательно, в этом случае чрезвычайно важны точное описание условий и дан-ных, а также тщательность в интерпретации результатов. Достоверность ситуацион-ных исследований чрезвычайно сильно зависит от качества представления резуль-татов.

Релевантность

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

Другие методы

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

Представление достоверности (или недостоверности) в отчетах

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

Общие характеристики

у исследований с высокой достоверностью:

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

Ясно поставленный вопрос

Ясно сформулированный и однозначный вопрос — первопричина достоверности. Ведь если сами авторы не могут толком объяснить, что они пытаются узнать, то как они могут рассчитывать на то, что вы им поверите? Исследуемый вопрос необяза-тельно провозглашается под фанфары, но он может быть однозначно понятен из сводки и введения.

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

Информативное описание условий исследования

Понимание условий исследования является определяющим фактором достоверно-сти и главным отличием пресс-релизов от научных отчетов. Даже самый привлека-тельный результат обладает низкой достоверностью, если он был получен посред-ством гадания на хрустальном шаре. Всем нам порой попадаются впечатляющие заявления типа: «Эмпирическое исследование с почти 600 участниками показало, что Java превосходит С++ практически во всех отношениях — время программиро-вания сокращается на 11%, отладка ускоряется на 47%, а долгосрочная стабильность архитектуры улучшается на 42%. Только по быстродействию исполнения программ С++ все еще опережает Java на 23%».

Те же результаты начинают выглядеть куда менее достоверно, если вы знаете, что они были получены в результате опроса. И они могут стать еще менее достовер-ными, если повнимательнее присмотреться к вопросам: как сравнивать время про-граммирования и отладки, когда программы различны? А, так организаторы спра-шивали, насколько часто выполнение этих задач занимало больше времени, чем предполагалось! И что такое «долгосрочная стабильность архитектуры»? А, они спрашивали, какая часть методов оставалась неизменной! Как говорится, дьявол в деталях: метод, выборка, данные, анализ.

Предлагаем простой критерий: вы можете смело игнорировать все исследования, у которых условия проведения вообще не описаны, и весьма скептически относить-ся ко всем исследованиям, в которых после описания условий остаются какие-либо «вопросы на букву К»: к какому типу относится исследование? Какие задачи ре-шались участниками? Как выглядел рабочий контекст? Кем были участники ис-следованрш? Как собирались данные? Как они проверялись? Как выглядят точные определения основных метрик? Хороший отчет по эмпирическому исследованию должен удовлетворительно ответить на все эти вопросы.

Содержательное и доступное представление данных

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

Предположим, в исследовании были задействованы шесть разных групп и пять раз-ных метрик. Некоторые авторы представят такие данные в виде таблицы, у которой в каждой строке указывается название группы, размер группы и, допустим, макси-мальное, минимальное и среднее значение, а также стандартное отклонение одной метрики. Таблица состоит из пяти блоков по шесть таких строк каждый; в итоге получается таблица из 37 строк, занимающая более половины страницы. Что вы бу-дете делать, столкнувшись с такой информацией? Либо проигнорируете таблицу (лишаясь возможности проанализировать данные), либо погружаетесь в таблицу, пытаясь сравнить группы по каждой метрике. В последнем случае придется стро-ить мысленное представление о ситуации в целом: сначала разбираться в отдельных записях, а затем представлять отношения между ними. Фигурально выражаясь, вы приходите на кладбище данных, оживляете покойников и учите их танцевать под свою музыку.

В более предпочтительном варианте авторы сохраняют свои данные «живыми», представляя их так, чтобы помочь читателю включиться в работу. Они находят визуальные представления, относящиеся к ключевым вопросам и отношениям, которые авторы желают рассмотреть и которые непосредственно относятся к та-бличному или текстовому представлению данных. Хорошие визуализации фор-мируют логичную связь заметных визуальных характеристик (масштаб, цвет и т. д.) с информацией, представляющей интерес. В плохих визуализациях исполь-зуются визуальные характеристики — неочевидные или отвлекающие зрителей от данных, — например, дискретные данные соединяются линиями, создающими впечатление некой непрерывности, или на взаимосвязанных графиках исполь-зуются разные масштабы, или оси начинаются не с нуля, или на графике отобра-жаются посторонние элементы, привлекающие больше внимания, чем данные. Основы правильной визуализации были изложены в книге Эдварда Тафта [Tufte 1983].

Прозрачность статистического анализа

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

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

В хорошем исследовании авторы простыми словами объясняют смысл каждого использованного статистического показателя. Они предпочитают статистические показатели, смысл которых хорошо понятен (например, доверительные интерва-лы) показателям с неочевидным смыслом (р-значения или величины эффекта, нормализованные по стандартным отклонениям). Они четко интерпретируют каждый результат, говоря: «Здесь, вероятно, присутствуют реальные проявления» (положительный результат), «Скорее всего, здесь эффект не проявляется или остается минимальным; в основном мы наблюдаем случайный шум» (отрицатель-ный результат) или «Трудно сказать, что это значит» (неопределенный результат). Даже последний случай внушает оптимизм, потому что он говорит, что неуверен-ность по поводу смысла данных, которую вы испытали при взгляде на них, была обоснована, и она не устраняется даже статистическими средствами (по крайней мере не этими; возможно, другой метод анализа способен пролить больше света на ситуацию).

Честное обсуждение недостатков

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

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

Надежные и релевантные выводы

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

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

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

Общество, культура, технология программирования и вы

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

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

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

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

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

Благодарности

Авторы благодарны своим коллегам, которые терпеливо сносили их нерешитель-ность в доказательном подходе к доказательствам, — в том числе Дэвида Баджена (David Budgen), Гордона Рагга (Gordon Rugg) и Джудит Сигал (Judith Segal).

Что можно узнать из систематического обзора

Будучи убежденным сторонником научно-доказательного подхода к технологи-ям программирования ([Dyba et al. 2005], [Kitchenham et al. 2004]), я также явля-юсь убежденным сторонником систематических обзоров (SR, Systematic Review) ([Kitchenham, 2004], [Kitchenham and Charters, 2007]). Иногда их также называют систематическими обзорами литературы, чтобы избежать возможной путаницы с методами чтения и анализа документации или кода. Научно обоснованный под-ход к технологиям программирования невозможен без качественной методологии объединения доказательств, полученных из разных эмпирических исследований. Систематические обзоры предоставляют такую методологию.

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

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

Материал также может представлять интерес для более опытных исследователей, еще не уверенных в ценности методологии систематических обзоров. Многие евро-пейские ученые публикуют систематические обзоры в области технологий про-граммирования, но в США количество таких ученых невелико ([Kitchenham et al. 2009b], [Kitchenham et al. 2010a]).

Также хочется верить, что после прочтения этой главы исследователи-эмпирики осознают, что плоды их труда могут использоваться в будущих систематических обзорах, и будут представлять свои результаты в форме, удобной для сводной обра-ботки. В одном из недавних систематических исследований оказалось, что полный метаанализ невозможен из-за того, что в первичных исследованиях использовались слишком сильно различающиеся способы представления результатов ([Turner et al. 2008], [Turner et al 2010]).

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

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

Общие сведения о систематических обзорах

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

Классический пример, доказывающий пользу систематических обзоров, относится к области медицины. В 1990 году группа во главе с Кроули опубликовала систематиче-ский обзор с метаанализом 12 первичных исследований результатов приема корти-костероидов беременными женщинами с риском преждевременных родов [Crowley et al. 1990]. Существовала гипотеза, что кортикостероиды снижают проблемы с лег-кими у недоношенных детей. Систематический обзор Кроули подтвердил, что при-ем кортикостероидов существенно снижает риск детской смертности. В то время принятие кортикостероидов не относилось к стандартным методам предупрежде-ния преждевременных родов, и публикация обзора привела к изменению врачеб-ной практики. Однако этот случай не считался триумфом научно-доказательного подхода в медицине; из 12 исследований 8 были опубликованы до 1982 года. Если бы эти 8 исследований были обобщены в 1982 году, это предотвратило бы восемь лет неверного лечения и связанных с ним детских смертей. Переоценка важности своевременного обобщения доказательств привела к основанию Кокрейновского Сотрудничества (Cochrane Collaboration) — некоммерческой организации, которая проводит систематические обзоры в области медицины и здравоохранения и ведет базу данных отчетов по ним.

Обновленную версию отчета Кроули и др. по кортикостероидам можно бесплатно загрузить в библиотеке Кокрейновского Сотрудничества [Roberts and Dalziel, 2006 . Информация представляет не только исторический интерес, для начинающих ис-следователей она служит хорошим примером качественного обзора.

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

Эксперты могут ошибаться.

Группа Антмана подтвердила, что экспертное мнение не всегда отражает текущее состояние медицинской науки [Antman et al. 1992 .

Выбор «сопутствующих исследований» может быть необъективным

Шадиш провел опрос среди авторов более 280 статей в психологических журна-лах. Как оказалось, многие исследования упоминались в обзорах не из-за высо-кого качества, а лишь потому, что они подтверждали позицию автора [Shadish, 1995].

В неформальных обзорах могут быть пропущены важные исследования.

Например, неформальный обзор убедил лауреата Нобелевской премии Линуса Полинга в том, что сверхдозы витамина С защитят от обычной простуды. Систе-матический обзор опроверг это заключение. Обнаружилось, что Полинг не упомянул 5 из 15 методологически обоснованных исследований [Knipschild, 1994].

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

Формулировка исследуемых вопросов

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

Поиск релевантных исследований

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

Оценка качества отдельных исследований

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

Выделение и обобщение данных

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

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

Неопытным исследователям, только начинающим изучать процессы системати-ческого обзора, я рекомендую обратить внимание на классификационные исследо-вания, Речь идет о систематических обзорах, целью которых является не ответ на конкретный вопрос, а поиск и классификация литературы, относящейся к широ-кой теме [Kitchenham et al. 2010b]. Различия между двумя типами обзоров хорошо KJ отражены в двух статьях Магна Иоргенсена (Magne Jorgensen). Первая статья со-держит традиционное систематическое исследование вопроса о том, обеспечивает ли моделирование затрат более точные результаты, чем экспертные оценки затрат по предстоящему проекту [Jorgensen, 2007]. Вторая статья представляет собой вы-сококачественное классификационное исследование, которое делит на категорир! литературу, посвященную оценке затрат [Jorgensen and Shepperd, 2007]. В разделе «Систематические обзоры в области технологий программирования» этой главы рассматриваются некоторые систематические обзоры, приведшие к кардинальным изменениям в области технологий программирования, для демонстрации необхо-димости методологически обоснованных методов обобщения доказательств. Но прежде чем переходить к обсуждению этих примеров, я приведу некоторые общие сведения о процессе систематизации литературы.

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

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

Достоинства и недостатки систематических обзоров

За прошедшее время я определила два стандарта выполнения систематических об-зоров, подходящих для исследователей в области технологий программирования. Первый стандарт базируется на медицинских систематических обзорах [Kitchenham 2004], а второй стандарт пересматривает первый с учетом новых концепций, поза-имствованных из социологических исследований [Kitchenham and Charters 2007]^

В этом разделе приводится краткая сводка рекомендаций, представленных в этих отчетах. Тем не менее я должна предупредить читателей: не рассчитывайте успеш-но провести систематический обзор на основании этой краткой сводки. Прочитай-те полные технические отчеты, обратитесь к другим источникам (например, [Fink, 2005], [Higgins and Green, 2009], [Khan et al. 2003], [Petticrew and Roberts, 2006]) и реальным примерам систематических обзоров (некоторые из них рассматривают-ся далее в этой книге). После знакомства с хорошими примерами систематических обзоров вы увидите, что это далеко не самая простая форма исследования. Они за-нимают много времени, требуют тщательного планирования, исполнения и пред-ставления результатов [Brereton et al. 2007].

Фазы систематического обзора

Систематический обзор состоит из трех основных фаз: планирования, проведения обзора и представления результатов.

Планирование

Рассмотрим этапы фазы.

Выявление потребности в обзоре

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

Заказ на проведение обзора

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

Формулировка исследуемых вопросов

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

Разработка протокола

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

Анализ протокола

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

Проведение обзора

Рассмотрим этапы фазы.

Поиск литературных источников

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

Выбор первичных исследований

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

Оценка качества исследований

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

Например, при проведении экспериментов в анкету обычно включаются такие стан-дартные вопросы, как «Был ли выбор пациентов при назначении препарата случай-ным?» и «Было ли известно исследователям, кто из пациентов принимает препарат, до завершения эксперимента?» Для применения систематических обзоров в обла-сти технологий программирования с ее разнообразными методами исследования я рекомендую взять в качестве отправной точки контрольный список [Dyba апс DingS0yr, 2008а], хотя, по моему мнению, при ответах на вопросы лучше использо-вать числовую шкалу вместо двоичного выбора «да/нет». Также см. главу 2.

Извлечение данных и синтез

Данные, извлеченные из каждой публикации, необходимо объединить для полу-чения ответов на вопросы исследования. Если в вашем распоряжении имеется до-статочный объем совместимых количественных данных, можно применить методы метаанализа [Lipsey and Wilson, 2001]. Если таких данных нет, результаты следует представить в табличной форме, отвечающей на поставленные вопросы.

Метаанализ является самой распространенной формой объединения в медицин-ских систематических обзорах, но в других областях он встречается значительно реже. На практике метаанализ возможен только в том случае, если результаты всех первичных исследований представлены в виде, пригодном для статистического ана-лиза. Впрочем, даже при наличии статистических результатов полный метаанализ возможен не всегда [Turner et al. 2010].

Представление результатов обзора

Рассмотрим этапы фазы.

Определение механизмов распространения

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

Форматирование основного отчета

На систематические обзоры распространяются основные стандарты представления результатов в эмпирических статьях. Я рекомендую использовать формат струк-турированной аннотации (как в [Roberts and Dalziel, 2006]). Если вы соблюдали правильно выбранный протокол и фиксировали результаты процессов поиска и из-влечения данных, то этот этап будет относительно простым.

Оценка отчета

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

Одним из требований к систематическим обзорам является повторяемость их резуль-татов — в том смысле, что если другая группа будет следовать тому же протоколу, она получит те же результаты. Повторяемость зависит от однозначности исследуе-мых вопросов, полноты отчетов о процессах поиска и обобщения, а также от масштаба исследования. В одном недавнем исследовании сравнивались два независимых си-стематических обзора по одной теме [Macdonell et al.]. Исследование заключает, что в контексте относительно малого количества первичных исследований в ipynnax, со-стоящих из экспертов в предметной области, систематические обзоры в области тех-нологии программирования обладают довольно неплохой повторяемостью. Другой систематический обзор, основанный на очень большом объеме эмпирической литера-туры [Turner et al. 2010], обнаружил серьезные различия между обзорами литературы, но объяснил их различиями в формулировках исследуемых вопросов.

Проблемы, связанные с проведением обзора

Теоретически систематический обзор проводится строго в соответствии с заранее определенным протоколом. Однако на практике выполнить это требование слож-нее, чем кажется. Несмотря на предварительную проверку, может оказаться, что протокол не учитывает некоторые варианты в планировании и представлении дан-ных релевантных первичных исследований, поэтому в ходе работы могут возник-нуть ситуации, не предусмотренные протоколом. В таких обстоятельствах протокол приходится пересматривать. В зависимости от характера пересмотра иногда возни-кает необходимость в анализе и даже повторном выполнении большого объема ра-боты для ее согласования с пересмотренным протоколом [Turner et al. 2008].

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

При автоматизированном поиске Ханней рекомендует ограничиться электронными источниками АСМ Digital Library, IEEE Xplore, Compendex и ISI Web of Science, так как в этих библиотеках представлены материалы АСМ, IEEE, Kluwer Online, Science Direct, SpringerLink и Wiley [Hannay et al. 2009]. Авторы также советуют вы-полнить ручной поиск по тезисам важнейших тематических конференций. А если вам понадобится найти всю актуальную литературу (как опубликованную, так и нет), также можно воспользоваться Google Scholar или CiteSeer. Учтите, что в разных элек-тронных библиотеках используются несколько различающиеся реализации поиска, поэтому вам стоит проконсультироваться у ответственного за работу библиотеки по поводу процесса и строк поиска. Особое внимание уделите следующим нюансам:

  • Электронные библиотеки, посвященные технологиям программирования, имеют разные интерфейсы и разную степень совместимости со сложными формулами, обычно применяемыми исследователями для поиска релевантных статей.
  • В электронных библиотеках, посвященных технологиям программирования, также используются разные процедуры поиска в основном тексте статьи, поиска по на-званию, аннотации или ключевым словам. И разумеется, системы индексирования осуществляют поиск только по названиям, ключевым словам и аннотациям.
  • Результаты автоматизированного поиска из разных источников могут пере-крываться (то есть одна публикация может быть найдена в разных электронных библиотеках), и в каждый поиск включается большое количество нерелевантных статей ([Brereton et al. 2007], [Dieste and Padua, 2007]).

При ручном поиске необходимо выбрать журналы и тезисы конференций, в которых вы собираетесь искать информацию. Также необходимо обосновать выбор источ-ников. Как ни странно, в одной ситуации мы обнаружили, что целенаправленный ручной поиск работает намного быстрее широкого автоматического [Kitchenham et al. 2009а]. Вероятно, на практике стоит использовать смешанную стратегию. Ручной поиск в некоторых источниках (скажем, в тезисах конференций для специалистов) предоставит базовый набор первичных исследований-кандидатов, на которых вы сможете проверить эффективность своих строк автоматизированного поиска. Так-же базовый набор статей может быть отобран экспертом.

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

Повторное включение одного исследования повлияет на объединение данных. По этой причине необходимо проверить, содержат ли статьи данные многих исследова-ний или их результаты ссылаются на одни и те же исследования. Однако распознать дубликаты отчетов по одному исследованию порой бывает непросто. В одном из не-давних систематических обзоров для выявления отчетов по одному исследованию мне с коллегами пришлось проверять размеры выборок со списком авторов [Turner et al. 2010]. В другом систематическом обзоре проблема оказалась еще более ковар-ной: разные исследователи использовали одни и те же наборы данных для иссле-дования одних и тех же методов анализа данных, но при этом они не приводили информацию об использованных наборах данных [Kitchenham et al. 2007].

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

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

Предполагается, что участие нескольких исследователей в систематическом обзоре компенсирует субъективность человеческого мышления. Изначально мы с коллега-ми предположили, что процесс извлечения и проверки станет более эффективным при использовании двух независимых операций извлечения данных и оценки ка-чества [Brereton et al. 2007], но в конечном итоге идея оказалась неудачной [Turner et al. 2008]. Тем не менее иногда систематический обзор приходится выполнять одному исследователю, например, при выполнении дипломных исследований или в условиях ограниченности ресурсов. Например, из-за жесткого графика и нехватки ресурсов мне пришлось выполнять предварительное классификационное исследо-вание самостоятельно [Kitchenham, 2010]. В таких случаях исследователи приме-няют специальные методы оценки точности субъективных решений, такие как про-цедура повторного тестирования, предложенная Финком [Fink, 2005].

Наконец, в отношении критериев качества я обнаружила, что фактическая оцен-ка качества отдельных исследований выполнялась лишь в относительно неболь-шой части систематических обзоров в области технологий программирования ([Kitchenham et al. 2009b], [Kitchenham et al. 2010a]). Однако оценка качества яв-ляется критическим элементом процесса систематического обзора и играет важную роль в объединении и интерпретации результатов. Пример влияния низкого каче-ства исследований на результаты встречается в недавнем систематическом обзоре, посвященном эффективности гомеопатии [Shang et al 2005]. При включении всех исследований создается впечатление, что гомеопатия эффективнее плацебо, а си-стематический обзор с исключением низкокачественных исследований показывает, что гомеопатия не более эффективна, чем плацебо. Пример проблемы некачествен-ных первичных исследований в области технологий программирования будет рас-смотрен далее.

Систематические обзоры в области технологий программирования

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

Исследования по оценке затрат

в исследованиях по оценке затрат часто приводятся результаты эмпирических ис-следований на реальных наборах данных, так что вопросы, связанные с оценкой затрат, являются очевидными кандидатами для систематических обзоров. В самом деле, анализ систематических обзоров, опубликованных в период с января 2004 года по июнь 2007 года, показал, что оценка затрат чаще всего становилась темой систе-матических обзоров [Kitchenham et al. 2009b]. Два таких обзора представляют осо-бый интерес, потому что они разрушают некоторые стереотипные представления об оценке затрат по разработке ПО.

Точность моделирования затрат

в двух своих систематических обзорах Магн Йоргенсен исследовал вопрос о том, обе-спечивают ли оценки, полученные посредством моделирования затрат (математиче-ские формулы, которые обычно строятся на основании данных прошлых проектов), большую точность по сравнению с экспертными оценками (основанными на субъ-ективных мнениях разработчиков или руководителей) [Jorgensen, 2004], [Jorgensen, 2007]. С момента публикации книг Боэма [Boehm, 1981] и Демарко [DeMarco, 1982 в начале 1980-х годов исследователи верили, что моделирование дает более точный результат, чем экспертная оценка. В своих обзорах Йоргенсен впервые попытался определить, основана ли эта вера на эмпирических доказательствах.

В своем обзоре [j0rgensen, 2004] Йоргенсен нашел 15 первичных исследований, в которых сравнивались результаты экспертных оценок и моделирования затрат. Согласно его классификации 5 исследований отдавали предпочтение экспертной оценке, 5 не находили существенных различий и еще 5 утверждали превосходство модельной оценки. В [Jorgensen, 2007] он представил 16 исследований, сравнивав-ших экспертные оценки с формальными моделями, и обнаружил, что средняя точ-ность экспертной оценки оказалась выше в 12 из них.

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

Что касается возможной субъективности разделов «Сопутствующие исследования» в статьях, я была соавтором одной из статей, входивших в оба обзора Йоргенсена [Kitchenham et al. 2002]. В этой статье мы с коллегами нашли только 2 из 12 статей, опубликованных до 2002 года и найденных Йоргенсеном; обе статьи отдавали пред-почтение экспертной оценке перед модельной, как и мы сами.

Точность оценок затрат в отрасли

в проекте 1994 CHAOS Report [The Standish Group, 2003] утверждается, что среднее превышение запланированных затрат в области разработки ПО составляет 189%, и только 16% проектов завершаются успешно (то есть укладываются в бюджет и график). Последующие отчеты Standish Group обнаруживают более низкие зфовни пре-вышения, а к успешным уже относятся 34% проектов — наблюдатели преподносят это изменение как наглядную демонстрацию совершенствования в области техно-логий программирования. Но когда Молоккен-Остволд И’ Йоргенсен предприняли литерат}фный обзор по этой теме [Molokken-Ostvold et al. 2004], [Molokken-Ostvold and Jorgensen, 2003]), они обнаружили три отраслевых исследования по этой теме, со-гласно которым среднее превышение затрат лежало в диапазоне от 30 до 50%. Данные настолько сильно отличались от отчета CHAOS, что ученые тщательно проанализиро-вали отчет CHAOS, стремясь понять, почему величина превышения была настолько большой, и в результате своих исследований полностью исключили отчет CHAOS из своего обзора.

Подробности их анализа отчета CHAOS приведены в [j0rgensen and Molokken, 0stvold 2006]. Оказалось, что методология, применявшаяся Standish Group, остав-ляла желать лучшего.

  • Метод вычисления превышений не был описан. Когда Молоккен-Остволд и Йоргенсен провели собственные вычисления, они обнаружили, что величина превышения должна быть ближе к 89, а не к 189%.
  • Похоже, специалисты Standish Group намеренно отбирали истории с неудачным исходом.
  • Не было предусмотрено категории для проектов, завершенных в рамках бюджета.
  • Превышение затрат не имело четкого определения, и в него могли включаться затраты на отмененные проекты.

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

Гибкие методы

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

Экстремальное программирование (ХР, ХР2)

Исходный метод экстремального программирования объединял 12 основных приемов: игра в планирование, частые небольшие релизы, метафора системы, про-стота архитектуры, опережающее тестирование, рефакторинг, парное программи-рование, коллективное владение, непрерывная интеграция, 40-часовая рабочая неделя, заказчик всегда рядом и стандарты кодирования [Веек, 2000]. Пересмо-тренная версия метода ХР2 состоит из следующих «первичных практик»: работа в одном помещении, команда как единое целое, информативность окружения, энергичная работа, парное программирование, «рассказы», еженедельный цикл, ежеквартальный цикл, слабина, 10-минутная сборка, непрерывная интеграция, опережающее тестирование и инкрементное проектирование [Веек, 2004].

Scrum [Schwaber and BeedlCy 2001]

В этом методе центральное место занимает управление проектом в ситуациях, в которых опережающее планирование затруднено. Метод основан на механиз-мах «эмпирического управления процессом», базирующихся на циклах обратной связи. Программный продукт разрабатывается самоорганизующейся группой как последовательность шагов (называемых «спринтами»), начиная с планиро-вания и заканчивая итоговым обзором. Функции, которые должны быть реали-зованы в системе, регистрируются в резерве свойств (backlog). Затем владелец продукта решает, какие из элементов резерва свойств должны быть разработаны во время следующего спринта. Участники группы координируют свою работу на ежедневных встречах. Один участник группы (scrum master) отвечает за решение проблем, мешающих эффективной работе группы.

DSDM (Dynamic Software Development Method) [Stapleton, 2003]

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

Экономная разработка [Poppendieck and Poppendieck, 2003]

Использование принципов экономного производства (lean production), и в первую очередь производственной системы Toyota, в области разработки ПО. Со-стоит из семи принципов: устранение отходов, повышение квалификации, как можно более позднее принятие решений, быстрые релизы, расширение полно-мочий, формирование целостности и видение «общей картины».

Один из возможных недостатков систематических обзоров заключается в том, что они могут прогрессировать слишком медленно, вследствие чего их содержание не представляет интереса в такой быстроразвивающейся области, как технологии про-граммирования. Однако уже появились два новых систематических обзора, посвя-щенных гибким методологиям: [Dyba and DingS0yr 2008а] и [Hannay et al. 2009 .

Диба и Дингсойр

Авторы первого обзора [Dyba and Dingsayr, 2008а] преследовали три цели:

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

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

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

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

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

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

Ханней, Диба, Арисхолм и Сьоберг

Группа [Наппау et al. 2009] исследовала парное программирование и применила ме-таанализ для объединения результатов. Если вас интересует, как проводится метаа-нализ, в этой публикации содержится хорошее введение в тему. В систематическом обзоре отобраны 18 первичных исследований, причем во всех проводились экспери-менты. Из 18 исследований в 4 экспериментах участвовали только профессионалы, в 1 — профессионалы и студенты, а в остальных 13 — только студенты. Группа Хан-нея исследовала 3 разных показателя: качество, продолжительность и трудозатраты (хотя не все показатели были рассмотрены в каждом исследовании). Исходный ана-лиз показал, что применение парного программирования оказало:

  • небольшой положительный эффект на качество;
  • средний положительный эффект на продолжительность;
  • средний отрицательный эффект на трудозатраты

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

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

Авторы указали, что неоднородность и возможная необъективность отбора могли объясняться присутствием регулирующих переменных (то есть переменных, став-ших причиной различий между результатами исследований). Для исследования влияния возможных регулирующих переменных одно исследование подверглось подробному анализу. Это было самое масштабное исследование с 295 участниками трех уровней квалификации (высокий, средний и низкий). Авторы сделали вывод, что, по всей вероятности, сложность задачи связана с показателями: так, в очень сложных задачах парное программирование может повышать качество, но за счет существенного увеличения трудозатрат, а задачи низкой сложности могут решаться быстро, но за счет снижения качества. Авторы рекомендуют исследователям в буду-щих первичных исследованиях сосредоточиться на регулирующих переменных.

Исследование Дибы и Дингсойра предполагает, что применение гибких методоло-гий приносит определенную пользу [Dyba and Dingsoyr, 2008а]. С другой стороны, метаанализ Ханнея и др. указывает на то, что эффект парного программирования не настолько велик, как принято считать [Наппау et al. 2009]. В целом из результатов обоих исследований можно сделать вывод, что не только эффект применения гиб-ких методов нуждается в более серьезном исследовании, но и сами методы анализа, применяемые к первичным исследованиям, нуждаются в совершенствовании.

Методы контроля

Методами контроля называются методы чтения кода и документации с целью вы-явления дефектов. Возможно, это одна из наиболее исследованных тем в области эмпирического анализа технологий программирования. Между 1993 и 2002 года-ми было выполнено 103 антропоцентрических экспериментальных исследования Sj0berg et al. 2005]; 37 (36%) из них относились к методам контроля. Следующую по значимости категорию составляли методы объектно-ориентированного (ОО) проектирования, которые исследовались в 8 (7,8%) из этих 103 публикаций. Таким образом, методы контроля являются хорошим кандидатом для проведения система-тического обзора.

Недавно Циолковски выполнил систематический обзор с метаанализом для провер-ки оценок метода PBR (Perspective-Based Reading) [Ciolkowski, 2009]. Например, многие исследователи предполагали, что PBR улучшает результаты по сравнению с ситуативным чтением или методом CBR (Checklist-Based Reading), а по оценкам участников электронного семинара, прирост составляет около 35% [Boehm, and Basili 2001], [Shull et al. 2002]. Другие исследователи проявили меньший энтузиазм. Группа Хулина проанализировала исследования в области методов контроля и за-ключила, что метод CBR обеспечивает наибольшую эффективность [Wholin et аl 2003]

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

Заключение

В предыдущем разделе были представлены некоторые систематические обзоры, которые в чем-то изменили наши представления о технологиях программирова-ния. Также за последние годы было опубликовано много других систематических и классификационных обзоров по разным темам (см. [Kitchenliam et al. 2009b], [Kitclienham et al. 2010a], виртуальный специальный выпуск IST^ и главу 12). На мой взгляд, эти работы должны постепенно повлиять на подход к исследованиям в области технологий программирования. Если вы интересуетесь какой-либо темой, обязательно проверьте наличие систематических обзоров по этой теме. Если обзоры существуют, они могут послужить отправной точкой для самостоятельных поисков или же укажут на тематические области, в которых требуются новые исследования. Если найти систематический обзор не удалось, возможно, вам стоит его создать.

Впрочем, у систематических обзоров имеются очевидные недостатки. Прежде всего, далеко не каждая работа, претендующая на звание систематического обзо-ра, действительно является качественным обзором. К чтению систематических обзоров следует подходить так же критично, как и к чтению любых других иссле-довательских публикаций. Для оценки можно использовать критерии [Гринхальга Greenhalgh, 2000] или пять критериев, используемых CRD (Centre for Reviews and Dissemination) [Centre for Reviews and Dissemination, 2007]:

  • Содержит ли обзор описания критериев включения/исключения, насколько они обоснованы?
  • Насколько вероятно, что при поиске литературы были рассмотрены все релевант-ные исследования?
  • Были ли исследования синтезированы?
  • Оценили ли авторы обзора качество/валидность включенных исследований?
  • Достаточно ли подробно описаны базовые данные/исследования?

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

  • соответствовать правилам качества для данного типа работы;
  • представлять свои результаты достаточно подробно для проведения метаанализа;
  • быть независимыми друг от друга в отношении исследовательских групп и материалов (в отличие от предлагамых Базили семействами экспериментов [Basili et al.1999]);
  • собрать данные о различных регулирующих переменных (например, тип и квали-фикация участников, сложность задачи, размер и продолжительность).

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

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

Качественные методы в области технологий программирования

Люди доверяют числам. Числа — подлинная суть обработки данных, фундамент финансовой системы, неотъемлемая часть прогресса в прошлом веке. С их помо-щью современное общество составляет представление обо всем: какие лекарства безопасны, а какие вредны; какие принципы работают, а какие нет; как развивается наша Вселенная. Вероятно, числа являются одним из самых мощных инструментов человечества.

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

А затем произошел прорыв: в исследовании [Conrad, 1985] был применен принци-пиально иной подход. Вместо того чтобы пытаться измерить явление на количе-ственном уровне, исследователи провели 80 собеседований с эпилептиками; они об-суждали ситуации, в которых пациент должен был принять лекарство, но не делал этого. Исследователи обнаружили, что несоблюдение графика приема было обу-словлено не иррациональным, необъяснимым поведением, а сознательным реше-нием пациента. Например, некоторые пациенты знали о возможном эффекте при-выкания и тщательно регулировали прием для предотвращения зависимости. Эти качественные результаты — одни из первых в своем роде в области общественного здравоохранения — сыграли важнейшую роль в переосмыслении подхода к лечению эпилепсии в современном обществе.

Какое отношение все это имеет к технологиям программирования? Как и в здраво-охранении, в этой области часто возникают вопросы «почему?» и «как?», на кото-рые числа и статистика ответить не смогут. Предположим, вы руководите группой разработчиков; наверняка вы часто спрашиваете себя: почему мои разработчики не пишут модульные тесты? Почему пользователи часто ошибаются при заполнении этой формы? Почему некоторые из моих разработчиков в 10 раз производительнее других? Получить ответ на эти вопросы при помощи чисел не удастся, но зато это можно сделать хорошо продуманным применением качественных методов.

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

Что такое «качественные методы»

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

Давайте проанализируем конкретную ситуацию и посмотрим, как качественные ме-тоды помогут лучше понять суть происходящего. Представьте, что вы только что начали руководить группой разработчиков. В только что начавшемся проекте при-нята новая система отслеживания ошибок с замечательной функциональностью, которая так нужна вашим разработчикам. Проходит несколько месяцев; группа исправно пишет код, проект движется вперед, но каждый раз, когда вы проверяете список ошибок в новой системе, вы находите в нем несколько отчетов от группы тестирования, которые почему-то остаются неизменными. Затем однажды утром вы подходите к столу своего лучшего разработчика и видите на экране старую систему отслеживания ошибок. Ваша группа неделями тайно использовала старую систе-му! И это после обучения, всех хлопот с переходом, покупки дорогостоящих лицен-зий… — Почему они не используют новую систему?

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

Возможно, вы попросите надежного друга «поговорить по душам» с подчиненны-ми во время обеденного перерыва и провести краткие неформальные собеседова-ния. Это даст каждому человеку возможность высказать свое мнение за пределами группы и, возможно, сделать это более честно и откровенно. Тем не менее вы по-прежнему будете ограничены рамками представлений друзей вашего друга. Еще хуже, если ваш друг не будет полностью непредвзятым; если он недолюбливает новую систему, его личные предубеждения окажут непреднамеренное влияние на представленные сведения.

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

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

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

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

Помимо выяснения причин, качественные методы также помогают представить себя на чьем-либо месте. Нарушения коммуникаций и процессов, а также недовольство пользователей слишком часто объясняются нашим неумением взглянуть на мир глазами другого человека. Часто именно такое «изменение угла зрения» становит-ся главной целью качественных методов. Предположим, вы обнаружили, что в ва-шей рабочей группе каждую пятницу сборка перестает работать; ваши подчиненные тратят целый день на исправление ошибок, а потом расходятся по домам уставшие и злые. Используя качественный метод для поиска причин, вы обнаруживаете, что большинство изменений вносится вечером в четверг, потому что по пятницам про-водятся собрания группы. Такие знания помогут вам взглянуть на мир с точки зре-ния разработчиков PI найти решения, которые устроят всех.

Чтение результатов качественных исследований

Разобравшись с тем, что собой представляют качественные методы, мы поговорим о том, как читать результаты качественных исследований. Чему нас учит конкрет-ное исследование? Можно ли доверять его результатам? Когда результаты иссле-дования можно обобщить до более высокого уровня? Рассмотрим эти вопросы на примере статьи «The Errors of ТеХ», опубликованной лауреатом премии Тьюринга Дональдом Кнутом [Knuth, 1989].

В этой классической статье Кнут анализирует более 850 ошибок, зафиксированных им во время работы над пакетом ТеХ. По словам Кнута, его задача состояла в «пред-ставлении списка всех ошибок, исправленных в ТеХ в ходе разработки, а также попытке анализа этих ошибок». Кнут излагает свое обоснование этого метода как преодоление ограничений количественных методов:

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

Что же Кнут обнаружил в своем исследовании? Он представляет 15 категорий оши-бок, выделенных из много большего каталога, а затем описывает их с примерами из своего журнала. Например, Кнут определяет категорию ошибок, причиной кото-рых являются синтаксически правильные, но семантически ошибочные команды. Глубинной причиной этих ошР1бок становятся имена переменных, тесно связанные концептуально, но способные сильно изменить семантику программы (например, перепутанные переменные before и after или next_l ine и new_1 ine). Затем Кнут опи-сывает другие категории ошибок, историю проекта ТеХ, его личные впечатления от работы над программой и то, как он фиксировал ошибки в журнале. В конце статьи он заключает:

…Чему же меня все это научило? Пожалуй, прежде всего, необходимости совер-шенствования чувства баланса и пропорций. Теперь я лучше понимаю сложности программной системы среднего масштаба и возможные пути ее эволюции. Теперь я понимаю, что столь разнообразные ошибки невозможно искоренить, система-тически уничтожая все, что «кажется вредным». Теперь я знаю о своей склон-ности ошибаться достаточно много, чтобы принять ее как непреложный факт; теперь меня будет легче убедить в моей неправоте, когда я допускаю ошибку.

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

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

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

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

Прежде всего, доверяете ли вы исходным данным в исследовании Кнута? Напри-мер, считаете ли вы ТеХ типичной программой? Считаете ли вы Кнута типичным программистом? Доверяете ли вы самому Кнуту? Все эти факторы могут повлиять на то, сочтете ли вы 15 категорий Кнута исчерпывающими и репрезентативными, и будут ли они встречаться на практике через много лет после публикации его статьи. Если вы полагаете, что Кнут — нетипичный программист, как могли бы изменить-ся результаты, если бы работу выполнил кто-то другой? Для примера представьте, что Кнут, как и многие академические ученые, — рассеянный профессор. Вероятно, это объяснит, почему многие категории связаны с забывчивостью или отсутствием предвидения (например, забытые функции, несоответствия между модулями, не-предвиденный сценарий и т. д.). Возможно, у человека более дисциплинированного (или работающего в ситуации, когда все внимание обращено на код) таких проблем не будет. Ни один из этих потенциально усложняющих факторов не будет фаталь-ным для результатов исследования, но их следует тщательно проанализировать, прежде чем делать какие-либо обобщенные выводы.

Доверяете ли вы исполнению Кнутом своего исследования? Иначе говоря, соблюдал ли Кнут описанный им метод, а если не соблюдал — то как отклонения могли повли-ять на результат? Кнут использовал методологию анализа дневников, которая ча-сто применяется в наши дни для получения информации о чьих-то впечатлениях за долгий период времени без прямого наблюдения со стороны исследователя. Чтобы анализ дневников дал объективную картину, вы не должны сообщать участникам предполагаемые результаты — это повлияет на то, что и как они напишут в своих дневниках. Однако Кнут в своем исследовании был и экспериментатором, и участ-ником. Какие результаты он ожидал полз^ить? У него уже были какие-то представ-ления о категориях ошибок, прежде чем он начал вести дневник? Осуществлялась ли классификация ошибок в процессе разработки ТеХ или же ретроспективно после завершения проекта? Он не описывает все эти подробности в своем отчете, но отве-ты на эти вопросы могут значительно повлиять на интерпретацию результатов.

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

Анализ дневников также усложняется тем, что он требует от участников единого рит-ма работы со временем. Например, в какой-то период Кнут временно прервал свое ис-следование, заметив: «Я не отмечал ошибки, исправленные в жаркий период отладки ТеХ82…» Какие ошибки нашел бы Кнзгг, если бы он регистрировал их в этот период? Отличались бы они от найденных в другое, менее напряженное и жаркое время?

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

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

Когда результаты и выводы идут рука об руку, легко забыть, что это две разные сущности, которые должны оцениваться независимо друг от друга. Я доверяю вос-поминаниям Кнута об историях, которые привели его к процитированному выводу, потому что он объяснил процесс сохранения этих историй. Однако на мой взгляд, при формировании своих рекомендаций Кнут перестарался с интерпретацией этих историй. Удалось бы ему завершить работу над ТеХ, если бы он тратил столько вре-мени на экстремальное тестирование? Я доверяю его дневнику, но скептически от-ношусь к итоговым рекомендациям

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

Применение качественных методов на практике

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

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

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

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

  • как к вам относятся ваши подчиненные;
  • уважают ли они вас;
  • доверяют ли они вам.

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

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

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

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

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

Обобщение результатов качественных исследований

Независимо от того, нашли ли вы результаты качественных исследований в науч-ной статье или получили их сами, неизбежно встает один вопрос: в какой степени их можно обобщать?

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

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

О систематичности качественных методов

Качественные методы играют все более важную роль в исследованиях в сфере тех-нологий программирования; они приносят пользу и в практической области. Одна-ко между простым и систематическим пониманиями проблем существуют серьез-ные различия. Таким образом, когда вы в следующий раз будете читать результаты качественных исследований или будете проводить их самостоятельно, проследите за тем, чтобы это происходило по следующей схеме:

Формулировка вопроса

Какую информацию вы хотите получить и почему? Как будут использоваться полученные знания?

Рассмотрите надежные источники объективных доказательств

Какие данные можно получить объективно, с минимально возможной субъек-тивностью? Можно ли получить данные из нескольких источников, чтобы ком-пенсировать субъективность отдельных источников?

Интерпретация закономерностей в доказательствах

Согласуются ли доказательства, полученные из разных источников, или же они противоречат друг другу? Какие новые вопросы открывают данные доказатель-ства? Можно ли проверить гипотезы, сформулированные на их основе, по допол-нительным данным?

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

Уроки практического применения: становление метода QIP

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

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

Сложность исследований в области технологий программирования

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

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

Вторая отличительная особенность дисциплины технологий программирования — нематериальный характер программного продукта (то есть «невидимость» его струк-туры, компонентов и форм разработки). К ней добавляется третья особенность — от-носительная незрелость самой области (в том смысле, что в ней еще не разработано достаточное количество моделей для обоснованного обсуждения процессов, продук-тов и отношений между ними). Эти затруднения только усиливают необходимость извлекать полезные уроки от применения идей в разных сР1туациях.

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

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

Реалистичный подход к эмпирическим исследованиям

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

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

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

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

Построение «общей картины» — слишком масштабная задача, которая не по силам никакой отдельной группе. Столь серьезная дисциплина требует сотрудничества многих групп. Потребуется эффективно организованный механизм обмена данны-ми, репозиторий различных моделей и уроков их практического применения, кото-рый исследователи могут использовать и пополнять своими данными.

Лаборатория технологий программирования NASA: испытательная площадка для эмпирических исследований

Чтобы подкрепить свои доводы в пользу неформального изучения, приведенные в этой главе, я кратко расскажу о своем опыте работы в лаборатории технологий программирования NASA (SEL), где на протяжении 25 лет мы узнавали много но-вого не только из экспериментов, но и из попыток разобраться в проблеме, найти возможное решение и понять, в чем оно не оправдало ожиданий. Мы проводили контролируемые эксперименты, выполняли ситуационные исследования, но все это делалось в контексте более масштабного эволюционного процесса пррюбрете-ния знаний.

Лаборатория SEL была основана в 1976 году для изучения разработки программ-ного обеспечения запуска спутников (и по возможности для улучшения качества технологического процесса и конечного продукта) в отделе динамики полета в Год-дарде. Основными средствами ее работы были наблюдения, эксперименты, изуче-ние и моделирование [Basili and Zelkowitz, 1977]. В лаборатории были группы разработчиков из NASA и CSC (Computer Sciences Corporation), а также группа ис-следователей из Мэрилендского университета (UMD). Эти три группы образовали консорциум. Организация решила поддержать наши эмпирические исследования и интегрировать их в свою общую деятельность. Поддержка поступала из бюджета проекта, а не из исследовательского бюджета NASA.

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

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

С 1976 по 2001 год мы узнали много нового, хотя и совершили при этом немало ошибок. Вот лишь несколько примеров таких ошибок:

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

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

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

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

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

QIP

Начну с квинтэссенции наших трудов — процесса применения научного мето-да в области технологий программирования в промышленной среде. Мы назвали свою версию научного метода «парадигмой повышения качества», сокращенно QIP (Quality Improvement Paradigm) [Basili, 1985], [Basili and Green, 1994]. Она состоит из шести основных шагов:

4. Описание текущего проекта и его среды в отношении соответствующих моделей и метрик. (Как выглядит наш мир?)

5. Назначение количественно измеряемых целей для успешного выполнения и со-вершенствования проекта. (Что мы хотим знать о своем мире и чего хотим до-биться?)

6. Выбор модели процесса, сопутствующих методов и инструментов для работы над проектом. (Какие процессы подойдут для этих целей в этой конкретной среде?)

7. Исполнение процессов, построение продуктов, сбор, проверка и анализ данных для получения «обратной связи» в реальном времени для своевременной коррек-тировки. (Что происходит в ходе применения выбранных процессов?)

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

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

Как видно из рис. 5.1, процесс QIP состоит из двух циклов. Взаимодействие науч-ного исследования с практикой представлено корпоративным и проектным приоб-ретением знаний на основании «обратной связи», полученной в результате практи-ческого применения идей.

рисунок 1.корпоративное приобретение знания

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

Приобретение знаний проходило в течение 25 лет, хотя я сосредоточусь на том, что мы узнали в первые 20. Материал разбит в соответствии в 6 шагами QIP, хотя роли многих шагов перекрываются. В каждом случае я указываю, что мы узнали о приме-нении научного метода и что мы узнали о совершенствовании разработки ПО в от-деле динамики полета NASA/GSFC.

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

Описание

Сначала мы рассмотрели различные модели в литературе (например, кривая Рэйли или модели MTTF) и попытались применить их, чтобы лучше понять нашу среду. Оказалось, что эти модели не всегда актуальны. Либо они определялись для систем существенно больших, чем те, которые мы строили (порядка 100К строк исходно-го кода), либо применялись в другие моменты времени. Это привело нас к выводу о необходимости построения собственных моделей, соответствующих нашей среде и основанных на наших данных. Мы должны были лучше понять и охарактеризо-вать свою среду, проекты, процессы, продукты и т. д., потому что мы не могли ис-пользовать чужие модели, созданные для других сред [Basili and Zelkowitz, 1978], Basili and Freburger, 1981], [Basili and Beane, 1981]

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

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

Назначение целей

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

рисунок 2.некоторые базовые показатели NASA

ответов на вопросы. Стало ясно, что собирать данные, а потом решать, что с ними делать, в принципе неверно — сам сбор данных должен происходить целенаправлен-но. Так был разработан метод GQM (Goal Question Metric), упрощающий структу-рирование данных для конкретного исследования [Basili and Weiss, 1984]. С другой стороны, в море данных можно утонуть, особенно при отсутствии четко поставлен-ных целей. Мы продолжали развивать GQM — например, определяя шаблоны це-лей fBasili and Rombach, 19881.

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

Выбор процесса

Сначала мы использовали эвристически определенные комбинации существующих процессов. Мы начали проводить контролируемые эксперименты в университете со студентами, чтобы изолировать влияние малых наборов переменных с минимальны-ми затратами [Basili and Reiter, 1981]. Когда эффект этих процессов стал понятен, на-чались эксперименты с четко определенными технологиями и семействами техноло-гий высокой надежности. Многие из этих технологий сначала проходили изучение в университете в ходе контролируемых экспериментов, прежде чем переходить в ла-бораторию SEL для использования в реальных проектах — например «Чтение кода посредством пошаговой абстракции» [Basili and Selby, 1987], «Стерильная комната» [Selby et al. 1987] и «Ada и объектно-ориентированное проектирование» [Basili et al. 1997]. Университетские исследования снизили риск от применения этих техно-логий в SEL. Со временем мы начали понимать, как объединять контролируемые эксперименты и ситуационные исследования для проведения более формального анализа изолированных операций [Basili, 1997].

Мы начали экспериментировать с новыми технологиями, чтобы больше узнать об отношениях между применением процессов и характеристиками полученных продуктов. Но причины для выбора этих методов были основаны на знаниях, по-лученных нами в ходе наблюдения за проблемами, возникающими в SEL, и были направлены на достижение конкретных целей — например, на сведение к минимуму дефектов. Так, после осознания проблем с формулировкой требований мы разрабо-тали некоторые методы чтения для выявления дефектов в документации по требо-вать [Basili et al. 1996].

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

Исполнение процесса

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

Анализ

Мы начали с построения и анализа базовых показателей, характеризующих рабо-чую среду. Набор базовых показателей включал многие переменные, например, распределение усилий, типы допущенных ошибок и даже рост объема исходного кода с течением времени. Показатели предоставляли информацию о рабочей сре-де, показывали, на чем следует сконцентрироваться для улучшения процессов, а также помогали лучше понять сходства и различия между проектами. Мы стали рассматривать изучение разработки программных продуктов как реализацию па-радигмы эксперимента, то есть план экспериментов, оценка результатов и «обрат-ная связь» были необходимы для получения информации. Наша оценка методов анализа развивалась от поиска корреляции между переменными [Basili et al. 1983 до построения регрессионных моделей [Bailey and Basili, 1983] и более сложных методов количественного анализа [Briand et al. 1992], вплоть до включения все-возможных форм качественного анализа [Seaman and Basili, 1998]. Качественный анализ сыграл важную роль в процессе приобретения знаний и помог нам получить представление о глубинных причинах воздействий. Постепенно мы начали пони-мать важность простого применения идей с последующим наблюдением и органи-зацией «обратной связи» для расширения нашего понимания. Эта концепция была включена в наши модели и определяла, в каких случаях следует применять более формальные аналитические методы.

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

Оформление

Наше понимание важности, сложности и неочевидности оформления полученной информации развивалось медленно. Сначала мы сохраняли сведения о базовых показателях и моделях. Затем стала очевидна потребность в специализированных пакетах — например общих программных компонентах и методах, которые могут адаптироваться для конкретного проекта. Полученная нами информация долж-на была найти практическое применение в рабочей среде, и мы должны были по-стоянно изменять рабочую среду на основании полученной информации. Переход к новой технологии подразумевал новую организационную структуру, эксперимен-тирование и эволюционные изменения культуры. Мы построили то, что было назва-но моделями опыта — то есть моделями поведения, основанными на наблюдениях и «обратной связи» в конкретной организации. Мы строили специализированные, допускающие возможность изменения модели процессов, продуктов, дефектов и ка-чества и оформляли свой опыт их применения разнообразными способами (фор-мулы, гистограммы, параметризованные определения процессов и т. д.). Основные сложности возникали с последующей интеграцией таких моделей. Все это привело к разработке структуры фабрики опыта [Basili, 1989] (рис. 5.3).

рисунок 3.фабрика опыта

Фабрика опыта для процессов, продуктов и других форм знания играет важную роль в их совершенствовании [Basili, 1989]. Эта модель признает необходимость от-деления организационных операций с проектом от накопления знаний на основании опыта в рамках этой организации. В качестве примера организационных операций можно привести разложение задачи на несколько более простых подзадач, планиро-вание и реализацию, подтверждение и проверку правильности результата. Их цель заключается в выпуске продукта без нарушения графика и бюджета. Деятельность фабрики опыта направлена на объединение различных решений с переопределением задачи, обобщением, формализацией и интеграцией полученного опыта. Для этого применяются анализ и синтез наблюдаемых явлений и эксперименты для проверки идей. Фабрика опыта отвечает за оценку, адаптацию и оформление опыта для по-вторного использования.

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

Со временем мы достаточно хорошо поняли, как извлекать новые знания из резуль-татов наблюдений, Э. ТЗ,КЯСС КйК объединять результаты ситуационных исследований и контролируемых экспериментов. Процесс практического применения, наблю-дения и приобретения знаний продолжился. Мы занимались такими темами, как коммерчески-стандартные разработки, методы чтения и т. д.

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

Заключение

в этой главе представлена история 25 лет эволюции и адаптации целей и процессов к условиям конкретной рабочей среды. Технологическое совершенствование оце-нивалось по трем показателям (частоте дефектов разработки, сокращению затрат на разработку и возможности повторного использования кода) на трех контрольных точках: 1987, 1991 и 1995 годы. Каждая точка данных вычислялась как среднее зна-чение за трехлетний промежуток [Basili et al. 1995] (табл. 5.1).

рисунок 4.результаты применения метода QIP

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

Затраты на проведение исследований составили около 10% от затрат на разработку. Однако данные показывают, что 10% затрат обернулись улучшением примерно на порядок. Как видите, инвестиции оказались весьма эффективными.

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

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

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

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

Личность, интеллект и опыт: влияние на разработку

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

Роберт Гласс (факт 1 из книги «Facts and Fallacies of Software Engineerings [2002])

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

Роберт Гласс (факт 2 из книги «Facts and Fallacies of Software Engineering» [2002])

В двух постулатах Роберта Гласса (о которых он напоминает нам в статье «Frequently Forgotten Fundamental Facts about Software Engineering» на сайте IEEE Computer Society) отражено несколько важных моментов. Прежде всего, признается роль че-ловеческого фактора в сугубо технологической области программирования. В част-ности это помогает научной дисциплине эмпирических исследований рассматри-вать практику технологий программирования с дополнительных точек зрения (управленческой, социологической и психологической), не ограничиваясь одной лишь технологической точкой зрения. Пожалуй, это необходимо для того, чтобы сделать практику более доказательной и научной.

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

  • Существует ли нормальное определение «хорошего разработчика»?
  • Если существует, то можно ли надежно и эффективно определить, что один раз-работчик лучше другого?
  • Если не существует, то следует ли сосредоточиться на инструментах и методах?

Утвердительный ответ на первые два вопроса будет не чем иным, как маленькой революцией. Ей будут рады многие люди, в том числе и Джоэл Сполски. Он пишет, что участие суперзвезд (вместо программистов среднего уровня) определяет, удаст-ся ли вам создать действительно великий продукт, который станет новым шагом на пути прогресса, или же у вас получится посредственная поделка, которая только соз-даст проблемы с переработкой, переделкой и отладкой у других участников группы Spolsky, 2007]. Однако найти специалиста экстра-класса очень трудно. Люди, давно работающие в сфере найма профессиональных программистов, посоветуют, на что нужно обращать внимание при подборе персонала (см. у того же Сполски), но про-блема остается. Вообще говоря, проблема поиска, удержания и развития талантов является одной из самых актуальных проблем для руководителей отдела кадров, но по данным отчета Global Assessment Trends Report [Fallaw and Solomonsen, 2010], научно обоснованных методологий в этой области пока недостаточно.

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

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

Как узнать хорошего программиста

Чтобы дать определение «хорошего программиста», необходимо рассмотреть два более глубоких вопроса:

  • Какие качества программиста обеспечивают хорошую производительность про-граммирования? Нужно ли обращать внимание на его опыт? Нужно ли беспоко-иться о его личных качествах? Попытаться ли измерить его IQ? И как выглядят все эти вопросы в контексте парного программирования и коллективной работы?
  • Что считать хорошей производительностью программирования? Например, кого лучше нанять — человека, выдающего больше строк за единицу времени, или че-ловека, который производит код более высокого качества (что бы это ни значило) независимо от количества затраченного времени?

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

Индивидуальные различия: фиксированные или переменные

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

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

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

Личность

Личность человека уже давно представляет интерес в контексте программирова-ния и разработки ПО. Например, Вайнберг в книге «The Psychology of Computer Programming» предсказал, что «внимание, уделяемое личным качествам работника, должно внести значительный вклад в повышение производительности программи-ста» [Weinberg, 1971], причем эта позиция была повторно подтверждена в переиз-дании 1998 года [Weinberg, 1998]. Шнейдерман в «Software Psychology» утвержда-ет: «Личностные факторы играют важнейшую роль в определении взаимодействий между программистами и стиле работы отдельных программистов» [Shneiderman, 1980]. Однако оба автора признают недостаточный уровень эмпирических до-казательств относительно влияния личностных качеств на производительность: «Пока мы еш;е не видели, чтобы оценка личности успешно применялась для отбо-ра программистов, которые стали хорошими программистами» [Weinberg, 1971], Weinberg, 1998], «К сожалению, о влиянии личностных факторов пока известно слишком мало» [Shneiderman, 1980 .

С тех пор в области влияния личности на разработку ПО были проведены эмпириче-ские исследования. Например, Дик и Зарнетт заключили, что «формирование группы разработки с личностными качествами, полезными для парного программирования, приведет к большему успеху в экстремальном программировании, чем формирова-ние группы на основе одних лишь технических навыков» [Dick and Zarnett, 2002]. Не ограничиваясь рамками программирования, Девито Да Кунья и Грейтхед заключают, что «если компания организует своих работников в соответствии с их типами лич-ности и потенциальными способностями, это может привести к повышению произво-дительности и качества работы» [Devito Da Cunha and Greathead, 2007]. Также выска-зываются мнения, что на конкретные роли в разработке ПО следует подбирать людей с определенным типом личности [Capretz and Ahmed, 2010], [Acuna et al. 2006 .

Итак, что же такое «личность»? В неформальном разговоре мы постоянно упомина-ем личность других людей. «Она по типу личности идеально подходит для работы адвоката» или «У него серьезные личностные проблемы». Действительно, на осно-вании таких неформальных представлений ежедневно принимается много важных решений. Одни из них оказываются правильными, другие — ошибочными. Переход на научно обоснованный метод означает, что такие решения должны определяться информацией, полученной систематическим (то есть научным) методом. Я должен прямо сейчас сказать о том, что у систематического подхода имеются свои изна-чальные ограничения, но мы вернемся к ним позднее.

Прежде всего необходимо спросить, возможно ли определить и измерить личност-ные качества? Для технологических специалистов (к которым относимся и мы) это далеко не очевидно. Возможно, в будущем можно будет указать на материальные (скажем, генетические или психофизиологические) механизмы, определяющие че-ловеческую личность [Read et al. 2010]. Однако основное развитие теории личности в прошлом веке пошло по другому пути. Ученые пришли к выводу, что то, что мы называем «личностью», может меняться в зависимости от действий или высказыва-ний людей. Этой линии исследования удалось сформировать убедительные модели личности на основании указанных поведенческих и лингвистических умозаклю-чений. Вероятно, наибольшим признанием пользуется модель «большой пятерки» и связанная с ней модель «пяти факторов» (см. врезку «Личностные факторы»). Да, личностные качества можно определить и измерить. Разговоры о человеческой личности обоснованы в научном смысле, и существуют тесты, которые позволяют надежно установить особенности личности человека. Ученый бы сказал, что мы рас-полагаем конструктивной валидностью для концепции личности.

Определения личности использовались для разнообразных способов классифика-ции людей. Например, в отношении модели «большой пятерки» мы обнаружили, что программисты отличались от контрольной группы более низким уровнем экс-траверсии, более низкой эмоциональной стабильностью и более высоким уровнем открытости опыту [Наппау et al. 2010]. Также аналогичные результаты упоминаются у [Мооге, 1991], [Smith, 1989], [Woodruff, 1979], [Capretz, 2003] и [Turley and Bieman, 1995]. Программисты также обладают более высокой личностной однородностью, чем население в целом; иначе говоря, в области личностных качеств программисты более постоянны, чем остальные люди. Этот результат соответствует стереотипному представлению о программисте как нервном интеллектуале-интроверте — и, кстати говоря, мужчине (я точно знаю, что некоторые люди считают это обстоятельство личностной характеристикой!)

Личные факторы

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

В то же время личностные исследования в академической среде привели к раз-работке научно обоснованных моделей и тестов. За последние годы в области личностных исследований центральное место занимали две модели [Вагпск et al. 2001], состоящие из пяти факторов и известные под названиями модели «пяти факторов» (FFM, Five Factor Model) [Costa and McCrae, 1985] и «большой пя-терки» [Goldberg, 1990], [Goldberg, 1993]. Модель «пяти факторов» базируется на том, что характеристики личности принадлежат разносторонней модели при-чин и контекстов — как генетических, так и обусловленных окружающей средой. «Большая пятерка» утверждает, что самые важные личностные различия в жизни людей кодируются в понятиях их естественного языка (так называемая лекси-ческая гипотеза, [Goldberg, 1990]. Эти две модели часто рассматриваются как единое целое, и между их соответствующими факторами существует достаточно сильная корреляция (например, [Goldberg et al. 2006]). Тем не менее между двумя моделями имеются концептуальные различия, и их теоретические обоснования подразумевают разные подходы к проектированию тестов.

Далее перечислены все пять факторов (с описаниями из [Pervin and John, 1997]). 1. Экстраверсия
Используется для оценки количества и интенсивности межличностных взаи-модействий, уровня активности, потребности в стимулировании и способности к положительным эмоциям.
2. Доброжелательность
Используется для оценки качества межличностной ориентации индивида в диа-пазоне от сострадания до антагонизма в мыслях, чувствах и действиях.
3. Добросовестность
Используется для оценки организованности, упорства и мотивации индивида в целенаправленном поведении. Такие люди составляют противоположность зависимым, излишне привередливым и апатичным людям.
4. Эмоциональная стабильность/Нейротизм
Используется для оценки уровня эмоциональной стабильности. Позволяет выявить индивидов, склонных к психологическим переживаниям, нереалистич-ным идеям, избыточным влечениям и неадекватным реакциям.
5. Открытость опыту
Используется для оценки активного познания и усвоения опыта «ради него самого», терпимости и склонности к познанию неизвестного.
Некоторые коммерческие модели и тесты подверглись критике в академическом со-обществе за плохую концептуальную обоснованность, низкую надежность и низкую валидность ([Furnham, 1996], [Saggio et al. 2001], [Saggio and Kline, 1996]). В част-ности, многие личностные тесты связывались с «эффектом Форера^> — туманными и неопределенными описаниями, которые часто вызывают у людей ощущение узна-вания независимо от их Фактических личностных качеств.

Определения личности использовались для разнообразных способов классифика-ции людей. Например, в отношении модели «большой пятерки» мы обнаружили, что программисты отличались от контрольной группы более низким уровнем экс-траверсии, более низкой эмоциональной стабильностью и более высоким уровнем открытости опыту [Наппау et al. 2010]. Также аналогичные результаты упоминаются у [Мооге, 1991], [Smith, 1989], [Woodruff, 1979], [Capretz, 2003] и [Turley and Bieman, 1995]. Программисты также обладают более высокой личностной однородностью, чем население в целом; иначе говоря, в области личностных качеств программисты более постоянны, чем остальные люди. Этот результат соответствует стереотипному представлению о программисте как нервном интеллектуале-интроверте — и, кстати говоря, мужчине (я точно знаю, что некоторые люди считают это обстоятельство личностной характеристикой!)

Как было сказано ранее, у систематического научного подхода имеются свои из-начальные ограничения, причем частично они обусловлены его сильными сторо-нами. Прежде всего следует отметить то, что ученые называют валидностью: на-сколько разумно утверждение о том, что в вашем определении личности отражено все, что обычно понимается под личностью? Например, большинство окружаю-щих вряд ли согласится с тем, что человека можно охарактеризовать всего пятью факторами. Другие личностные модели пытаются описывать более сложные типы и сложные, нетривиальные комбинации личностных факторов, но им не хватает конструктивной валидности. Систематичность подхода изначально ограничивает то, к чему этот подход можно применять! Мы оказываемся перед классическим компромиссом: простые модели (такие как модель «пяти факторов») упропхают реальность, их можно проверить на правильность и измерить метрики. Более сложные модели претендуют на более качественное отражение реальности, но их труднее проверить.

С нашей точки зрения, главным вопросом оказывается практическая польза от из-мерения личностных качеств. Какие различия в производительности дает то или иное различие в личностных качествах? Насколько практически приемлемо ис-пользование личностных данных для прогнозирования других аспектов поведения, и прежде всего производительности программирования? По поводу связи между личностными качествами и общей производительностью проводилось немало ис-следований. Их результаты были обобщены в крупномасштабных метаанализах Barrick et al. 2001], [Peeters et al. 2006], [Bell, 2007]. По данным Баррика, общее влияние личных качеств на производительность работы «несколько разочаровыва-ет» и «проявляется умеренно… даже в самых лучших слз^аях» [Barrick et al. 2001]. Таким образом, прямая зависимость производительности от личных качеств может быть относительно незначительной.

С другой стороны, личность может оказывать более существенное косвенное влияние на производительность работы через социальные факторы, влияющие на слаженность работы коллектива. Как выясняется, влияние на коллективную ра-боту оказывается более сильным, чем влияние на общую производительность, по всем факторам «большой пятерки» [Barrick et al. 2001]. Из этого можно сделать вывод, что влияние личностных качеств может быть более релевантным в кон-тексте коллективной, а не индивидуальной производительности. Мы исследовали эту гипотезу на примере 198 профессиональных программистов, занимавшихся парным программированием в течение одного дня [Наппау et al. 2010]. Оказалось, что личные качества весьма незначительно отражаются на производительности парного программирования. Даже приближенные метрики опыта, сложности за-дачи и даже страны, в которой были наняты программисты, обладали большей прогнозирующей способностью, чем личностные качества. В ходе исследования был проведен анализ личности при индивидуальном программировании, а также исследовался вопрос о том, связано ли изменение производительности при пар-ной работе с личностными качествами. И снова квалификация и сложность зада-чи оказываются намного более важными прогностическими факторами, чем лич-ность программиста.

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

Вполне может оказаться, что влияние личностных качеств проявляется толь-ко по прошествии некоторого времени. В частности, парное программирование за один день может не дать достаточного времени, чтобы личности участников сколько-нибудь серьезно повлияли на производительность. Также ведутся споры вокруг коротких тестов, которые могут проводиться почти автоматически (на-пример, тесты оценки личности или интеллекта), в сравнении с более глобаль-ными методами, требующими специальной интерпретации. Возьмем хотя бы личностную особенность, называемую «стремлением к успеху». Из метаанализа следует, что небесспорная процедура измерения стремления к успеху ТАТ (Thematic Apperception Test) обеспечивает лучшую прогностическую валидность для реал1^ной производительности, чем стандартные тесты на базе опросников, ко-торые лучше подходят для прогнозирования производительности в контролируе-мых средах [Spangler, 1992]. Научное сообщество относится к ТАТ по-прежнему скептически. Однако Спанглер утверждает, что «неумышленным последствием применения научного метода может быть сокраш;ение выражения индивидуаль-ных различий и взаимодействия индивидуальных различий с характеристиками среды» [Spangler, 1992]. Мы снова сталкиваемся с проблемой содержательной валидности! Также обратите внимание на то, что организовать долгосрочные из-мерения производительности в реальных условиях намного сложнее, чем в кон-тролируемых условиях лаборатории.

Короче говоря, личность вряд ли может рассматриваться как сильный предиктор производительности. Давайте кратко рассмотрим основные проявления влияния. В том, что касается прогнозирования производительности, самым актуальным фактором обычно является добросовестность [Schmidt and Hunter, 1998]. Пред-ставьте себе, к парному программированию это, похоже, не относится [Saleh et al. 2010]. В своих данных мы даже обнаружили отрицательное влияние добросовестно-сти (эффект присутствует и у программистов-одиночек). Похоже, положительное влияние оказывает открытость опыту [Saleh et al. 2010] и различия в экстраверсии Наппау et al. 2010]. Пары, участники которых имеют разные уровни экстраверсии, работают быстрее, чем пары с близкими уровнями.

ТРИ БОЛЬШИХ ПРОБЛЕМЫ ЭМПИРИЧЕСКИХ ИССЛЕДОВАНИИ

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

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

Таким образом, первая большая проблема эмпирических исследований связана с конструктивной валидностью: как узнать, что ваши измерительные средства из-меряют именно то, что нужно? И действительно ли вы знаете, что именно нужно измерить? Комбинация концепции и средств ее измерения {индикаторов) назы-вается конструкцией (рис. 6.1(a)). Например, каждый из личностных факторов в модели «большой пятерки» измеряется по 20 позициям опросника, поэтому конструкция «Экстраверсия» изображается в виде эллипса с соответствующей надписью и 20 индикаторами, соединенными с ним.

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

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

Третья большая проблема — критериальная валидность. Этим термином обозначается полезность конструкции для прогнозирования изменений в другой конструкции. Можно ли использовать личностные качества для пропюзирования производитель-ности программ1фования? Можно ли использовать квалификацию программирования для прогнозирования эффективности человека в качестве разработчика в следующем крупном проекте? И т. д. На рис. 6.1(c) изменения в одной конструкции (предиктор) используются для прогнозирования изменений во второй конструкции (критерий).

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

рисунок 5.Типы валидности

Интеллект.

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

Общая ментальная способность, или сокращенно GMA (General Mental Ability), — чрезвычайно общая концепция интеллекта и когнитивных способностей, присут-ствующих в каждом человеке. Приближенно говоря, именно эта величина оцени- вается тестами IQ (см. врезку «Факторы интеллекта»). ОМА является довольно хорошим предиктором способности к обучению [Schmidt and Hunter, 1998]. Иначе говоря, человек с высоким уровнем ОМА обычно осваивает новые задачи быстрее, чем человек с более низким уровнем ОМА. ОМА также неплохо прогнозирует бу-дущую производительность работников, не имеющих предыдущего опыта [Schmidt and Hunter, 1998]. Таким образом, если наша начальница отдела кадров собирается .нанять неопытных программистов, которые еще не умеют работать над большими сложными системами, она права: возможно, ей действительно стоит заняться опре-делением их IQ.

ФАКТОРЫ ИНТЕЛЛЕКТА

Современные научные взгляды на интеллект объединяют ряд аспектов. Многие разработчики приняли модель интеллекта, предложенную Кэрроллом [Carroll 1993], которая состоит из восьми первичных факторов:

  • Gf:способность к рассуждениям
  • Gc: культурные знания;
  • SAR:краткосрочное восприятие и выборка из краткосрочной рабочей памяти (STWM, Short-Term Working Memory);
  • Gv:зрительное восприятие;
  • Ga:слуховое восприятие
  • Gs:скорость восприятия;
  • Gq:количественные знания.

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

Хотя некоторые исследователи и выступали с предложениями, не существует значительных эмпирических доказательств по поводу всеобъемлющего фактора общего интеллекта (GI, General Intelligence) [Horn and Masunaga, 2006]. Ранее Спирмен [Spearman, 1923] указывал, что его концепция представляет сущность интеллекта, но сейчас она рассматривается как соответствующая лишь одному фактору Gf. То, что в этой главе называется «общей ментальной способностью» (GMA), в действительности представляет собой свертку факторов Gf и Gc Valentin Kvist and Gustafsson, 2008] (рис. 6.2). Между этими факторами суще-ствуют зависимости: скажем, Gf способствует формированию Gc. Также имеются доказательства того, что некоторые факторы ухудшаются с возрастом нанять неопытных программистов, которые еще не умеют работать над большими сложными системами, она права: возможно, ей действительно стоит заняться опре-делением их IQ.

рисунок 6.Факторы интеллекта

Эффект GMA зависит от типа выполняемой задачи. Задача называется стабиль-ной, если со временем лучшие работники разрабатывают сходные стратегии для ее решения. Напротив, для нестабильной задачи разрабатываются существенно различающиеся стратегии решения. При накоплении опыта на стабильных зада-чах влияние интеллекта постепенно снижается или полностью исчезает, и произ-водительность выполнения работы вскоре начинает зависеть от других факторов, например, опыта и уровня обучения ([Аскегтап and Beier, 2006], [Schmidt et al. 1988], [Schmidt et al. 1986]). Этот факт особенно ярко проявляется в задачах, силь-но зависящих от знания предметной области, таких как разработка ПО ([Bergersen and Gustafsson, 2010], [Ackerman and Beier, 2006]). Разработка вообще и програм-мирование в частности обладают свойствами как стабильных, так и нестабильных задач. Отсюда следует, что интеллект важен, но не является единственным опре-деляющим фактором. Для опытных работников GMA не является однозначным предиктором ([Ericsson, 2006], [Schmidt and Hunter, 1998], [Ackerman and Beier, 2006]). A что является? Ответ: интеллект в сочетании с квалификацией [Schmidt and Hunter, 1998].

Эти исследования говорят нам о том, что полагаться исключительно на GMA не-разумно в долгосрочной перспективе. Проблема GMA заключается в том, что это понятие имеет слишком общий характер. Оно концептуализируется как универ-сальная характеристика человеческой личности, а средства измерения намеренно проектируются независимо от какой-либо предметной области (полностью по-лагаться на GMA не следует еще и потому, что GMA не является настолько уж универсальной характеристикой, например, она зависит от культуры [Bond, 1995]). А это означает, что если вы хотите нанять хороших разработчиков, то помимо об-щих способностей, следует проверить их на чем-то имеющем отношение к их буду-щей работе.

Задача программирования

Для оценки квалификации часто применяются рабочие пробы — тесты, состоящие из небольших, репрезентативных задач. Такое определение создает сразу две про-блемы: задачи должны быть «небольшими» и «репрезентативными». Если вы хо-тите проверить навыки программирования потенциальных или существующих работников, это необходимо сделать за как можно меньшее время. Следовательно, тестовые задачи должны быть намного меньше тех, которые встречаются в обычных рабочих ситуациях. Но как тогда убедиться в том, что ваши тесты актуальны? На помощь приходит репрезентативность.

Собственно, мы снова приходим к проблеме конструктивной и содержательной ва-лидности: как узнать, что ваши измерительные средства измеряют именно то, что нужно? И действительно ли вы знаете, что именно нужно измерить? Мы приме-няли этот подход к личности, применяли его к интеллекту (хотя и не указывали на это явно), а здесь он снова проявляется в квалификации программирования: определите «квалртфикацию программирования» (сюда входит определение зада-чи программирования), а затем разработаР1те быстрый тест для ее оценки! В общем случае проверка конструктивной валидности тестов рабочих проб весьма проблема-тична [Campbell et al. 1993 .

В своей исследовательской лаборатории мы разрабатываем измерительные сред-ства для оценки квалификации в области программирования [Bergersen, 2010]. Они базируются на рабочих пробах — задачах по программированию малого и среднего размера, тщательно отобранных и видоизмененных в соответствии с развивающим-ся пониманием концепции квалификации программирования. Наш инструмент в значительной мере базируется на теории измеренрп! и удовлетворяет строгим статистическим стандартам. Таким образом, он выполняет двойную функцию: от-слеживание сложности задач и отслеживание квалификации человека, решающе-го эти задачи. Как и в случаях с интеллектом и личностными качествами, оценка производится относительно других участников теста. Но в отличие от интеллекта и личностных качеств, квалификация программирования имеет прямое отношение к найму и сохранению хороших программистов в штате.

Производительность программирования

А что считать хорошей производительностью программирования? Очевидно, что одним из критериев должно быть качество кода. Само понятие «качества», в том, что касается программного кода, стало темой бесконечных дискуссий. Но для те-стирования методом рабочих проб существуют очевидные и научно обоснованные метрики качества, такие, как функциональная правильность, глубина наследования и т. д. Другой критерий — время, затраченное на программирование. Все мы хотим получить качественный код, и притом как можно быстрее. Казалось бы, эти два кри-терия противоречат друг другу, а на создание более качественного кода должно ухо-дить больше времени. Но это не всегда так [Arisholm and Sjoberg, 2004], [Bergersen 2010b]. В некоторых задачах программист либо понимает, что делать, либо не пони-мает; если понимает — то делает быстро. Однако есть и другие задачи, в которых ре-шение только улучшается от дополнительных затрат времени. Важно знать, с какой разновидностью задачи вы имеете дело.

Экспертность

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

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

ФАКТОРЫ ЭКСПЕРТНОСТИ

Существует несколько определений экспертности [Ericsson, 2006

  1. В контексте расширенного опыта.
  2. В контексте улучшенного представления и организации знаний [Horn and Masunaga, 2006].
  3. В контексте стабильно лучшей производительности при решении типичных задач.

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

При оценке различных аспектов экспертности необходимо действовать крайне осторожно. Например, расширенный опыт (вариант 1) часто измеряется просто в годах продолжительности работы, тогда как более релевантная метрика должна ориентироваться на решаемые задачи [Sonnentag, 1998], [Shaft and Vessey, 1998]. Улучшенное представление и организация знаний (вариант 2) относится к ког-нитивному аспекту экспертности. На практике этот сложный аспект тоже часто измеряется в годах работы, так как предложить метрику для оценки когнитивных структур непросто. Считается, что ментальные представления улзд1шаются со вре-менем в результате накопления опыта, относящегося к выполняемой работе. Это утверждение истинно часто, но не всегда. Говоря о квалификации, исследователи обычно имеют в виду улучшенную производительность при решении типичных задач, то есть рабочие пробы (вариант 3).

Также большинство исследователей признает два других аспекта экспертно-сти:

  1. Экспертность в выполнении стабильных задач имеет асимптотическую при-роду («у совершенства есть предел»). К нестабильным задачам это относится в меньшей степени.
  2. Экспертность зависит от практики. При отсутствии практического применения экспертность обычно падает ниже оптимального уровня.

Интеллект способствует процессу приобретения квалификации, но не определяет квалификацию. Согласно теории инвестиций Кэттела, «инвестиции» Gf (способ-ность к рассуждениям, или умение решать проблемы в краткосрочной перспективе; см. «Факторы интеллекта») в ситуациях обучения, требующих знания сути слож-ных отношений, способствуют приобретению знаний и квалификации. В последнее время были ползд1ены доказательства того, что этот принцип истинен и для про-граммирования [Bergersen and Gustafsson, 2010] (рис. 6.3). На диаграмме емкость рабочей памяти WMC (Working Memory Capacity) используется как заменитель Gf. WMC оказывает существенное положительное влияние на знания по программи-рованию, которые, в свою очередь, положительно влияют на квалификацию в обла-сти программирования. Однако прямое влияние WMC на квалификацию в области программирования ничтожно мало! Иначе говоря, фактор WMC не делает человека квалифицированным сам по себе, как непосредственная причрша. Влияние проис-ходит опосредованно, через упрощение приобретения знаний. Аналогичным образом опыт программирования косвенно (а не напрямую) влияет на квалификацию программирования, хотя и не так сильно, как WMC.

рисунок 7.Теория инвестиций для квалификации в области программирования

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

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

ОБЪЕДИНЕНИЕ ИНТЕЛЛЕКТА С ЭКСПЕРТНОСТЬЮ

Когнитивные структуры являются структурными элементами как интеллекта, так и компетентности. Некоторые исследователи предпринимали попытки объединить эти две когнитивные темы в общую теорию [Horn and Masunaga, 2006]. В этой об-ласти проявляются интересные контрасты: если Gf (способность к рассуждениям) представляет индуктивное мышление, основанное на заданных предпосылках (например, правилах шахмат), экспертное мышление имеет дедуктивную приро-ду (например, выводы, основанные на базе отыгранных и изученных шахматных позиций). Если выборка SAR осуществляется из краткосрочной рабочей памяти, содержащей семь информационных объектов плюс/минус два, то эксперт исполь-зует расширенную рабочую память в своей предметной области, объем которой значительно превышает объем краткосрочной памяти SAR. Если Gs представляет скорость выборки на пустяковых задачах, когнитивная скорость эксперта пред-ставляет скорость выборки информации, относящейся к предметной области. Таким образом, для построения объединенной модели восемь аспектов интеллек-та дополняются тремя новыми аспектами:

  • ExpDR:экспертное дедуктивное мышление;
  • ExpSAR:краткосрочное восприятие и выборка из экспертной рабочей памяти (ExpWM);
  • ExpCS:экспертная когнитивная скорость.

Оценка затрат на разработку ПО

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

Процесс разработки программной системы сложен по своей природе. Оценка затрат, необходимых для ведения крупного проекта по разработке, поднимает эту слож-ность на более высокий уровень. Очевидные следствия сложности этой задачи за-ключаются в том, что оценки затрат на разработку весьма неточны и обычно ока-зываются заниженными [Molekken-Ostvold and Jergensen, 2003], профессионалы проявляют в своих оценках большую уверенность, чем следовало бы [Jergensen et al. 2004], а оценки ненадежны в том отношении, что один эксперт может оценивать один проект по-разному в разных случаях [Grimstad and Jorgensen, 2007]. За про-шедшие десятилетия в точности оценок не было достигнуто заметных улучшений, а с извлечением уроков из прошлых результатов возникают проблемы [Gruschke and Jergensen, 2005].

А если одной сложности еще недостаточно, следует учесть, что человеческие мысли-тельные процессы, задействованные в формировании оценки, подвержены влиянию целого ряда подсознательных процессов [Kahneman and Frederick, 2004], [LeBceuf and Shafir, 2004], [Jorgensen and Sj0berg, 2001], [Jorgensen and Carelius, 2004], [Jor-gensen and Sj0berg, 2004]. Например, оценками легко манипулировать: для этого достаточно заранее сообщить эксперту нужные базовые оценки {эффект якоря). На мыслительные процессы также влияет характер и формат информации, доступ-ной на момент формирования оценки [Jorgensen and Grimstad, 2008], [Jorgensen and Grimstad, 2010], [Jorgensen and Halkjelsvik, 2010], [Jorgensen, 2010]. Например, оценка может зависеть от постановки вопроса: сколько времени понадобится для выполнения заданного объема работы или какой объем работы можно выполнить за заданное время? Вторая форма представляет modus operandi для выделения времени в гибких методологиях разработки. Результат? Выделение времени под заданный объем работы способствует занижению оценок. Вдобавок оно, похоже, противоре-чит общей тенденции переоценки затрат для малых задач при недооценке затрат для больших задач [Halkjelsvik et al. 2010].

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

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

Индивид и среда

Мы возвращаемся к третьему вопросу, ,с которого началась эта глава. Теперь мы можем сформулировать его более точно: если известно, что определение эксперт-ности разработчика является нетривиальной задачей, не стоит ли сосредоточиться на инструментах и методах? Представьте себя на месте чиновника, занимающегося снижением количества и опасности дорожных аварий — главной (в мировых маштабах) причины смерти в возрасте от 10 до 19 лет, и шестой по значимости при-чины смерти в США. Следует ли поставить на первое место повышение квалифика-ции и информированность водителей или же потратить больше денег на улучшение обстановки вождения — ремонт дорог, ограничение скорости, продвижение новых средств безопасности в машинах? И то и другое, скажете вы, но сколько именно по каждому направлению в условиях ограниченного бюджета?

Как ни печально, исследованиям в области дорожных аварий «повезло»: по всему миру доступен огромный объем данных для анализа. Руководители могут принимать рациона.тьные решения по поводу расходования ресурсов. Область разработки ПО еще не достигла состояния для принятия подобных решений: мы не располагаем до-статочным объемом данных, а наши задачи исключительно разнородны по своей при-роде.

Квалификация или безопасность

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

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

Однако известно, что меры по улучшению окружающей среды могут принести пользу. Несколько примеров мер такого рода: удаление нерелевантной инфор-мации PI3 документацрш по требованиям, предотвращение искаженных представ-лений за счет отказа от умозрительных базовых оценок, проведение оценки иде-альных затрат до оценки наиболее вероятных затрат [Jorgensen, 2005]. Эти меры должны изменить среду, в которой происходит процесс оценки, чтобы предот-вратить влияние известной психологической субъективности в лицах, эту оцен-ку производящих. Также к числу мер по улучшению среды относится групповая оценка, которая в среднем точнее одиночных оценок, и правильный выбор модели процесса — оценки, связанные с интерактивной разработкой, часто лучше оце-нок, связанных с разработкой по эстафетному принципу [Molokken-Ostvold and Jorgensen, 2005]. Все эти меры могут поддерживаться соответствующими инстру-ментами и методами.

Парное программирование (рассматриваемое в главе 17 и в меньшей степени в гла-ве 18) является примером действий по улучшению рабочей среды, повышающих качество кода. Целью их применения становятся не сами программисты, а социаль-ные процессы, повышающие производительность как отдельного программиста, так и группы в целом. Важно знать, в каких обстоятельствах объединение программи-стов в пары особенно эффективно. В частности работа в парах приносит особенно заметную пользу новичкам в сложных программных задачах [Arisholm et al. 2007 также см. данные метаанализа в [Наппау et al. 2009] и [Dyba et al. 2007 .

Сотрудничество

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

И все же следует разобраться, что же считать успешным сотрудничеством. Вместо личностных факторов (или в дополнение к ним) стоит рассмотреть, как происходит сотрудничество. В области сотрудничества, формирования команд и групповых процессов проводились обширные исследования. Возможно, их было даже слиш-ком много! Однажды я попытался составить схему основных групповых процессов парного программирования (рис. 6.4), но вскоре стало очевидно, что без информа-ции о том, какое именно сотрудничество реализуется в данной ситуации, невозмож-но выбрать применяемую теорию. Довольно часто исследователи применяют ту или иную теорию, чтобы «задним числом объяснить свои наблюдения« [Наппау et al. 2007]. И обычно сделать это несложно — всегда найдется какая-нибудь подходя-щая теория! Например, теория социальной фасилитации объяснит, почему группа работает хорошо, а теория социального торможения — почему группа работает пло-хо. Для любого наблюдаемого результата можно подобрать что-нибудь подходящее.

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

рисунок 8.Слишком много теории

Чтобы понять, какое сотрудничество реализуется в парном профаммировании, мы прослушали аудиозаписи 43 пар профессиональных программистов, занимаю-щихся решением общей задачи. Далее была произведена классификация режима сотрудничества в соответствии с характером вербальных взаимодействий [Walle and Hannay, 2009]. Использованная схема классификации разрабатывалась мето-дом раскрутки: сверху вниз от существующих схем, и снизу вверх от конкретных взаимодействий, проявляющихся в аудиозаписях. Итоговая схема изображена на рис. 6.5.ы

Схема состоит из двух уровней. Первый уровень различается по основной теме об-суждения — например, пара обсуждает описание задачи или пытается разобраться в коде, или совместно пишет код, или обсуждает что-то еще (хотя бы последний футбольный матч). На втором уровне анализируются так называемые последова-тельности взаимодействий [Hogan et al. 2000]. Центральным элементом здесь яв-ляются схемы взаимодействий. Например, общение относится к категории «уточ-няющие», если оба собеседника своими высказываниями поочередно развивают или проясняют предыдущее высказывание другой стороны. Казалось бы, обилие уточняющих взаимодействий должно благоприятно отражаться на производитель-ности. Тем не менее мы не нашли подтверждений этому в своих данных. Предвари-тельные результаты свидетельствуют о том, что дополнительное время, потраченное на описание задачи, приводит к сокращению времени, потраченного на ее решение. Впрочем, относиться к этим результатам как к окончательно доказанному факту еще рановато — скорее их следует воспринимать как часть исходных данных для ваших рассуждений в практическом контексте. Кроме того, исследователи продол-жают попытки анализа взаимодействий, связанных с оценкой затрат на разработку ПО [Berte and Nerland, 2010], [Jergensen, 2004].

Снова о личностных качествах

Когда речь заходит о сотрудничестве, на сцену снова неизбежно выходит лич-ностный фактор. Например, этнографические исследования, посвященные во-просам влияния личностных факторов и дезорганизации работы групп, показали, что антагонизм — это плохо, но нехватка обсуждения проблемных вопросов еще хуже [Кагп and Cowling, 2006], [Karn and Cowling, 2005]. Утверждается, что в па-рах или группах, составленных из участников со слишком похожими личностны-ми качествами, наблюдается недостаточный уровень обсуждения. Этот факт на-ходит эмпирическое подтверждение в [Williams et al. 2006] и [Walle and Hannay, 2009]. В частности самое сильное влияние оказывают экстраверсивные различия: в парах с разными уровнями экстраверсии наблюдается более интенсивное взаи-модействие (то есть более высокие уровни обсуждения), чем в парах со сходным уровнем.

Расширенная модель интеллекта

Люди с высокими оценками тестов IQ не всегда хорошо справляются с планирова-нием или с принятием решений о том, когда нужно планировать, а когда переходить к действию [Sternberg, 2005]. Планирование играет важную роль. Вспомните наши предварительные результаты: с решением задачи быстрее всего справлялись пары программистов, которые тратили относительно много времени на анализ описания задачи, что можно рассматривать как планирование. Также существует мнение, что «классические» тесты интеллекта, уделяющие особое внимание скорости обработ-ки информации, всего лишь показывают, что обладатели высоких результатов хоро-шо справляются с ответами на вопросы теста, но никак не измеряют их способность найти лучшее решение для реальных задач [Schweizer, 2005 .

рисунок 9.Схема классификации вербальных взаимодействий

Некоторые исследователи сомневаются в содержательной валидности традици-онных конструкций интеллекта. На основании работ специалистов по когнитив-ной психологии, занимающихся интеллектом, Роберт Стернберг и его коллеги сочли, что модель интеллекта должна учитывать приобретение знаний на осно-ве опыта, чтобы метакогнитивные процессы (например, планирование) могли использоваться для повышения качества усвоения информации и умения при-спосабливаться к среде. Кроме того, то, что считается проявлением интеллекта в одной культуре, в другой может считаться глупостью [Sternberg, 2005]. Таким образом, «классические» конструкции интеллекта могут оказаться недостаточно широкими.

Согласно Стернбергу, интеллект особенно сильно проявляется в способности про-являть адаптивное поведение, складывающ’^еся из навыков практического решения задач, навыков вербального общения и социаяьной компетентности. В последнюю категорию входит умение принимать другртх такими, какие они есть, умение при-знавать свои ошибки и проявление интереса к миру в целом — бесценные свойства для сотрудничества!

Адаптивное поведение также является темой исследования Герда Гигерензера и группы адаптивного поведения и познания. Когда вы сталкиваетесь со сложной задачей, западные научные и технические дисциплины обычно учат анализировать и составлять полное представление обо всех актуальных факторах, а затем пред-принимать соответствующие действия. Однако многие задачи (особенно нечетко определенные, такие как оценка затрат на разработку ПО) выходят за пределы наших способностей анализа хотя бы для составления общего представления обо всех актуальных факторах. Скорее всего, несмотря на все затраченные усилия, мы упустим больше факторов, чем учтем в своем анализе. Таким образом, аналитиче-ский подход обречен на неудачу. Чтобы выйти из подобных сложных положений, мы не пытаемся провести полный анализ, а исключаем второстепенные факторы и концентрируемся на нескольких важных [Gigerenzer, 2007], [Gigerenzer and Todd, 1999]. Итак, адаптивное поведение подразумевает, что вы признаете ограничен-ность своих возможностей и выбираете стратегию соответствующим образом. Этот принцип распространяется и на оценку затрат по разработке ПО, где невозможно все определить и проанализировать заранее. К числу методов оценки затрат, на-правленных на выделение самых важных факторов, относится метод рассуждения по аналогиям и нисходящая оценка [Li et al. 2007], [j0rgensen, 2004], [Hertwig et al. 19991.

ДРУГИЕ АСПЕКТЫ ИНТЕЛЛЕКТА

В книге Стернберга [Sternberg, 2003] представлены три аспекта интеллекта: ана-литический, творческий и практический (рис. 6.6). Теория предлагает описание интеллектуальной компетентности в соответствии с личными стандартами ин-дивида и социокультурным контекстом. Успех достигается сочетанием всех трех аспектов, а также использованием сильных сторон и компенсацией слабостей по всем трем аспектам. Теория Стернберга включает в себя концепции интеллекта из врезки «Факторы интеллекта» (см. ранее).

— Аналитический интеллект — связь интеллекта с внутренним миром обработки информации. Аспект состоит из компонентов трех видов:

  • метакомпоненты — процессы более высокого порядка, используемые для пла-нирования и контроля за использованием других компонентов;
  • компоненты производительности — когнитивные процессы более низкого по-рядка, используемые для реализации решений метакомпонентов (родственны GMA);
  • компоненты приобретения знаний — когнитивные процессы, используемые для решения задач.

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

  • реакцию на новшества — умение мыслить и усваивать информацию в рамках новых концептуальных систем;
  • автоматизацию обработки информации — освоение решения задач

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

  • адаптацию к окружающей среде
  • формирование окружающей среды;
  • выбор другой среды.

Также существует много других моделей интеллекта [Sternberg, 2005].

рисунок 10.Тройственная теория интеллекта

Заключение

Вероятно, читателям этой книги будет близка точка зрения практиков, которые раз-мышляют над тем, что они делают в ходе своей повседневной работы, и разрабаты-вают усовершенствованные методы выполнения своих рабочих задач [Jarvis, 1999], Argyris and Schon, 1996]. Главной целью таких дисциплин, как наша, должно стать понимание того, что знают практики (но о чем обычно не рассказывают). Кстати го-воря, начальница отдела кадров из приводившегося ранее примера также говорила о том, что программисты ее компании не должны тратить слишком много времени на размышления о своей работе. Их дело — реализовать то, что прикажут. Я уверен, что большинству из нас (включая Джоэла Сполски) эта точка зрения покажется не слишком привлекательной, но когда сроки поджимают, такая стратегия начинает выглядеть излишне соблазнительно. Иначе говоря, проект застревает в квадранте «срочно/важно» в ущерб квадранту «важно/несрочно», к которому относится пла-нирование и разработка [Covey et al. 1999].

Впрочем, в словах начальницы отдела кадров кроется логическое противоречие. Из ее мнения по поводу IQ следует, что (1) GMA влияет на производительность про-граммирования, но (2) поскольку GMA, в первую очередь, влияет на способность к обучению, получается, что ей нужны программисты, способные быстро обучать-ся. Как известно, что (3) обучение базируется на мыслительной практике, но (4) начальница отдела кадров не хочет, чтобы принятые на работу программисты раз-мышляли о вещах, не имеющих прямого отношения к работе.

Впрочем, действия нашей начальницы отдела кадров нельзя назвать полно-стью бездумными. Она знает, что интеллект важен. Вероятно, она даже читала некоторые книги, упоминаемые в этой главе, но не дочитала до страницы, на которой говорилось, что интеллект хорошо подходит для приобретения навы-ка, а не для прогнозирования уже приобретенных навыков. Интеллект также важнее показателя IQ (который отражает всего лишь один аспект интеллекта). Читая научную литературу, легко запутаться в подробностях, и это далеко не первый случай. Одна из легенд утверждает, что именно так произошло со ста-тьей Ройса [Royce, 1970], в которой он выдвигал возражения против каскадной модели — слишком многие не дочитали до страницы, на которой говорилось, что модель с предыдущей страницы применять не рекомендуется. Помните: принимая решения на основе доказательств, необходимо представлять себе полную картину!

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

С ответом на второй вопрос дело обстоит аналогичным образом. Похоже, для не-которых задач возможно определить показатели сложности и экспертного уровня, но в других задачах мы столкнемся с куда большими сложностями. Учтите, что речь идет об эффективном определении экспертности, то есть без отслеживания произ-водительности за долгий период времени. А это означает, что определение должно ЗД1итывать и прогнозирование производительности в будущем.

Две основные задачи, представленные в этой главе, — программирование и оцен-ка затрат на разработку — сильно различаются по своей природе: одна относится к планированию, а другая к непосредственной работе. Казалось бы, наши ответы на первые два вопроса только усугубляют эти различия. Но из того, что мы наконец-то начали подступаться к одной задаче, но еще не знаем, как взяться за друг>^ю, со-вершенно не следует, что эти две задачи не связаны. Напротив, будет естественно спросить, связана ли эффективность выполнения одной задачи с эффективностью выполнения другой.

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

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

Почему так трудно научиться программировать

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

Прежде всего необходимо понять, действР1тельно ли нам нужно больше программи-стов? Бюро трудовой статистики США недавно предсказало огромный рост спроса на профессионалов в компьютерных областях. Согласно отчету за ноябрь 2008 года [Association, 2008], спрос на 1Т-профессионалов за период с 2006 по 2016 год вдвое превысит темпы роста трудовых ресурсов. В обновленной оценке за ноябрь 2009 года говорится: «Компьютерные и математические профессии составляют наи-более быстрорастущую профессиональную подгруппу в пределах самой быстрора-стущей профессиональной категории» [Consortium, 2010]. Но что следует понимать под «1Т-профессионалом»? «Компьютерной и математической» профессией? Опыт многих безработных 1Т-профессионалов, особенно во время текущей рецессии, наводит на мысль, что, возможно, в США сейчас слишком много программистов [Rampell, 2010].

Даже если ответ на вопрос о том, нужно ли нам больше программистов, не так оче-виден, совершенно ясно, что многие люди вступают на путь программирования и относительно рано терпят неудачу. Слухи о высоком проценте неудач на вводных компьютерных курсах (часто обозначаемых сокращением «CS1» в соответствии с ранними стандартами оформления резюме) постоянно встречаются в литературе и в кулуарных беседах на конференциях — таких как симпозиум АСМ SIGCSE (Special Interest Group in Computer Science Education). Йене Беннедсен и Майьсл Касперсен сделали первую осмысленную попытку определить действительный процент неудач [Bennedsen and Caspersen, 2007]. Они запросили данные из учебных учреждений по всему миру по образовательным спискам рассылки. 63 учреждения предоставили информацию о проценте неудач на своих вводных курсах; таким образом, решения об отборе и предоставлении данных принимались самими учебными заведениями (например, участники с особенно неудачными результатами могли отказаться от предоставления данных или предоставить неверные данные, что могло привести к искажению результатов из-за нарушения случайности выборки).

В целом 30% студентов «проваливаются» или уходят с первого курса, причем в кол-леджах процент неудач выше, чем в университетах (40% вместо 30%). Полз^ает-ся, что примерно треть студентов, поступающих на курсы CS1 в разных учебных учреждениях по всему миру, терпит неудачу или отказывается от продолжения уче-бы. Почему?

Результаты Беннедсена и Касперсена сообщают об успехе или неудаче в учебе, од-нако критерии учргтелей CS1 не являются единственно возможным определением успеха. Многие программисты вообще никогда не ходили ни на какие курсы, но добились успеха. Таким образом, сначала необходимо удостовериться в том, что у людей действительно возникли трудности с изз^ением программирования, не привлекая к этому доказательства в виде оценок. Если нам удастся установить этот факт, можно задать вопрос «Почему?» Может, программирование противо-речит человеческой природе? Не станет ли оно проще в другой форме? Можно ли учить программированию так, чтобы упростить обучение? А может, мы просто понятия не имеем, как измерить реальные познания студентов в программиро-вании?

Действительно ли у студентов возникают трудности

в 1980-х годах в Иельском университете Эллиот Соловей (Elliot Soloway) регуляр-но давал на занятиях по программированию на Pascal следующее задание [Soloway etaL 1983]:

Напишите программу, которая в цикле читает положительные числа до тех пор, пока не прочитает целое число 99 999. После чтения 99 999 программа выводит среднее арифметическое прочитанных чисел.

Эта задача, названная «дождевой задачей чаще других изучалась на ранних порах исследований в преподавании программирования. В статье от 1983 года, из которой взята эта формулировка задачи (другие формулировки исследовались в других ста-тьях), группа из Йельского университета выясняла, улучшает ли возможность ис-пользования команды leave (break в С или Python) эффективность решения задачи. Задача была предложена трем группам студентов:

  • первокурсникам CS1 после изучения и практического применения конструкций WHILE, REPEAT и FOR — 3/4 семестра
  • CS2 (второй семестр, обычно курс структур данных) — 3/4 семестра;
  • студентам предпоследнего и последнего курса, специализация «системное про-граммирование».

В каждой категории половина студентов использовала традиционный синтаксис Pascal, а другая имела возможность использовать Pascal с добавлением команды leave. Результаты, представленные в табл. 7.1, покажутся поразительными каждому, кто успешно начал карьеру в области программирования. Только 14% первокурс-ников смогли решить эту задачу в традицрюнном синтаксисе Pascal? А 30% самых опытных студентов задачу вообще не решили? Исследование повторялось несколь-ко раз (например, работа студентов над «дождевой задачей» изучалась в диссер-тациях Джима Спорера [Spohrer, 1992] и Льюиса Джонсона [Johnson and Soloway, 1987]), а также многократно воспроизводилось неформально — и каждый раз с уди-вительно похожими результатами.

рисунок 11.Результаты решения дождевой задачи студентами Йельского университета

Задача требует относительно сложного условного управления циклом. Если про-грамма читает отрицательное число, она игнорирует его, но продолжает принимать данные. Если число положительно и отлично от 99 999, оно прибавляется к нако-пленной сумме, а счетчик увеличивается на 1. Если число равно 99 999, то оно иг-норируется, а выполнение цикла прерывается. Ошибка в реализации логики легко приводит к тому, что к накопленной сумме будет прибавлено отрицательное число или 99 999.

Эти результаты были получены в Йельском университете. Может, в нем просто не умеют учить программированию? Лишь немногие студенты в наше время изуча-ют программирование до поступления в высшее учебное заведение, так что полу-ченные ими сведения были в основном получены с курсов CS1. Ученые уже много лет пытаются найти способ провести исследование, из которого был бы исключен усложняющий фактор возможности плохого обучения в конкретном учебном за-ведении.

Группа Маккракена

в 2001 году Майк Маккракен [МсСгаскеп et al. 2001] организовал встречу группы исследователей на конференции ITICSE (Innovation and Technology in Computer Science Education) в Кентерберийском университете (Кент). ITICSE — европейская конференция, на которую приезжают участники со всего мира. Учителя из груп-пы Маккракена должны были провести одинаковое исследование в своих учебных группах CS1 и CS2: поставить одну и ту же задачу и дать студентам 90 минут на ее выполнение на бумаге. Все результаты анализировались участниками на конфе-ренции. В этом многоцентровом многонациональном исследовании участвовали четыре учебных учреждения из трех стран. Сравнивая студентов из разных стран и учреждении, исследователи надеялись полз^ить представление о том, чему же студенты реально учатся на начальных этапах.

Задача заключалась в вычислении результатов логических выражений (префикс-ных, инфиксных или постфиксных) с использованием только чисел, бинарных операторов (+, -, /, *) и унарного отрицания для предотвращения сложностей, связанных с перегрузкой знака -). Всего ответы были получены от 216 студентов. Средний показатель по независимой от языка шкале до 110 баллов составил всего 22,89 (21%). Студенты справились с этой задачей просто ужасно. Один преподава-тель даже «сжульничал», проведя лекцию по вычислению выражений до назначе-ния задачи. Результаты этой группы были не лучше, чем у других.

Группа Маккракена проанализировала полученные данные. Было обнаружено, что эффективность решения задачи сильно изменялась между учебными группами. Так-же были обнаружены доказательства «эффекта двух подгрупп», который многие пре-подаватели заметили, а некоторые научные статьи попытались объяснить. Некоторые студенты просто «врубились» и отлично справились с задачей. Более многочисленная подгруппа показала куда худший результат. Почему одни студенты «врубаются» в про-граммирование, а у других это не получается? Были исследованы разные переменные факторы — от прошлого опыта до математической подготовки [Bennedsen and Caspersen, 2005], — однако убедительного объяснения этого эффекта до сих пор не найдено.

Группа Листера

Возможно, некоторые студенты плохо реагируют на конкретного преподавателя или стиль преподавания, но почему так много студентов в нескольких учреждениях показали такие низкие результаты? Неужели плохо учат повсюду^ Мы переоцени-ваем возможности своих студентов? Или оцениваем что-то не то? Рэймонд Листер в 2004 году организовал вторую рабочую группу ITICSE для изучения некоторых вопросов [Lister et al. 2004 .

Группа Листера решила проверить, не слишком ли много ожидала группа Маккра-кена от студентов. Для разработки и реализации решения задачи требовался относи-тельно высокий уровень мышления. Группа Листера решила сосредоточиться на низ-коуровневых способностях чтения и отслеживания кода. Была разработана анкета с множественным выбором ответов, которая предлагала студентам выполнять такие задачи, как определение результатов по фрагменту кода или заполнение пропусков в фрагменте программы. Вопросы в основном относились к операциям с массивами. Исследователи попросили своих участников из разных стран мира опробовать ту же анкету на своих студентах и доставить результаты на конференцию ITICSE.

Результаты группы Листера были лучше, но и они разочаровывали. У 556 студен-тов средняя оценка была около 60%. Хотя из этих результатов можно было сделать вывод, что группа Маккракена переоценила возможности студентов. Листер и его группа ожидали куда более высоких результатов.

Из работ Маккракена и Листера исследователи узнали, что на первом курсе трудно понять, что студенты понимают в программировании. Бесспорно, они узнают намно-го меньше, чем нам кажется. Но одни студенты учатся, а большинство — нет. Что же такого сложного в программировании, что многие студенты не могут освоить его?

Естественное понимание

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

Как ответить на этот вопрос? Можно попытаться использовать метод, аналогичный модифицированным Листером методом Маккракена: выбрать меньшую часть задачи и сосредоточиться на ней. «Программировать» значит указать машине, что она долж-на сделать, на неестественном языке. А если мы попросим участников приказать дру-гому человеку выполнить некоторую задачу на естественном языке? Как участники определят свои «программы»? Если убрать искусственный язык, станет ли програм-мирование более «естественным» или «основанным на здравом смысле»?

Л. А. Миллер попросил участников своего исследования написать указания для за-дачи, которую должен выполнять кто-то другой [Miller, 1981]. Участники получа-ли наборы данных (например, информацию о работниках, должностях и зарплате) и задачи вида:

Составьте список работников, удовлетворяющих хотя бы одному из следующих критериев.

(1) Работник занимает должность техника и зарабатывает не менее 6 долла-ров в час.

(2) Работник не состоит в браке и зарабатывает менее 6 долларов в час.

Список должен быть упорядочен по имени.

Миллер узнал много нового о том, что было трудно, а что было просто для участ-ников. Прежде всего все з^астники эксперимента справились со своей задачей. Он не говорит, что 1 /3 участников сдались или потерпели неудачу, как это постоянно происходит на курсах программирования. Похоже, проблема связана не со слож-ностями описания процесса.

Ключевое различие между решениями задач Миллера на естественном языке и за-дачами по программированию, изучавшимися предыдущими исследователями, от-носится к структуре решения. Участники эксперимента Миллера определяли не итерации, а операции. Например, они не говорили: «Возьмите каждую запись и про-верьте фамилию. Если она начинается с буквы ‘А’…» Вместо этого они использовали формулировки вида: «Для всех фамилий, начинающихся с буквы ‘А…» Миллера это удивило: никто не указывал условие завершения цикла. Некоторые участники гово-рили о проверяемых IF-подобных конструкциях, но никто и никогда не использовал ELSE. Уже одни этих результаты указывают на возможность определения языка про-граммирования на естественном уровне более понятного для новичков.

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

Джон Пейн повторил это исследование в конце 1990-х и начале 2000-х [Рапе et al. 2001]. Пейна интересовала возможность создания языка программирования, при-ближенного к естественному языку, которым люди описывают выполняемые про-цессы друг другу. Он повторил эксперимент Миллера с другой задачей и другим набором исходных данных. Его беспокоило то, что концепции «наборов данных» и «списков» в описании Миллера могли подсознательно влиять на действия участ-ника. Вместо этого Пейн показывал участникам графику и ролики из видеоигр, а затем спрашивал, как бы они описали компьютеру выполнение соответствующих действий, например: «Напишите команду, которая описывает, как я (компьютер) должен перемещать Рас-Мап в присутствии или отсутствии других объектов».

Пейн, как и Миллер, обнаружил, что участники не пытались явно определять ите-ративные действия. Он сделал следующий шаг и попытался охарактеризовать на-писанные ими инструкции в контексте парадигм программирования. Он обнару-жил использование ограничений («Эта штука всегда ведет себя так»), событийных («Когда Рас-Мап собирает все точки, он переходит на следующий уровень») и им-перативных конструкций. Никто и никогда не говорил об объектах. Участники го-ворили о характеристиках и поведении сущностей видеоигры, но не о группиров-ке этих сущностей (например, в классах). Они никогда не говорили о поведении с точки зрения самих сущностей; все происходящее представлялось с точки зрения игрока или программиста.

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

Группа исследователей, называющая себя CCG (,Commonsense Computing Group), занялась из}^ением подобных вопросов. Студентам, не прошедшим даже начальный курс программирования, было предложено решить нетривиальные алгоритмиче-ские задачи (такие как сортировка или параллелизация процессов) на естественном языке, до изучения каких-либо программных конструкций. Участники эксперимен-та на удивление успешно справлялись с этими задачами.

В одном из исследований [Lewandowski et al. 2007] студентам было предложено соз-дать модель театра с двумя продавцами билетов:

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

Задача была предложена 66 участникам из 5 образовательных учреждений — и они решили ее с поразительным успехом! Как видно из табл. 7.2, почти все студенты рас-познали суть проблемы, а 71% предложил работоспособное решение. В большин-стве предложенные решения были неэффективными (в них использовался центра-лизованный арбитраж), так что студентам еще предстоит многому наз^иться. Тем не менее, сам факт решения задачи параллельной обработки наводит на мысль, что трудности с программированием у студентов возникают из-за неподходящего ин-струментария. Возможно, студенты в большей степени способны к компьютерному мышлению, чем нам кажется.

рисунок 12.Результаты решения дождевой задачи студентами Йельского университета

Совершенствование инструментария и визуальное программирование

Как улучшить существующие инструменты? Один из очевидных ответов — переход на визуальные технологии. Еще со времен создания Дэвидом Смитом языка про-граммирования Pygmalion, основанного на пиктограммах [Smith 1975], существует теория, что визуальное мышление проще для студентов. Многие исследования по-казывают, что визуализация в целом упрощает изучение программирования [Naps et al. 2003], но действительно серьезных исследований было относительно немного.

Затем Томас Грин и Мэриан Петр провели параллельное сравнение языка програм-мирования, основанного на традиционных потоках обработки данных, с текстовы-ми языками программирования [Green and Petre, 1992]. Они написали программы на двух визуальных языках, хорошо сработавших в предыдущих исследованиях, и на текстовом языке, который тоже хорошо показал себя при тестировании. Ис-следователи ненадолго выдавали участникам визуальную или текстовую програм-му, а затем задавали вопросы о ней (например, о входных данных или результатах выполнения). На то, чтобы разобраться в графическом языке, участникам всегда требовалось больше времени. Причем результат не зависел от предыдущего опы-та работы участника с визуальными или текстовыми языками или разновидностью визуального языка. Визуальные языки воспринимались участниками эксперимента медленнее, чем текстовые.

Грин и Петр опубликовали несколько статей по разновидностям этого исследо-вания — [Green et al. 1991], [Green and Petre, 1996], — но настоящей проверке это утверждение подверглось, когда Том Моэр со своими коллегами [Moher et al. 1993 попытались склонить чашу весов в пользу визуальных языков. Том со своими аспи-рантами использовал для обучения студентов программированию особую систему визуальных обозначений, так называемые сети Петри. Он раздобыл копию мате-риалов Грина и Петра и создал версию, в которой из визуальных языков использо-валась только модель сетей Петри. Затем Том повторил это исследование на себе и на своих студентах. И снова выяснилось, что текстовые языки в любых ситуациях проще воспринимаются участниками эксперимента.

Выходит, мы зря доверились своей интуиции по поводу визуальных языков? И на самом деле визуализация только затрудняет понимание программнного кода? А как же исследования группы Нэпса [Naps et al. 2003] — все они были ошибочными?

Для сравнения нескольких исследований применяется стандартный метод, назы-ваемый метаанализом, Барбара Китченхэм описывает эту процедуру в главе 3. Крис Хундхаузен, Сара Дуглас и Джон Стаско провели такой анализ для исследований в области визуализации алгоритмов [Hundhausen et al. 2002]. Они обнаружили, что многие исследования, обладающие статистической значимостью, действительно де-монстрировали преимущества визуализации алгоритмов для студентов. Также было много исследований со статистически незначимыми результатами. Некоторые ис-следования демонстрировали статистически значимые результаты, но из них было неясно, как алгоритмические визуализации способствовали усвоению материала (рис. 7.1). Хундхаузен и его коллеги обнаружили, что многое зависело от исполь-зования визуализаций. Например, использование визуализаций на лекциях мало влияло на обучение студентов. С другой стороны, самостоятельное построение ви-зуализаций студентами оказывало значительное влияние на процесс их обучения.

рисунок 13.Сводные данные по 24 исследованиям из статьи Хундхаузена

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

Роль контекстуализации

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

В 1999 году Технический университет штата Джорджия решил ввести обязатель-ный вводный курс компьютерных технологий для всех студентов. За первые пять лет это требование было выполнено только одним курсом. В целом процент успеш-ной сдачи экзаменов по этому курсу составлял 78%, что, в соответствии с данными Беннедсена и Касперсена, было неплохо [Bennedsen and Caspersen, 2007]. Но если как следует проанализировать это число, ситуация выглядит уже не столь привле-кательной. Среди студентов общеобразовательных, архитектурных и управленче-ских колледжей процент успешной сдачи был ниже 50% [Tew et al. 2005а]. Среди женщин «провалы» встречались почти вдвое чаще, чем у мужчин. Если курс пред-назначен для всех студентов, а успешно проходят его в основном мужчины с техни-ческой специализацией, это говорит о системных проблемах в преподавании про-граммирования.

В 2003 году был начат эксперимент по преподаванию новой разновидности ввод-ного курса в контексте обработки цифровых материалов [Forte and Guzdial, 2004 . Студенты работали практически над теми же задачами, как и в других вводных кур-сах компьютерных технологий. Нам пришлось изрядно потрудиться, чтобы вклю-чить в курс все темы [Guzdial, 2003], рекомендованные действовавшим на то время стандартом АСМ and IEEE Computing Standards [lEEE-CS/ACM 2001]. У нас это получилось, и во всем тексте учебников, примерах кода и домашних заданиях речь шла об обработке цифровых материалов. Например, задача перебора элементов массива рассматривалась на примере преобразования всех пикселов графического изображения в оттенки серого — а вместо конкатенации строк студенты выполняли конкатенацию звуковых буферов в операциях цифрового монтажа. Перебор подди-апазона массива изучался на примере удаления эффекта «красных глаз» без ущерба для красного цвета на фотографии.

Реакция студентов была положительной и очень заметной. Студентам новый курс показался намного более актуальным и интересным — особенно женщинам, у ко-торых процент успешной сдачи превзошел аналогичный показатель среди мужчин (хотя и не в пределах статистической значимости) [Rich et al. 2004]. За следующие три года средний процент успешной сдачи экзаменов увеличился до 85%, причем даже в тех специализациях, в которых он ранее находился на уровне ниже 50% [Tew et al. 2005а].

Казалось бы, успех налицо, но о чем реально говорится в этих статьях? Можно ли утверждать, что все остальные условия остались неизменными, а изменился только новый метод? Возможно, в университетские колледжи вдруг стали поступать более умные студенты. Или технический университет штата Джорджия принял на работу нового обаятельного преподавателя, который увлек студентов своим энтузиазмом. Социологи называют такие факторы, которые мешают нам утверждать желаемое, угрозами валидности^. В защиту своей оценки изменений мы можем сказать, что в статье [Tew et al. 2005а] приводятся данные по нескольким семестрам с разными преподавателями, результаты обобщаются за три года исследований, а внезапное изменение уровня студентов кажется маловероятным.

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

Первое испытание контекстной методологии в другом учебном заведении было про-ведено Чарльзом Фаулером в колледже Гейнсвиля (штат Джорджия), государствен-ном колледже с двухгодичной формой обучения. Результаты представлены в той же статье [Tew et al. 2005а]. Фаулёр также обнаружил кардинальный рост успеваемости среди своих студентов из разных специализаций, от компьютерных технологий до медицины. Впрочем, и в техническом университете штата Джорджия, и в колледже Гейнсвиля учились в основном белые студенты. Сработает ли этот метод для этни-ческих меньшинств?

В Иллинойском университете в Чикаго (UIC) Пэт Трой и Боб Слоан ввели кон-текстную методологию на своих курсах CS 0.5 [Sloan and Troy, 2008]. Их занятия предназначались для студентов, которые хотели специализироваться на компьютер-ных технологиях, но не имели предварительной подготовки в области программи-рования. Вводный курс CS 0.5 должен был подготовить их к первому курсу (CS1). За несколько семестров процент успешной сдачи экзаменов среди этих студентов также возрос. UIC отличается более разнородным этническим составом, а большин-ство студентов принадлежит к этническим меньшинствам.

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

Бет Саймон и ее коллеги из Калифорнийского университета в Сан-Диего (UCSD) начали использовать контекстную методологию два года назад в качестве основного вводного курса (CS1) для студентов со специализацией в области компьютерных технологий [Simon et al. 2010]. Новый курс повысил успеваемость студентов. Бо-лее того, прошедшие его студенты показывали более высокие результаты на втором курсе по сравнению со студентами, прошедшими традиционный курс CS1.

Так что же, контекстная методология — панацея? Все должны использовать ее? И хотя мой издатель хотел бы, чтобы вы в это поверили, исследования — [Guzdial and Ericson, 2009а] [Guzdial and Ericson, 2009b] — не позволяют однозначно сделать такой вывод.

Прежде всего, я не утверждал, что студенты при использовании контекстной ме-тодологии получают такой же объем знаний. Если кто-то скажет вам, что студенты при использовании их метода узнают столько же, сколько при другом методе, к по-добным заявлениям следует относиться весьма осторожно, потому что в настоящее время мы не располагаем достоверными и валидными метриками эффективности преподавания на вводных курсах программирования. Эллисон Тью ([Tew et al. 2005а]) в 2005 году сначала попыталась ответить на вопрос, одинаково ли учатся студенты на разных курсах CS1 [Tew et al. 2005b]. Она разработала две тестовые анкеты с множественным выбором для каждого из сравниваемых языков. Предпо-лагалось, что анкеты будут изоморфными: задача, предназначенная для проверки определенной концепции (скажем, перебора элементов массива), будет практически одинаково решаться независимо от теста и языка. Тесты использовались до и после второго курса программирования (CS2) для оценки различий в усвоении материа-ла в курсах CS1. Исследования Тью показали, что студенты действительно получа-ли разные знания на курсах CS1 (как показывало тестирование до начала CS2), но к концу CS2 эти различия исчезали. Это был очень важный вывод — из него следует, что различия в CS1 не были критичны для будущего успеха. Но в дальнейших ис-следованиях этот результат никогда не повторялся.

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

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

Во-вторых, даже если бы Технический университет штата Джорджия, колледж Гейнсвиля, Иллинойский университет в Чикаго и Калифорнийский университет в Сан-Диего вдруг смогли показать, что студенты получают на вводных курсах один и тот же объем знаний, то что бы это доказало? Что контекстная методология по-дойдет для всех? Что она будет лучше «традиционного» курса, каким бы успешным и замечательным ни был последний? Для всех студентов, даже самых плохо под-готовленных и апатичных? Каким бы плохим ни был учитель? Конечно, это просто смешно. Всегда можно придумать что-то, что пойдет не так.

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

Заключение

Дисциплина исследований компьютерного образования как научная область еще очень молода [Fincher and Petre 2004]. Мы лишь недавно осознали важность ком-пьютерного образования и необходимость поддержки преподавания. Организация АСМ для преподавателей компьютерных дисциплин — CSTA (Computer Science Teachers Association) — была образована только в 2005 году. Сравните с Националь-ным советом преподавателей математики, созданным в 1920 году.

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

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

Кроме количества строк нужны ли дополнительные метрики сложности?

Сложность присутствует во всем жизненном цикле программного продукта: в определении требований, анализе, проектировании и, конечно, реализации. Сложность обычно является нежелательным свойством программного продукта, потому что она затрудняет его чтение и понимание, а следовательно, и внесение изменений; также считается, что сложность является главной причиной появле-ния дефектов. Из всех артефактов, производимых в ходе работы над программ-ным проектом, исходный код предоставляет самые простые возможности для из-мерения сложности. Однако за несколько десятилетий исследований в области разработки ПО аналитики так и не пришли к единому мнению по поводу того, какие метрики лучше всего отражают сложность заданного блока кода. Трудно даже сравнить два блока кода, написанных на разных языках программирования, и сказать, какой из них сложнее. Из-за этого сейчас развелось множество всевоз-можных метрик для оценки сложности программы. Что говорят исследования по поводу того, какие метрики лучше всего подходят в каждом конкретном случае? И дают ли они более точную оценку, чем простейшие метрики типа количества строк кода?

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

Выбор продукта

Первым шагом исследования должен стать выбор репрезентативного программного продукта (как при проведении социологических опросов). Для известной совокуп-ности статистические методы позволяют определить минимальный размер выборки для формулировки выводов с заданной неопределенностью. Например, на момент написания этого текста население США составляло около 300 миллионов человек; чтобы опрос на выходе с избирательных участков точно предсказал результаты выборов, количество опрашиваемых участников должно быть достаточно велико — скажем, около 30 ООО.

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

Впрочем, несмотря на го, что вся совокупность программных продуктов неопре-делима, часть этой совокупности открыта и доступна для исследований, а ее ис-ходный код доступен всему миру: речь идет о программах с открытым кодом. Ко-нечно, ограничение совокупности такими программами теоретически привязывает ответ на исходный вопрос к этой разновидности программ. Но в конечном счете между программами с открытым и закрытым кодом существует только одно раз-личие: лицензия. Хотя программы с открытым кодом обычно разрабатываются с применением конкретных методов (обш;ественное ведение проекта, доступность исходного кода и т. д.), совокупность программных продуктов с открытым кодом весьма разнородна — от проектов, существуюш;их исключительно по инициативе сообщества, до проектов, находящихся под жестким контролем компаний. Един-ственный признак, общий для всех продуктов с открытым кодом, — набор лицен-зий, по которым он публикуется, вследствие чего его исходный код становится общедоступным. Следовательно, мы можем предположить, что лучшие метрики сложности исходного кода, определенные для проектов с открытым кодом, также будут лучшими метриками сложности для любого другого исходного кода (как от-крытого, так и закрытого).

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

Впрочем, продукты с открытым кодом также таят некоторые опасности и ловушки. Формирование большой выборки таких проектов затрудняется разнородностью источников данных. Не все проекты используют одинаковые инструменты для организации разных (или даже одинаковых) репозиториев, причем нередко эти репозитории разбросаны в нескольких местах. Некоторые проекты — такие как FLOSSMetrics (http://flossmetncs.org) и FLOSSMole (http://flossmole.org) — предо-ставляют доступ к базам данных, содержащим метрические и фактические дан-ные о проектах с открытым кодом; наличие таких баз частично компенсирует разнородность данных при самостоятельном анализе репозиториев. Кроме того, решению проблемы способствует и само сообщество разработки с открытым ко-дом на уровне дистрибутивов программ — например, хорошо известных Ubuntu и Debian. Дистрибутивы собирают программы из проектов с открытым кодом, адаптируют к другим программам и предоставляют доступ к ним в откомпили-рованном двоичном формате и в виде пакета исходного кода. Пакет снабжается метаданными, которые упрощают классификацию и определение будущих за-висимостей для установки. Некоторые дистрибутивы включают тысячи пакетов и миллионы строк исходного кода. Они идеально подходят для любого исследо-вания, требующего большого объема исходного кода, — как исследование, пред-ставленное в этой главе.

Метрики исходного кода

Мы выбрали для своего исследования дистрибутив ArchLinux (http://archlinux. org), состоящий из тысяч пакетов с открытым кодом. ArchLinux представляет собой «легкий» дистрибутив GNU/Linux, авторы которого отказываются изменять исход-ный код, упакованный в дистрибутиве, для достижения своей цели по кардиналь-ному сокращению времени между официальным выходом пакета и его интеграцией в дистрибутив. Пакеты в ArchLinux могут устанавливаться двумя способами: либо в виде «официальных» заранее откомпилированных пакетов, либо из исходного кода с использованием системы сборки ABS (Arch Build System).

ABS позволяет получить «эталонную» версию исходного кода всех пакетов. В этом отношении ArchLinux отличается от других дистрибутивов, которые копируют ис-ходный код пакетов и часто вносят в него изменения для адаптации к другим про-граммам. ABS делает возможным автоматизированную загрузку кода с сайтов и из репозиториев первичного проекта. Это гарантирует, что исходный код не подвер-гался изменениям, а следовательно, что выборка содержит независимые данные. Как будет показано позднее, свойство независимости чрезвычайно важно для обе-спечения валидности результатов.

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

Листинг 8.1. Начало сценария сборки в ArchLinux
pkgname=ppl Dkgver=0.10.2 (1) Dkgrel=2 (2)
Dkgclesc=»A modern library for convex polyhedra and other numerical abstractions.»

Листинг 8.1 (продолжение)
arch=(‘1686’ ‘х86_64’) url=»http://www.cs.unipr.1t/ppl» license=(‘GPL3’) depencls=( ‘gnip>=4.1.3’) options=(‘!docs’ ‘llibtool’)
source=(http://www.cs.un1pr.1t/ppl/Download/ftp/releases/$pkgver/ppl-$pkgver.tar.gz) md5sums=(‘e7dd265afdeaea81f7e87a72bl82d875’) (4)

(1) — версия пакета; используется для сборки пакетов, загруженных с URL-адреса;
(2) — дополнительный номер версии; также используется для сборки пакетов, за-суженных с URL-адреса;
(3) — URL-адрес для загрузки исходного кода;
(4) — контрольная сумма исходного 1аг-архива.

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

Во всем собранном коде язык программирования каждого файла определялся при помощи утилиты SlocCount (http://www.dwheeler,com/sloccount). Ограничив свою выборку только кодом на языке С, мы измерили несколько метрик размера и слож-ности при помощи пакета cmetrics из инструментария Libresoft (http://tools.libresoft.es/cmetrics).

Анализ выборки

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

рисунок 14.ВЫбор метрик для исследования

Элементы кода, по которым вычисляются все эти метрики, представлены в следую-щем фрагменте кода (листинг 8.2). Фрагмент взят из пакета urlgfey кроссплатфор-менного менеджера загрузки (недавно пакет urlgfe был переименован в uget, поэтому найти его в репозиториях ArchLinux под исходным именем уже не удастся). Файл содержит директивы препроцессора ((1)), комментарии ((3)) и всего одну функцию (начинающуюся в точке (4)) с циклом whilе.

рисунок 15.Пример файла с исходным кодом C

(1) — директивы препроцессора (учитываются в LOC и SLOC);
(2) — пустые строки (з^итываются в LOC, но не в SLOC);
(3) — строки с комментариями (учитываются в LOC, но не в SLOC);
(4) — строки с программным кодом (учитываются в LOC и 8ЮС).

Простейшие метрики сложности относятся к количеству строк кода (общее коли-чество строк кода LOC и количество строк «содержательного» кода SLOC). Так-же по исходному коду можно легко определить количество функций. Остальные метрики сложности — цикломатическая сложность Маккейба и набор метрик Хэл-стеда — требуют более сложных вычислений

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

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

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

SLOC

Для вычисления этой классической метрики мы воспользуемся определением, при-веденным у Конта.

Строкой кода считается любая строка программы, 7ie пустая и не содержащая ком-ментария, независимо от количества команд или их фрагментов. В частности сюда включаются все строки с заголовками программ, объявлениями, а также исполняе-мыми и неисполняемыми командами.

Так, для фрагмента кода в листинге 8.2 без учета пустых строк и комментариев, но с включением директив препроцессора и других строк, метрика SLOC рав-на 23.

LOG

Для вычисления этой метрики мы подсчитываем общее количество строк в каждом файле с исходным кодом, включая комментарии, пустые строки и т. д., при помощи утилиты UNIX WC. Для фрагмента в листинге 8.2 метрика LOC равна 32 (с учетом 18 строк текста лицензии в комментарии, который был удален для удобства пред-ставления).

CFUNC

Для подсчета количества функций в каждом файле использовалась утилита exuberant-ctags в сочетании с wc. Эта метрика вычисляется еще проще. В листинге 8.2 содержится только одна функ-ция, поэтому для этого файла метрика CFUNC равна 1.

Цикломатическая сложность Маккейба

Мы используем определение из исходной статьи Маккейба [МсСаЬе 1976], в кото-ром говорится о количестве областей в графе, представляющем файл с исходным кодом. Любая программа может быть отображена в виде графа. Простейшая об-ласть представляет собой строго последовательную серию команд, не содержащую циклов, условных или безусловных переходов; она представляется графом (а) на рис. 8.1. Конструкция 1 f обозначается ветвлением (граф (Ь) на рис. 8.1). Цикл обо-значается на диаграмме ребром, ведущим к предшествующему узлу.

рисунок 16.Примеры графов

Для графа G, состоящего из п вершин, е ребер ир точек выхода (например, возврата управления из функции для области С) сложность v вычисляется по следующей формуле:

рисунок 17.формула

Минимальное значение метрики цикломатической сложности (CYCLO) рав-но 1; оно соответствует последовательной серии команд без ветвлений и ци-клов. Каждая дополнительная область на графе увеличивает CYCLO на 1. На-пример, у программы с командой if (без else) метрика CYCLO равна 2, потому что условный переход создает на графе еще одну область в дополнение к ис-ходной.

У программы в листинге 8.2, граф которой изображен на диаграмме (Ь) рис. 8.1, ме-трика CYCLO равна 3. Ветвление if создает одну новую область (А на рис. 8.1), а цикл while создает другую (В на рис. 8.1). Наконец, окружающая область С тоже всегда вносит в цикломатическую сложность свой вклад, равный 1.

Метрики Хэлстеда

в этой категории будет использоваться определение, данное Капом [Кап 2003]. Мы вычислили четыре метрики: длина, объем, уровень и количество умозаключений. Вычисление этих метрик основано на избыточности операндов и операторов про-граммы.

В языке С к категории операндов относятся строковые константы и имена перемен-ных, а к категории операторов — знаки операций (такие как -, ++ и —), оператор косвенного обращения sizeof, константы препроцессора, управляющие команды (такие как if и while), спецификаторы типа хранения (такие как static и extern), спецификаторы типов (такие как Int и char), а также спецификаторы структур (struct и union).

Метрики вычисляются подсчетом количества несовпадающих операторов гг^, ко-личества несовпадающих операндов «з, общего количества операторов N^ и обще-го количества операндов N2. Длина программы L представляет собой сумму общего количества операторов и операндов: