Форум Сообщества Аналитиков
Общий раздел => Примеры => Тема начата: LampBear от 08 Октября 2016, 18:18:07
-
Добрый день, всем уважаемым участникам форума.
Прошу заранее извинить мое невежество. Обстоятельства сложились определенным образом, что теперь я работаю системным аналитиком.
Небольшая фирма занимается разработкой веб-сервиса, команда работает по scrum. Собственно, хотят начать разрабатывать требования (тз) на uml. С данным инструментом никогда не работал и сейчас все, что прочитал, только еще больше вопросов породило, как и что конкретно применять.
Для примера есть задача. Добавить сущность: поле с ценой за разовую услугу (стрижка). У данной новой сущности есть определенные атрибуты(1 женская 2 мужская 3 окрашивание...6 химия:)) Какой тип диаграммы выбрать, чтобы предоставить разработчикам? Как в данном случае использовать use case диаграммы? Понимаю, что все весьма абстрактно, но даже если пару строк посоветуете, в каком направлении смотреть/копать, что изучать, преисполнюсь личной благодарностью.
Спасибо за уделенное внимание.
-
А разработчикам то что надо сделать? Что с этой сущностью дальше происходит?
-
Добрый вечер.
Описание задачи какое-то сумбурное. Реально ваша команда работает по scrum?
Для справки. Если вы хотите использовать uml, то сначала просто ознакомьтесь что это такое, возможностей море. Можно просто начать с youtube. Можете посмотреть эту книгу http://book.uml3.ru. Можете посмотреть эту библиотеку знаний http://uml-diagrams.org,
Функциональные требования выражаются use cases. Требования к структуре данных обычно выражаются в виде диаграммы классов, используя классы предметной области. Приведенная задача предполагает построение диаграммы классов (или диаграммы объектов).
Для начала нужно понять какие понятия (сущности) фигурируют в предметной области. Судя по задаче есть Услуга, есть Клиент.
Клиент получает 1 или несколько Услуг в ходе Посещения (эта сущность придумана мною, у вас может быть что-то боле точное).
Одна и та же Услуга может оказываться разным Клиентам.
Из этого простого примера можно сделать примерно такое заключение: Клиент (1) - (1 - *) Посещение (0 -*) - (1) Услуга
Услуга может описываться через атрибуты:
Вид услуги
Наименование услуги
Стоимость единицы услуги
Клиент (ФИО, адрес - если вообще нужно)
Посещение
Дата
Время
Кто оказывал услугу
Общая стоимость
Все сущность и атрибуты должны быть аккуратно прописаны в модели или словаре данных с указанием типа данных, диапазона значений, правил и ограничений
-
А разработчикам то что надо сделать? Что с этой сущностью дальше происходит?
Добавить новый функционал по категории услуг "Стрижка" на фронтенде (поскольку ранее такой категории не было, поэтому вводим новую сущность). Соотвественно, у нее есть определенный набор атрибутов: мужская, женская, различные названия (модельная, каре) и т.д. Таким образом сперва понять какие поля будут у данной категории.
И мне непонятно какой тип диаграммы выбирать и какой в данном случае use case. На уме только: актер-(услуга), тупик полный.
-
Реально ваша команда работает по scrum?
Для справки. Если вы хотите использовать uml, то сначала просто ознакомьтесь что это такое, возможностей море.
Некое подобие scrum, полагаю.
Вот это море возможностей настораживает, как выбрать правильное направление и кто действительно эксперт в области.
Учебник по вашей рекомендации посмотрю.
И также буду думать над вашим описанием, не до конца его понял.
Благодарю за ваш развернутый ответ.
-
Если SCRUM, то сформулируйте новый функционал в виде user story
http://2tickets2dublin.com/how-to-write-good-user-stories-part-1/
-
Добрый день, всем уважаемым участникам форума.
Прошу заранее извинить мое невежество. Обстоятельства сложились определенным образом, что теперь я работаю системным аналитиком.
Небольшая фирма занимается разработкой веб-сервиса, команда работает по scrum.
Собственно, хотят начать разрабатывать требования (тз) на uml.
А про Scrum вы почитали? Никакого когнитивного диссонанса от слов ТЗ и Scrum не возникло?
Команда хочет разрабатывать — пусть разрабатывает. Какова ваша роль тут?
Где менеджер проекта? Руководитель разработки? Руководитель направления? Что хотят они?
С данным инструментом никогда не работал и сейчас все, что прочитал, только еще больше вопросов породило, как и что конкретно применять.
Для примера есть задача. Добавить сущность: поле с ценой за разовую услугу (стрижка).
У данной новой сущности есть определенные атрибуты(1 женская 2 мужская 3 окрашивание...6 химия:))
Какой тип диаграммы выбрать, чтобы предоставить разработчикам?
Никакой.
Как в данном случае использовать use case диаграммы?
Никак.
Используйте словарь данных Data Dictionary. Достаёте Вигерса, читаете эту главу.
Один из важнейших вопросов аналитика — «чтобы что». Зачем вам в проекте UML? Разработчики умеют его читать?
-
Команда хочет разрабатывать — пусть разрабатывает. Какова ваша роль тут?
Где менеджер проекта? Руководитель разработки? Руководитель направления? Что хотят они?
Как раз от PM исходит желание перейти на использование uml. На данный момент есть куча тикетов с неописанными требованиями. Мне предстоит создать варианты user stories.
Пошел изучать Вигерса.
-
Как раз от PM исходит желание перейти на использование uml. На данный момент есть куча тикетов с неописанными требованиями. Мне предстоит создать варианты user stories.
Пошел изучать Вигерса.
Все-таки стоит понимать, что user stories и uml мало сочетаются. И реально узнайте, что хотят получить от вас программисты.
-
Все-таки стоит понимать, что user stories и uml мало сочетаются.
Такой вопрос: какие диаграммы сочетаются с user stories?
-
Как раз от PM исходит желание перейти на использование uml.
Чтобы что? Какие именно управленческие решения он хочет принимать на основании диаграмм?
UML – это не инструмент детализации требований. Это инструмент обеспечения их полноты в соотношении многие-ко-многим.
На данный момент есть куча тикетов с неописанными требованиями. Мне предстоит создать варианты user stories.
Ну так создавайте.
-
Такой вопрос: какие диаграммы сочетаются с user stories?
Любые, даже сайт про это есть: http://www.agilemodeling.com/
-
Такой вопрос: какие диаграммы сочетаются с 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
-
Такой вопрос: какие диаграммы сочетаются с user stories?
Я не совсем верно выразился, хотел сказать, что user stories не следует путать с use cases, которые являются частью uml и соответственно остальные диаграммы выстроены вокруг use case view.
Если же user stories рассматривать как описание требований, то дальнейшая их проработка может быть выполнена многими диаграммами как в uml, так и в других языках и нотациях.
Не совсем ясная ориентированность на Uml. Ну и в любом случае, если Вы планируете его как-то использовать, следует познакомиться с его синтаксисом, семантикой и прагматикой использования.
Поищите в сети книгу Скотта Амблера Гибкое моделирование. Возможно натолкнет Вас на какие-то идеи.
-
Если же user stories рассматривать как описание требований, то дальнейшая их проработка может быть выполнена многими диаграммами как в uml, так и в других языках и нотациях.
Не совсем ясная ориентированность на Uml.
Ориентированность обусловлена желанием UX-дизайнера создавать прототипы на основе uml диаграмм.
Начал изучать Фаулера и как он пишет, что в основном применял uml для создания эскизов. Надеюсь это что-то подходящее.
-
Ориентированность обусловлена желанием UX-дизайнера создавать прототипы на основе uml диаграмм.
Пусть попробует структурные карты Константайна :)
-
Ориентированность обусловлена желанием UX-дизайнера создавать прототипы на основе uml диаграмм.
Начал изучать Фаулера и как он пишет, что в основном применял uml для создания эскизов. Надеюсь это что-то подходящее.
А разработчики будут при этом пользоваться диаграммами?
Или для них нужна другая форма представления?
-
Любая крайность - губительна.
Если вы работаете по модели Agile, то и хранение знаний (требований) выстраивайте по этой модели.
Диаграммы могут дополнять текстовое описание, но чтобы его полностью его заменить - необходимы колоссальные усилия по их созданию и поддержке, которые в итоге никак не окупятся.
Используйте диаграммы там, где это уместно, при описании каких-то сложных процессов, для визуализации картины вцелом.
А там где возможно - используйте текстовые описания, на сколько это возможно.
С дизайнером проще всего будет общаться с помощью макетов экранов и описания требований к интерфейсу, тут UML вовсе не обязателен.
-
А разработчики будут при этом пользоваться диаграммами?
Или для них нужна другая форма представления?
В ближайшей перспективе нет. Буду представлять в виде user stories и описанием в хранилище знаний.
Интересно, почитать где-то про прототипирование можно?
-
В ближайшей перспективе нет. Буду представлять в виде user stories и описанием в хранилище знаний.
Для полноты описания рекомендую в состав историй включать сценарии:
http://2015.secr.ru/lang/ru/program/submitted-presentations/bdd-by-example-russian-bylina-written-in-gherkin-language
-
Для полноты описания рекомендую в состав историй включать сценарии:
http://2015.secr.ru/lang/ru/program/submitted-presentations/bdd-by-example-russian-bylina-written-in-gherkin-language
Сценарии в формате BDD используются в первую очередь для автоматизации проверки Acceptance Criteria у User Story.
Если у вас используется автоматизация тестов, то тогда это действительно довольно удобный инструмент.
Если автоматизации нет, то сценарии можно использовать в некоторых случаях, для пояснения сложных сценариев работы.
-
В ближайшей перспективе нет. Буду представлять в виде user stories и описанием в хранилище знаний.
Интересно, почитать где-то про прототипирование можно?
Для общего ознакомления советую статью: http://www.bridging-the-gap.com/using-wireframes-or-prototypes-to-elicit-analyze-and-validate-software-requirements/
Так же в книжке Вигерса есть отдельная глава, посвященная прототипам: "Прототипы как средство снижения риска".
Обзор инструментов прототипирования можно поискать на хабре или в гугле.
-
Судя по общей динамике этой беседы, единственное лекарство, которое вам поможет - делать свои задачи так, как считаете нужным. После десятого раза начнет получаться (а может и раньше, ели сообразительный))). Я 12 лет назад именно так начинала свою карьеру аналитика (через 8 лет после ее начала моя зарплата выросла примерно в 7 раз). Так что не бойтесь, бить за ошибки вас никто не будет (увольнять, думаю, тоже вряд ли - ведь найти нового и трудоустроить это лишний геморрой для компании)))