dovesokХотелось бы перевести процесс разработки в более-менее стандартное русло. Для этого внедрить несколько программ:<...>
На текущий момент ничего этого нет.
По каждой отдельно системе я почитал, вопрос в том, чтобы они были максимально интегрированы между собой и по возможности бесплатны! Хотя платные варианты тоже рассматриваю.

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

SVN - отлично. Bugzilla работает отлично, Trac не видел. Wiki работает. OpenProj работает, но мне больше нравится легковесный процесс и XPlanner. Требованиями можно управлять при помощи той же wiki, ну или Calc, и не верьте продавцам, которые скажут, что без автоматической трассировки невозможно всего со всем нельзя стать успешным.

В Enterprise Architect есть всё, кроме SVN, но я видел, как его применяли только для требований, UC и моделей.

И ещё раз: инструментами пользуются люди. Они должны работать согласованно, должны быть обучены и мотивированы. А серебряных пуль не бывает.

Big17<...>
Не совсем согласен с тем, что сначала нужно ставить процессы, а затем внедрять ПО. Например, управление конфигурациями и изменениями удобнее ставить сразу с соответствующим ПО.
<...>
Согласен, что SVN, Bugzilla и какую-нибудь wiki удобнее разворачивать сразу же, хотя без регламентов использования и производственной дисциплины они мало чего стоят.
Для всего остального можно использовать офисные приложения, до тех пор, пока не сложится отчётливого понимания, что они стали "малы".

byur<...>
побаловаться и wiki, хотя я бы предложил использовать обычный Word <...>
1) Что может Word, чего не может wiki?
2) По моему опыту работы, документы в wiki воспринимается программистами и тестировщиками значительно проще, а принятые решения исполняются, а не считаются спущенной сверху бюрократией; возможно, причина в том, что эти документы - живые, их можно обсуждать и улучшать
3) Если честно, обсуждения и правки в пересылаемом по почте документе word - это просто неудобно: необходимо сильнее переключать контекст, неудобно писать, трудно версионировать и консолидировать.

byur<...>
но при иметь утвержденный шаблон документа для описания требований<...>

IMHO важнее регламент, причём простой и естественный, т.к. иначе программисты - homo logicus, имеющие мало общего с обычными homo sapiens - просто на него забьют.
Строгость формата и его искусственные "навороты" мешают передавать смысл.

byur<...>
Если же у вас проект большой и есть строгие формальные требования от заказчика по формату документов, и при этом ТЗ не просто отписка а по ней реально проходит приемка софта. И это все усугубляется частыми изменениями требований ... то использование wiki и просто Word становиться просто достаточно наклАдным.
В этом случае имеет смысл посмотреть в сторону специализированного инструментария типа DOORS, или CaliberRM. RequisitePro не советую рассматривать, как минимум в свете приобретения IBM-ом компании Telelogic.
К сожалению, зачастую в этом случае требования начинают жить своей жизнью, работать с ними могут только разбирающиеся в навороченном средстве и структуре требований люди. Которые сильно удивляются, видя, что их картина мира драматически отличается от ПО, выходящего из отдела разработки.

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

Чисто технической проблемой может стать то, что далеко не все люди используют MS Windows, и их всё меньше. Между тем,
"The DOORS 9.0 Client runs on:
* Windows XP Professional SP2
* Windows Terminal Server on Windows 2003 Server (Standard or Enterprise Edition)
* Windows Vista (Business or Enterprise Edition)
* Citrix Presentation Server V4.5"
"CaliberRM*
Requirements Management
Client: Windows 2000, XP, Vista"
Держать лишнюю виртуалку? Крутить wine? Зачем?

А ведь всё, если честно, нужно ещё и покупать, кстати, весьма недёшево, и поддерживать. И снова - зачем?

Простые средства вполне работают для больших и сложных требований.

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

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

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

Big17<...>
Ни Word или Wiki не обеспечат возможности сортировки и фильтрации требований по различным критериямwiki: фильтрация: теги+поиск, сортировки действительно не вижу

