Системный анализ в структуре разработки ПО
Модуль позволяет синхронизировать общее представление о роли аналитика и определить навыки, которые будут сформированы в процессе обучения. Примечание: занятия, в которых есть теория для ознакомления перед занятием в формате видео, обозначены так: "// Предзапись".
Обзорное занятие // ДЗ
рассмотреть основные функции СА;
пояснить место СА в разработке ПО.
ДЗ
Заполнение карты профессиональных компетенций и выбор темы проектной работы.
Необходимо:
1. Скопировать шаблон карты компетенций по ссылке: https://docs.google.com/spreadsheets/d/146RTUdoTo29BN1J8pQ-fJxjqgzFccUcuSwoYSL8XDpg/edit?gid=612769418#gid=612769418.
2. Проанализировать функции СА, указанные в стандартной карте.
3. Оценить свой уровень компетенций по каждой функции в графе «На старте курса».
4. Добавить те функции, которые вы выполняете в рамках своей работы, но которые отсутствуют в стандартной карте, и указать свой уровень компетенций по этой функции.
5. Изучить описание проектной работы по ссылке: https://otusmetodist.yonote.ru/share/6f9076bf-6807-4a7b-83c6-4fac2208a7bb/doc/opisanie-kejsa-dlya-proektnoj-raboty-6XntZ3vr6b.
6. Указать тему проекта. Вы можете выбрать тему проекта из списка ниже или предложить свою.
- Приложение для заказа + табло
- Автоматизация роботов + настройка меню и технологических карт
- Инвентаризация, автозаказ, контроль срок
Процесс разработки ПО. Waterfall. Системный анализ в Agile командах // Предзапись
рассмотреть процесс разработки ПО, определить степень участия СА на каждом из этапов, назвать зоны развития СА;
определить задачи СА в водопадной методологии и в командах гибкой методологии разработки;
рассмотреть основные артефакты, которые создаёт СА в рамках водопадной модели.
чтобы подготовиться к вебинару, заранее изучите «теорию для ознакомления перед занятием» во вкладке «материалы».
Обследование, работа с требованиями
В рамках модуля подробно рассматриваются наиболее эффективные приемы выявления и обработки требований, а также рекомендации по их трассировке и управлению. Примечание: занятия, в которых есть теория для ознакомления перед занятием в формате видео, обозначены так: "// Предзапись".
Основные виды требований. Основные способы выявления требований. Подготовка к обследованию для выявления требований // ДЗ, предзапись
определить основные виды требований;
рассмотреть и использовать основные способы выявления требований;
рассмотреть методики работы с разными категориями стейкхолдеров;
подготовиться к процессу обследования и выявления требований.
чтобы подготовиться к вебинару, заранее изучите «теорию для ознакомления перед занятием» во вкладке «материалы».
ДЗ
Подготовка плана интервью и перечня вопросов.
Необходимо:
1. Проанализировать предложенную вам как аналитику ситуацию: https://docs.google.com/document/d/1hnodk_N1XAC4MdrGGdRl9ihiksETSFk9DEBIIjLb-Tc/edit?usp=sharing.
2. Определить основные темы, по которым необходимо провести интервью.
3. Составить список необходимых участников интервью.
4. По каждой теме составить перечень вопросов, ответы на которые необходимо получить.
5. Описать ожидаемые результаты встречи.
6. Предложить тайминг встречи.
Задание выполняется индивидуально и сдаётся в виде ссылки на документ Google Doc или на страницу в базе знаний (например, Confluence/Notion/Yonote) с подготовленным планом интервью.
Нефункциональные требования. Классификация, способы выявления, влияние на продукт // ДЗ, предзапись
рассмотреть различные НФТ;
определять степень влияния НФТ на продукт/проект.
чтобы подготовиться к вебинару, заранее изучите «теорию для ознакомления перед занятием» во вкладке «материалы».
ДЗ
Подготовка вопросов к ЗС в части НФТ для интервью.
В рамках подготовки к занятию №5 «Практикум 1. Групповая работа. Выявление требований» подготовить вопросы к ЗС в части НФТ (минимум 1 вопрос по каждой категории):
1. Производительность.
2. Безопасность.
3. Масштабируемость.
4. Надежность.
5. Совместимость.
6. Доступность.
7. Удобство использования.
8. Концептуальная целостность.
9. Ремонтопригодность.
10. Возможность повторного использования.
11. Поддерживаемость.
12. Тестируемость.
Задание выполняется индивидуально и сдаётся в произвольном формате (лучше в свободно открывающихся форматах, например, .pdf). Если используется онлайн-сервис (Miro/Holst, Google Doc и пр.), необходимо указать доступ по ссылке.
Практикум 1. Групповая работа. Выявление требований // ДЗ
подготовиться ко встрече по выявлению требований;
провести встречу по выявлению требований;
подготовить бриф по результатам встречи.
ДЗ
Описание требований.
Необходимо:
1. Все требования, выявленные в ходе практикума, формализовать и оформить в виде протокола требований по результатам каждой встречи. Шаблон протокола приложен к занятию.
2. Разбить список требований на три протокола по количеству интервьюируемых.
3. Отразить в списках все выявленные требования.
4. Зафиксировать открытые вопросы.
Задание выполняется индивидуально и сдаётся в виде ссылки на онлайн документ или статью в базе знаний (например, Confluence/Notion/Yonote).
Обработка и визуализация требований: Моделирование БП
научиться описывать сценарии использования приложения;
научиться читать схемы бизнес-процессов, смоделированных с использованием различных нотаций.
Обработка и визуализация требований: Моделирование БП BPMN // Предзапись
рассмотреть нотации моделирования процессов и получить базовые знания по работе с нотацией BPMN;
изучить правила работы с нотацией BPMN;
рассмотреть на практике различные схемы BPMN.
чтобы подготовиться к вебинару, заранее изучите «теорию для ознакомления перед занятием» во вкладке «материалы».
Практикум 2. Работа с нотацией BPMN // ДЗ
научиться моделировать БП в нотации BPMN 2.0;
научиться правильно выбирать нотацию;
поработать с инструментами.
ДЗ
Подготовка схемы бизнес-процесса в соответствии с требованиями в нотации BPMN.
Необходимо:
1. Проанализировать предложенное описание бизнес-процесса.
2. Проанализировать схему, подготовленную в рамках практикума, и внести в нее исправления в соответствии с описанным бизнес-процессом.
3. Подготовить схему бизнес-процесса нотации BPMN 2.0, описывающую все шаги процесса.
Задание выполняется индивидуально. Для сдачи работы отправьте преподавателю следующие файлы:
1) схему в формате .jpg или .png в высоком разрешении;
2) один исходник (например, в формате .bpmn).
Задачи документирования требований. Use Case // Предзапись
работать с диаграммой пользовательских сценариев (вариантов использования);
работать с описанием пользовательских сценариев.
обратите внимание, что в дополнительных материалах к занятию есть видеозапись, которую рекомендуется посмотреть перед занятием.
Практикум 3. Документирование требований Use Case // ДЗ
составить диаграмму Use Case;
описать основной и альтернативный сценарий использования.
ДЗ
Доработка диаграммы и описания Use Case.
Необходимо:
1. Завершить диаграмму Use Case, начатую на вебинаре (учесть комментарии + возможно внести собственные правки относительно работы в группе).
2. Детально описать сценарий для одного из вариантов использования: «Оформить заказ», «Отменить заказ», «Настроить состав меню» или «Настроить технологическую карту».
Задание выполняется индивидуально. Для сдачи работы отправьте преподавателю следующие файлы:
1) схему в формате .jpg или .png в высоком разрешении;
2) один исходник (например, в формате .bpmn).
Задачи документирования требований. User Story // Предзапись
научиться оптимально составлять пользовательские истории и объединять их в иерархии.
чтобы подготовиться к вебинару, заранее изучите «теорию для ознакомления перед занятием» во вкладке «материалы».
Практикум 4. Документирование требований. User Story // ДЗ
создать набор эпиков;
разбить эпики на набор пользовательских историй;
составить карту пользовательских историй.
ДЗ
Доработка набора пользовательских историй.
Необходимо:
1. Проанализировать требования к приложению, разрабатываемому в рамках проектной работы.
2. Подготовить пользовательские требования в виде User Story, описанные в рассмотренной на занятии структуре.
3. Описать минимум 15 пользовательских историй.
Задание выполняется индивидуально. Вы можете сдать работу с описанными требованиями в виде:
- ссылки на онлайн документ Google Doc;
- ссылки на виртуальную доску (например, Miro/Holst);
- ссылки на страницу в базе знаний (например, Confluence/Notion/Yonote).
Прототипирование, как инструмент работы с требованиями // ДЗ
понять разницу между прототипами, вайрфреймами и мокапами;
научиться использовать визуализацию экранных форм для выявления требований;
научиться подготавливать вайрфреймы экранов приложения;
научиться подготавливать прототипы экранных форм приложений.
ДЗ
Подготовка экранных форм приложения.
User Story:
Система должна предоставлять посетителю ресторана возможность оформить заказ. Это включает в себя возможность:
- ознакомиться с меню;
- добавить интересующие позиции в корзину;
- указать информацию «в зале» или «на вынос»;
- произвести оплату, после чего посетителю выдается талон с номером заказа.
Также при оформлении заказа необходимо учитывать, что если посетитель не зарегистрирован в нашей программе лояльности, нужно предложить ему это сделать.
После готовности заказа информация об этом отображается на информационном табло, после чего посетитель предъявляет талон и забирает свой заказ. При возникновении проблем с заказом пользователь должен получить информационное сообщение с призывом обратиться к менеджеру.
Задание:
Для представленного User Story роботизированного ресторана «Робот и точка» подготовить необходимые макеты экранов мобильного приложения. Минимальный набор из 5 экранных форм:
- каталог заказов;
- информацию «с собой» или «в зале»;
- проверки заказа;
- оплата;
- ошибка заказа.
Остальные экранные формы по необходимости.
Задание выполняется индивидуально. Экранные формы делаются в Balsamiq или Figma. Работа сдается в виде ссылки на облачные ресурсы или в формате файла с расширением .pdf.
Согласование требований. Управление изменениями, трассировка требований
научиться управлять согласованием требований и понимать зачем это надо;
научиться выстраивать процедуры работы с изменениями в разных методологиях работы;
научиться отслеживать требования.
Проектирование ПО
В модуле рассматриваются ключевые аспекты проектирования приложения: информационная модель и компонентная архитектура.
Этапы, задачи и виды проектирования
научиться декомпозировать задачи проектирования;
научиться выделять задачи по проектированию информационной, архитектурной, технологической и ресурсной составляющей приложения.
обратите внимание, что в дополнительных материалах к занятию есть видеозапись, которую рекомендуется посмотреть перед занятием.
Проектирование информационной модели приложения. Объектно-ориентированный подход
научиться выделять основные сущности приложения;
научиться определять атрибутивный состав сущностей;
научиться проектировать взаимосвязи сущностей;
научиться отображать информационную модель в виде диаграммы классов.
Domain Driven Design для построения модели предметной области
разобрать концепт ДДД;
научиться выделять поддомены и ограничивать контексты.
Практикум 5. Разработка базовой информационной модели // ДЗ
составить перечень объектов информационной системы;
описать взаимосвязи объектов;
сформировать диаграмму классов на языке UML.
ДЗ
Доработка модели предметной области.
Необходимо:
1. Доработать модель предметной области, которую проектировали на занятии (провалидировать атрибутику и сущности по требованиям и пользовательским сценариям).
2. Добавить сущности и их атрибутику для нового пользовательского сценария, который приложен к материалам занятия (Кейс-заказ еды в ресторане.docx).
3. Разработать диаграммы состояний для новых сущностей, добавляемых в рамках ДЗ (опционально).
Задание выполняется индивидуально. Для сдачи работы отправьте преподавателю следующие файлы:
1) схему в формате .jpg или .png в высоком разрешении;
2) один исходник (например, в формате .bpmn).
Архитектура информационных систем. Монолиты, SOA и микросервисы
рассмотреть описание, характерные свойства и характеристики разных моделей;
описать плюсы и минусы каждой модели;
выбрать подходящую архитектурную модель;
предложить способы описания взаимодействия компонентов приложения.
Методология интеграций приложений
описать основные типы межсервисного взаимодействия;
понять технологию работы очередей;
выбрать способ интеграции со сторонним приложением;
описать интеграционные взаимодействия.
Брокеры очередей и варианты их использования
понять, какие бывают варианты межсервисного взаимодействия;
научиться ставить задачи и проектировать системы с использованием брокером очередей.
Паттерны микросервисной архитектуры
научиться определять потребность в микросервисах в архитектуре;
научиться разделять систему микросервисов.
Практикум 6. Разработка архитектуры приложения // ДЗ
разработать архитектуру приложения;
определить состав и способ взаимодействия компонентов приложения;
определить способы интеграционного взаимодействия с внешними приложениями;
описать интеграционные взаимодействия с помощью диаграммы последовательности.
ДЗ
Доработка компонентной архитектуры приложения.
Необходимо:
1. Перевести диаграмму C4 на модель «Микросервисы» (1 и 2 уровень).
2. Сделать табличное описание всех компонентов приложения (само приложение, контейнеры внутри приложения), а также внешних систем. Описание должно давать понимание назначения контейнера, с чем он взаимодействует и для чего (если не показали на схеме).
3. Описать на диаграмме все потоки и интерфейсы. Для взаимодействий между сервисами нужны протоколы и подпись, какие именно данные передаются (информация о заказах, адреса, данные по брони и т.д.).
4. Сделать таблицу информационных потоков между системами. В таблице показываем контейнер-источник, контейнер-приемник, передаваемая информация (сущность или группа сущностей) и протокол взаимодействия (если не показали на схеме).
5. Добавить служебный слой (опционально).
6. Добавить другие внешние системы (опционально).
Задание выполняется индивидуально. Для сдачи работы отправьте преподавателю следующие файлы:
1) схему либо таблицу в формате .jpg или .png в высоком разрешении;
2) один исходник (например, в формате .bpmn).
Проработка интеграционного взаимодействия // ДЗ
научиться выбирать инструменты для описания интеграционных взаимодействий;
научиться описывать интеграционные взаимодействия;
научиться разрабатывать и читать диаграммы последовательности.
ДЗ
Разработка диаграммы последовательности.
Для приложения необходимо описать взаимодействие сервисов в рамках получения заказа и передачи его на кухню.
1. Описать общую схему взаимодействия.
2. Определить и описать альтернативное течение события.
3. Описать цикл из нескольких запросов при недоступности какого либо сервиса.
Задание выполняется индивидуально. Для сдачи работы отправьте преподавателю следующие файлы:
1) схему в формате .jpg или .png в высоком разрешении;
2) один исходник (например, в формате .bpmn).
Консультация по проектам и домашним заданиям
получить ответы на вопросы по ДЗ;
получить ответы на вопросы по проектной работе.
Проектирование API
В модуле с нуля проектируется REST API для создаваемого приложения.
Принципы работы API. RESTful API vs SOAP
рассмотреть отличия технологий построения веб сервисов RESTful API и SOAP;
выбрать наиболее подходящую технологию;
выбрать инструмент для тестирования API.
Проектирование структуры API собственного приложения, документирование API
рассмотреть принципы построения ресурсной модели API.
Практикум 7. Проектирование ресурсной модели Open API // ДЗ, предзапись
сформировать набор информации, который должен быть доступен для передачи/получения по API;
описать структуру объектов ресурсной модели;
описать атрибутивный состав и связи, в том числе с использованием PlantUML.
чтобы подготовиться к вебинару, заранее изучите «теорию для ознакомления перед занятием» во вкладке «материалы».
ДЗ
Подготовка описания сервиса API для проектируемого приложения и описания ресурсов.
Необходимо:
1. Рассмотреть следующие сценарии работы:
- UC-8 Оформление заказа.
- UC-9 Просмотр статуса заказа.
- UC-10 Добавление отзыва о заказанном блюде.
- UC-11 Просмотр истории заказов.
- UC-12 Повторение заказа.
2. Для одного из методов описать контракт по примеру из занятия. Результат – в формате MS Word или ссылка на Confluence.
3. Для трёх методов написать спецификацию OpenAPI. Результат – в виде ссылки на SwaggerHub. YAML или JSON – по желанию.
Задание выполняется индивидуально.
Наложение API на интеграцию фронтенд и бэкэнд части
связать спроектированные методы API с Use Case и формами пользовательского интерфейса.
Практикум 8. Групповая работа. Управление изменениями и трассировка требований
проработать в группах поступивший от Заказчика запрос на изменение требований;
выявить требования, требующие изменения;
условие: Заказчик вносит изменения в требования. СА обрабатывает изменения и трансформирует для меньшего влияния на проект.
Анализ данных
Модуль посвящён наиболее новой области знания для СА — работе с данными, как с источниками и инструментом расширения, и обогащения требований.
Базовые и продвинутые SQL процедуры на примере PostgreSQL
научиться составлять сложные процедуры и запросы для чтения и анализа данных.
Обобщенные табличные выражения (CTE) и оконные функции
использовать CTE в запросах; писать запросы с использованием оконных функций.
Анализ данных в PowerBI
научиться использовать инструмент Power BI Desktop для создания отчетов и анализа данных.
Практикум 9. Анализ данных с помощью Excel, SQL, PowerQuery // ДЗ
проанализировать массив технологических метрик;
выявить закономерности в загрузке ПО;
определить потенциальные точки для улучшения.
ДЗ
Использование SQL, Power Query и Excel.
Необходимо:
1. Подготовить SQL-запросы согласно заданию.
2. Подключиться к БД с помощью Power Query.
3. Подтянуть ранее составленные SQL-запросы в Excel с помощью Power Query.
4. Визуализировать полученные данные.
5. Сделать выводы.
Задание выполняется индивидуально и сдаётся в формате Excel.
Проектирование и работа с SQL/NoSQL БД
Модуль посвящён базам данных и ключевым аспектам участия СА в работе с БД.
SQL vs NoSQL. Особенности и хитрости работы с реляционными базами данных. Аспекты их применения
выбрать наиболее подходящую БД для ваших задач;
рассмотреть задачи и особенности применения реляционных СУБД.
Возможности и примеры использования NoSQL баз данных
рассмотреть разные NoSQL базы данных и их основные отличия, и решаемых задачах;
выбрать необходимую БД для решения конкретной задачи.
Подходы к проектированию баз данных
рассказать о проектировании БД исходя из требований;
рассмотреть особенности проектирования SQL / NoSQL БД.
Способы прогнозирования нагрузки на приложения. Способы повышения производительности БД
рассмотреть основные способы прогнозирования нагрузки на приложение;
найти необходимое средство масштабирования приложения и БД в зависимости от профиля нагрузки.
Практикум 10. Доработка архитектуры приложения с учетом предполагаемой нагрузки // ДЗ
рассчитать нагрузку на ваше приложение в виде количества запросов, количества одновременно работающих пользователей и объема загружаемой информации;
сформировать профиль нагрузки, предложить наиболее подходящее средство масштабирования приложения;
сформировать критерии для нагрузочного тестирования.
ДЗ
Оценка нагрузки на проектируемое приложение.
Необходимо:
Определить нагрузку на приложение на момент запуска в соответствии с алгоритмом, приведенным на занятии.
Составить прогноз по приросту нагрузки через 1 год/3 года/5 лет с обоснованием прироста:
1. указать требования к производительности;
2. рассчитать первичную нагрузку;
3. рассчитать количество пользователей;
4. рассчитать нагрузку на систему с учетом пользователей из п.3;
5. рассчитать размер БД;
6. сделать выбор БД.
Задание выполняется индивидуально и сдаётся в виде Excel-файла или ссылки на Google таблицу с описанием прогноза нагрузки.
Сопровождение процесса разработки
В этом модуле рассматриваются ключевые аспекты работы аналитика после завершения проектирования: постановка и контроль выполнения задач; производство и приемка результатов работ.
Сложности декомпозиции задач, критерии готовности и приемка // ДЗ
научиться оптимально декомпозировать задачи для себя и для команды разработки;
научиться четко формировать критерии готовности задач и их приемки.
ДЗ
Декомпозиция и критерии приемки.
Необходимо:
1. Выбрать одну из историй, описанных в рамках ДЗ по User Story, и предложить минимум три варианта её декомпозиции.
2. Выбрать минимум 4 истории, описанных в рамках ДЗ по User Story, и для каждой описать минимум три Acceptance Criteria.
3. Для каждой истории из пункта 2 подготовить минимум три задачи для разработчиков, приложив макет интерфейса и описав необходимые для реализации поля и функции.
Задание выполняется индивидуально.
Подходы к оформлению проектной документации
рассмотреть документы, которые готовятся по цифровому продукту;
познакомиться с разделами документов проекта, которые готовит аналитик;
рассмотреть различные подходы наполнения технического задания.
Системы контроля версий. GitFlow. Автоматизация доставки кода. CI\CD
рассмотреть принципы хранения кода в СКВ;
разобраться в структуре репозитория СКВ;
понять, какая версия кода развернута на стенде;
рассмотреть логику конвейера доставки изменений на стенды;
рассмотреть порядок разворачивания приложений, контролировать корректность с точки зрения архитектуры.
Практикум 11. Работа с репозиториями
создать commit;
отправить commit в репозиторий.
Контроль качества ПО // ДЗ
рассмотреть назначение различных видов тестирования;
подготовить acceptance criteria для всех видов тестирования;
подготовить чек-листы и тест-кейсы.
ДЗ
Тестовые сценарии.
Необходимо:
1. Проанализировать User Story, декомпозированные в рамках предыдущего ДЗ, и их критерии приёмки.
2. Минимум для трёх критериев приёмки описать тестовые сценарии (позитивный, 2-3 негативных) используя техники тест-дизайна.
3. Составить чек-лист для проверки продукта (5-7 пунктов).
Задание выполняется индивидуально и сдаётся в виде ссылки на документ Google Doc или на страницу в базе знаний (например, Confluence/Notion/Yonote) с перечнем задач.
Практикум 12. Тестирование ПО // ДЗ
подготовить план тестирования и тест-кейс для своего проекта;
подготовить чек-лист готовности ПО;
протестировать API.
ДЗ
Самооценка по компетенциям.
Необходимо оценить свои навыки в конце обучения в графе «На финише курса».
Задание выполняется индивидуально и сдаётся в виде ссылки на заполненную анкету в Google Doc. К документу должен быть открыт доступ по ссылке на просмотр. Внутри файла все группы, в которых проставлены оценки, должны быть развёрнуты.
Тестирование API
научиться использовать техники тестдизайна при тестировании API;
научиться тестировать запросы с использование Postman и SOAP UI;
научиться частично автоматизировать тестирование.
Проектная работа
Заключительный месяц курса посвящён проектной работе. Свой проект — это то, что интересно писать слушателю. То, что можно создать на основе знаний, полученных на курсе. При этом не обязательно закончить его за месяц. В процессе написания по проекту можно получить консультации преподавателей.
Консультация по проектам и домашним заданиям
получить ответы на вопросы по проекту, ДЗ и по курсу.
ДЗ
Проектная работа.
Необходимо:
1. Выбрать кейс автоматизированного ресторана или подготовить его.
2. Согласовать кейс с преподавателем, а также предупредить, если вы работаете в паре с другим студентом.
3. Подготовить документацию в соответствии с требованиями кейса.
4. Сделать презентацию по шаблону (прикреплен в материалах).
5. Сдать проектную документацию в чат с преподавателем.
6. На защиту вашего проекта дается 15 минут, более подробная информация дана на вебинаре к этому занятию.
7. Куратор проекта указан в кейсе или определяется в ходе согласования темы проектной работы.
Проектная работа выполняется индивидуально либо в паре с одногруппником. Если вы планируете работать в паре, предупредите об этом руководителя курса — Иннокентия Бодрова.
Защита проектных работ
защитить проект и получить рекомендации экспертов.
Подведение итогов курса
узнать, как получить сертификат об окончании курса, как взаимодействовать после окончания курса с OTUS и преподавателями, какие вакансии и позиции есть для выпускников (опционально — в России и за рубежом) и на какие компании стоит обратить внимание.