Просмотр сообщений
1
Системный Анализ и Требования / Re: Как подготовить детальные требования в случае нескольких систем?
« : 12 Августа 2009, 15:45:26 »
Добрый день!
Огромное спасибо всем откликнувшимся за советы! Честно говоря, был приятно удивлен активностью и желанием поучаствовать в обсуждении.
Попробую ответить на возникшие вопросы, резюмировать и добавить побольше деталей.
Отдельная просьба - частично ответ я на него получил, получить ответ на главный вопрос:
Лучшие практики, методологии, ссылки, как организовать свой мозг, чтобы отделять зерна от плевел, вплоть до мнемонических практик при работе с требованиями.
Теперь детали
:
---------
Проект ватерфольный, в стадии сбора требований (Анализ высокоуровневых - собраных требований и детализация)
Система А будет существовать еще несколько лет, изменения к сожалению в ней не маленькие.
Проблема усложняется тем, что команда А никогда доступ к А не даст, документация есть, в общем сносная, но о доступе к системе (тем более боевой) речи нет.
Политика есть, но это не интересно.
Я выступаю аналитиком со стороны команды Б, моя задача составить часть проектного артефакта на И и Б и помочь команде А составить артефакт на систему А.
Дальше активность с нашей стороны Б перейдет к инженеру - программисту,у которого не будет интерфейса с заказчиком а только с разработчиком со стороны А.
Соответственно нужно включить все, что нужно для построения дизайна и написания кода.
В мой проектный артефакт планирую включить (помимо описания, AS IS, TO BE,ссылки на бизнес и юзер требования)
1)Описать требования к (изменению) существующей модели данных А (система разрабатывается не с нуля) На уровне
"В системе Б для сущности C должен храниться признак , при его обнавлении через интерфейс Б,
сообщение 'Обновление сущности С'должно передать новое значение.Предположение: В системе А признак должен быть недоступен для редактирования"
2)По бизнес процессам To Be определить все сценарии использования СИ. Если процесс начинается в системе Б, указать,
что его порождает. (поможет )
3)Для каждого СИ определить основной поток сообщений (например, сиквенс диаграмма) и передаваемые параметры
Там где возможно разветвление (откат процесса), нарисовать дополнительные сообщения. Указать степень логирования.
4)Описать отдельно сообщения на уровне передаваемой информации + характеристики сообщений (кто инициирует, тип вызова, и т.п.)
5)Для каждого СИ описать какая процедура в системе А должна вызываться и что должна возвращать.
Ответы:
----------------
AlextheRaven
1)~ Описано, но не тщательно. К тому же мы (Б) не можем оценить, насколько полно :-(.
2)~ Тоже вроде есть, хотя с этим сложнее.
3)+ Да, это большая задача, так как входы для нас это требования Т1-Тn + описания AS IS, TO Be.
В целом требования ограничены потоком сообщений + процедурами обработки сообщений.
4)? не понял, что значит разбить на этапы? С точки зрения разработки? В общем это нужно, но это уже вопрос к разработчикам.
Мы в общем можем определить приоритеты.
5)- В общем не моя проблема, надежда на людей с А, что они смогут переписать свой функционал. (Ресурсы у них есть и немаленькие)
reverse engineering - хорошо, проблема, что толкового доступа к А нет.
-----------------
Водолей
Да, процессы не меняются, подходить будем с лица, с изнанки доступа нет :-(.
3 - как ни печально звучит, специально проблемы мы не собираемся исправлять по причинам
-разрастания скоупа
-есть команда А, которая это может сделать в А
-вероятность, что "особенность реализации" легко можно исправить (например, поменяв модель данных только Б) небольшая
-недостаточное понимание на текущем этапе командой Б тонкостей работы А и отсутствия доступа к А
4 + да, план нужен (правда включен он будет в другой артефакт, но не суть). Планируется переносить по кускам данных в течении года (объемы порядка 100 млн. объектов)
----------------------
AlextheRaven
Возможно нет другого выхода. В общем, заплатки и примочки будут (скорее всего как запросы на изменение), будем чинить.
------------------
Boatman
Подход с точки зрения пользовательских выводов интересен.
Можно считать, что первый этап пройден + зафиксированы (высокоуровневого) что в какой системе должно происходить.
Мысли интересные, еще подумаю на досуге
----------------------
...
----------------
mouse
a) Да, примерно так, т.е система Б будет на время передавать А данные Д, потом обновлять их по запросу А.
Бизнес процессы не получается разделить на А и Б, они в общем существуют независимо от систем.
Нас в общем интересуют только те, которые проходят через Б и А вместе.Спецификации запроса определять рано,
нужно понять, ЧТО нужно передавать.
С учетом различных моделей данных вопрос гадкий..Возможно есть смысл оперировать терминами А и Б одновременно, дублируя их.
Вопрос не в magic, вопрос в том, как абстрагироваться.
----------
Почему хочется избежать деталей реализации - явных ограничений нет, какое то внутренне ощущение
т.е. допускается гибкость, важно ее осознавать
Причины:
-Требования (тот проектный артефакт, который я готовлю) нужно согласовывать с заказчиком. Если не абстрагироваться, есть шансы взорвать ему мозг, такой задачи нет.
-Я не самый профессиональный разработчик и не могу сразу придумать оптимальное решение, к тому же не имея полной картины
-Излишняя детализация ограничивает свободу в выборе решений
-Больший риск допустить неточности, которые потом придется пересогласовывать
*Отметил для себя, что будет где -
Какая из систем инициирует интеграционный процесс? (далее рассматривается случай, если активная система А, пассивная Б)
( + СИ, сиквенс диаграмма)
Какой запрос приходит из системы А?
(+ СИ, на стрелочках описание параметров + описание сообщений)
Как преобразовать формат данных запроса?
( -Не будет в документе, будет в деталях реализации, задача процедур, описание входа)
Что нужно вызвать в системе Б, чтобы по параметрам переданным из системы А получить из нее необходимые данные?
(- Не будет в документе, будет в деталях реализации, задача процедур)
Как преобразовать формат полученных данных?
(- Не будет в документе, будет в деталях реализации, задача процедур, описание выхода)
Какой ответ нужно сформировать для системы А?
(+ Описание сообщений)
Какие могут быть исключительные ситуации и что делать в каждом конкретном случае?
(+ Описание аварийных сообщений, например, будут называться также как нормальные, но возвращать детали ошибок,
Отдельно описать, что будет, если что-то пойдет не так.)
Требуется ли логирование интеграционных процессов, если требуется, то в каких точках, какой уровень логирования?
(~Хороший вопрос, думаю нужно, возможно описанием СИ )
Огромное спасибо всем откликнувшимся за советы! Честно говоря, был приятно удивлен активностью и желанием поучаствовать в обсуждении.
Попробую ответить на возникшие вопросы, резюмировать и добавить побольше деталей.
Отдельная просьба - частично ответ я на него получил, получить ответ на главный вопрос:
Лучшие практики, методологии, ссылки, как организовать свой мозг, чтобы отделять зерна от плевел, вплоть до мнемонических практик при работе с требованиями.
Теперь детали
:---------
Проект ватерфольный, в стадии сбора требований (Анализ высокоуровневых - собраных требований и детализация)
Система А будет существовать еще несколько лет, изменения к сожалению в ней не маленькие.
Проблема усложняется тем, что команда А никогда доступ к А не даст, документация есть, в общем сносная, но о доступе к системе (тем более боевой) речи нет.
Политика есть, но это не интересно
.Я выступаю аналитиком со стороны команды Б, моя задача составить часть проектного артефакта на И и Б и помочь команде А составить артефакт на систему А.
Дальше активность с нашей стороны Б перейдет к инженеру - программисту,у которого не будет интерфейса с заказчиком а только с разработчиком со стороны А.
Соответственно нужно включить все, что нужно для построения дизайна и написания кода.
В мой проектный артефакт планирую включить (помимо описания, AS IS, TO BE,ссылки на бизнес и юзер требования)
1)Описать требования к (изменению) существующей модели данных А (система разрабатывается не с нуля) На уровне
"В системе Б для сущности C должен храниться признак , при его обнавлении через интерфейс Б,
сообщение 'Обновление сущности С'должно передать новое значение.Предположение: В системе А признак должен быть недоступен для редактирования"
2)По бизнес процессам To Be определить все сценарии использования СИ. Если процесс начинается в системе Б, указать,
что его порождает. (поможет )
3)Для каждого СИ определить основной поток сообщений (например, сиквенс диаграмма) и передаваемые параметры
Там где возможно разветвление (откат процесса), нарисовать дополнительные сообщения. Указать степень логирования.
4)Описать отдельно сообщения на уровне передаваемой информации + характеристики сообщений (кто инициирует, тип вызова, и т.п.)
5)Для каждого СИ описать какая процедура в системе А должна вызываться и что должна возвращать.
Ответы:
----------------
AlextheRaven
1)~ Описано, но не тщательно. К тому же мы (Б) не можем оценить, насколько полно :-(.
2)~ Тоже вроде есть, хотя с этим сложнее.
3)+ Да, это большая задача, так как входы для нас это требования Т1-Тn + описания AS IS, TO Be.
В целом требования ограничены потоком сообщений + процедурами обработки сообщений.
4)? не понял, что значит разбить на этапы? С точки зрения разработки? В общем это нужно, но это уже вопрос к разработчикам.
Мы в общем можем определить приоритеты.
5)- В общем не моя проблема, надежда на людей с А, что они смогут переписать свой функционал. (Ресурсы у них есть и немаленькие)
reverse engineering - хорошо, проблема, что толкового доступа к А нет.
-----------------
Водолей
Да, процессы не меняются, подходить будем с лица, с изнанки доступа нет :-(.
3 - как ни печально звучит, специально проблемы мы не собираемся исправлять по причинам
-разрастания скоупа
-есть команда А, которая это может сделать в А
-вероятность, что "особенность реализации" легко можно исправить (например, поменяв модель данных только Б) небольшая
-недостаточное понимание на текущем этапе командой Б тонкостей работы А и отсутствия доступа к А
4 + да, план нужен (правда включен он будет в другой артефакт, но не суть). Планируется переносить по кускам данных в течении года (объемы порядка 100 млн. объектов)
----------------------
AlextheRaven
Возможно нет другого выхода. В общем, заплатки и примочки будут (скорее всего как запросы на изменение), будем чинить.
------------------
Boatman
Подход с точки зрения пользовательских выводов интересен.
Можно считать, что первый этап пройден + зафиксированы (высокоуровневого) что в какой системе должно происходить.
Мысли интересные, еще подумаю на досуге
----------------------
...
----------------
mouse
a) Да, примерно так, т.е система Б будет на время передавать А данные Д, потом обновлять их по запросу А.
Бизнес процессы не получается разделить на А и Б, они в общем существуют независимо от систем.
Нас в общем интересуют только те, которые проходят через Б и А вместе.Спецификации запроса определять рано,
нужно понять, ЧТО нужно передавать.
С учетом различных моделей данных вопрос гадкий..Возможно есть смысл оперировать терминами А и Б одновременно, дублируя их.
Вопрос не в magic, вопрос в том, как абстрагироваться.
----------
Почему хочется избежать деталей реализации - явных ограничений нет, какое то внутренне ощущение
т.е. допускается гибкость, важно ее осознавать
Причины:
-Требования (тот проектный артефакт, который я готовлю) нужно согласовывать с заказчиком. Если не абстрагироваться, есть шансы взорвать ему мозг, такой задачи нет.
-Я не самый профессиональный разработчик и не могу сразу придумать оптимальное решение, к тому же не имея полной картины
-Излишняя детализация ограничивает свободу в выборе решений
-Больший риск допустить неточности, которые потом придется пересогласовывать
*Отметил для себя, что будет где -
Какая из систем инициирует интеграционный процесс? (далее рассматривается случай, если активная система А, пассивная Б)
( + СИ, сиквенс диаграмма)
Какой запрос приходит из системы А?
(+ СИ, на стрелочках описание параметров + описание сообщений)
Как преобразовать формат данных запроса?
( -Не будет в документе, будет в деталях реализации, задача процедур, описание входа)
Что нужно вызвать в системе Б, чтобы по параметрам переданным из системы А получить из нее необходимые данные?
(- Не будет в документе, будет в деталях реализации, задача процедур)
Как преобразовать формат полученных данных?
(- Не будет в документе, будет в деталях реализации, задача процедур, описание выхода)
Какой ответ нужно сформировать для системы А?
(+ Описание сообщений)
Какие могут быть исключительные ситуации и что делать в каждом конкретном случае?
(+ Описание аварийных сообщений, например, будут называться также как нормальные, но возвращать детали ошибок,
Отдельно описать, что будет, если что-то пойдет не так.)
Требуется ли логирование интеграционных процессов, если требуется, то в каких точках, какой уровень логирования?
(~Хороший вопрос, думаю нужно, возможно описанием СИ )