Big17трекинга (состояния)wiki: теги+поиск+rss; + дисциплина: закоммитил код, который призван удовлетворять требование - отметься, удалось собрать с unit- и smoke-тестами - отметься (возможно, автоматически), протестировал - отметься, внёс в программную документацию - отметься

Big17и уж тем более трассировки требований, но каждая система управления требованиями это умеет (кроме самых простейших)wiki: гиперссылки, backlinks; согласен, ссылки на документы, изменённые с момента создания ссылки, не выделяются специальным образом

Big17И CailberRM и DOORS и RequisitePRO умеют в любой момент сгенерировать нужный документ по нужному шаблону в Word или RTF (а Requsite вообще в Word по сути встраивается). Удобно держать требования в едином репозитории и в нужный момент сгенерировать то, что нужно. Например, можно подготовить шаблоны для генерирования спецификаций требований, бизнес-требований, документов для обсуждения сроков и приоритетов и т.д. и т.п.
Согласен, удобно, doc wiki, например, без соотв. плагинов так не умеет. Нужны:
- include plugin
- multitemplate plugin

Big17Совсем не обязательно каждому программеру иметь на машине клиента к подобной системе и тратить время на его изучение. Это инструменты аналитиков/разработчиков требований, а результатом работы с их использованием пусть будут готовые документы - те самые спецификации требований, ТЗ и т.д. Мое мнение - системы управления требованиями для аналитиков, то же самое, что системы контроля версий для разработчиков... рабочие инструменты.Согласен, для формальных процессов разработуи, где кодеру спускают спецификации и укрупнённые алгоритмы, это так.
Другое дело, что формальные процессы разработки обычно значительно менее эффективны, чем гибкие. Хотя да, гибкие имеют границы размера эффективного проекта, т.к. в них раньше проявляются эффекты масштаба.
А в гибких ТЗ или спецификации пишут сами разработчики. Для себя. По желанию. Быстро и много обсуждая, т.к. "залезание не в своё дело" в разумных рамках поощряется. Но требования - никуда не деваются. Поэтому каждому разработчику в гибком процессе важно думать о пользователях - а для этого знать требования, и иметь к ним доступ. И это не должно его напрягать.

byur<...>
Совершенно согласен, что средства должны соответствовать проекту и процессу, а процесс - быть регламентированным.

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

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

byur<...>
Отсюда, если у вас нет формальных требований со стороны заказчика о формате документации и в частности ТЗ, плюс проект небольшой ... то вполне можно побаловаться и wiki, хотя я бы предложил использовать обычный Word .. но при иметь утвержденный шаблон документа для описания требований. И при этом можно использовать хоть SharePoint, хоть SVN для версионирования и, собственно, collaboration.
Если же у вас проект большой и есть строгие формальные требования от заказчика по формату документов, и при этом ТЗ не просто отписка а по ней реально проходит приемка софта. И это все усугубляется частыми изменениями требований ... то использование wiki и просто Word становиться просто достаточно наклАдным. В этом случае имеет смысл посмотреть в сторону специализированного инструментария типа DOORS, или CaliberRM. RequisitePro не советую рассматривать, как минимум в свете приобретения IBM-ом компании Telelogic.
Юрий, хоть переход на личности - это и запрещённый приём, но думаю, что Ваша длительная работа в Borland консультантом по направлению ALM (CaliberRM, StarTeam и иже с ними) мешает Вам взглянуть шире. Гигантские, и при этом неделимые проекты, для которых нужны формальные средства и сложные, коммерческие средства - это исключение. Для всех остальных главное - не устав и процесс, а команда, человеческое взаимодействие, вовлечённость, заинтересованность, совместное накопление и обмен знаниями. Внедрение сложных средств, ведение тяжёлых процессов зачастую не окупаются. Чем проще и дешевле - тем лучше. Средства должны соответствовать цели.