Форум Сообщества Аналитиков
Дисциплины => Системный Анализ и Требования => Тема начата: Брат от 16 Ноября 2012, 10:52:18
-
Коллеги, не знаю сюда ли моя тема. Если что извиняйте
Суть проблемы. Есть объемная система состоящая из нескольких больших модулей. На каждый из модулей есть ЧТЗ страниц не менее 100 в каждом. Система не стоит на месте развивается добавляются новые фичи. И вот столкнулись с проблемами:
1) Каждая вторая из новых фич затрагивает не только модуль в котором должна быть реализована но и краем - другие модули. Естественно анаитики пишут требования к одной фиче одновременно в нескольких ЧТЗ.
2) Есть вероятность, что требования по каждой, допустим, 4й из фич не будут реализовываться именно в этой фазе а в следующей или через одну. Но записать их куда-то тоже надо
3) Разработчикам очень тяжело пролистывать несколько сотен страниц чтобы добраться до нужных требований.
Несомненно кто-то уже сталкивался с подобными проблемами. Вопросы следующие:
1) Что можно сделать с точки зрения изменений в процессах описания требований, чтобы в один момент времени Система соответствовала документации и наоборот.
2) Как упростить жизнь программистам чтобы до необходимых им требований можно было бы легко добраться
Заранее спасибо за конструктивный и дельный ответ.
-
>1) Каждая вторая из новых фич затрагивает не только модуль в котором должна быть реализована но и краем - другие модули. Естественно анаитики пишут требования к одной фиче одновременно в нескольких ЧТЗ.
Имхо это правильно.
> 2) Есть вероятность, что требования по каждой, допустим, 4й из фич не будут реализовываться именно в этой фазе а в следующей или через одну. Но записать их куда-то тоже надо
Как вариант, указывать для каждого требования фазу. Может быть, кто-то ещё варианты подкинет...
> 3) Разработчикам очень тяжело пролистывать несколько сотен страниц чтобы добраться до нужных требований.
А куда денешься? Ну попробуйте разбить на более мелкие документы...
-
На мой взгляд, логичный вариант -- отдельный небольшой документ с требованиями на доработку этого базового модуля. Если доработки оказывают влияние на другие модули -- указать в документе.
А вообще, я бы сначала настроил правильное именование документов.
Например,
ТЗ 00 -- Общее ТЗ на всю систему
ТЗ 01 -- ЧТЗ [Название модуля]
ТЗ 02 -- ЧТЗ [Название модуля]
Документы с требованиями на доработку:
ТЗ 011 -- [Название дорабатываемого функционала в базовом модуле 1]
ТЗ 021 -- [Название дорабатываемого функционала в базовом модуле 2]
...
-
для таких случаев и придуманы автоматизированные системы управления требованиями
чтобы не шерстить несколько документов частым гребнем.
требования в такой системе составляют единую ...э... иерархию и имеют горизонтальные связи там где надо. это позволяет отслеживать взаимное влияние требований.
плюс к тому хорошие системы позволяют сформировать очередную версию документа, содержащего актуальные требования
а в идеале и дать пищу для разработки ПМИ и тестов.
-
Предыдущий пост совершенно правильный. существуют системы управления требованиями. в них есть такая архиполезнейшая вещь, как матрицы трассировки требований - двумерный массив взаимосвязей между элементом разработки в различных документах.
и они довольно дорого стоят.а если вы используете в разработке долбанный ТФС, то выбор таких систем очень сужается.
можно не покупать систему и попытаться реализовать матрицу трассирования в excel. это более чем реально и ещё более чем геморройно :)
для этого вам придётся ввести спортивную кодификацию артефактов документов.
-
В своем ответе, конечно же, я имел в виду отсутствие СУТ.
-
Не совсем понял это:
существуют системы управления требованиями. в них есть такая архиполезнейшая вещь, как матрицы трассировки требований
...
а если вы используете в разработке долбанный ТФС, то выбор таких систем очень сужается.
Вроде бы TFS включает в себя систему управления требованиями, трассировки требований там реализованы.
Вы используете еще одну систему управления требованиями в дополнение к TFS? Какие задачи она решает? Нельзя ли их решить с помощью TFS ?
Вопрос для меня очень актуальный, т.к. наша компания как раз сейчас переносит управление требованиями в TFS.
-
Вроде бы TFS включает в себя систему управления требованиями, трассировки требований там реализованы.
ахаха))) вы делаете мне смешно :)
к сожалению, ТФС не располагает никакими средствами управления требованиями. только, как я выше написал, excel и ведение матриц трассировок ручками с синхронизацией с айтемами ТФС.
Вы используете еще одну систему управления требованиями в дополнение к TFS? Какие задачи она решает? Нельзя ли их решить с помощью TFS ?
Вопрос для меня очень актуальный, т.к. наша компания как раз сейчас переносит управление требованиями в TFS.
ТФС совершенно не заточена под анализ и не предполагает управление требованиями. политика ТФС в том, что аналитики и архитекторы выступают для разработки и тестирования в роли заказчиков и формируют "требования" - таски на разработку. в этапах разработки и тестирования ТФС хорош. многие процессы он автоматизирует и упрощает.
но в качестве системы управления требованиями он вообще никакой.
в нашей компании вопрос управления требованиями стоит очень остро и я ответственный от аналитики по реализации СУТ у нас. мы уже полгода ведём переговоры с IBM но пока поженить их СУТ с TFSdoc не получается. завтра, вот, они встречу организовали - может нашли решение.
Майкрософт мне написал следующее: да, ТФС в этом плане некомильфо, юзайте решения, интегрированные с TFS
http://www.edevtech.com/products.html
http://www.technosolutions.com/topteam_analyst.html
-
сообщение устарело
-
соответствие артефактов СУТ артефактам ТФС и взаимное импортирование артефактов документов и просто документов. в той реализации, которую нам предложил IBM - интеграция обуславливалась ручным перекладыванием файликов из репозитория СУТ в репозиторий ТФС с последующей генерацией айтемов в ТФС.
-
сообщение устарело
-
ахаха)))ТФС совершенно не заточена под анализ и не предполагает управление требованиями. политика ТФС в том, что аналитики и архитекторы выступают для разработки и тестирования в роли заказчиков и формируют "требования" - таски на разработку.
Ссылки интересные, спасибо, почитаем.
Для анализ и разработки требований у нас Sparx Enterprise Architect, затем самопальная утилита конвертирует их в TFS. Шаблон проекта от Microsoft MSF for CMMI 5.0 со своими доработками вроде бы обеспечивает устраивающую всех трассируемость требований - от бизнес-требований продуктового департамента до системных и требований к компонентам. Таски для разработчиков (Work Item Type = Task) подвешиваются под требования (Work Item Type = Requirement).
Воркфлоу тасков и требований разных типов разный.
А у вас, как я понял, Work Item Type = Requirement и Work Item Type = Change Request не используется?
-
с айтемами понимаю, а зачем Вам документы туда-сюда таскать? Может достаточно одного места для хранения документов, по такой схеме
Документы (СУТ) <-> items (СУТ) <==> items (TFS)?
документы таскать туда-сюда нужно, ибо помимо аналитики есть архитектура, разработка и тестирование.
фишка в том, что в СУТ артефактом является требование или его реализация в виде ФТ или ВИ или TC. СУТ оперирует на уровне этих сущностей. при необходимости из артефактов собирается документ по шаблону.
ТФС же хранит артефакты как документы. плодить айтемы в ТФС под каждую задачу, когда у нас, бывает, МТС по сотне требований в рамках одной задачи выкатывает за аналитическую фазу, а задач в релизе - несколько десятков - не совсем удобно и опасно для головы. особенно учитывая ту форму, в которой айтемы живут в ТФС.
другими словами, как реализовать общий процесс для всей разработки, а не только для архитектуры и анализа: если мы оперируем уровнем артефактов СУТ, то они должны быть доступны на любой стадии процесса разработки, если мы от них отказываемся, то нужно придумать, как жить с двумя независимыми системами. в общем, проблема пока не поддаётся решению средствами IBM. посмотрим, что они завтра скажут
-
Ссылки интересные, спасибо, почитаем.
Для анализ и разработки требований у нас Sparx Enterprise Architect, затем самопальная утилита конвертирует их в TFS. Шаблон проекта от Microsoft MSF for CMMI 5.0 со своими доработками вроде бы обеспечивает устраивающую всех трассируемость требований - от бизнес-требований продуктового департамента до системных и требований к компонентам. Таски для разработчиков (Work Item Type = Task) подвешиваются под требования (Work Item Type = Requirement).
Воркфлоу тасков и требований разных типов разный.
А у вас, как я понял, Work Item Type = Requirement и Work Item Type = Change Request не используется?
ну так это не ТФС, а EA+ самопал.
у нас почти такой же процесс. только без ЕА. я модельки в нём набиваю, но смутно представляю себе как вести учёт и трассировку требований к проекту в нём. когда совсем задница мы в екселе ведём трассировки с синхронизацией с ТФС.
а так пока управляем требованиями с помощью силы головы и какой-то матери :)
а можно подробнее про ваш процесс управления требованиями и EA?
-
Таски для разработчиков (Work Item Type = Task) подвешиваются под требования (Work Item Type = Requirement).
Воркфлоу тасков и требований разных типов разный.
А у вас, как я понял, Work Item Type = Requirement и Work Item Type = Change Request не используется?
у нас не совсем так. подписанный с заказчиком КП делется на requirements, каждый проект живёт под requirement, под ним задачи на предложение по реализации, HLA, ПМИ, разработку по модулям, подсистемам и прочее формируются в виде leadtask.
CR-ы - да, мы не используем.
-
подписанный с заказчиком КП делется на requirements, каждый проект живёт под requirement, под ним задачи на предложение по реализации, HLA, ПМИ, разработку по модулям, подсистемам и прочее формируются в виде leadtask.
Мне кажется, что разработчики TFS не предполагали такого его применения. TFS хорошо работает, когда КП (это же "комплексный проект", да, или что-то в таком роде?) - это Project Collection, проект - это Project, требование - это Requirement, если вы работаете по CMMI, или User Story, если по Agile. В вашем случае, судя по всему - CMMI.
А вы смотрели примеры по ссылке Process Guide, которая образуется в корне сайта проекта TFS (шаблон CMMI 5.0) сразу после его создания?
-
Мне кажется, что разработчики TFS не предполагали такого его применения. TFS хорошо работает, когда КП (это же "комплексный проект", да, или что-то в таком роде?) - это Project Collection, проект - это Project, требование - это Requirement, если вы работаете по CMMI, или User Story, если по Agile. В вашем случае, судя по всему - CMMI.
А вы смотрели примеры по ссылке Process Guide, которая образуется в корне сайта проекта TFS (шаблон CMMI 5.0) сразу после его создания?
КП - это коммерческое предложение. да, мы по CMMI работаем, но через задницу :)
извините, разве вы не согласны, что в ТФС работа с требованиями совершенно неудобна, или скорее невозможна, ибо ничего с этими ворк айтемами больше сделать нельзя. ни матрицу трассирования создать, ни вменяемое дерево трассировок, кроме как классические чайльд-парент. а плодить айтемы под каждую хотелку, а потом таски под каждый реквайрмент - мы с нашей спецификой только месяцев пять будем тратить на заведение и манагерство всей этой эпичной структуры.
может, это работает для сравнительно небольших проектов с явными границами автоматизации. у нас своя специфика - в год мы выпускаем 2-3 релиза, в которые набиваются все задачки, которые заказчик смог пропихнуть за оговоренный бюджет и срок. соответственно поток хотелок и требований у нас мощн, порывист и беспощаден :) в виду того, что OSS/BSS решение одного немаленького оператора связи - очень и очень сложная система и релизы, как правило, затрагивают комплексно все подсистемы.
конечно нам, как аналитикам и архитектуре, хотелось бы упростить жизнь и иметь полноценную СУТ. на базе ТФС бесполезно даже пытаться рассматривать управление требованиями в том объёме, в котором нам приходится работать с ними.
может, конечно, я не прав и есть способ забодать ТФС в этом плане, но, когда я плотно исследовал этот вопрос, я на него нашёл только отрицательный ответ - мелкософт сами признаются, что полноценного функционала СУТ в ТФС нет.
открыт для обсуждения :)
признаться вы меня своим вопросом про process guide поставили в тупик. поковырялся, что-то не нашёл. бегло в инете тоже не нашёл.
-
поковырялся. если скриптами долбить таски-требования и выгружать во внешние системы для управления и ведения связей, то жить, в принципе, можно попробовать :)
но всё-равно это криво и убого, на мой взгляд.
-
сообщение устарело
-
сообщение устарело
-
Коллеги, привет. Спасибо за конструктивные ответы. TFS никто не будет ставить.
Про ЧТЗ. В этом на мой взгляд нет смысла, так как разработчикам все равно придется читать гору документации
Про системы управления требованиями - подумаю. Будут ли еще серебряные пули?
-
извините, разве вы не согласны, что в ТФС работа с требованиями совершенно неудобна, или скорее невозможна, ибо ничего с этими ворк айтемами больше сделать нельзя. ни матрицу трассирования создать, ни вменяемое дерево трассировок, кроме как классические чайльд-парент.
Для этого линки типа Affects / Affected by рекомендуется использовать.
Навскидку из форумов: http://blogs.objectsharp.com/post/2012/02/22/Requirements-Traceability-in-Visual-Studio.aspx (http://blogs.objectsharp.com/post/2012/02/22/Requirements-Traceability-in-Visual-Studio.aspx)
С учетом трассировок в TFS все хорошо, с визуализацией - действительно, не очень.
http://mickyd.wordpress.com/2011/06/19/team-foundation-server-has-great-traceability-until-you-need-to-report-on-it/ (http://mickyd.wordpress.com/2011/06/19/team-foundation-server-has-great-traceability-until-you-need-to-report-on-it/)
Но никто не мешает найти какой-нибудь плагин к студии, или написать свой плагин для нужной визуализации. БД TFS имеет достаточно простую структуру и хорошо документирована, сам сервер легко интегрируется, особенно легко - со всеми микрософтовскими продуктами.
а плодить айтемы под каждую хотелку, а потом таски под каждый реквайрмент - мы с нашей спецификой только месяцев пять будем тратить на заведение и манагерство всей этой эпичной структуры.
Т.е вы не ведете атомарный учет каждого требования? Вы принимаете от заказчика единый документ с набором требований, и отлеживаете жизненный путь всего документа в целом?
может, это работает для сравнительно небольших проектов с явными границами автоматизации. у нас своя специфика - в год мы выпускаем 2-3 релиза, в которые набиваются все задачки, которые заказчик смог пропихнуть за оговоренный бюджет и срок. соответственно поток хотелок и требований у нас мощн, порывист и беспощаден :) в виду того, что OSS/BSS решение одного немаленького оператора связи - очень и очень сложная система и релизы, как правило, затрагивают комплексно все подсистемы.
Так ведь поток требований и его беспощадность вроде бы не уменьшается и не увеличивается от того, в какую систему вы его записываете? Он только от бюджета зависит...
мелкософт сами признаются, что полноценного функционала СУТ в ТФС нет.
Ну, они обычно так признаются, когда их просят показать, как реализован функционал, например IBMовской линейки FocalPoint -> Doors. Если с чем попроще сравнивать, то спорят :)
признаться вы меня своим вопросом про process guide поставили в тупик. поковырялся, что-то не нашёл. бегло в инете тоже не нашёл.
Это я ошибся, конечно, не process guide, а Process Guidance. Самая нижняя ссылка в левой колонке сайта проекта TFS, после Team Web Access, Dashboards и т.д.
Ведет по умолчанию (если проект не кастомизирован) для проекта, сделанного по шаблону CMMI 5.0 на ссылку:
http://msdn.microsoft.com/en-us/library/dd997574(VS.100).aspx
Там надо начинать с Artifacts (CMMI).
-
С Cradle мы связывались. не впечатлил он моё руководство.
у нас требования к интеграции не только в том, чтобы сынтегрить две системы, но и в том, чтобы не сломать существующую аналитику в тфс - отчёты, выгрузки и прочее.
Вчера встречались с IBM - нашли они способ поженить RRC и TFS - есть малоизвестная буржуйская контора - TaskTop - они разработали шину для интеграции RRC и TFS. вчера нам показали архитектуру. вроде всё очень даже устраивает.
что до остальных вопросов - да, мы не ведём учёт атомарных требований в тфс. это чудовищно, понимаю, но это так :)
Каждый аналитик на своей задаче как ему удобно ведёт учёт требований. или не ведёт. полная демократия)
я пришёл сюда год назад и инициировал эту бучу с RRC.
как костыли перед внедрением СУТ, предложил руководству использовать excel для управления требованиями и генерации реквайрментов в тфс под задачами. кто-то впечатлился, кто-то нет. у нас специфика особая - мы иногда даже предложения по реализации пишем вообще без требований :-)
что до трассировок в ТФС - это надо потратить довольно много времени и написать все скрипты для минимизации заведения айтемов в нём. под это нет внутреннего заказчика у нас, ибо "и так работает" и требования мы не учитываем в тфс. но если IBM не нашёл бы решения, то, скорее всего к этому бы мы и пришли - продумали актуальную иерархию артефактов тфс с учётом трассирования, визуализировали и прочее.
под любое усовершенствование, внедрение или пересмотр существующего функционала внутри компании-разработчика всегда должен быть внутренний заказчик(потребность в усовершенствовании/Изменении) без этого все предложения обречены на провал.
-
Вчера встречались с IBM - нашли они способ поженить RRC и TFS - есть малоизвестная буржуйская контора - TaskTop - они разработали шину для интеграции RRC и TFS.
Ага, ну тогда расскажите потом, как оно на практике синтегрировалось, и сколько времени и человеко-месяцев понадобилось. Будет интересен ваш опыт.
У нас интеграция / миграция TFS <-> существующие системы сейчас от 3 до 5 человек требует, и уже поболе 5 человеко-лет затрат скушала. (Согласно оценкам руководства, идет успешо).