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

×


Нет ни малейшего понимания. (Прочитано 19003 раз)
Нет ни малейшего понимания. : 08 Октября 2016, 18:18:07
 Добрый день, всем уважаемым участникам форума.

Прошу заранее извинить мое невежество. Обстоятельства сложились определенным образом, что теперь я работаю системным аналитиком.
Небольшая фирма занимается разработкой веб-сервиса, команда работает по scrum. Собственно, хотят начать разрабатывать требования (тз) на uml. С данным инструментом никогда не работал и сейчас все, что прочитал, только еще больше вопросов породило, как и что конкретно применять.
Для примера есть задача. Добавить сущность: поле с ценой за разовую услугу (стрижка). У данной новой сущности есть определенные атрибуты(1 женская 2 мужская 3 окрашивание...6 химия:)) Какой тип диаграммы выбрать, чтобы предоставить разработчикам? Как в данном случае использовать use case диаграммы? Понимаю, что все весьма абстрактно, но даже если пару строк посоветуете, в каком направлении смотреть/копать, что изучать, преисполнюсь личной благодарностью.
Спасибо за уделенное внимание.



Re: Нет ни малейшего понимания. Ответ #1 : 08 Октября 2016, 20:54:45
А разработчикам то что надо сделать? Что с этой сущностью дальше происходит?



Re: Нет ни малейшего понимания. Ответ #2 : 08 Октября 2016, 20:54:53
Добрый вечер.

Описание задачи какое-то сумбурное. Реально ваша команда работает по scrum?

Для справки. Если вы хотите использовать uml, то сначала просто ознакомьтесь что это такое, возможностей море. Можно просто начать с youtube. Можете посмотреть эту книгу http://book.uml3.ru. Можете посмотреть эту библиотеку знаний http://uml-diagrams.org,

Функциональные требования выражаются use cases. Требования к структуре данных обычно выражаются в виде диаграммы классов, используя классы предметной области. Приведенная задача предполагает построение диаграммы классов (или диаграммы объектов).
Для начала нужно понять какие понятия (сущности) фигурируют в предметной области. Судя по задаче есть Услуга, есть Клиент.

Клиент получает 1 или несколько Услуг в ходе Посещения (эта сущность придумана мною, у вас может быть что-то боле точное).
Одна и та же Услуга может оказываться разным Клиентам.

Из этого простого примера можно сделать примерно такое заключение: Клиент (1) - (1 - *) Посещение (0 -*) - (1) Услуга
Услуга может описываться через атрибуты:
Вид услуги
Наименование услуги
Стоимость единицы услуги

Клиент (ФИО, адрес - если вообще нужно)

Посещение
Дата
Время
Кто оказывал услугу
Общая стоимость

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



Re: Нет ни малейшего понимания. Ответ #3 : 08 Октября 2016, 21:21:25
А разработчикам то что надо сделать? Что с этой сущностью дальше происходит?
Добавить новый функционал по категории услуг "Стрижка" на фронтенде (поскольку ранее такой категории не было, поэтому вводим новую сущность). Соотвественно, у нее есть определенный набор атрибутов: мужская, женская, различные названия (модельная, каре) и т.д. Таким образом сперва понять какие поля будут у данной категории.
И мне непонятно какой тип диаграммы выбирать и какой в данном случае use case. На уме только: актер-(услуга), тупик полный. 
 



Re: Нет ни малейшего понимания. Ответ #4 : 08 Октября 2016, 21:37:48
Реально ваша команда работает по scrum?
Для справки. Если вы хотите использовать uml, то сначала просто ознакомьтесь что это такое, возможностей море.
Некое подобие scrum, полагаю.
Вот это море возможностей настораживает, как выбрать правильное направление и кто действительно эксперт в области.
Учебник по вашей рекомендации посмотрю.
И также буду думать над вашим описанием, не до конца его понял.
Благодарю за ваш развернутый ответ.
 



Re: Нет ни малейшего понимания. Ответ #5 : 08 Октября 2016, 21:51:07
Если SCRUM, то сформулируйте новый функционал в виде user story

http://2tickets2dublin.com/how-to-write-good-user-stories-part-1/



Re: Нет ни малейшего понимания. Ответ #6 : 09 Октября 2016, 15:15:08
Добрый день, всем уважаемым участникам форума.

Прошу заранее извинить мое невежество. Обстоятельства сложились определенным образом, что теперь я работаю системным аналитиком.

Небольшая фирма занимается разработкой веб-сервиса, команда работает по scrum.
Собственно, хотят начать разрабатывать требования (тз) на uml.
А про Scrum вы почитали? Никакого когнитивного диссонанса от слов ТЗ и Scrum не возникло?
Команда хочет разрабатывать — пусть разрабатывает. Какова ваша роль тут?
Где менеджер проекта? Руководитель разработки? Руководитель направления? Что хотят они?

