Size: a a a

Архитектура ИТ-решений

2020 June 09

F

Fagor in Архитектура ИТ-решений
Sergey
помню Моторола показывала как у них требования прослеживаются вплоть до результатов прогона тестов на системе которая сделана по требованиям
т.е можно взять требование и получить отчет по статусу тестов
LMC (три продукта jama software к примеру), но в проде их не пользовал.
источник

П

ПашМиш in Архитектура ИТ-решений
Sergey
ну требования - это таблички. Главное traceability на артефакты
Вероятно это зависит от конкретного бизнеса, например заказная или продуктовая разработка. У нас вот важный выхлоп от RM — загрузка разрабов фичами которые лучше всего помогут продаваться
источник

S

Sergey in Архитектура ИТ-решений
ну Doors использовал, Rational ClearQuest использовал, Rational RM (часть jazz.net) тоже юзал и даже интеграцию с ней делал
источник

S

Sergey in Архитектура ИТ-решений
RM нужен в производстве - электроники, авионика, авиа и мото в целом.  Там довольно обьемные наборы требований и детальные
источник

S

Sergey in Архитектура ИТ-решений
и важно отслеживать исполнение
источник

S

Sergey in Архитектура ИТ-решений
в бизнес-кейсах требования менее формальны
источник

F

Fagor in Архитектура ИТ-решений
Sergey
RM нужен в производстве - электроники, авионика, авиа и мото в целом.  Там довольно обьемные наборы требований и детальные
Сдача ИТ продуктов с ним упрощается в разы, только теперь сбор и утверждение становится болью заказчика. Они же привыкли - вот вам абзац, вперед, наше управление считает что автоматизация 30 складов это 20 страниц текста с полей.
источник

S

Sergey in Архитектура ИТ-решений
ну это склад... а представьте набор требований на самолет ? :)
источник

M

Maxim in Архитектура ИТ-решений
Про управление требованиями - это вам надо в чат к аналитикам)
источник

F

Fagor in Архитектура ИТ-решений
Конструкторский софт за оверпрайс. Для ИТ
источник

F

Fagor in Архитектура ИТ-решений
Maxim
Про управление требованиями - это вам надо в чат к аналитикам)
А вот и нет, аналитик это сбор. Управление - не их задача.
источник

F

Fagor in Архитектура ИТ-решений
Ну только если управлени процессами, тогда их. Но не требованиями к софту.
источник

S

Sergey in Архитектура ИТ-решений
к тому же я требование рассматриваю как нечто, что надо отследить на всех уровнях - модели, код, тесты, бинарники, деплой, документация и т.д
источник

F

Fagor in Архитектура ИТ-решений
Sergey
к тому же я требование рассматриваю как нечто, что надо отследить на всех уровнях - модели, код, тесты, бинарники, деплой, документация и т.д
Тогда однозначно LCM продукт. Ну или три: сбор, отслеживание, тестирование
источник

M

Maxim in Архитектура ИТ-решений
Fagor
Ну только если управлени процессами, тогда их. Но не требованиями к софту.
Типа один раз собрал требования и всё?) А проанализировать? А согласовать? А внести изменения?
Я конечно допускаю, что в каких-то проектах ПМ на себя может часть задач взять, но всё-таки требования обычно считаются вотчиной аналитиков...
источник

F

Fagor in Архитектура ИТ-решений
Maxim
Типа один раз собрал требования и всё?) А проанализировать? А согласовать? А внести изменения?
Я конечно допускаю, что в каких-то проектах ПМ на себя может часть задач взять, но всё-таки требования обычно считаются вотчиной аналитиков...
То что вы написали вот это я и называю собрать. Потом зафиксировать, передать в проектирование, разработку куда угодно, и тут начинается управление ими. Даже BA в лучшем случае приходит и говторит что это новое требование плюс к процессу но управлять старыми, отменять, и направлять имплементацию нового, замораживать связанные до принятия решения Архитектором, или вобще отметать новое, вообще ни разу ни Аналитик. Принимать имплементацию тем более.

Может офтоп, но скажу, Знаете вот меня прямо умиляют РП консалтов РФ, у них раб-консультнант все делает, еще и тестирует, нужно же проект протолкнуть заказчику, ведь не барское это дело что бы РП работал 😂
источник

VS

Vsevolod Shulaev in Архитектура ИТ-решений
Может и архитектор, может и системный аналитик. Зависит от распределения компетенций и зон ответственности в команде.
Чисто имхо это скорее к СА. Чтобы видеть картинку в целом внутри одного проекта/задачи лычки архитектора не нужны.
источник

M

Maxim in Архитектура ИТ-решений
Fagor
То что вы написали вот это я и называю собрать. Потом зафиксировать, передать в проектирование, разработку куда угодно, и тут начинается управление ими. Даже BA в лучшем случае приходит и говторит что это новое требование плюс к процессу но управлять старыми, отменять, и направлять имплементацию нового, замораживать связанные до принятия решения Архитектором, или вобще отметать новое, вообще ни разу ни Аналитик. Принимать имплементацию тем более.

Может офтоп, но скажу, Знаете вот меня прямо умиляют РП консалтов РФ, у них раб-консультнант все делает, еще и тестирует, нужно же проект протолкнуть заказчику, ведь не барское это дело что бы РП работал 😂
Значит мы друг друга не поняли.
То о чем вы говорите больше похоже на управление проектом, а не требованиями.
Аналитик обычно не отвечает за имплементацию требований.
Но он следит за изменениями требований, если требование изменилось, то оно возвращается к аналитику в работу.

В ходе анализа и согласований аналитик вполне может прийти к выводу что новое требование не пойдёт дальше в работу.
источник

M

Maxim in Архитектура ИТ-решений
Из BABOK про управление требованиями
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Fagor
Project
Так управление требованиями - не совсем его задача, это скорее про Product.
Project интересует бюджет, сроки, ресурсы и т.п.
А уж как там Product c Project договорятся (если для одного важно, а у другого бюджета нет) - это их личное дело.
источник