Форум Сообщества Аналитиков
Дисциплины => Системный Анализ и Требования => Тема начата: Denis Beskov от 11 Мая 2007, 16:12:00
-
Отличный материал в Открытых системах:
Wiki в коллективной разработке требований (http://www.osp.ru/os/2007/03/4177763/)
От себя могу сказать, что технология действительно обкатанная и эффективная, даже учитывая то, что мы не слишком строго организовывыали рабочее пространство и результирующий документ собирали руками.
-
Я бы не спешил с восторженными оценками применимости Wiki в разработке требований.
Это удобно, если аналитики требований удалены друг от друга.
Но при этом на пвервое место вылазит вопрос безопасности...
Если разворачивать wiki локально - то смысл ее теряется в значительной мере - специалистам проще собраться и поговорить.
Кроме того, в малых и средних фирмах будут ли специалисты, обесчивающие поддержку wiki внутри сети, решать все проблемы с ней.
Крупной фирме проще будет купить doors, caliberRm, requisitePro - в которых также есть коллективные обсуждения требований, но при этом они лишены обозначенных в статье недостатков.
Мне кажется, что проблема инструментария - вторична, по сравнению с опытом и компетенцией аналитика, его работой с заказчиком. Я бы не стал повсеместно пропагандировать wiki к применению. wiki, на мой взгляд, будет востребована при разработке ПО с открытым кодом, когда сроки не стоят жестко.
-
Но при этом на пвервое место вылазит вопрос безопасности...
Не в большей степени, чем у любой другой онлайновой системы.
Если разворачивать wiki локально - то смысл ее теряется в значительной мере - специалистам проще собраться и поговорить.
Ты не прав. Собраться и поговорить - это одно. Создавать проектную дкоументцаию - это постоянный процесс.
Кроме того, в малых и средних фирмах будут ли специалисты, обесчивающие поддержку wiki внутри сети, решать все проблемы с ней.
А какие с ней проблемы? Поставил и пользуйся. И то, я не вижу смысла ставить локально вики в малых компаниях, если нет задачи интеграции и модификации. Во-вторых, плох тот аналитик, который не может поставить вики :)
Крупной фирме проще будет купить doors, caliberRm, requisitePro - в которых также есть коллективные обсуждения требований, но при этом они лишены обозначенных в статье недостатков.
Саша, ты в крупной фирме работаешь? Почему тебя вообще крупные фирмы волнуют?
Посчитай, какое количество проектов, связанных с требованиями делается в мире/России, и какую долю из них составляют проекты больших компаний. У НИХ И ТАК ВСЁ НОРМАЛЬНО. ИЛИ НЕНОРМАЛЬНО, НО НИКОМУ ДО ЭТОГО НЕТ ДЕЛА.
Вот я сейчас вроде как в крупной, и ПО мы себе КАЗАЛОСЬ БЫ купить/поставить можем, и регламенты написаны - а процесс не внедрён, ан нет - если пересчитать потребное кол-во лицензий, получается немалая сумма, каждого надо обучать программе и т.д. и т.п. И на реальном проекте я использовал MediaWiki, и для локальных нужд мы купили и поставили Confluence (а не имеющийся SharePoint) - но уже не для УТ, а в качестве основы системы накопления знания. Потому что это - работает.
Мне кажется, что проблема инструментария - вторична, по сравнению с опытом и компетенцией аналитика, его работой с заказчиком.
Инструментарий влияет на качество процесса. К тому же такого процесса, как коммуникация, которая очень важна для УТ.
Я бы не стал повсеместно пропагандировать wiki к применению. wiki, на мой взгляд, будет востребована при разработке ПО с открытым кодом, когда сроки не стоят жестко.
Саша, я использовал и использовую wiki на реальных проектах. Мне 50-летний бизнес-аналитик сказал, что это удобно - что он смог сесть на выходных и вне этих корпоративных будничных запар спокойно и тихо расписать всё в онлайне. Причём тут сроки?
-
Не в большей степени, чем у любой другой онлайновой системы.
Клиентам понравится, если разработка ТЗ их информационной системы будет вестись он-лайн. Думаю, будет довольно трудно убедить их в безопасности. Вместе с тем, понимаю, что вопрос спорный - клиенты не стесняются посылать нешифрованные письма с тем же ТЗ.
Ты не прав. Собраться и поговорить - это одно. Создавать проектную дкоументцаию - это постоянный процесс.
Достаточно спорно. Все от команды зависит. Кому то комфортно общаться через интернет, кому-то удобнее общаться в реале.
А какие с ней проблемы? Поставил и пользуйся.
И то, я не вижу смысла ставить локально вики в малых компаниях, если нет задачи интеграции и модификации. Во-вторых, плох тот аналитик, который не может поставить вики :)
Я - плохой аналитик. Я не умею ставить wiki. CaliberRM, RequsitePro - поставлю :). Я не уверен, что ясмогу обеспечить безопасность документации. Можно ли запретить на wiki просмотр незарегистрированным пользователям и централизовать регистрацию? Или это делается другими способами. Как делал ты в своих проектах?
Саша, ты в крупной фирме работаешь? Почему тебя вообще крупные фирмы волнуют?
Посчитай, какое количество проектов, связанных с требованиями делается в мире/России, и какую долю из них составляют проекты больших компаний. У НИХ И ТАК ВСЁ НОРМАЛЬНО. ИЛИ НЕНОРМАЛЬНО, НО НИКОМУ ДО ЭТОГО НЕТ ДЕЛА.
Вот я сейчас вроде как в крупной, и ПО мы себе КАЗАЛОСЬ БЫ купить/поставить можем, и регламенты написаны - а процесс не внедрён, ан нет - если пересчитать потребное кол-во лицензий, получается немалая сумма, каждого надо обучать программе и т.д. и т.п. И на реальном проекте я использовал MediaWiki, и для локальных нужд мы купили и поставили Confluence (а не имеющийся SharePoint) - но уже не для УТ, а в качестве основы системы накопления знания. Потому что это - работает.
Сегодня в некрупной, завтра в крупной.
Я пытаюсь обсмыслить преимущества wiki. Мы же обсуждаем применимость ее в разных проектах. Заставить работать можно все что угодно. Для этого необходима воля руководства и желание сотрудников.
Инструментарий влияет на качество процесса. К тому же такого процесса, как коммуникация, которая очень важна для УТ.
Не сомневаюсь. Но написать хорошие требования можно карандашом в блокноте. Инструменты - они лишь облегчают жизнь. Не стоит под инструменты пытаться подстраивать бизнес-процессы.
Саша, я использовал и использовую wiki на реальных проектах. Мне 50-летний бизнес-аналитик сказал, что это удобно - что он смог сесть на выходных и вне этих корпоративных будничных запар спокойно и тихо расписать всё в онлайне. Причём тут сроки?
Может быть проблема в том, что у аналитика нет возможности расписать это в рабочее время? в спокойной обстановке?
Возможно, в такой обстановке wiki - нормальный выход.
Но с клиентами тоже удалось в выходные пообщаться? Мне не удавалось, они изволят отдыхать.
Повторюсь - я не имею реального опыта в применении wiki для управления требованиями, все мои высказывания носят характер "не пробовавшего устриц"
-
Если честно - очень хочу попробовать.
Денис, если не трудно, расскажи, как технически все организовали?
-
Я - плохой аналитик. Я не умею ставить wiki. CaliberRM, RequsitePro - поставлю :).
Хм, значит я хороший аналитик? Я умею ставить wiki, да чего его не поставить? Ставим Apache 2.x, PHP 5.x.x, mysql 4.x, качаем дистриб mediawiki и ставим его по инструкции. Или можно обойтись например dokuwiki там запросы скромнее и даже mysql ненужно.
А вот CaliberRM ставить не умею, ну не ставится он у меня, зараза! А вот DOORS поставился с полпинка.
Другой вопрос - как настроить все это хозяйство? Какая должна быть структура? И т.п.
Вот здесь - мы как сообщество, можем разработать механизм и технологию настройки и внедрения, и предложить для использования. Как вы думаете, коллеги?
-
Я думаю - можно в отдельной ветке.
"Техническая организация управления требованиями"
Создадим?
-
Я думаю - можно в отдельной ветке.
"Техническая организация управления требованиями"
Создадим?
why not?
-
Достаточно спорно. Все от команды зависит. Кому то комфортно общаться через интернет, кому-то удобнее общаться в реале.
Саша, если у людей есть возможность общаться в реале и они общаются в реале, например в режиме "парного анализа", то какая нафиг разница, что у них там на экране открыто в режиме редактирования - MS Word/OpenOffice или браузер? Просто большинство вики лишено избыточного синтаксиса и автоматически поддерживает версионность.Я - плохой аналитик. Я не умею ставить wiki.
Я сказал - "не может", а не "не умеет" ) Ты попробуй.
Можно ли запретить на wiki просмотр незарегистрированным пользователям и централизовать регистрацию? Или это делается другими способами. Как делал ты в своих проектах?
Хорошо, буду нудить. Большинство вики-систем являются открытыми системами. Открытая система - это значит, что её код доступен и его можно расширять. Для открытых систем обычно есть возможность написать модуль, плагин, патч и т.д. У популярных открытых систем обычно есть много полезных плагинов. Если плагин настолько полезен, что нужен почти всем, он попадает в ядро очередной версии системы. Поскольку, например, MediaWiki создавалась для Википедии, которая предполагает полную открытость контента, то там нем очевидного удобного разграничения прав доступа. Но тем не менее, в базовой поставке есть возможность ограничить видимость через конфигурационные файлы.
Если ты будешь пользоваться готовыми hosted-сервисами, такими, как, например, Zoho Wiki, то там разграничение доступа - естественная и удобная функция системы.
Подобрать вики-систему для установки у себя можно на WikiMatrix.org (http://wikimatrix.org)
Заставить работать можно все что угодно. Для этого необходима воля руководства и желание сотрудников.
Когда я говорил "это - работает", я имел в виду не физическую осуществимость, а естественность процесса, который не надо удерживать в рамках никакими регламентами и руководством.
Не стоит под инструменты пытаться подстраивать бизнес-процессы.
А кто пытался?
Но с клиентами тоже удалось в выходные пообщаться?
Смотря какими. Представителям крупного бизнеса всё до фени. Мелкий и средний вполне общается, если система для них критична и время есть.
-
А вы в своей работе какую Wiki используете? Я так понимаю в основном используют MediaWiki.
-
Мы то же начали использовать в своей работе Wiki. Перед тем как его применять общался с Юрием Булуй и поняли, что можно использовать, но с ограничениями. Кстати, Luxoft на основе Confluence (Wiki) и Jira (issue tracker) сделали свое решение по управлению требованиями (RMS) и задачами.
В принципе инструмент подходящий, но имеет ряд недостатков по сравнению с традиционными инструментами управления требованиями (кроме тех, которые есть в статье):
1. Не возможность добавления атрибут к страницам, если отдельную страницу считать за требовние.
Частично решается за счет создания шаблона, в котором будут определены внутри страницы строчки, отвечающие за эти параметры.
2. Не возможность генерации цельного документа на основе написанных требований в ВИКИ
Возможно решить за счет написания плагина
3. Слабая структурированность требований. Например, если мы добавляем некое требование и оно должно быть вставлено, как номер 5 среди уже неаписаных 10 требований, то автоматическаянумерация не произойдет
Пока не понял как решить, кроме переименования всех страниц в ручную.
4. Нет возможно сказать, что это финальная версия требования или подтвержденная руководством.
Частично решается с помощью добавления в заголовок слова approved или добавления соответсвующей строчки в страничку
Мы пробовали использовать две Wiki - Confluence и TWiki. Остановились на TWiki, т.к. не договрились о цене с Confluence на 100 пользователей (на 50 было мыло, а на 500 много и дорого). TWiki мне понравилась меньше по юзебилити: сложно создавать странички и привязывать их к родительской, не возможнсть просмотра заголовков страниц в виде иерархий, убогие комментарии и т.д.
В понедельник выложу иерархию требований, которые я (с одобрением Юрия) создал в Confluence.
-
кстати, тоже тема для семинара или статьи
-
3. Слабая структурированность требований. Например, если мы добавляем некое требование и оно должно быть вставлено, как номер 5 среди уже написаных 10 требований, то автоматическая нумерация не произойдет
Пока не понял как решить, кроме переименования всех страниц в ручную.
Не понял, ты номера требованиям вручную что-ли задаёшь? Зачем?
-
Не понял, ты номера требованиям вручную что-ли задаёшь? Зачем?
Не обязательно требований (хотя иногда нужно и это), можно целей или просто структуры. Я имел в виду, что если я хочу чтобы некие страницы шли друг за другом, а потом вставить что-то в середину,то, например, Confluence это не получиться.
-
Кстати, а смотрели TrackStudio (http://www.trackstudio.ru) для целей управления требованиями (хотя вообще-то это навернутый issue tracker) ? С доп. атрибутами и структурированностью проблем нет, никакой интеграцией заниматься не надо, цена более чем демократичная.
-
TrackStudio - интересная штучшка, во всяком случае по описанию более чем.
Но опять же: Как на счет генерации документации??
-
Вот как и обещал иерархия требований.
Надо еще добавить раздел: Functional Requirements
-
TrackStudio - интересная штучшка, во всяком случае по описанию более чем.
Но опять же: Как на счет генерации документации??
Там есть Detailed report, есть экспорт в XML/MS Project. Думаю, из всего этого что-нибудь можно смудрить. По крайней мере я видел очень симпатичные отчеты на основе обработки этим XML-ек через XSLT.
-
Я бы еще разделил на Пользовательские требовния и Функциональные .. по классике ;-)
-
Ну, я тоже этим баловалась, и могу сказать следующее: там, где не нужно общего доступа к отдельным файлам, хранимым в репозитории (модели, документы, требования) - wiki вполне применима.
Но в условиях часто изменяемых требований и большого объема проектной документации (+ состыковка нескольких аналитиков, создающих модели, между собой) - не самая удобная вещь.
Оптимальным лично мне кажется другой вариант: wiki - как инструмент первичного ("быстрого") сбора требований от заказчика, и дальнейшее использование уже более-менее привычной системы, предназначенной для управления требованиями.
Кстати, преимущество wiki - только возможность доступа к ней отовсюду. А вот что касается управления контентом в ней, прав доступа, многоязычности и т.д. - здесь у wiki скорее проблемы, чем преимущества.
-
Ну, я тоже этим баловалась, и могу сказать следующее: там, где не нужно общего доступа к отдельным файлам, хранимым в репозитории (модели, документы, требования) - wiki вполне применима.
Но в условиях часто изменяемых требований и большого объема проектной документации (+ состыковка нескольких аналитиков, создающих модели, между собой) - не самая удобная вещь.
Так все прямо в Вики и надо писать, а не в виде вордовых файлов выкладывать. Тогда все проблемы уходят. остаётся только одновременное изменение моделей. Но тут наверное можно прикрутить SVN какой нить.
Кстати, преимущество wiki - только возможность доступа к ней отовсюду. А вот что касается управления контентом в ней, прав доступа, многоязычности и т.д. - здесь у wiki скорее проблемы, чем преимущества.
Преимущество здесь одно - цена. Т.к. многие системы УТ имеют веб интерфейс. А все перечисленные проблемы в Вики решаемы.
-
... многие системы УТ имеют веб интерфейс....
Разве? Например?
-
Разве? Например?
Requsite, DOORS/Net точно имеют, а про Caliber точнее скажет Юра.
-
CaliberRM имеет вэб-интерфейс. Есть одна проблема -- у всех систем-лидеров RDM вэб-интерфейс почему-то как "нелюбимый ребенок" ... его функциональность и удобство использования оставляет желать лучшего.
-
CaliberRM имеет вэб-интерфейс. Есть одна проблема -- у всех систем-либеров RDM вэб-интерфейс почему-то как "нелюбимый ребенок" ... его функциональность и удобство использования оставляет желать лучшего.
Ну не "почему-то", а вполне понятно - под веб нужны другие проектировщики с другими мозгами, а на вторую команду денег нет.
-
Так все прямо в Вики и надо писать, а не в виде вордовых файлов выкладывать. Тогда все проблемы уходят. остаётся только одновременное изменение моделей. Но тут наверное можно прикрутить SVN какой нить
Да мы, в общем, так и сделали в конце концов - я же говорю: для того, для чего wiki можно использовать, она использовалась.
Но у wiki (в отличие от Requisite Pro + SoDa) есть один недостаток: эта система не выгружает текст, который вбит в нее, в документ Word (и потому Вам придется либо руками переносить все в Word, либо исхитряться скрестить Wiki и DocBook какой-нибудь, когда заказчик у Вас потребует все-таки какой-нибудь отчетик ему настрочить и документик в красивой синей папочке (Blue Book - для тех, кто понимает) на стол положить.
Вот тогда будет сложно, конечно. До тех пор - все ништяк.
А все перечисленные проблемы в Вики решаемы.
Да, решаемы. Я знаю. Но - трудоемко. Если деньги, уплоченные мне за все то время, которое я буду тратить на решение этих проблем, пустить на цели приобретения софта, боюсь, что мы наскребем на лицензию Rational Software :-)
-
Если деньги, уплоченные мне за все то время, которое я буду тратить на решение этих проблем, пустить на цели приобретения софта, боюсь, что мы наскребем на лицензию Rational Software :-)
MS Word стоит дешвеле :-), его и пользовать для целей создания ДОКУМЕНТАЦИИ требований.
-
MS Word стоит дешвеле :-), его и пользовать для целей создания ДОКУМЕНТАЦИИ требований.
Если говорить серьезно, то есть "примочка" к MS Word у Sybase, она входит в пакет Sybase Power Designer. Там есть макросы специальные для Word, они позволяют помечать требования как требования и даже связывать их с определенными элементами модели. Это не полоноценное управление требованиями, конечно, но уже почти Borland-овского уровня продукт (ну и цели, наверное, тоже общие: RAD - он порождает некий общий концепт, однако).
-
2 Наталья Желнова
Ну у Вики я вижу одну большую проблему - генерация документа. Но никто этим не занимался, плагин я думаю написать недолго.
Все остальное решаемо без больших трудозатрат:
1. Трассирока - шаблон или в Confluence есть ссылки прям
2. Атрибуты - шаблон
3. Права - есть во многих Вики
4. Что еще??
-
Если говорить серьезно, то есть "примочка" к MS Word у Sybase, она входит в пакет Sybase Power Designer. Там есть макросы специальные для Word, они позволяют помечать требования как требования и даже связывать их с определенными элементами модели. Это не полоноценное управление требованиями, конечно, но уже почти Borland-овского уровня продукт (ну и цели, наверное, тоже общие: RAD - он порождает некий общий концепт, однако).
Ну до Borland CaliberRM, (а так же DOORS и ReqPro) по функциональности он не дотягивает явно. Requirements там скорее как опиция, а основные фичи -- это проектирование.
-
А у нас MediaWiki в качестве средства для управления требованиями не прижилась. Специализированные не-web-based средства удобнее. Даже "плоские" пользовательские истории количеством больше десятка хранить уже неудобно, вперемешку со специфическими тегами форматирования, а от вбивания в wiki оценок оставшихся/сделанных единиц по этим историям люди отказались на третий день :) .
-
Кто просил полное описание возможностей системы Confluence прошу сюда
http://dkvartal.ru/eldar/35506.
В посте описание основных возможностей Confluence + краткая инструкция для пользователей с иллюстрациями.
-
Похоже нашел как из Confluence экспортировать дерево/иерархию требований в один документ (ТЗ или SRS):
http://confluence.atlassian.com/display/DOC/Confluence+to+PDF
-
Насколько я понял, основное преимущество wiki - возможность удалённого участия в разработке требований, которые при этом автоматически документируются. Это замечательно, если заказчики и прочие заинтересованные лица готовы к такому сотрудничеству.
Для каскадной разработки, если есть длинный этап сбора требований, завершаемый выходом ТЗ "на скрижалях", всё просто замечательно.
Но даёт ли этот подход какие-то преимущества на этапах, следующих за сбором и уточнением требований? Что получается на выходе, кроме красиво отформатированного документа в пресловутой blue book? При итерационной разработке интересует, в первую очередь, распределение требований по этапам, отслеживание их статуса в процессе разработки, соответствие тестов требованиям (не обязательно матрица трассировки, но хотя бы лекго управляемые списки связей) и т. п.
Есть ли в wiki механизмы, позволяющие всё это реализовать? Если нет, то, скорее всего, придётся предусматривать экспорт требований в другие системы. Что сильно усложняет работу.
-
Но даёт ли этот подход какие-то преимущества на этапах, следующих за сбором и уточнением требований?
Что получается на выходе, кроме красиво отформатированного документа в пресловутой blue book?
Так оно как раз и заменят СУТ (систему управления требованиями). Веб - это не самоцель.
распределение требований по этапам,
Не совсем понял что это?? Приоретаризация?? Пожалуйста, линкуйте требования со страницей приоритета или делайте шаблон, в кот. будет указан приоритет прям внутри страницы - поиск вам их вловит
отслеживание их статуса в процессе разработки,
Шаблон страницы, к сожалению с правами выставления этого статуса уже сложнее, но если аналитики не злыдни то все ок, да и историю изменений всегда можно просмотреть
соответствие тестов требованиям (не обязательно матрица трассировки, но хотя бы лекго управляемые списки связей)
Линки или теги можно ставить - вот вам и матрица. Многие Вики позволяют выловить трассируемые объекты
и т. п.
Что еще интересует??
Немного плоховато с моделями, но можно прикрутить какой-нить СВН и это должно решиться.
-
Подытожим:
Основные Wiki-кандидаты на СУТ:
1. Confluence
2. Twiki
3. MediaWiki
4. DekiWiki
Основные Wiki-подобные кандидаты на СУТ:
1. Jira (приплетем ее сюда)
2. TrackStudio (приплетем ее сюда)
3. NPJ
-
Хм, может давайте определим ключевые требования к СУТ и тогда кандидаты будут понятны сами собой по wikimatrix.org?
-
Требования к СУТ:
http://www.nat.naumen.ru/new/Main/OpenResearch/RequirementsManagement
-
Вот был интерсный доклад на СЕКР от Стаса:
http://lib.custis.ru/index.php/%D0%98%D0%BD%D1%82%D0%B5%D0%B3%D1%80%D0%B0%D1%86%D0%B8%D1%8F_Open_Source-%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC_%D0%B4%D0%BB%D1%8F_%D1%83%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F_%D1%80%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%BE%D0%B9_%D0%9F%D0%9E
Здесь тоже можно высказывать свои мысли и замечания по этому поводу