Форум Сообщества Аналитиков
Дисциплины => Системный Анализ и Требования => Тема начата: Dmitry Lobasev от 15 Января 2014, 00:12:10
-
Скажите, а какие вы используете сценарии версионирования/бейсланирования документов требований в своих проектах?
Например, создали документ, сохранили как версию и отправили заказчику на согласование. А пока можете его дорабатавать, а потом он присылает результаты и [..тут мы что-то делаем с версиями..]
Или делаем заканчиваем релиз 6, а параллельно релиз 7 аналитику, и приходит изменение законодательства и надо его у честь в обоих релизах и вот тут мы [..используем бейслайны предусмотрительно сделанные или что-то еще..]
Хочется понять, что сейчас актуально в современных проектах. Только именно сценарии, которые на самом деле используются в работе.
-
Например, создали документ, сохранили как версию и отправили заказчику на согласование. А пока можете его дорабатавать, а потом он присылает результаты и [..тут мы что-то делаем с версиями..]
Если речь именно о согласовании - какая может быть активная работа над этим документом между его отправкой и получением результата? Только косметические правки.
Если речь про какую-то форму совместной разработки документа, то результаты "согласования" включаются в очередную версию документа. Которая публикуется, например, с примечанием "с учетом результатов рассмотрения документа [отв. лицо Заказчика] [дата]".
Или делаем заканчиваем релиз 6, а параллельно релиз 7 аналитику, и приходит изменение законодательства и надо его у честь в обоих релизах и вот тут мы [..используем бейслайны предусмотрительно сделанные или что-то еще..]
Состоявшийся "релиз" это история. Править историю задним числом = искать себе и окружающим неприятности на пятую точку.
Еще несостоявшийся "релиз" документа в отечественной практике называется "проект". С проектом можно делать все, что угодно, включая противоестественное.
-
Для документов которые читает заказчик используем SVN.
Сделал версию -> коммит -> заказчику.
Этап согласования прошел -> коммит -> заказчику.
Для внутренней переписки добавляем циферку в конце документа, т.е. _1, _2 и т.д.
Обычно так. Но есть заказчики которые любят совместную работу с документом через режим правки. В итоге на 5-6й итерации в документе полный бардак, приходится все убивать, класть документ в SVN и так до нового бардака.
-
Лучше всего процесс, наверное, рассмотреть на документе ворд:
1. Аналитик шарашит документ, каждая новая версия - это изменение версии в названии файла + трек внутри документа в табличке версионности.
2. Аналитик отсылает документ Заказчикам(Разработчикам, Тестировщикам), версия N.
3. Аналитик что-то шарашит еще в документе, изменяя версии.
4. Аналитик получает документы с замечаниями от Заказчика, вносит изменения в свою последнюю версию по всем замечаниям, изменяет версию на N+M.
5. Аналитик отсылает документ Заказчикам, версия N+M.
6. Заказчики говорят, что все ок, тогда версия N+M считается согласованной - это бейслайн требований. Далее идет процесс разработки и изменений согласованных требований. Если есть еще замечания, то идем к п. 4.
Если один документ изменяют несколько аналитиков, то уже без СВН или СУТ не обойтись.
-
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,
Хитро.
-
Хитро.
Сергей, главное, на наш взгляд, чтобы полезно оказалось :)
-
Сергей, главное, на наш взгляд, чтобы полезно оказалось :)
Дмитрий, ваш подход мне кажется действительно правильным.
Еще хоиел сказать... Я почитал описание продукта на вашем сайте. Сложилось мнение что над описанием фич работали не совсем профессионалы. Много логических несостыковок и термины не всегда употребляются верно. Это важно, потому что по этому описанию складывается первое впечатление о продукте.
-
Сергей, спасибо за замечание, а в чем именно вы увидели неверное употребление терминов и, тем более, логическую несостыковку?