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

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

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

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

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

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

Применение wiki в разработке требований

В ряде исследований подтверждается, что малые и средние предприятия при разработке требований используют лишь несколько инструментов [3-5], главным образом общего характера, вроде наборов офисных приложений или Web-сайтов. В табл. 1 приведены краткие характеристики наиболее часто используемых инструментов.

Вместо этих инструментов мы используем wiki как базовую технологию разработки требований для программного проекта с участием самых разных заинтересованных лиц. Wiki характеризуют как техническое решение для совместного редактирования Web-страниц и одновременно как основообразующую методологию такого сотрудничества [2].

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

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

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

Организация общения

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

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

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

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

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

Разрешение конфликтов

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

Структура документов

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

Предлагаемая нами структура документов представлена на рис. 1. В качестве основы мы взяли минимальный набор документов из опубликованных примеров (в частности, шаблон сценария использования [6], шаблон документа из проекта Volere (www.volere.co.uk) и шаблоны требований из проекта ReadySET (readyset.tigris.org). Комплект документов получил дальнейшее развитие в ходе выполнения нескольких прикладных проектов. Документы связаны между собой типизированными ссылками.

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

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

Страницы «Пожелание заказчика» (User Story), «Актер» (Actor) и «Сценарий использования» (Use Case) помогают выявлять и документировать требования согласно соответствующим шаблонам. Использование этих шаблонов обеспечивает согласованность однотипных документов и связей между документами различных типов.

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

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

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

Эти документы служат отправной точкой для сбора требований. Модератор может расширить их структуру в соответствии с потребностями проекта. Подобная способность к расширению весьма желательна; например, в модели Кокберна Hub and Spoke [6] сценарии использования составляют лишь одну треть общего объема документации по требованиям. Wiki является платформой разработки документации общего назначения, однако расширения структуры документов могут отразить дополнительную информацию, такую как дизайн графического интерфейса, бизнес-правила и качественные требования. Вообще говоря, расширения могут быть двух типов: добавление разделов к существующему шаблону и добавление новых шаблонов в структуру документов. Например, участники могут формулировать проблемы производительности непосредственно в подразделе сценария использования или же отвести под эти проблемы отдельную страницу, на которую может ссылаться сценарий использования.

Опыт разработки приложений

Мы использовали наш wiki-подход как в промышленных, так и в академических проектах. Первым проектом, в ходе которого мы разработали и применили большую часть обсуждаемых здесь решений, была совместная с немецкими коллегами научно-исследовательская работа под названием RISE (Reuse in Software Engineering, rise-it.info). В проекте, продолжавшемся с 2003-го по 2005 год, участвовали 12 специалистов (исследователи, программисты и менеджеры) из пяти организаций. Технология wiki использовалась для выявления требований, разработки начальной архитектуры и распределения производственных заданий, основанных на этих требованиях. На стадии разработки требований были составлены описания пяти актеров и 20 высокоуровневых сценариев использования. Полноценность технологии wiki подтверждается тем, что два промышленных партнера проекта внедрили ее в разработку программного обеспечения в своих организациях и используют до сих пор.

Дальнейшее развитие наши идеи получили в другом проекте, где мы разрабатываем wiki-систему Software Organization Platform. Работа над проектом также велась по технологии wiki. Реализация SOP-Wiki базируется на бесплатном пакете программ MediaWiki (www.mediawiki.org), первоначально написанном для Wikipedia. В проекте SOP в настоящее время заняты три менеджера и восемь разработчиков. Он состоит из девяти подпроектов, в каждом из которых разрабатывается от пяти до десяти сценариев использования. Большинство участников присоединяются к SOP только на время разработки своего подпроекта. Сценарии использования служат важным средством коммуникации между разработчиками и руководством. Кроме того, в проекте SOP технология wiki применяется также для создания других артефактов программной инженерии, например руководящей документации.

SOP-Wiki в настоящее время используется в проекте BelAmi (Bilateral German-Hungarian Collaboration Project on Ambient Intelligent Systems, www.belami-project.org), нацеленном на развитие технологий «окружающего разума» (ambient intelligence). В нем насчитывается шесть подпроектов и 20 участников из четырех различных организаций. SOP-Wiki используется для документирования сценариев использования, интерфейсов и технических реализаций основообразующей сервис-ориентированной архитектуры.

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

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

wiki: проблемы и решения

Применение технологий wiki в реальных проектах поставило перед нами целый ряд проблем. Предлагаемые нами решения нашли отражение в SOP-Wiki.

Названия страниц

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

Контроль версий многостраничных документов

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

Рис. 2. Простановка ссылок. Кнопки справа предоставляют ссылки на экземпляр шаблона (документ), показанный в левой части экрана
Для преодоления этого неудобства мы создали два средства поддержки межстраничного контроля версий. Первое из них объединяет две функции: сборщик ссылок (link harvester) и замораживание (freeze). Сборщик ссылок на специальной странице создает список всех ссылок (в том числе из обзоров категорий). Затем эти ссылки размещаются на странице релиза и замораживаются, т.е. преобразуются в постоянные.

Второе средство, маркировка версии (version tagging), обеспечивает обзор, позволяющий назначить маркер версии выбранным страницам. Маркер версии указывает, что текущая версия страницы является официальной или одобренной. Маркировка версии позволяет выбрать подмножество страниц, группируя страницы по категориям. Wiki уведомляет пользователей об изменении официальных версий. Кроме того, обзор страниц, относящихся к маркеру версии, содержит ссылки как на текущие версии страниц, так и на их версии в момент установки маркера. Для поддержки нескольких зафиксированных наборов требований пользователь может связать версию страницы с несколькими маркерами версий.

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

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

Реструктуризация контента

Большинство wiki-систем поддерживает структуризацию страниц только по категориям или по префиксам, например, по пространствам имен. Другими словами, они не могут отразить метаданные или реляционную семантику. Однако пользователь нуждается в этой дополнительной информации, чтобы полностью понять отношения между требованиями. Дополнить страницы такой информацией позволяют семантические wiki-системы. В рамках SOP-Wiki мы используем семантическое расширение для MediaWiki (ontoworld.org/wiki/Semantic_MediaWiki). Это расширение позволяет наделять страницы свойствами и определять типизированные ссылки между страницами. Мы используем такую возможность для выражения отношения между документом и шаблоном («экземпляр») или между двумя документами, например в отношении «уточнения» между неформальным и формальным сценариями использования на рис. 1.

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

Классификация страниц

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

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

Репликация контента

Отсутствие возможности репликации wiki-контента может привести к проблемам в случаях, когда участники проекта должны время от времени работать автономно. FlexWiki (www.flexwiki.org) имеет функцию репликации, но при ее использовании мы увидели недостатки в поддержке ссылок.

Табл. 2 является продолжением табл. 1, в ней перечислены все «за» и «против» систем, основанных на технологии wiki. Используя свой положительный опыт разработки приложений, мы планируем создать собственную wiki-систему для коллективной разработки требований. Одним из направлений будет подробное исследование круга ее потенциальных пользователей. Мы также планируем сравнить качество требований, разработанных традиционным путем и по технологии wiki, например, в отношении законченности спецификаций. Для поддержки этих исследований следующие шаги в проекте SOP будут направлены на выявление несогласованностей в требованиях, например, актеров, которые не используются ни в одном из документов. Это напоминает обычную проверку целостности — скажем, наличие страниц-«сирот», уже имеющуюся в wiki-системах. В долгосрочной перспективе мы собираемся использовать семантическую информацию для поэтапного связывания и формализации требований.

ЛИТЕРАТУРА

  1. K. El Emam, S. Quintin, N.H. Madhavji, User Participation in the Requirements Engineering Process: An Empirical Study. Requirements Eng., vol. 1, no. 1, 1996.
  2. P. Louridas, Using Wikis in Software Development. IEEE Software, vol. 23, no. 2, 2006.
  3. U. Nikula, J. Sajaniemi, H. Kalviainen, A State-of-the-Practice Survey on Requirements Engineering in Small- and Medium-Sized Enterprises. Research report, Telecom Business Research Center Lappeenranta, 2000.
  4. H.F. Hofmann, F. Lehner, Requirements Engineering as a Success Factor in Software Projects. IEEE Software, vol. 18, no. 4, 2001.
  5. J. Rech, B. Decker, E. Ras, Intelligente Assistenz in der Softwareentwicklung 2006: Zusammenfassung der Ergebnisse [Intelligent Assistance in Software Development 2006: Summary of Results], Kaiserslautern IESE tech. report IESE-045.06/D, 2006 (in German).
  6. A. Cockburn, Writing Effective Use Cases. 1st ed., Addison-Wesley Longman, 2000.

Бьорн Декер (bjoern.decker@iese.fraunhofer.de), Эрик Рас (eric.ras@iese.fraunhofer.de), Йорг Рек (joerg.rech@iese.fraunhofer.de), Паскаль Жобер (pascal.jaubert@iese.fraunhofer.de), Марко Райт (marco.rieth@iese.fraunhofer.de) — сотрудники Института экспериментальных технологий программного обеспечения в Кайзерслаутерне (Германия).

Bjorn Decker, Eric Ras, Jorg Rech, Pascal Jaubert, Marco Rieth. Wiki-Based Stakeholder Participation in Requirements Engineering. IEEE Software, March/April 2007. IEEE Computer Society, 2007. All rights reserved. Reprinted with permission.