3 курс (заочка) / Лабораторная работа 1
.docxЛегковесные процессы разработки Поиск и создание продукта Хорошим примером данного процесса будет являться задача разработки сайта, размещенная интернет-магазином на одной из известных площадок. Организуется встреча с заказчиком (возможно общение по электронной почте), составляется ТЗ в свободной форме. Развитие продукта Заказчик пользовался сайтом на протяжении пары месяцев и теперь изъявил желание добавить кнопку лайков. По прошествии одной итерации сдается промежуточный продукт, и выявляются новые требования заказчика. Например, добавить функцию удаления уже поставленного лайка и изменить его внешний вид.
Сопровождение продукта Спустя 5 лет пользования сайтом, разработанном нами, выяснилось, что функция лайков не работает с устройства Xiaomi Redmi 4X через Яндекс.Браузер, и заказчик просит устранить данную проблему.
Разработка по требованиям 1) Список пожеланий 2) Создание бизнес-требований (документы, бизнес-кейсы, бизнес-процессы) 3) По ним создаются системные требования: варианты использования, спецификации 4) Они согласовываются, и создаются доработки
Идея: 1) Хотим добавить в существующую систему возможность «лайкать» товары. 2) Аналитик описывает как это происходит: нажимается кнопка «лайк», отображается в интерфейсе сердечко, и оно сохраняется на будущее 3) Системные требования: фронтенд получает макет, бэкэнд получает описание системы «лайков»: нужен метод, который принимает id товара, id клиента и добавляет лайк и метод который возвращает кол-во лайков под записью и поставил ли текущий клиент лайк. 4) Разработчики разбирают себе задачи и начинают выполнение.
Организация поддержки пользователей Идея: • Создать единый портал для обращений клиентов а также базу знаний с типовыми решениями проблем для интернет магазина. • Разбивать обращения на три типа : проблемы с наполнением сайта, технические неполадки на сайте, проблемы с покупкой товара (доставка,сроки,отмена покупки.) • Спроектировать SLA на каждый тип обращения.
Поиск или создание продукта
При разработке проекта для лабораторной работы мы используем данный процесс. Требования к лабораторной работе иногда достаточно непонятны и приходится часто переделывать то, что было реализовано на предыдущих итерациях. Так же мы не тратим время на документацию. Для выполнения лабораторной работы нам приходится часто общаться с преподавателем.
По моему мнению, это достаточно эффективный процесс разработки из-за того, что пользователи получают работающий продукт часто и могут применять его в работе. Но в то же время из-за этот процесса требует достаточно большое количество времени из-за меняющихся требований.
Развитие продукта
Для примера возьмём приложение для доставки еды. У нас уже имеется готовый продукт, но необходимо добавлять новые требования (фичи) и одновременно решать срочные запросы пользователей. К примеру, добавить отображение курьера на карте и расчет времени ожидания заказа. Единовременно нужно исправлять ошибки из-за которых приложение крашится. Таким образом выглядит данный процесс разработки.
Я считаю, что это не совсем подходящий процесс разработки для некоторых приложений, которые не требуют дальнейшего развития (узконаправленные). В современном мире достаточно часто требуется развивать продукт, чтобы привлекать новых пользователей и не терять старых.
Сопровождение продукта
При выпуске новой версии ОС выявляются баги и дефекты работы. Их необходимо исправить в короткий промежуток времени. Действительно, сопровождение требуется многим продуктам, так как пользовательские требования постоянно растут, а при реализации этих требований выявляются новые баги, которые необходимо срочно исправлять.
Разработка по требованиям
Данный метод разработки предполагает сбор, анализ и проектирование проектирование технических требований к продукту.
Главное отличие от легковесного подхода является наличие двух циклов: проектировочного и цикла разработки.
Все пользовательские требования попадают в список пожеланий. В порядке приоритета аналитики берут их в работу для выполнения анализа. Пожелание можно декомпозировать на несколько задач, чтобы распределить работу между несколькими аналитиками и проектировщиками. В результате работы над пожеланием, создаются новые требования или модифицируются существующие.
Когда техническая документация готова, ее можно выгрузить в любой удобный формат и распечатать, либо организовать цикл разработки на платформе Devprom ALM.
Передача требований в разработку происходит путем создания доработок. Доработку можно создать на весь документ, на все требования в документе или при помощи массовой операции "Реализовать" над произвольным подмножеством требований. После того как разработка распланирована, можно приступить к проработке документации на следующий релиз. Для этого создается бейзлайн с названием очередного этапа. Изменения, которые будут вноситься в документацию не повлияют на ранее запланированные доработки.
После выполнения доработок исходные требования помечаются как реализованные. После выпуска релиза можно приступать к разработке нового релиза.
Разработка по ГОСТ
Этот процесс очень похож на "Разработку по требованиям" с той разницей, что названия этапов проекта приведены в соответствие с ГОСТ-ом. Такой процесс можно применять и адаптировать в ситуациях, когда требуется формальное планирование и управление проектом на основе ГОСТ.
Весь проект делится на стадии, а каждая стадия состоит из нескольких этапов. В этом процессе сознательно перечислены не все стадии, а только ключевые, используемые при разработке и внедрении ПО.
Организация поддержки пользователей
Процесс поддержки программного продукта обычно включает в себя следующие этапы:
Сбор обращений пользователей через email, по телефону или через форму обратной связи.
Попытка быстро решить проблему при помощи имеющихся типовых решенийили при помощи документации.
Передача заявки разработчикам для исправления дефекта или реализации доработки.
Общение с пользователем с целью выяснения деталей, сообщение о сроках решения заявки.
Процессы поддержки и разработки отличаются сильно, в том числе у них различные цели, метрики и средства контроля. Поддержкой и разработкой занимаются отдельные команды, но при этом им необходимо:
обмениваться максимально полной информацией о заявке,
обмениваться актуальной документацией и ответами на часто задаваемые вопросы, исключая при этом потерю или искажение информации,
обмениваться сроками решения и статусами заявок,
чтобы общение разработчиков о реализации не затрагивало конечного пользователя.