2 современные методы разработки ПО

Содержание

Слайд 2

Программная инженерия – систематический, дисциплинированный и измеримый подход к разработке программного обеспечения
Прикладная

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

Слайд 3

У любого программного обеспечения есть жизненный цикл — этапы, через которые оно

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

Слайд 4

Рассмотрим эти этапы на примере жизненного цикла интернет-магазина.

Подготовка. Иван решил запустить книжный интернет-магазин

Рассмотрим эти этапы на примере жизненного цикла интернет-магазина. Подготовка. Иван решил запустить
и начал анализировать, какие подобные сайты уже представлены в сети. Собрал информацию об их трафике, функциональности.
Проектирование. Иван выбрал компанию-подрядчика и обсудил с её специалистами архитектуру и дизайн будущего интернет-магазина.
Создание. Иван заключил с разработчиками договор. Они начали писать код, отрисовывать дизайн, составлять документацию.
Поддержка. Иван подписал акт сдачи-приёмки, и подрядчик разместил интернет-магазин на «боевых» серверах. Пользователи начали его посещать и сообщать о замеченных ошибках в поддержку, а программисты — оперативно всё исправлять.

Слайд 5

Модель разработки программного обеспечения описывает, какие стадии жизненного цикла оно проходит и что

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

Слайд 6

1 Каскадная модель, или «водопад»
разработка осуществляется поэтапно: каждая следующая стадия начинается после

1 Каскадная модель, или «водопад» разработка осуществляется поэтапно: каждая следующая стадия начинается
того, как заканчивается предыдущая. Если всё делать правильно, «водопад» будет наиболее быстрой и простой моделью
Преимущества «водопада»
Разработку просто контролировать. Заказчик может управлять сроками и ценой.
Стоимость проекта определяется на начальном этапе. Все шаги запланированы уже на этапе согласования договора, ПО пишется непрерывно.
Не нужно нанимать тестировщиков с серьёзной подготовкой. Тестировщики смогут опираться на подробную техническую документацию.
Недостатки каскадной модели
Тестирование начинается на последних этапах разработки. Если в требованиях к продукту была допущена ошибка, то исправить её будет стоить дорого. Обнаружат её, когда разработчик уже написал код, а технические писатели — документацию.
Заказчик видит готовый продукт в конце разработки и только тогда может дать обратную связь. Велика вероятность, что результат его не устроит.
Пишут много технической документации, что задерживает работы. 

Слайд 7

«Водопад» подходит для разработки проектов в медицинской и космической отрасли, где уже сформирована

«Водопад» подходит для разработки проектов в медицинской и космической отрасли, где уже
обширная база документов (СНиПов и спецификаций), на основе которых можно написать требования к новому ПО. 
При работе с каскадной моделью основная задача — написать подробные требования к разработке. На этапе тестирования не должно выясниться, что в них есть ошибка, которая влияет на весь продукт.

Слайд 8

2. V-образная модель (разработка через тестирование) Это усовершенствованная каскадная модель, в которой

2. V-образная модель (разработка через тестирование) Это усовершенствованная каскадная модель, в которой
заказчик с командой программистов одновременно составляют требования к системе и описывают, как будут тестировать её на каждом этапе.

Слайд 9

Преимущества V-образной модели
Количество ошибок в архитектуре ПО сводится к минимуму.
Недостатки V-образной модели
Если при

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

Слайд 10

