Какое хорошее решение для сбора документации по бизнес-правилам?

Ответ 1

+ 10⁶ для Wiki, это лучшее решение, которое я нашел до сих пор для документации, особенно технической документации. IMO, преимущества "хороших" движков Wiki над документами Office в VCS (но вы уже знаете об этом, так как список этих функций очень близок вашим требованиям):

• они просто быстрее и проще в использовании, чем документы Office в VCS (нет необходимости открывать клиент VCS, проверять последнюю версию, дополнительно блокировать ее, открывать слово, сохранять, регистрировать, освобождать блокировку)
• они основаны на тексте, поэтому вы делаете diff (в отличие от слова), и это просто должно быть
• они предлагают механизмы уведомления (например, почту, RSS), и поэтому информация передается вам (в отличие от VCS, где вам нужно вытягивать документ, когда они устарели)
• нет "документа, заблокированного другой проблемой пользователя", потому что кто-то забыл его освободить (если вы используете эксклюзивную блокировку, которая часто применяется к документам, которые вы не можете объединить)
• страницы могут быть легко реорганизованы, реорганизованы, собраны в больших документах.
• они действительно совместимы
• они обеспечивают гораздо лучшую поддержку кода (например, вы можете прямо указывать исходный код в VCS с гораздо лучшим форматированием, чем на слово)
• они могут индексировать содержимое страниц и прилагаемых документов (pdf, офисные документы и т.д.) и сделать их доступными для поиска.

Единственная проблема, с которой я столкнулся при использовании Wiki для документации, - это то, что вам сложнее выполнить версию документации одновременно с вашим кодом (т.е. вы доставляете версию x.y.z и хотите "заблокировать" документацию этой версии). Я использовал экспорт, чтобы решить эту проблему, но это не идеально.

Я уже работал с TWiki Foswiki, Confluence и XWiki. Все они "хорошие" Wiki-движки (как указано выше) и все отвечают вашим требованиям. Таким образом, окончательный выбор может зависеть только от ваших ограничений (лицензия, ценообразование, технология) и личных предпочтений.

На сегодняшний день я бы выбрал Confluence, если коммерческий инструмент является опцией, XWiki, если нет.

Ответ 2

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

Ответ 3

Я разрабатываю один.

Примерно год назад я искал программное обеспечение для управления требованиями в сети и нашел не менее 30 из них примерно в 3 категориях:

• Бесценный (и продаваемый, например, в аэрокосмических компаниях)

• Дорого (например, 1000 долларов за место), которые мои работодатели никогда не выбрали для использования

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

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

Я думаю, вы должны уточнить: "Отсутствуют функции, которые мне кажутся важными".

Есть вещи, которые вы можете сделать с помощью универсальной Wiki:

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

Но есть некоторые вещи, которые, я думаю, вы не можете сделать с Wiki общего назначения, даже довольно простые вещи:

• Определить пользовательские атрибуты (например, "Дата начала", "Ориентировочная стоимость" и т.д.); свяжите эти значения атрибутов с вашими функциями; (в таблице или сетке) с их атрибутами (чтобы их можно сортировать, например, сортировать по "Важность" или "Трудности" )

• Помощь в отслеживании (прослеживаемость не слишком сложна, если есть только два этапа, например, "требования" и "реализация", но это сложнее, если есть несколько этапов, например "варианты использования", "функциональная спецификация", "архитектура", "подробности реализации", "тестовые примеры", "результаты теста" и "отчеты об ошибках" )

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

Даже просто редактирование не так хорошо, как должно быть. Деловые люди могут предпочесть использовать интерфейс MS Word для редактирования: но MS Word создает документы, то есть "информационные силосы"; но если вы не используете MS Word, то вы используете что? WYSIWYG в браузере? Или синтаксис уценки?

Ответ 4

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

Ответ 5

Drupal соответствует вашим перечисленным требованиям, он очень расширяемый с множеством модулей (см. ниже) и доступен под GPL.

• Редактор Wysiwig
• Diff view
• Subscriptions
• Управление доступом пользователей
• Управление вложениями
• Может быть настроено с помощью функций Wiki

Ответ 6

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

• Легко обновляется: да
• Diff view: доступна полная история изменений
• Подписываемое: да, есть идея "контрольных списков"
• Роль: да, многофункциональная модель безопасности
• Вложения: да, каждое правило может иметь собственные вложения
• Поиск: есть полнотекстовый поиск
• Ограничение вложений: hmm - не уверен в этом и точно, что вы пытаетесь сделать.

Некоторые советы, если вы решите пойти по этому пути...

• Использовать индивидуальный идентификатор JIRA в другом месте для ссылки на правило, например. MYPRJ-334
• У вас есть четкие рекомендации относительно того, какие состояния, которые вы планируете использовать, означают, предлагать, утверждать, реализовывать, проверять, удалять.
• Единственное определение правила в описании - все комментарии - это просто комментарии
• Вы можете связать Правило, чтобы использовать случаи, компоненты как бы

Это отличный подход, и я действительно рекомендую его.