exam10 4
Методология RUP (Rational Unified Process). Основные части описания прецедентов (Use Case) и их изображение на диаграммах прецедентов
Реферат к лекции 10 История развития итеративной разработки программных средств
Выполнил: Крупенко Илья, ИДБ-18-08
Проверил: Козарезов Денис, ИДБ-18-08
Унифицированный процесс Rational — это универсальная методология распределения задач и сфер ответственности при разработке программного обеспечения. Её цель – создание высококачественного программного обеспечения, отвечающего потребностям и запросам пользователей. Методология RUP была разработана в компании Rational Software Corporation, которую в 2003 году купила IBM.
Методология RUP предназначена для крупных проектов разработки, поэтому многие менеджеры уверены, что она не подойдёт для небольших задач, не требующих большого объёма ресурсов. Но есть множество примеров, когда небольшие проекты значительно выигрывали от внедрения RUP.
К примеру, RUP используется в системе управления онлайн-обучением TAP University. Компания поставила перед собой цель расширить область традиционного офлайн-обучения и улучшить свои сервисы для корпоративных, частных пользователей и студентов.
Хотя это был небольшой проект, внедрение методологии RUP показало отличные результаты. Она помогла выстроить набор принципов, необходимых для организации сценариев использования сервисов TAP University, помогла увидеть направления для перехода к третьей, самой важной фазе RUP — построению.
Работа над процессом – команда разработчиков RUP тесно работает с покупателями, партнёрами и группами компаний, постоянно обновляя методологию.
RUP оптимизирует командную работу – обеспечивает команде разработчиков свободный доступ к базе знаний с инструкциями для использования программных средств. Это помогает быстрее справиться с критическими проблемами. Благодаря этому команда легко находит общий язык в процессе работы над проектом.
RUP ориентирован на создание и поддержание моделей – вместо написания большого количества бумажной документации при использовании RUP методологии создаются модели – семантические представления разрабатываемого командой программного обеспечения.
RUP – это инструкция использования Unified Modelling Language (UML) – UML позволяет команде легко донести свои требования к проекту, его архитектуру и план реализации.
RUP – это конфигурируемый процесс, он подходит как небольшим группам разработчиков, так и крупным организациям.
В основе RUP лежит шесть главных принципов:
- Итеративная модель разработки – устранение рисков на каждой стадии проекта позволяет лучше понять проблему и вносить необходимые изменения, пока не будет найдено приемлемое решение;
- Управление требованиями – RUP описывает процесс организации и отслеживания функциональных требований, документации и выбора оптимальных решений (как в процессе разработки, так и при ведении бизнеса);
- Компонентная архитектура – архитектура системы разбивается на компоненты, которые можно использовать как в текущем, так и в будущих проектах;
- Визуальное моделирование ПО – RUP методология разработки показывает, как создать визуальную модель программного обеспечения, чтобы понять структуру и поведение архитектуры и его компонентов;
- Проверка качества ПО – в процессе разработки программного обеспечения контролируется качество всех действий команды;
- Контроль внесённых изменений – отслеживание изменений позволяет выстроить непрерывный процесс разработки. Создаётся благоприятная обстановка, в рамках которой команда будет защищена от изменений в рабочем процессе.
Данный подход описывает, кто делает что делает, как и когда. RUP можно представить в виде четырёх основных элементов:
Элемент «работник» определяет поведение и ответственность всех членов команды, сконцентрированных на общей цели – создании искусственных объектов (артефактов). В RUP работник – это скорее роль, определяющая, как индивидуумы должны выполнять свою работу. Работник не только производит определённые действия, но также владеет набором артефактов.
Действие — это единица работы, которую может выполнить работник. У каждого действия есть чётко обозначенная цель. Каждое действие назначено определённому работнику. Действия могут включать в себя создание или обновление артефактов, таких как модель, класс или план.
В методологии RUP объекты или информация, производимая и изменяемая в процессе работы над финальным результатом. Артефакты служат как вводными данными для действий работников, так и результатами этих действий.
Рабочий процесс представляет собой последовательность действий, приводящих к видимому результату. В терминах UML можно представить рабочий процесс как диаграмму последовательности, диаграмму кооперации или диаграмму активности:
Лабораторная №4
Разработка алгоритма и описания процедуры в проектной команде
Дисциплина "Проектирование информационных систем".
Деловая игра "Разработка по SCRUM".
| Участник | Категория | Цель (goal) |
|---|---|---|
| Студент | Основной | Освоить методику организации разработки по SCRUM |
| Куратор | Внешний | Стимулировать освоение методики |
| Лектор | Внешний | Сократить количество ошибок |
| Репозиторий | Инструмент | Предоставить место размещения канбан-доски, задач, кода и текстов |
| PlantUML | Инструмент | Предоставить средства генерации диаграмм |
-
сформирована команда, определены полномочия и обязанности ролей 👣
-
сформулирован проект, цели проекта и системы разобраны по SMART 👣
-
сформулирована пользовательская история (User Story) для реализации в ходе деловой игры 👣
-
освоены основные методы проведения совещаний в форме мозгового штурма
-
освоены основные средства веб-программирования:
-
определены предпочтения и личные возможности самостоятельного выполнению в ходе деловой игры типовых задач:
- разработка функции
- разработка теста
- разработка схемы и/или подготовка данных
- все задачи (issues) к выбранной пользовательской истории зарегистрированы в соответствующем проекте
- все задачи (issues) включены в спринт и распределены по исполнителям
- все исполнители дали оценку по трудозатратам и срокам выполнения назначенных им задач
- в каждой задаче записаны ее зависимости (dependencies) от других задач
| Участник | Действие (activity) | Ожидаемый результат |
|---|---|---|
| РП (Владелец продукта) | Регистрирует участников проекта | Участники приняли приглашения и подключились к проекту |
| СП (Аналитик) | Регистрирует историю как отдельную задачу проекта (issue) | Задача с номером |
| НИ (Архитектор) | Разбивает задачу истории на подзадачи - процедуры | Список подзадач с именами процедур |
| ВН (Дизайнер) | Разбивает задачу истории на подзадачи - страницы | Список подзадач с именами страниц |
| БА (Тестировщик) | Разбивает задачу истории на подзадачи - тесты | Список подзадач с именами тестов |
| АД (Мастер) | Получает оценку времени для каждой подзадачи, собирает sprint log, назначает исполнителей | Список подзадач на канбан-доске |
| КО (Тех.писатель) | Делает описания для всех подзадач, требующих программной реализации | Описание и необходимые диаграммы в комментариях к задаче, в виде вики-страницы или в виде комментариев в файле программы |
| ПП (Программист) | Разрабатывает алгоритмы выполнения всех подзадач, требующих программной реализации | Описание алгоритма и диаграмма деятельности в комментариях к задаче, в виде вики-страницы или в виде комментариев в файле программы |
| Условие (риск) | Последствия | Реакция |
|---|---|---|
| Распределение только выбранных задач не полностью покрывает задачи спринта | Срыв выполнения всего спринта | Дораспределить оставшиеся задачи по участникам команды |
| Возникают слишком объемные задачи | Задача не может быть решена в ходе одной лабораторной | Разбить задачи на более мелкие, занимающие не более 1 нормочаса каждая |
| ??? | ??? | ??? |
Что может повлиять на путь перехода от предусловий к постусловиям?
-
Триггер (событие, стартующее прецедент): начало занятия по расписанию
-
Номинальная частота повторения прецедента: 1 раз в семестр * число студентов (60)
-
Продолжительность прецедента: 4 ак.часа = 4 нормочаса
Унифицированный процесс – это процесс, управляемый прецедентами, которые отражают сценарии взаимодействия пользователей. Фактически, это взгляд пользователей на программную систему снаружи. Таким образом, одним из важнейших этапов разработки, согласно RUP, будет этап определения требований, который заключается в сборе всех возможных пожеланий к работе системы, которые только могут прийти в голову пользователям и аналитикам. Позднее эти данные должны будут систематизированы и структурированы, но на данном этапе в ходе интервью с пользователями и изучения документов, аналитики должны собрать как можно больше требований к будущей системе, что не так просто, как кажется на первый взгляд. Пользователи часто сами не представляют, что они должны получить в конечном итоге. Для облегчения этого процесса аналитики используют диаграммы прецедентов:
Диаграмма представляет собой отражение действующих лиц (актантов), которые взаимодействуют с системой, и реакцию программных объектов на их действия. Актантами могут быть как пользователи, так и внешние агенты, которым необходимо передать или получить информацию. Значок варианта использования отражает реакцию системы на внешнее воздействие и показывает, что должно быть сделано для актанта.
Для детализации конкретного прецедента используется диаграмма Активности (Activity Diagram):
Простота диаграммы прецедентов позволяет аналитикам легко общаться с заказчиками в процессе определения требований, выявлять ограничения, налагаемые на систему и на выполнение отдельных требований, такие, например, как время реакции системы, которые в дальнейшем попадают в раздел нефункциональных требований.
Также диаграмма прецедентов может использоваться для создания сценариев тестирования, поскольку все взаимодействие пользователей и системы уже определено.
❌ Реферат не закончен: нет ни структуры описания прецедента, см. любую из лабораторных4-6, ни примера его отображения (частичного, что важно) на диаграммах UML. Ну т.е. попросту потеряна связь между RUP и прецедентами.
-
Rational Unified Process // https://ru.wikipedia.org/wiki/Rational_Unified_Process
-
Методологии разработки программного обеспечения. Часть 3. Rational Unified Process // https://compress.ru/article.aspx?id=9633
-
RUP методология // https://www.internet-technologies.ru/articles/newbie/unificirovannyy-process-rational-rup.html
-
Using RUP to manage small projects and teams // https://immagic.com/eLibrary/ARCHIVES/GENERAL/IBM/I050715K.pdf