Agile Method and Scrum, как мне заполнить этот шаблон документа?

Question

Я делаю проект (сайт) для университета.Прямо сейчас я в спринте. В шаблоне, предоставленном моим учителем, у меня есть два раздела: пользовательские истории и дизайн продукта.В каждом из этих двух разделов у меня есть подразделы: «Диаграмма классов» и «Диаграмма последовательности».Не могли бы вы дать мне знать, в чем разница между двумя разделами и между двумя диаграммами в различных разделах одного и того же SPRINT?не должны ли они быть одним и тем же?Большое спасибо

Answer 1

Диаграмма классов или последовательностей одинакова в обоих контекстах;таким образом, нет никакого смысла в том, что вам нужно делать некоторые диаграммы для пользовательских историй и другие для дизайна продукта ... У вас есть только продукт (программное обеспечение), и эти диаграммы должны представлять этот продукт.

Кроме того, здесь речь идет о совершенно разных темах: эти диаграммы относятся к UML, общему языку для абстрагирования и представления концепций проектирования программного обеспечения.Пользовательские истории обычно относятся к SCRUM (или любому другому методу Agile), который используется для предоставления формального способа разработки программного обеспечения.

Обе диаграммы представляют собой концепции, относящиеся к дизайну продукта (программное обеспечение).Это всего лишь инструменты для абстрактного представления некоторых концепций вашего продукта.

Пользовательские истории используются для представления требований или работы, которую необходимо выполнить для завершения вашего продукта.Например, пользовательская история может быть «Создать представление, в котором посетитель может создать учетную запись», «Создать представление входа в систему для зарегистрированных пользователей» или «Создать диаграмму классов для представления отношений между сущностями в вашем».product "and" создать диаграмму последовательности для представления взаимодействия ".Видите ли вы это сейчас?

По моему мнению, вы должны сделать свою диаграмму классов и последовательностей (один раз), и, конечно, это является частью фазы проектирования продукта, но, поскольку вы используете пользовательские истории дляДля представления задач, которые необходимо выполнить, чтобы завершить ваш продукт, у вас будет две пользовательские истории, которые говорят что-то вроде этого:

• Создайте диаграмму классов для продукта
• Создайте последовательностьдиаграмма для продукта
• Создайте что-нибудь еще для моего проекта.

Answer 2

Я второй Thisisalexis.Это две разные темы UML и Scrum.Пользовательские истории - это не что иное, как краткое и точное представление требований в повествовании пользователя.Agile делает вещи игривыми, а значит легкими и веселымиЛучший аспект Agile.

В то время как диаграммы классов boht и диаграммы последовательностей должны входить в состав Product Design.Описание пользовательских историй может содержать ссылку на один или несколько шаблонов дизайна продукта, состоящих из диаграмм классов и / или последовательностей.

Я постарался сделать его кратким и простым.Надеюсь, это поможет:)

Answer 3

Я предполагаю, что ваш шаблон выглядит так (поправьте меня, если я ошибаюсь):

• История пользователя
  • ClassDiagram
  • SequenceDiagram
• ProductDesign
  • Диаграмма классов
  • Диаграмма последовательности

Первая,

• ClassDiagram предназначен для описания статических аспектов (структура)
• SequenceDiagram предназначен для описания динамических аспектов (поведение, взаимодействия)

Например, определить классы Aи B. A имеет метод A, а B имеет метод B.Вот структура, которую вы изображаете в диаграмме классов.В диаграмме последовательности вы описываете поведение, например, A.methodA вызывает B.methodB, чтобы реализовать функцию, описанную в истории.

Вы можете использовать обе диаграммы на разных этапах процесса проектирования и реализации (т. е. во время анализа требований или во время разработки решения), поэтому вы можете использовать его как для описания истории, так и для описания дизайна.

Во-вторых,

Я предполагаю, что домашняя работа заключается в подходе, который называется " Объектно-ориентированный анализ и проектирование", который разбивает проблему на различные аспекты (структурный анализ) и выводит соответствующий дизайн (объектно-ориентированное проектирование), оба этапа используют различные элементы UML.

Aистория может быть структурно разложена с помощью объектно-ориентированного анализа, а дизайн продукта может быть создан с использованием объектно-ориентированного дизайна.

Итак, давайте предположим, что у вас есть пользовательская история "Как учитель я хочу проводить экзамены, чтобы проверить знаниямои ученики ".

У вас есть актtor "учитель", сценарий использования "проведение экзаменов" и актер "студенты".Вы можете вывести модель анализа из этого:

• Преподаватель класса
  • проводить экзамен ()
• Учащийся класса
  • testKnowledge()

Teacher.conductExam () -> Studen.testKnowledge ()

Из этой модели анализа вы можете получить модель проектирования

• Учитель
• Экзаменационные таблицы
• Ученик
• StudentTests
• Счет
• ...

и сколько вам еще нужно, чтобы описать решение вашей проблемы.

Фактический подход основан на Rational Unified Process (RUP), а не обязательно на «гибкой» разработке, которая гораздо менее структурирована в отношении как вы действительно разрабатываете решение.UML со всеми его элементами представляет собой стандартизированный набор визуальных элементов с определенной семантикой.Однако вышеупомянутый подход - один способ интерпретации вашей задачи, я уверен, что есть и много других.