Size: a a a

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

2020 June 09

PD

Phil Delgyado in Архитектура ИТ-решений
Но вообще формальное управление требованиями очень дорого и обычно нужно только там, где может окупиться.
Для кучи разных бизнесов вполне нормально иметь очень примерное описание требований (кроме некоторых особо важных).
А управление сводить к написанию функциональных тестов
источник

MB

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

S

Sergey in Архитектура ИТ-решений
у Моторолы это где-то в 2004-м было
источник

S

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

S

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

MB

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

PD

Phil Delgyado in Архитектура ИТ-решений
А цели какие были? Т.е. какой это приносит profit?
источник

F

Fagor in Архитектура ИТ-решений
По сути это шаг к цифровизации, часть пазла
источник

F

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

F

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

F

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

В ходе анализа и согласований аналитик вполне может прийти к выводу что новое требование не пойдёт дальше в работу.
Все просто ниже вроде верно за что ПМ отвечает, а что есть реализация требований, т.е. само требование в проекте ПМа? Основная составляющая качества и границ проекта. Значит в чьей зоне, после сбора требований они? В рамках проекта ПМа конечно. Если у вас реализация изменений идет в рамках функциональных обязанностей руководителя отдела, то зона ответственности естественно меняется
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Fagor
По сути это шаг к цифровизации, часть пазла
Ну, а какой смысл с цифровизации? Это же не святой грааль.
источник

F

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

PD

Phil Delgyado in Архитектура ИТ-решений
А с чего бы рынок идет к цифровизации? Есть какие-то обоснования, которые идут не от продавцов цифровизации?
источник

PD

Phil Delgyado in Архитектура ИТ-решений
(При этом я даже не уверен, что управление требованиями - шаг к цифровизации, прямо скажем)
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Вот "требование как код" - это уже интересно )
источник

F

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

PD

Phil Delgyado in Архитектура ИТ-решений
Неа. Построение модели целевой системы с самого начала - это да, это про цифровизацию.
А управление требованиями - просто некоторая управленческая практика сбоку.
источник

F

Fagor in Архитектура ИТ-решений
Phil Delgyado
Вот "требование как код" - это уже интересно )
Интересно на низком уровне, например вам, поднимемся выше... И уже вопрос - зачем? И тут появляется "модель".
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Модель - тоже код )
источник