Цитировать
С данным инструментом никогда не работал и сейчас все, что прочитал, только еще больше вопросов породило, как и что конкретно применять.
Для примера есть задача. Добавить сущность: поле с ценой за разовую услугу (стрижка).
У данной новой сущности есть определенные атрибуты(1 женская 2 мужская 3 окрашивание...6 химия:))

Какой тип диаграммы выбрать, чтобы предоставить разработчикам?
Никакой.

Цитировать
Как в данном случае использовать use case диаграммы?
Никак.

Используйте словарь данных Data Dictionary. Достаёте Вигерса, читаете эту главу.

Один из важнейших вопросов аналитика — «чтобы что». Зачем вам в проекте UML? Разработчики умеют его читать?



Re: Нет ни малейшего понимания. Ответ #7 : 09 Октября 2016, 23:28:05
Команда хочет разрабатывать — пусть разрабатывает. Какова ваша роль тут?
Где менеджер проекта? Руководитель разработки? Руководитель направления? Что хотят они?
Как раз от PM исходит желание перейти на использование uml. На данный момент есть куча тикетов с неописанными требованиями. Мне предстоит создать варианты user stories.   
Пошел изучать Вигерса.



Re: Нет ни малейшего понимания. Ответ #8 : 09 Октября 2016, 23:46:24
Как раз от PM исходит желание перейти на использование uml. На данный момент есть куча тикетов с неописанными требованиями. Мне предстоит создать варианты user stories.   
Пошел изучать Вигерса.
Все-таки стоит понимать, что user stories и uml мало сочетаются.  И реально узнайте, что хотят получить  от вас программисты.



Re: Нет ни малейшего понимания. Ответ #9 : 10 Октября 2016, 00:04:02
Все-таки стоит понимать, что user stories и uml мало сочетаются.
Такой вопрос: какие диаграммы сочетаются с user stories?
« Последнее редактирование: 10 Октября 2016, 00:06:37 от LampBear »



Re: Нет ни малейшего понимания. Ответ #10 : 10 Октября 2016, 00:57:27
Как раз от PM исходит желание перейти на использование uml.
Чтобы что? Какие именно управленческие решения он хочет принимать на основании диаграмм?

UML – это не инструмент детализации требований. Это инструмент обеспечения их полноты в соотношении многие-ко-многим.

Цитировать
На данный момент есть куча тикетов с неописанными требованиями. Мне предстоит создать варианты user stories.
Ну так создавайте.



Re: Нет ни малейшего понимания. Ответ #11 : 10 Октября 2016, 00:59:01
Такой вопрос: какие диаграммы сочетаются с user stories?


Любые, даже сайт про это есть: http://www.agilemodeling.com/



Re: Нет ни малейшего понимания. Ответ #12 : 10 Октября 2016, 11:28:32
Такой вопрос: какие диаграммы сочетаются с user stories?

Недавно у Касперского проходила очень интересная конференция по управлению требованиями в agile.

https://youtu.be/uHjmBAbUJrc

Ее ценность в том, что на ней делились практическим опытом Agile.

Я для себя сделал примерно такой вывод: user story и uml сочетаются ограниченно. То есть uml диаграмма может быть разработана как иллюстрация какой то user story, но обеспечить единый поток моделирования в agile  крайне трудно за счет того, что поток моделирования прерывается из-за итерационности разработки.

Так же много интересного пл управлению требованию в Agile на страничке журнала "Практика проектирования систем"

https://m.facebook.com/story.php?story_fbid=1221314127939008&id=939608916109532
« Последнее редактирование: 10 Октября 2016, 11:30:23 от Humbert »



Re: Нет ни малейшего понимания. Ответ #13 : 11 Октября 2016, 00:13:47
Такой вопрос: какие диаграммы сочетаются с user stories?
Я не совсем верно выразился, хотел сказать, что user stories не следует путать с use cases, которые являются частью uml и соответственно остальные диаграммы выстроены вокруг use case view.

Если же user stories рассматривать как описание требований, то дальнейшая их проработка может быть выполнена многими диаграммами как в uml, так и в других языках и нотациях.

Не совсем ясная ориентированность на Uml. Ну и в любом случае, если Вы планируете  его как-то использовать, следует познакомиться с его синтаксисом, семантикой и прагматикой использования.

Поищите в сети книгу Скотта Амблера Гибкое моделирование. Возможно натолкнет Вас на какие-то идеи.



Re: Нет ни малейшего понимания. Ответ #14 : 11 Октября 2016, 12:30:57
Если же user stories рассматривать как описание требований, то дальнейшая их проработка может быть выполнена многими диаграммами как в uml, так и в других языках и нотациях.
Не совсем ясная ориентированность на Uml.
Ориентированность обусловлена желанием UX-дизайнера создавать прототипы на основе uml диаграмм.
Начал изучать Фаулера и как он пишет, что в основном применял uml для создания эскизов. Надеюсь это что-то подходящее.




 

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