Форум Сообщества Аналитиков

×


Проблема с документированием(Прочитано 23242 раз)
Коллеги, не знаю сюда ли моя тема. Если что извиняйте

Суть проблемы. Есть объемная система состоящая из нескольких больших модулей. На каждый из модулей есть ЧТЗ страниц не менее 100 в каждом. Система не стоит на месте развивается добавляются новые фичи. И вот столкнулись с проблемами:

1) Каждая вторая из новых фич затрагивает не только модуль в котором должна быть реализована но и краем - другие модули. Естественно анаитики пишут требования к одной фиче  одновременно в нескольких ЧТЗ.

2) Есть вероятность, что требования по каждой, допустим, 4й из фич не будут реализовываться именно в этой фазе а в следующей или через одну. Но записать их куда-то тоже надо

3) Разработчикам очень тяжело пролистывать несколько сотен страниц чтобы добраться до нужных требований.

Несомненно кто-то уже сталкивался с подобными проблемами. Вопросы следующие:

1) Что можно сделать с точки зрения изменений в процессах описания требований, чтобы в один момент времени Система соответствовала документации и наоборот.
2) Как упростить жизнь программистам чтобы до необходимых им требований можно было бы легко добраться

Заранее спасибо за конструктивный и дельный ответ.



Re: Проблема с документированием Ответ #1 : 16 Ноября 2012, 12:22:53
>1) Каждая вторая из новых фич затрагивает не только модуль в котором должна быть реализована но и краем - другие модули. Естественно анаитики пишут требования к одной фиче  одновременно в нескольких ЧТЗ.
Имхо это правильно.

> 2) Есть вероятность, что требования по каждой, допустим, 4й из фич не будут реализовываться именно в этой фазе а в следующей или через одну. Но записать их куда-то тоже надо
Как вариант, указывать для каждого требования фазу. Может быть, кто-то ещё варианты подкинет...

> 3) Разработчикам очень тяжело пролистывать несколько сотен страниц чтобы добраться до нужных требований.
А куда денешься? Ну попробуйте разбить на более мелкие документы...



Re: Проблема с документированием Ответ #2 : 16 Ноября 2012, 17:57:59
На мой взгляд, логичный вариант -- отдельный небольшой документ с требованиями на доработку этого базового модуля. Если доработки оказывают влияние на другие модули -- указать в документе.

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

Например,
ТЗ 00 -- Общее ТЗ на всю систему
ТЗ 01 -- ЧТЗ [Название модуля]
ТЗ 02 -- ЧТЗ [Название модуля]

Документы с требованиями на доработку:

ТЗ 011 -- [Название дорабатываемого функционала в базовом модуле 1]
ТЗ 021 -- [Название дорабатываемого функционала в базовом модуле 2]
...



Re: Проблема с документированием Ответ #3 : 16 Ноября 2012, 18:33:32
для таких случаев и придуманы автоматизированные системы управления требованиями
чтобы не шерстить несколько документов частым гребнем.
требования в такой системе составляют единую ...э... иерархию и имеют горизонтальные связи там где надо. это позволяет отслеживать взаимное влияние требований.
плюс к тому хорошие системы позволяют сформировать очередную версию документа, содержащего актуальные требования
а в идеале и дать пищу для разработки ПМИ и тестов.
Лью воду...



Re: Проблема с документированием Ответ #4 : 19 Ноября 2012, 12:40:46
Предыдущий пост совершенно правильный. существуют системы управления требованиями. в них есть такая архиполезнейшая вещь, как матрицы трассировки требований - двумерный массив взаимосвязей между элементом разработки в различных документах.
и они довольно дорого стоят.а если вы используете в разработке долбанный ТФС, то выбор таких систем очень сужается.
можно не покупать систему и попытаться реализовать матрицу трассирования в excel. это более чем реально и ещё более чем геморройно :)
для этого вам придётся ввести спортивную кодификацию артефактов документов.



Re: Проблема с документированием Ответ #5 : 19 Ноября 2012, 14:22:20
В своем ответе, конечно же, я имел в виду отсутствие СУТ.



Re: Проблема с документированием Ответ #6 : 19 Ноября 2012, 20:42:44
Не совсем понял это:
существуют системы управления требованиями. в них есть такая архиполезнейшая вещь, как матрицы трассировки требований
...
а если вы используете в разработке долбанный ТФС, то выбор таких систем очень сужается.
Вроде бы TFS включает в себя систему управления требованиями, трассировки требований там реализованы.
Вы используете еще одну систему управления требованиями в дополнение к TFS? Какие задачи она решает? Нельзя ли их решить с помощью TFS ?
Вопрос для меня очень актуальный, т.к. наша компания как раз сейчас переносит управление требованиями в TFS.



