3 курс (заочка) / Лабораторная работа 1

Легковесные процессы разработки     Поиск и создание продукта Хорошим примером данного процесса будет являться задача разработки сайта, размещенная интернет-магазином на одной из известных площадок.  Организуется встреча с заказчиком (возможно общение по электронной почте), составляется ТЗ в свободной форме.  Развитие продукта Заказчик пользовался сайтом на протяжении пары месяцев и теперь изъявил желание добавить кнопку лайков. По прошествии одной итерации сдается промежуточный продукт, и выявляются новые требования заказчика. Например, добавить функцию удаления уже поставленного лайка и изменить его внешний вид.

    Сопровождение продукта Спустя 5 лет пользования сайтом, разработанном нами, выяснилось, что функция лайков не работает с устройства Xiaomi Redmi 4X через Яндекс.Браузер, и заказчик просит устранить данную проблему.

Разработка по требованиям 1)    Список пожеланий 2)    Создание бизнес-требований (документы, бизнес-кейсы, бизнес-процессы) 3)    По ним создаются системные требования: варианты использования, спецификации 4)    Они согласовываются, и создаются доработки

Идея: 1)    Хотим добавить в существующую систему возможность «лайкать» товары. 2)    Аналитик описывает как это происходит: нажимается кнопка «лайк», отображается в интерфейсе сердечко, и оно сохраняется на будущее 3)    Системные требования: фронтенд получает макет, бэкэнд получает описание системы «лайков»:  нужен метод, который принимает id товара, id клиента и добавляет лайк и метод который возвращает кол-во лайков под записью и поставил ли текущий клиент лайк.   4)    Разработчики разбирают себе задачи и начинают выполнение.

Организация поддержки пользователей       Идея:             • Создать единый портал для обращений клиентов а также базу знаний с типовыми решениями проблем для интернет магазина.      • Разбивать обращения на три типа : проблемы с наполнением сайта, технические неполадки на сайте, проблемы с покупкой товара (доставка,сроки,отмена покупки.)     • Спроектировать SLA  на каждый тип обращения. 

 

 

 

 

Поиск или создание продукта

При разработке проекта для лабораторной работы мы используем данный процесс. Требования к лабораторной работе иногда достаточно непонятны и приходится часто переделывать то, что было реализовано на предыдущих итерациях. Так же мы не тратим время на документацию. Для выполнения лабораторной работы нам приходится часто общаться с преподавателем.

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

Развитие продукта

Для примера возьмём приложение для доставки еды. У нас уже имеется готовый продукт, но необходимо добавлять новые требования (фичи) и одновременно решать срочные запросы пользователей. К примеру, добавить отображение курьера на карте и расчет времени ожидания заказа. Единовременно нужно исправлять ошибки из-за которых приложение крашится. Таким образом выглядит данный процесс разработки.

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

Сопровождение продукта

При выпуске новой версии ОС выявляются баги и дефекты работы. Их необходимо исправить в короткий промежуток времени. Действительно, сопровождение требуется многим продуктам, так как пользовательские требования постоянно растут, а при реализации этих требований выявляются новые баги, которые необходимо срочно исправлять.

Разработка по требованиям

Данный метод разработки предполагает сбор, анализ и проектирование проектирование технических требований к продукту.

Главное отличие от легковесного подхода является наличие двух циклов: проектировочного и цикла разработки.

Все пользовательские требования попадают в список пожеланий. В порядке приоритета аналитики берут их в работу для выполнения анализа. Пожелание можно декомпозировать на несколько задач, чтобы распределить работу между несколькими аналитиками и проектировщиками. В результате работы над пожеланием, создаются новые требования или модифицируются существующие.

Когда техническая документация готова, ее можно выгрузить в любой удобный формат и распечатать, либо организовать цикл разработки на платформе Devprom ALM.

Передача требований в разработку происходит путем создания доработок. Доработку можно создать на весь документ, на все требования в документе или при помощи массовой операции "Реализовать" над произвольным подмножеством требований. После того как разработка распланирована, можно приступить к проработке документации на следующий релиз. Для этого создается бейзлайн с названием очередного этапа. Изменения, которые будут вноситься в документацию не повлияют на ранее запланированные доработки.

После выполнения доработок исходные требования помечаются как реализованные. После выпуска релиза можно приступать к разработке нового релиза.

Разработка по ГОСТ

Этот процесс очень похож на "Разработку по требованиям" с той разницей, что названия этапов проекта приведены в соответствие с ГОСТ-ом. Такой процесс можно применять и адаптировать в ситуациях, когда требуется формальное планирование и управление проектом на основе ГОСТ.

Весь проект делится на стадии, а каждая стадия состоит из нескольких этапов. В этом процессе сознательно перечислены не все стадии, а только ключевые, используемые при разработке и внедрении ПО.

Организация поддержки пользователей

Процесс поддержки программного продукта обычно включает в себя следующие этапы:

• Сбор обращений пользователей через email, по телефону или через форму обратной связи.

• Попытка быстро решить проблему при помощи имеющихся типовых решенийили при помощи документации.

• Передача заявки разработчикам для исправления дефекта или реализации доработки.

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

Процессы поддержки и разработки отличаются сильно, в том числе у них различные цели, метрики и средства контроля. Поддержкой и разработкой занимаются отдельные команды, но при этом им необходимо:

• обмениваться максимально полной информацией о заявке,

• обмениваться актуальной документацией и ответами на часто задаваемые вопросы, исключая при этом потерю или искажение информации,

• обмениваться сроками решения и статусами заявок,

• чтобы общение разработчиков о реализации не затрагивало конечного пользователя.