3. Инкрементная модель
Это модель разработки по частям (increment в переводе с англ.

3. Инкрементная модель Это модель разработки по частям (increment в переводе с
— приращение)
Рассмотрим её на примере создания социальной сети.
Заказчик решил, что хочет запустить соцсеть, и написал подробное техническое задание. Программисты предложили реализовать основные функции — страницу с личной информацией и чат. А затем протестировать на пользователях.
Команда разработки показывает продукт заказчику и выпускает его на рынок. Если и заказчику, и пользователям социальная сеть нравится, работа над ней продолжается, но уже по частям.
Программисты параллельно создают функциональность для загрузки фотографий, обмена документами, прослушивания музыки и других действий, согласованных с заказчиком. Инкремент за инкрементом они совершенствуют продукт, приближаясь к описанному в техническом задании.

Слайд 11

Недостатки инкрементной модели
Каждая команда программистов разрабатывает свою функциональность и может реализовать интерфейс

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

Слайд 12

Преимущества инкрементной модели
Не нужно вкладывать много денег на начальном этапе. Заказчик оплачивает создание

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

Слайд 13

4. Итеративная модель Модель, при которой заказчик не обязан понимать, какой продукт хочет

4. Итеративная модель Модель, при которой заказчик не обязан понимать, какой продукт
получить в итоге, и может не прописывать сразу подробное техзадание.

Слайд 14

Рассмотрим на примере создания мессенджера
Заказчик решил, что хочет создать мессенджер. Разработчики сделали

Рассмотрим на примере создания мессенджера Заказчик решил, что хочет создать мессенджер. Разработчики
приложение, в котором можно добавить друга и запустить чат на двоих.
Мессенджер «выкатили» в магазин приложений, пользователи начали его скачивать и активно использовать. Заказчик понял, что продукт пользуется популярностью, и решил его доработать.
Программисты добавили в мессенджер возможность просмотра видео, загрузки фотографий, записи аудиосообщений. Они постепенно улучшают функциональность приложения, адаптируют его к требованиям рынка.

Слайд 15

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

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

Слайд 16

Недостатки итеративной модели
Использование на начальном этапе баз данных или серверов — первые сложно

Недостатки итеративной модели Использование на начальном этапе баз данных или серверов —
масштабировать, а вторые не выдерживают нагрузку. Возможно, придётся переписывать большую часть приложения.
Отсутствие фиксированного бюджета и сроков. Заказчик не знает, как выглядит конечная цель и когда закончится разработка.
Итеративная модель подходит для работы над большими проектами с неопределёнными требованиями, либо для задач с инновационным подходом, когда заказчик не уверен в результате. (Пример ПО для проведения чемпионатов WorldSkills)

Слайд 17

5. Спиральная модель заказчик и команда разработчиков серьёзно анализируют риски проекта и выполняют

5. Спиральная модель заказчик и команда разработчиков серьёзно анализируют риски проекта и
его итерациями. Последующая стадия основывается на предыдущей, а в конце каждого витка — цикла итераций — принимается решение , продолжать ли проект

.

Слайд 18

Рассмотрим, как функционирует эта модель, на примере разработки системы «Умный дом». 
Заказчик решил

Рассмотрим, как функционирует эта модель, на примере разработки системы «Умный дом». Заказчик
заказал программистам реализовать управление чайником с телефона. Они начали действовать по каскадной модели: провели анализ предложений на рынке, обсудили с заказчиком архитектуру системы, разработали, протестировали.
Заказчик оценил результат и риски: нужна ли пользователям следующая версия продукта – управление телевизором. Рассчитал сроки, бюджет и заказал разработку. Программисты по той же модели представили заказчику более сложный продукт на базе первого.
Заказчик решил создать функциональность для управления холодильником с телефона. Но, анализируя риски, понял, что в холодильник сложно встроить Wi-Fi-модуль, и производители не заинтересованы в сотрудничестве. Т.е. риски превышают потенциальную выгоду. Заказчик решил прекратить разработку и совершенствовать имеющуюся функциональность.

Слайд 19

Спиральная модель похожа на инкрементную, но здесь гораздо больше времени уделяется оценке

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

Слайд 20

На основе итеративной модели была создана 6. Agile — не модель и

На основе итеративной модели была создана 6. Agile — не модель и
не методология, а скорее подход к разработке.

Что такое Agile?
Agile («эджайл») переводится с английского как «гибкий». Включает в себя практики, подходы и методологии, которые помогают создавать продукт более эффективно:

Слайд 21

экстремальное программирование (ХР-все методы доводить до экстремальных: коллективное владение кодом, частые релизы,

экстремальное программирование (ХР-все методы доводить до экстремальных: коллективное владение кодом, частые релизы,
парное программирование, непрерывная интеграция, мах во всем…)
бережливую разработку программного обеспечения (lean из производства – сокращение всех потерь)
фреймворк для управления проектами Scrum (динамика, постоянное обсуждение, командный дух);
разработку, управляемую функциональностью
разработку через тестирование
методологию «чистой комнаты» (сертифицируемый уровень надежности)
итеративно-инкрементный метод разработки
методологию разработки Microsoft Solutions Framework
метод разработки динамических систем (постоянно меняется)
метод управления разработкой Kanban (принцип «точно в срок»)

Слайд 22

Не всё перечисленное в списке — методологии.
Например, Scrum чаще называют не

Не всё перечисленное в списке — методологии. Например, Scrum чаще называют не
методологией, а фреймворком. В чём разница? Фреймворк — это более сформированная методология со строгими правилами. В скраме все роли и процессы чётко прописаны. Помимо Scrum, часто используют Kanban. 
Фреймворк (каркас, каркасный подход) -
 программная платформа, определяющая структуру программной системы, программное обеспечение, облегчающее разработку и объединение разных компонентов большого программного проекта.

Слайд 23


Kanban - одна из наиболее популярных методологий разработки ПО. Команда ведёт работу

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

Слайд 24

Различия между Agile и традиционным подходом к разработке

:

Различия между Agile и традиционным подходом к разработке :
Имя файла: 2-современные-методы-разработки-ПО.pptx
Количество просмотров: 27
Количество скачиваний: 0