Видос 1 (3)

1.

Команда разработки
• Менеджер проекта — это человек, который отвечает за успешное выполнение проекта. Он планирует
работу, распределяет задачи между членами команды, следит за соблюдением сроков и бюджета, а
также решает возникающие проблемы.
• Аналитик – человек, который стоит между бизнесом и командой разработки. Он собирает и выявляет
требования к будущему продукту или функционалу, а затем переводит их на понятный язык.
• Дизайнер интерфейсов – специалист, который создает внешний вид сайтов (приложений). Он создает
удобные и интуитивно понятные интерфейсы, обеспечивает простую и понятную навигацию. При
создании интерфейсов руководствуются требованиями, которые составили аналитики.
• Разработчик - создаёт программный код, чтобы реализовать задуманные функции приложения.
Разрабатывает приложение в соответствии с требованиями, которые сформулировали аналитики.
• DevOps инженер - автоматизирует процессы разработки и эксплуатации программного обеспечения.
DevOps-инженеры настраивают инструменты, которые ускоряют сборку, тестирование и
развёртывание кода, а также обеспечивают непрерывную работу сервисов.
• Тестировщик - проверяет, работает ли программа так, как задумано. Тестировщики ищут ошибки в
приложении, проверяют, насколько удобно пользоваться продуктом, и оценивают его
производительность.

2.

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

3.

Жизненный цикл ПО
Планирование, проектирование и дизайн
На
стадии
проектирования
программисты,
руководствуясь
требованиями,
разрабатывают
дизайн системы, т.е. планируют как будут
реализовывать
требования.
Определяются
технологии,
инструменты,
языки
программирования, которые будут использоваться в
проекте

4.

Жизненный цикл ПО
Разработка ПО
После того как требования и дизайн продукта
утверждены, происходит переход к следующей
стадии жизненного цикла – непосредственно
разработке.
Здесь
начинается
написание
программистами кода программы в соответствии с
ранее определенными требованиями. Frontend
программисты разрабатывают
пользовательский интерфейс, для этого они берут
макеты, которые сделали дизайнеры и переводят их
в компьютерный код, а backend разработчики
создают логику работы приложения, а также
занимаются базами данных, которые хранят всю
информацию приложения.

5.

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

6.

Жизненный цикл ПО
Развертывание и сопровождение
Когда программа протестирована и в ней больше не
осталось серьезных дефектов, приходит время
релиза и передачи ее конечным пользователям.
После выпуска новой версии программы в работу
включается отдел технической поддержки. Его
сотрудники обеспечивают обратную связь с
пользователями, их консультирование и поддержку.
В случае обнаружения пользователями тех или
иных пост-релизных багов, информация о них
передается в виде отчетов об ошибках команде
разработки, которая, в зависимости от серьезности
проблемы,
либо
немедленно
выпускает
исправление (т.н. hot-fix), либо откладывает его до
следующей версии программы.

7.

Монолит
Микросервисы
Монолит — это подход к разработке
программного
обеспечения,
при
котором приложение представляет
собой
единую
программу.
В
монолитной
архитектуре
все
компоненты приложения тесно связаны
друг с другом, и изменение одного
компонента может повлиять на работу
всего приложения.
Микросервисы — это подход к
разработке программного обеспечения,
при котором приложение разделено на
небольшие
независимые
сервисы.
Каждый микросервис выполняет свою
функцию и может быть разработан,
развёрнут и масштабирован отдельно
от других.

8.

Плюсы монолитной архитектуры
Минусы монолитной архитектуры
• Простота разработки и тестирования
Все компоненты находятся в одной
кодовой базе, что упрощает разработку и
тестирование.
• Скорость запуска и развёртывания
Запуск и развёртывание монолитных
приложений происходит быстрее, чем
микросервисных.
• Меньше сложности
Монолитные
приложения
проще
разрабатывать и поддерживать на
начальных этапах.
• Зависимость компонентов:
Изменение одного компонента может
повлиять на работу всего приложения.
• Трудности масштабирования:
Масштабирование
монолитного
приложения
может
потребовать
значительных изменений в коде.
• Ограниченная гибкость:
Монолитные приложения менее гибкие,
чем микросервисы.
• Проблемы с безопасностью:
Если уязвимость обнаруживается в одном
компоненте, она может распространиться
на всё приложение.

9.

Плюсы микросервисной архитектуры
Минусы микросервисной архитектуры
• Гибкость
Микросервисы позволяют легко вносить
изменения
в
отдельные
части
приложения без влияния на другие его
части.
• Масштабируемость
Можно масштабировать только те
микросервисы,
которые
в
этом
нуждаются, не затрагивая остальные.
• Независимость
Каждый
микросервис
может
использовать свой собственный стек
технологий и базу данных.
• Возможность
параллельной
разработки
Разные команды могут работать над
разными
микросервисами
одновременно.
• Сложность разработки и поддержки
Разработка и поддержка микросервисной
архитектуры требует больше усилий, чем
монолитной.
• Коммуникация
Между микросервисами должна быть
налажена эффективная коммуникация,
чтобы
избежать
проблем
с
производительностью и надёжностью.
• Тестирование
Сложнее тестировать взаимодействие
между микросервисами.
• Безопасность
Необходимо обеспечить безопасность
каждого
микросервиса
и
их
взаимодействия.

10.

Методологии разработки
ПО разработки
Agile – это гибкие методологии
Agile-методологии направлены на создание продукта, который будет соответствовать
требованиям заказчика, в условиях меняющихся требований и неопределённости.
Разработка сводится к тому что разрабатывает продукт поэтапно, заказчик может видеть
проделанную работу и вносить свои коррективы.
Scrum – методология разработки ПО при
которой
задачи
на
разработку
распределяются на спринты. Спринты это
короткий период времени обычно от двух
до четырех недель. В течение спринта
выполняются только те задачи, которые
были запланированы, исключением могут
быть, только критичные баги. Перед
каждым
спринтом
проходит
планирование спринта. После каждого
спринта Ретро – встреча на которой
команда обсуждает результаты спринта.
Kanban – методология разработки ПО при
которой задачи берутся в работу из
бэклога задач. Задача берется исходя из
приоритета.

11.

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

12.

Agile доска

13.

Тестирование ПО – проверка соответствия между реальным и
ожидаемым поведением программы.
Основные задачи тестировщика
Изучение требований
Составление тестовой
документации
Проведение тестирования
Локализация ошибок
Обнаружение,
документирование и
отслеживание дефектов
Подведение итогов по
результатам тестирования

14.

Принципы тестирования
Тестирование показывает наличие
дефектов
Исчерпывающее тестирование невозможно
Тестирование может показать наличие
дефектов в программе, но не доказать их
отсутствие. В то же время, даже если
дефекты не были найдены в процессе
тестирования, нельзя утверждать, что их
нет.
Невозможно провести исчерпывающее
тестирование, которое бы покрывало все
комбинации пользовательского ввода и
состояний системы, за исключениями
совсем уж примитивных случаев.
Раннее тестирование
Скопление дефектов
Следует начинать тестирование на ранних
стадиях жизненного цикла разработки
ПО, чтобы найти дефекты как можно
раньше.
Разные модули системы могут содержать
разное количество дефектов – то есть,
плотность скопления дефектов в разных
элементах программы может отличаться.
Большая часть дефектов находится в
ограниченном количестве модулей.

15.

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