Это не статья — просто пища для размышлений о том, как её написать

http://personal.lse.ac.uk/sorensec/this_is_not....html
  • Перевод


Под катом перевод статьи Carsten Sørensen «This is not an article — just some food for thoughts on how to write one». В ней рассказывается на что нужно обращать внимание при написании научных статей. Если вы пишите диссертацию в области информационных технологий, то наверняка найдете что-то интересное для себя. Впрочем, и авторы популярных статей тоже могут найти что-то полезное.

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

Аннотация


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

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

1. Введение


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

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

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

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

Другие авторы писали на эту и связанные темы. Robert Day (1977, 1991) написал статью о том, как писать статьи, а также очень хорошую книгу, в которой излагаются важные аспекты того как написать статью и затем опубликовать её, плюс рассматривается множество других связанных вопросов. Я не пытаюсь конкурировать с ним или многими другими, перечисленными ниже. Данная статья может рассматриваться как руководство «на скорую руку» или аперитив для дальнейших исследований. Beer (1992) собрал более 60 коротких статей, предоставляющих практическую помощь по ряду вопросов от написания первого черновика статьи до выступлений. Я также нашел пару статей по этой теме: относительно короткая статья Naur (1992); статья, содержащая подробные примеры того, как представлять результаты Gopen и Swan (1990); статья Snyder (1991) направлена на потенциальных участников OOPSLA; Pugh (1991) и Wegman (1986) фокусируются на том, как писать расширенные тезисы. Klein (1989), Krathwohl (1988) и Witten (1990) писали о том, как писать предложения. Книга Lester Sr. и Jr. (2004), посвященная написанию исследовательских статей, новее, чем книга Day, но также и менее занимательна. Однако там где ей не хватает юмора описание компенсируется богатыми деталями. Björk и Räisänen (2003) предлагают полный курс академического письма. Weston (1987) дает очень вдохновляющую основу для построения аргументации, а классика Strunk и White (1979) научит вас большинству из того, что стоит знать о стиле в английском языке. The Economist (2003) выпустил отличное руководство по стилю написания, а Truss (2003) написала очень популярную книгу о пунктуации «Eats, Shoots & Leaves». Stephen King (2000) написал книгу о ремесле письма не в научном контексте, а с авторской точки зрения. Восьмистраничное руководство «Guide to punctuation, mechanics, and manuscript form» содержится в (Guralnik, 1970), а Cook (1985) предоставляет действующее и практическое руководство по написанию. Несколько книг предлагают помощь начинающим писателям, которые занимаются научной работой, например, книги Dunleavy (2003), Holliday (2001) и Philips & Pugh (2000). Olk & Griffith (2004) обсуждают, как знания создаются и распространяются среди ученых. Fuller (2005) в основном рассматривает разницу между научными сотрудниками и учеными, а Frankfurt доходит до некоторой крайности в своей маленькой философской экспозиции о бреде сивой кобылы. В MIT группа студентов-информатиков, возможно, вдохновленная этой работой, даже написала генератор, который автоматически подготовит для вас научную публикацию (http://pdos.csail.mit.edu/scigen/).

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

Данная статья структурирована как серия уроков, которые я выучил. В следующем разделе оговаривается, что вам нужно основание для того, чтобы высказаться. В разделе 3 подчеркивается важность простоты. В разделе 4 излагаются пять основных вопросов, которые следует задавать себе при написании статьи. В разделе 5 предлагается начинать с подражания, а в разделе 6 утверждается, что вы должны получить право на отклонение от нормы. В разделе 7 мы остановимся на процессе написания статьи. В разделе 8 сделаем акцент на читаемости, а в разделе 9 — на взаимосвязи между написанием и рецензированием.

2. Вам нужна уважительная причина для заявления своей позиции


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

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

(Этот список вдохновлен выступлением Джонатана Либенау на панельной сессии «Meet the Editors» на консорциуме «The Joint European and American Doctoral Consortium», Копенгаген, Дания. Декабрь 1990 года.)

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

Статья про «отличную идею» «У меня просто была эта замечательная идея! Не знаю была ли у кого-нибудь еще такая же, потому что я не проверял, к тому же я новичок в этой области. В любом случае, моя идея блестящая, поэтому я действительно хотел бы поделиться ею со всеми вами».
Статья про «идеи других людей» «Я только что прочитал эту замечательную книгу, которая мне очень нравится. Я просто резюмирую для вас интересные моменты из неё».
Статья «ИТ хакера» «Я только что разработал эту замечательную программу. Она не основана на каких-либо предыдущих теориях или эмпирических выводах. Да, и сам я не особо теоретик, но в системе много фантастических функций, и интерфейс по-настоящему прекрасен».
Статья «хакера-теоретика» «Я придумал эту теорию, концептуальный инструментарий, модель. Они не связаны с другими теориям, концептуальными инструментариями, моделями или с какими-либо эмпирическими данными. Большинство понятий были определены иначе светилами в данной области, но мне не нравятся их категории, поэтому я придумал свои собственные.»
Статья «со множеством идей» «Я только что завершил крупную исследовательскую работу, где я сделал много интересного. Я думаю, что вы могли бы многому научиться, прочитав эту статью, описывающую все аспекты моей работы.»

Рисунок 1. Примеры архетипов статей, чтение которых не приносит мне радости.

3. Не усложняйте


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

Только одна идея на статью


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

Кладите вашу шею только на одну гильотину


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

4. Основные вопросы, которые необходимо задать себе


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

Прежде чем мы углубимся в эти пять вопросов, давайте немного осветим их с помощью забавного примера того, как на них ответили во введении к статье «Трассировка лучей для желатина марки Jell-O» («Ray Tracing Jell-O Brand Gelatin») (Heckbert, 1987) (рисунок 2).

«Трассировка лучей зарекомендовала себя в последние годы как самый общий алгоритм синтеза изображений [10]. Исследователи изучили расчеты пересечения лучей с поверхностями для ряда поверхностных примитивов. К ним относятся шахматные доски [Whitted 80]; хромированные шары [Whitted 80]; манипуляторы [Barr 82]; синие абстрактные вещи [Hanrahan 82]; больше стеклянных шаров [Watterberg 83]; мандрилы [Watterberg 83]; больше мандрилов [Sweeney 83]; зеленые фрактальные холмы [Kajiya 83]; больше стеклянных шаров [SEDIC 83]; водные бесформенные вещи [Kaw 83]; больше хромированных шаров [Heckbert 83]; бильярдные шары [Porter 84]; больше стеклянных шаров [Kajiya 86].

К сожалению, никто не делал трассировку лучей для продуктов питания. До настоящего времени наиболее реалистичными продуктами были классические изображения апельсина и клубники Блинна, но они были созданы с помощью алгоритма построчного сканирования [2]. Проект „Dessert Realism Project“ в Pixar затрагивает эту проблему. В этой статье представлена новая технология трассировки лучей для ограниченного класса десертов, в частности, желатина марки Jell-O. Мы полагаем, что этот метод может применяться к другим маркам желатина и, возможно, к пудингу.

Данная статья делится на три части: метод моделирования статического Jell-O, моделирование движения Jell-O с использованием впечатляющей математики и вычисления пересечения лучей с Jell-O.»

Рисунок 2. Введение из статьи «Трассировка лучей для желатина марки Jell-O» (Heckbert, 1987).

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

Какова проблемная область?


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

«Трассировка лучей зарекомендовала себя в последние годы как самый общий алгоритм синтеза изображений [10]. Исследователи изучили расчеты пересечения лучей с поверхностями для ряда поверхностных примитивов.»

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

«К сожалению, никто не делал трассировку лучей для продуктов питания. До настоящего времени наиболее реалистичными продуктами были классические изображения апельсина и клубники Блинна, но они были созданы с помощью алгоритма построчного сканирования [2]. Проект „Dessert Realism Project“ в Pixar затрагивает эту проблему.»

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

В чем заключается проблема?


Вам самим очень важно получить четкое представление о том, какой исследовательский вопрос вы хотите рассмотреть в статье. Это важно по нескольким причинам. Во-первых, чем более четкое понимание у вас есть, тем лучше вы можете достичь достаточной глубины своей аргументации. Во-вторых, когда читатель прочитал вашу статью, он должен, по крайней мере, связать её с одной важной идеей, которую вы аргументировали. В качестве очень хорошего примера рассмотрим статью Брукса «Серебряной пули нет — сущность и акциденция в программной инженерии» (Brooks, 1987) (см. также рисунок 4). Когда вы прочтете эту статью, вы свяжете её с идеей: ни одна технология разработки программного обеспечения сама по себе не может решить проблему кризиса в области разработки программного обеспечения. Что является простым, но, как видно из числа ссылок на эту статью, также и мощным утверждением. Если у читателя будет небольшая путаница в отношении сути статьи, статья в лучшем случае будет иметь незначительное влияние. Один из основных критериев успеха в деле написания статей заключается в том, чтобы заставить специалистов в вашей области прочитать и процитировать ваши статьи. Если они не помнят, что они только что прочитали, мало шансов, что они будут использовать статью или рекомендовать ее другим.

Каков метод исследования?


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


Рисунок 3. Простая характеристика взаимосвязи между типом метода исследования и типом результата. Адаптировано из (Sørensen, 1993).

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

Вы могли бы также контекстуализировать свои исследования немного больше, чем просто охарактеризовать тип подхода и тип результата. На эту тему есть множество источников знаний, поэтому я остановлюсь лишь на нескольких. Ives, Hamilton и Davis (1980) представляют таксономию исследований ИС. Wynekoop и Conger (1990) характеризуют исследование CASE, объединяя исследовательские цель и подход. Dahlbom и Mathiassen (1993) предоставляют инструментарий на философской основе для проектирования систем и, наоборот, также являются основой для обсуждения исследований в области проектирования систем.

Как только контекст на месте, вы должны уточнить исследовательский подход, особенно если вы сообщаете об эмпирическом исследовании. Здесь раздолье для инструментариев, характеризующих разные подходы, и я остановлюсь только на нескольких источниках, которые я нахожу ценными. «The Information Systems Research Challenge» Гарвардской бизнес-школы делит исследовательские подходы на три аналитические категории: (1) экспериментальные исследования (Benbasat, 1989), (2) качественные исследования (Cash and Lawrence, 1989) и (3) обзоры (Kraemer, 1991). Mumford и другие (1985) обсуждают исследовательские подходы для информационных систем в ряде статей.

Что сделали другие?


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

Каковы результаты исследования?


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

Где нужно отвечать на эти пять вопросов?


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

5. Подражательство может окупиться


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

Давайте рассмотрим пример того, как быть подражателем и получить очень интересный результат, сильно отличающийся от того, что было скопировано (см. рисунок 4). Известная статья Брукса «Серебряной пули нет — сущность и акциденция в программной инженерии» (Brooks Jr., 1987) начинается со сравнения проектов по разработке программного обеспечения с оборотнями и использует идею убийства оборотней с помощью серебряных пуль в качестве литературного приема обрамления.

Читатель сразу понимает точку зрения Брукса о том, что мы не должны надеяться на единственную технологию, действующую как серебряная пуля. Dahlbom & Mathiassen (1994) не интересно заявлять что-либо об оборотнях. Тем не менее, они заинтересованы в том, чтобы захватить интерес читателя и в том, чтобы обратить внимание на проблему, с которой они сталкиваются так, что ни один читатель не будет сомневаться в том, какова их точка зрения. Что они делают? Они заимствуют трюк Брукса и заменяют оборотней часами. На рисунке 4 воспроизводятся большие выдержки из введений к статьям Брукса (левая колонка) и Dahlbom & Mathiassen (правая колонка). Как вы можете видеть, основная идея использования истории часов и часовщиков в качестве литературного приема обрамления для точного определения проблем, связанных с компьютерами и компьютерными специалистами, очень похожа на то, что делает Брукс в своей статье.

Статьи «Трассировка лучей для желатина бренда Jell-O» (Heckbert, 1987) (см. рисунок 2) и «Интерфейсное устройство, основанное на жестах носом: расширение виртуальных реальностей» (Henry et al., 1993) — обе отличные и очень забавные парафразы архетипных статей по компьютерным наукам. Объемом они всего лишь несколько страниц, но очень забавным способом отражают и исследуют стандартный формат статьи.

Серебряной пули нет — сущность и акциденция в программной инженерии
(Brooks Jr., 1987)
Будущее вычислений
(Dahlbom and Mathiassen, 1994)
1. Введение.

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

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

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

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

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

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

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

Рисунок 4. Выдержки из введений к статьям «No Silver Bullet: Essence and Accidents of Software Engineering» Brooks Jr. (1987) и «The Future of Computing» Dahlbom & Mathiassen (1994). Очевидно, обе статьи начинаются с очень мощных литературных приемов обрамления.

6. Заработайте свое право отклоняться от нормы


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

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

Вы легко сможете найти очень хорошие статьи, которые не следуют нормальной структуре. Просто взятие двух первых работ (Brooks Jr., 1987) и (Weinberg, 1982) из коллекции любимых статей по разработке программного обеспечения DeMarco и Lister (1990), показывает, что хорошие статьи не обязательно должны следовать самому распространенному рецепту. С другой стороны, мы, вероятно, не все Бруксы или Вайнберги в своей области. Если вы уже давно работаете в некоторой области, и вы очень уважаемый исследователь, специалисты будут читать вашу статью независимо от того, как она структурирована, исходя из предположения, что у вас, по-видимому, есть что-то интересное для представления, и что вы, вероятно, сделаете это в элегантной и подкрепленной аргументами манере. Остальным из нас, скорее всего, будет лучше полагаться на результаты наших исследований, как основного «рекламного аргумента», и представлять эти результаты таким образом, чтобы читателям было как можно проще их прочитать.

7. Как избежать написания нескольких статей в одной


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

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

Как вы, возможно, догадались, я сторонник нисходящего (top-down) процесса написания статей. Начните с названия. Найдите действительно хорошее название, которое отражает основную идею статьи. Вы можете пойти на юмористическое название или, возможно, более трезвое и описательное. В любом случае, оно должно отражать основную идею статьи. Будучи осторожным при разработке названия, вы заставляете себя думать о том, какие из бесконечного количества возможных идей для статьи вы на самом деле собираетесь реализовать. После того, как заголовок зафиксирован, займитесь аннотацией. Думайте о ней как о миниатюрной версии статьи. Используйте её для размышления об аргументации. Следующая остановка — введение. Здесь у вас есть немного больше места для описания статьи и ее контекста. Теперь вы готовы приступить к работе над разделами. Поскольку вы заставили себя задуматься о том, какую статью вы хотите написать, в отличие от всех других вариантов, у вас будет гораздо более четкое представление о том, чем наполнить разделы. Словом, научная статья должна, на мой взгляд, не обязательно рассматриваться как нечто выходящее из головы автора — она проектируется.

Ну, это вас спровоцировало? Надеюсь, что так, потому что я очень люблю провоцировать. К счастью, всё, конечно, немного сложнее. Любые аргументы, которые вы могли бы выдвинуть против моей позиции типа «всё это о написании статей с использованием нисходящего процесса просто невозможно, потому что невозможно обозреть все аспекты аргументации, и я мог бы стать мудрее в процессе написания и т.д., и т.п.» вполне обоснованы. Я совершенно согласен с тем, что люди не могут и не будут вести себя полностью рационально. Статьи не могут быть произведены полностью рациональным и нисходящим образом — но это не повод для того, чтобы не пытаться! Parnas и Clements (1986) написали статью об этом в области проектирования программного обеспечения. Они как-раз начинают, представляя исчерпывающий набор аргументов о том почему мы никогда не сможем рационально проектировать компьютерные системы. После чего они настаивают, что, в любом случае, к этому нужно стремиться. Название этой статьи: «Рациональный процесс проектирования: как и почему подделывать его» («A Rational Design Process: How and Why to Fake It»). Почему бы не подделывать рациональный процесс при написании статей? Стремитесь следовать нисходящему процессу и когда вы терпите неудачу, вы знаете, что все в порядке, потому что невозможно быть полностью рациональным. Если в середине написания статьи вы думаете о лучшем названии, то измените его. Не используйте в качестве аргумента, чтобы не думать о первоначальном варианте названия, риск того, что оно может быть изменено на более позднем этапе.

8. Шлифуйте упаковку и содержимое


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

То, как вы представляете результаты своих исследований, очень важно. Важно приложить усилия для шлифовки статьи, чтобы она была удобочитаемой. Аннотация Дональда Кнута к статье «Ошибки TeX» («The Errors of TeX») (см. рисунок 5) — очень хороший пример того, как в очень немногих и хорошо выбранных словах сформулировать аннотацию.

«Настоящая статья представляет собой тематическое исследование качественной оценки программы. Автор отслеживал все изменения, внесенные в TeX, в течение десяти лет, включая изменения, внесенные, когда программа была впервые отлажена в 1978 году. Журнал этих ошибок, насчитывающий более 850 элементов, приведен в приложении к данной статье. Ошибки были отнесены к пятнадцати категориям для целей анализа, и некоторые из примечательных ошибок рассматриваются детально. История проекта TeX может дать ценные уроки о подготовке хорошо портируемого программного обеспечения и сопровождении программ, стремящихся к высоким стандартам надежности.»

Рисунок 5. Аннотация к статье «Ошибки TeX» Кнута (Knuth, 1989).

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

Есть несколько источников, на которые следует обратить внимание, если вы хотите улучшить стиль своего письма. Weston (1991) написал очень хорошую книгу, которая настоятельно рекомендуется, о том, как выстроить аргументацию. Классика Strunk и White «Элементы стиля» (Strunk Jr. and White, 1979) и «Строка за строкой» Кука (Cook, 1985) обе являются ценными источниками знаний о том, как писать на английском языке. Книга Day (Day, 1991) обязательна для молодых исследователей, поскольку она дает короткие и точные предписания о том, как структурировать статьи.

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

9. Написание и рецензирование — две стороны одной монеты


Существует тесная взаимосвязь между написанием и рецензированием статьи, как утверждается в подзаголовке работы Gopen и Swan (1990): «Если читатель должен понять, что имел в виду писатель, писатель должен понять, что нужно читателю».

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

В рамки данной статьи не входит подробное описание процесса публикации: прочитайте, например, статьи Smith (1990) и Parberry (1990) для очень хороших введений, а также очень интересные дебаты в журнале «The Behavioral and Brain Sciences», начатые работой Peters & Ceci (1982), которая была прокомментирована в (BBS, 1982) и (BBS, 1985).

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

Заключение


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

  • Вам нужна уважительная причина для заявления своей позиции.
  • Не усложняйте, имея только одну идею на статью, и кладя вашу шею только на одну гильотину.
  • Основные вопросы, которые необходимо задать себе
    1. Какова проблемная область?
    2. В чем заключается проблема?
    3. Каков исследовательский подход?
    4. Что сделали другие? и
    5. Каковы результаты работы?
  • Подражательство может окупиться.
  • Заработайте свое право отклоняться от нормы.
  • Подделывайте нисходящий (top-down) процесс написания статьи.
  • Шлифуйте упаковку и содержимое.
  • Написание и рецензирование — две стороны одной монеты.

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

Задание


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

Онлайн ресурсы (чтобы было проще избежать библиотеки)


Strunk & White, The Elements of Style (full text)
Common Errors in English
A Handbook for Technical Writers
Grammar, Punctuation and Spelling
Guide to Grammar and Writing
Grammar Help
Guide to Grammar and Style
Ranking of IS Journals
Ranking of IS Journals
IS Journals
IS Journals

Благодарности тоже важны


Исследовательские сообщества — это слабосвязанные сети, основанные на высоких этических стандартах. Поэтому очень важно, чтобы признавался вклад в статью как в форме идей и предложений со стороны специалистов, так и в виде финансирования исследований. Надеюсь, поэтому, что я не забыл упомянуть кого-либо по ошибке! Длинные благодарности опущены. Все ошибки, просчеты и т.п. полностью на моей собственной ответственности. Это исследование частично спонсировалось Центром когнитивной информатики, финансируемым Датским советом технических исследований. Выражаю благодарность моему научному руководителю Lars Mathiassen за то, что он научил меня некоторым секретам мастерства (просто сообщите мне, если Вы хотите, чтобы Ваше имя было удалено после прочтения этих страниц). Спасибо Kristin Braa и Tone Bratteteig за приглашение обсудить эту тему на научном семинаре — это большой риск. Также выражаю благодарность John Venable за ценные предложения и за улучшение языка. Большое спасибо Henning Boje Andersen, Bo Dahlbom, John Paulin Hansen, Pertti Järvinen, Christian S. Jensen, Leif Løvborg, Lars Mathiassen, Kjeld Schmidt, Diane Sonnenwald, анонимному рецензенту IRIS и всем участникам семинара IRIS 17 за конструктивные комментарии и предложения. Курс для соискателей, проводимый Heinz K. Klein, по издательской игре и его панельная сессия на ICIS Doctoral Consortium, 1991 год, в Копенгагене, о представлении главного редактора, о том, как публиковать статьи, вдохновили меня на личную борьбу при написании статей. Все ошибки, просчеты и т.п. полностью на моей собственной ответственности.

Библиографические ссылки определяют контекст


Список источников
BBS (1982): Open Peer Commentary: Commentary on Peters & Ceci (1982): Journal review process. The Behavioral and Brain Sciences, vol. 5, no. 2, pp. 196–255.

BBS (1985): Continuing Commentary: Commentary on Douglas P. Peters & Stephen J. Ceci (1982): Peer-review of practices of psychological journals: The fate of published articles submitted again. The Behavioral and Brain Sciences, vol. 8, no. 4, pp. 743–750.

Beer, David F., ed. (1992): Writing & Speaking in the Technology Professions — A Practical Guide. New York: IEEE Press.

Benbasat, Izak, ed. (1989): The Information Systems Research Challenge: Experimental Research Methods, vol. 2. Boston Massachusetts: Harward Business School Research Colloquium Harward Business School.

Björk, L. A. & C. Räisänen (2003): Academic writing: A university writing course. Lund: Studentlitteratur.

Cash, James I. and Paul R. Lawrence, ed. (1989): The Information Systems research Challenge: Qualitative Research Methods, vol. 1. Boston Massachusetts: Harward Business School Research Colloquium Harward Business School.

Cook, Claire Kehrwald (1985): Line By Line — How to Improve Your Own Writing. Boston, USA: Modern Language Association.

Dahlbom, Bo and Lars Mathiassen (1993): Computers in Context — The Philosophy and Practice of Systems Design. Cambridge, Massachusetts: Blackwell Publishers.

Dahlbom, Bo and Lars Mathiassen (1994): The Future of Computing. In 17th Information systems Research seminar In Scandinavian at Syöte Conference Centre, Finland, August 6–9, Syöte, Finland, ed. Penti Kerola, Antti Juustila, and Janne Järvinen. Oulu University, vol. Vol. I, pp. 2–16.

Day, Robert A. (1977): How to Write a Scientific Paper. IEEE Transactions on Proffessional Communication, vol. PC-20, no. 1, pp. 32–37.

Day, Robert A. (1991): How to Write & Publish a Scientific Paper. Cambridge: Cambridge University Press.

DeMarco, Tom and Timothy Lister, ed. (1990): Software State-Of-The-Art: Selected Papers. New York: Dorset House Publishing.

Dunleavy, P. (2003): Authoring a PhD Thesis: How to Plan, Draft, Write and Finish a Doctoral Dissertation. Basingstoke, UK: Palgrave Macmillan.

Frankfurt, H. G. (2005): On Bullshit. Princeton University Press.

Fuller, S. (2005): The Intellectual. Icon Books.

Gopen, George D. and Judith A. Swan (1990): The Science of Scientific Writing — If the reader is to grasp what the writer means, the writer must understand what the reader needs. American Scientist, vol. 78, November-December, pp. 550–558.

Guralnik, David B., ed. (1970): Webster’s New World Dictionary of the American Language. Second College Edition. New York: The World Publishing Company.

Heckbert, Paul S. (1987): Ray Tracing Jell-O Brand Gelatin. Communications of the ACM, vol. 21, no. 4, pp. 73–74.

Henry, Tyson R., Andrey K. Yeatts, Scott E. Hudson, Brad A. Myers, and Steven Feiner (1993): A Nose Gesture Interface Device: Extending Virtual Realities. Presence, vol. 1, no. 2, pp. 258–261.
Holliday, A. (2001): Doing and Writing Qualitative Research. Sage.

Ives, Blake, Scott Hamilton, and Gordon B. Davis (1980): A Framework for research in Computer-Based Management Information Systems. Management Science, vol. 26, no. 6, pp. 910- 934.
King, S. (2000): On Writing: A Memoir of the Craft. London: New English Library.

Klein, Heinz K. (1989): The Prospectus and Dissertation Workplan in Information Systems Research. Manuscript. School of School of Management, SUNY Binghamton, NY 13902-6000: pp. 8 pages.
Kraemer, Kenneth L., ed. (1991): The Information Systems Research Challenge: Survey Research Methods, vol. 3. Boston Massachusetts: Harward Business School Research Colloquium. Harward Business School.

Krathwohl, David R. (1988): How to Prepare a Research Proposal — Guidelines for Funding and Dissertations in the Social and Behavioral Sciences. Third Edition, Syracuse, New York: Syracuse University Press.

Kuhn, Thomas S. (1969): The Structure of Scientific Revolutions, vol. 2. International Encyclopedia of Unified Science.

Lester, J. D. S. & J. D. J. Lester (2004): Writing Research Papers: A Complete Guide. Longman.
Mumford, Enid, Rudi Hirschheim, Guy Fitzgerald, and Trevor Wood-Harper, ed. (1985): Research Methods in Information Systems. Proceedings of the IFIP WG 8.2 Colloquium at Manchester Business School 1-3 September 1984. Amsterdam: North-Holland.

Naur, Peter (1992): Writing Reports — A Guide. In Computing: A Human Activity. New York: ACM Press, pp. 254–258.

Olk, P. & T. L. Griffith (2004): Creating and Disseminating Knowledge Among Organizational Scholars: The Role of Special Issues. Organization Science, vol. 15, no. 1, pp. 120-129.

Parberry, Ian (1990): A Guide for New Referees in Theoretical Computer Science. Unpublished manuscript Department of Computer Sciences, University of North Texas, P.O. Box 3886, Denton, TX 76203-3886, U.S.A.

Parnas, D. L. and P. C. Clements (1986): A Rational Design Process: How and Why to Fake it. IEEE Trans. Software Eng., vol. SE-12, no. 2, pp. 251-257.

Peters, Douglas P. and Stephen J. Ceci (1982): Peer-review practices of psychological journals: The fate of published articles, submitted again. The Behavioral and Brain Sciences, vol. 5, no. 2, pp. 187–195.

Phillips, E. M. & D. S. Pugh (2000): How to Get a PhD: A Handbook for Students and Their Supervisors. UK: Open University Press.

Pugh, William (1991): Advice to Authors of Extended Abstracts. Department of Computer Science and Institute for Advanced Computer Studies, University of Maryland, College Park.

Smith, Alan Jay (1990): The Task of the Referee. IEEE Computer, vol. 23, no. 4, pp. 65–71.

Snyder, Alan (1991): How to get Your paper Accepted at OOPSLA. In OOPSLA ‘91, pp. 359–363.

Sørensen, Carsten (1993): Introducing CASE Tools into Software Organizations. Ph.D. Dissertation Department of Mathematics and Computer Science, Aalborg University, [R-93- 2011].

Strunk Jr., William and E.B. White (1979): The Elements of Style. New York: Macmillan Publishing Co. Inc.

The Economist (2003): Style Guide: The Bestselling Guide to English Usage. London: The Economist.

Truss, L. (2003): Eats, Shoots & Leaves: The Zero Tolerance Approach to Punctuation. Profile Books.

Tufte, Edward R. (1983): The Visual Display of Quantitative Information. Cheshire, Connecticut: Graphics Press.

Tufte, Edward R. (1990): Envisioning Information. Cheshire, Connecticut: Graphics Press.

Wegman, Mark N. (1986): What it’s like to be a POPL Referee or How to write an extended abstract so that it is more likely to be accepted. SIGPLAN Notices, vol. 21, no. 5, pp. 91–95.

Weston, Anthony (1991): A Rulebook for Arguments. Indianapolis: Hackett Publishing Company.

Witten, Ian (1990): How to get a Research Grant. Research Report Department of Computer Science, The University of Calgary, [90/385/09].

Wynekoop, Judy L. and Sue A. Conger (1990): A Review of Computer-Aided Software Engineering Research Methods. In The Information Systems Research Arena of the 90’s: Challenges, Perceptions, and Alternative Approaches, Lund, Sweden, ed. H-E Nissen, H.K. Klein, and R. Hirschheim. IFIP TC 8 WG 8.2, vol. 1, pp. 129-154
ООО «ЦИТ» 45,95
ИКТ-решения и сервисы для органов власти и бизнеса
Поделиться публикацией
Комментарии 6
  • +8
    У вас пуля вместе с гильзой летит.
    • +1
      И верно.
      Спасибо за внимательность: )
      • +2
        это вторая ступень…
    • +2

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

      • 0
        У меня была обратная ситуация с научным руководителем. У него есть проекты типовых диссертаций, статей, моделей, определений и т.п. Достаточно просто привести материал к готовому шаблону и получишь текст диссертации и т.п.

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

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

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

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

      Самое читаемое