Re: Проблема с документированием Ответ #7 : 20 Ноября 2012, 14:59:41
Вроде бы TFS включает в себя систему управления требованиями, трассировки требований там реализованы.
ахаха))) вы делаете мне смешно :)
к сожалению, ТФС не располагает никакими средствами управления требованиями. только, как я выше написал, excel и ведение матриц трассировок ручками с синхронизацией с айтемами ТФС.
Вы используете еще одну систему управления требованиями в дополнение к TFS? Какие задачи она решает? Нельзя ли их решить с помощью TFS ?
Вопрос для меня очень актуальный, т.к. наша компания как раз сейчас переносит управление требованиями в TFS.
ТФС совершенно не заточена под анализ и не предполагает управление требованиями. политика ТФС в том, что аналитики и архитекторы выступают для разработки и тестирования в роли заказчиков и формируют "требования" - таски на разработку. в этапах разработки и тестирования ТФС хорош. многие процессы он автоматизирует и упрощает.
но в качестве системы управления требованиями он вообще никакой.
в нашей компании вопрос управления требованиями стоит очень остро и я ответственный от аналитики по реализации СУТ у нас. мы уже полгода ведём переговоры с IBM но пока поженить их СУТ с TFSdoc не получается. завтра, вот, они встречу организовали - может нашли решение.
Майкрософт мне написал следующее: да, ТФС в этом плане некомильфо, юзайте решения, интегрированные с TFS
http://www.edevtech.com/products.html
 http://www.technosolutions.com/topteam_analyst.html
« Последнее редактирование: 20 Ноября 2012, 15:01:22 от Мухо »



Re: Проблема с документированием Ответ #8 : 20 Ноября 2012, 15:57:02
сообщение устарело
« Последнее редактирование: 06 Июня 2016, 17:19:20 от pmle »
Ставлю крестики на ноликах © pmle



Re: Проблема с документированием Ответ #9 : 20 Ноября 2012, 16:40:40
соответствие артефактов СУТ артефактам ТФС и взаимное импортирование артефактов документов и просто документов. в той реализации, которую нам предложил IBM - интеграция обуславливалась ручным перекладыванием файликов из репозитория СУТ в репозиторий ТФС с последующей генерацией айтемов в ТФС.



Re: Проблема с документированием Ответ #10 : 20 Ноября 2012, 17:34:58
сообщение устарело
« Последнее редактирование: 06 Июня 2016, 17:19:24 от pmle »
Ставлю крестики на ноликах © pmle



Re: Проблема с документированием Ответ #11 : 20 Ноября 2012, 18:00:36
ахаха)))ТФС совершенно не заточена под анализ и не предполагает управление требованиями. политика ТФС в том, что аналитики и архитекторы выступают для разработки и тестирования в роли заказчиков и формируют "требования" - таски на разработку.
Ссылки интересные, спасибо, почитаем.
Для анализ и разработки требований у нас 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 не используется?



Re: Проблема с документированием Ответ #12 : 20 Ноября 2012, 18:03:34
с айтемами понимаю, а зачем Вам документы туда-сюда таскать? Может достаточно одного места для хранения документов, по такой схеме

Документы (СУТ) <-> items (СУТ) <==> items (TFS)?
документы таскать туда-сюда нужно, ибо помимо аналитики есть архитектура, разработка и тестирование.
фишка в том, что в СУТ артефактом является требование или его реализация в виде ФТ или ВИ или TC. СУТ оперирует на уровне этих сущностей. при необходимости из артефактов собирается документ по шаблону.
ТФС же хранит артефакты как документы. плодить айтемы в ТФС под каждую задачу, когда у нас, бывает, МТС по сотне требований в рамках одной задачи выкатывает за аналитическую фазу, а задач в релизе - несколько десятков - не совсем удобно и опасно для головы. особенно учитывая ту форму, в которой айтемы живут в ТФС.
другими словами, как реализовать общий процесс для всей разработки, а не только для архитектуры и анализа: если мы оперируем уровнем артефактов СУТ, то они должны быть доступны на любой стадии процесса разработки, если мы от них отказываемся, то нужно придумать, как жить с двумя независимыми системами. в общем, проблема пока не поддаётся решению средствами IBM. посмотрим, что они завтра скажут



Re: Проблема с документированием Ответ #13 : 20 Ноября 2012, 18:08:56
Ссылки интересные, спасибо, почитаем.
Для анализ и разработки требований у нас 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?



Re: Проблема с документированием Ответ #14 : 20 Ноября 2012, 18:13:52
Таски для разработчиков (Work Item Type = Task) подвешиваются под требования (Work Item Type = Requirement).
Воркфлоу тасков и требований разных типов разный.
А у вас, как я понял,  Work Item Type = Requirement и Work Item Type = Change Request не используется?
у нас не совсем так. подписанный с заказчиком КП делется на requirements, каждый проект живёт под requirement, под ним задачи на предложение по реализации, HLA, ПМИ, разработку по модулям, подсистемам и прочее формируются в виде leadtask.
CR-ы - да, мы не используем.




 

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