Cценарии версионирования/бейсланирования документов требований(Прочитано 12750 раз)
Скажите, а какие вы используете сценарии версионирования/бейсланирования документов требований в своих проектах?

Например, создали документ, сохранили как версию и отправили заказчику на согласование. А пока можете его дорабатавать, а потом он присылает результаты и [..тут мы что-то делаем с версиями..]

Или делаем заканчиваем релиз 6, а параллельно релиз 7 аналитику, и приходит изменение законодательства и надо его у честь в обоих релизах и вот тут мы [..используем бейслайны предусмотрительно сделанные или что-то еще..]

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



Например, создали документ, сохранили как версию и отправили заказчику на согласование. А пока можете его дорабатавать, а потом он присылает результаты и [..тут мы что-то делаем с версиями..]

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

Если речь про какую-то форму совместной разработки документа, то результаты "согласования" включаются в очередную версию документа. Которая публикуется, например, с примечанием "с учетом результатов рассмотрения документа [отв. лицо Заказчика] [дата]".

Или делаем заканчиваем релиз 6, а параллельно релиз 7 аналитику, и приходит изменение законодательства и надо его у честь в обоих релизах и вот тут мы [..используем бейслайны предусмотрительно сделанные или что-то еще..]

Состоявшийся "релиз" это история. Править историю задним числом = искать себе и окружающим неприятности на пятую точку.
Еще несостоявшийся "релиз" документа в отечественной практике называется "проект". С проектом можно делать все, что угодно, включая противоестественное.
« Последнее редактирование: 15 Января 2014, 13:04:01 от Леонид »



Для документов которые читает заказчик используем SVN.
Сделал версию -> коммит -> заказчику.
Этап согласования прошел -> коммит -> заказчику.

Для внутренней переписки добавляем циферку в конце документа, т.е. _1, _2 и т.д.

Обычно так. Но есть заказчики которые любят совместную работу с документом через режим правки. В итоге на 5-6й итерации в документе полный бардак, приходится все убивать, класть документ в SVN и так до нового бардака.



Лучше всего процесс, наверное, рассмотреть на документе ворд:
1. Аналитик шарашит документ, каждая новая версия - это изменение версии в названии файла + трек внутри документа в табличке версионности.
2. Аналитик отсылает документ Заказчикам(Разработчикам, Тестировщикам), версия N.
3. Аналитик что-то шарашит еще в документе, изменяя версии.
4. Аналитик получает документы с замечаниями от Заказчика, вносит изменения в свою последнюю версию по всем замечаниям, изменяет версию на N+M.
5. Аналитик отсылает документ Заказчикам, версия N+M.
6. Заказчики говорят, что все ок, тогда версия N+M считается согласованной - это бейслайн требований. Далее идет процесс разработки и изменений согласованных требований. Если есть еще замечания, то идем к п. 4.

Если один документ изменяют несколько аналитиков, то уже без СВН или СУТ не обойтись.
« Последнее редактирование: 16 Января 2014, 14:40:27 от bas »
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.




5. Аналитик отсылает документ Заказчикам, версия N+M.


Саша, думаю, что на этом этапе важен момент — те дополнения, которые аналитик "зашарашил" в локальном документе, когда происходило согласование у Заказчика, должны быть визуально выделены (т.е. внесены в режиме исправлений или любым отличным цветом), иначе на 6-м этапе Заказчик может не обратить внимания на "зашарашенные" во время согласования обновления, что потом при сдаче системы может вызвать массу вопросов.



Павел,

Спасибо за уточнение. Так как раз и делаю, просто сравнению версии N и N+M и посылаю документ с изменениям.
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Коллеги, спасибо вам за кейсы, мы их учли и выпустили новую версию Devprom ALM 3.2, которая теперь умеет делать бейзлайны требований и тестовых сценариев, версионировать документы, а так же сравнивать документы различных версий/бейзлайнов между собой!

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

Вот ссылка на полное описание изменений: http://devprom.ru/news/%D0%9D%D0%BE%D0%B2%D0%B0%D1%8F-%D0%B2%D0%B5%D1%80%D1%81%D0%B8%D1%8F-Devprom-3-2



Коллеги, спасибо вам за кейсы, мы их учли и выпустили новую версию Devprom ALM 3.2,
Хитро.



Хитро.
Сергей, главное, на наш взгляд, чтобы полезно оказалось :)



Сергей, главное, на наш взгляд, чтобы полезно оказалось :)
Дмитрий, ваш подход мне кажется действительно правильным.

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



Сергей, спасибо за замечание, а в чем именно вы увидели неверное употребление терминов и, тем более, логическую несостыковку?




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19