Методы разработки ПО. Процессы и методы разработки ПО

1.

Методы разработки ПО
Процессы и методы разработки ПО

2.

Жизненный цикл программного обеспечения
Software development process процесс, посредством которого потребности пользователей преобразуются в
программный продукт
Жизненный цикл разработки ПО (System/Software Development Life Cycle, SDLC) — процесс, состоящий из
конкретных этапов, который начинается в момент принятия решения о необходимости создания ПО и
заканчивается в момент прекращения поддержки ПО разработчиками.

3.

Жизненный цикл программного обеспечения

4.

Стадия подготовки (анализ)
Жизненный цикл разработки ПО начинается со стадии анализа, во время которого участники процесса
обсуждают требования, предъявляемые к конечному продукту. Цель этой стадии – определение детальных
требований к системе. Кроме этого, необходимо убедиться
в том, что все участники правильно поняли
поставленные задачи и то, как именно каждое требование будет реализовано на практике.
Зачастую, в обсуждении участвуют также и специалисты по тестированию, которые уже на стадии разработки
требований могут вносить собственные пожелания и, при необходимости, корректировать процесс.
Таким образом, этот этап предполагает сбор требований к разрабатываемому программному обеспечению, их
систематизацию, документирование, анализ, а также выявление и разрешение противоречий.

5.

Стадия проектирования
На стадии проектирования (называемой также стадией дизайна и архитектуры) программисты и системные
архитекторы, руководствуясь требованиями, разрабатывают высокоуровневый дизайн системы.
Разнообразные технические вопросы, возникающие в процессе проектирования, обсуждаются со всеми
заинтересованными сторонами, включая заказчика. Определяются технологии, которые будут использоваться в
проекте, загрузка команды, ограничения, временные рамки и бюджет. В соответствии с уточненными
требованиями выбираются наиболее подходящие проектные решения.
Утвержденный
дизайн
системы
определяет
перечень
разрабатываемых
программных
компонентов,
взаимодействие с третьими сторонами, функциональные характеристики программы, используемые базы
данных и многое другое. Дизайн, как правило, закрепляется отдельным документом – дизайн-спецификацией
(Design Specification Document, DSD).
На этом этапе для упрощения визуализации процесса проектирования используются блок-схемы, диаграммы,
макеты

6.

Разработка
После того как требования и дизайн продукта утверждены, происходит переход к следующей стадии жизненного
цикла – непосредственно разработке. Здесь начинается написание программистами кода программы в
соответствии с ранее определенными требованиями.
Системные администраторы настраивают программное окружение, front-end программисты разрабатывают
пользовательский интерфейс программы и логику ее взаимодействия с сервером.
Кроме того, программисты пишут Unit-тесты для проверки правильности работы кода каждого компонента
системы, проводят ревью написанного кода, создают билды и разворачивают готовое ПО в программной среде.
Этот цикл повторяется до тех пор, пока все требования не будут реализованы.

7.

Документация
Этот этап выделяют достаточно условно, поскольку, как мы видели, те или иные документы создаются на всех
стадиях жизненного цикла программы. Тем не менее, помимо проектной документации и сопровождающих
разработку записей, существуют также и другие текстовые документы, описывающие, например, функции
программы и способы ее использования.
Всего существует четыре уровня документации:
– Архитектурная (проектная) – например, дизайн-спецификация. Это документы, описывающие модели,
методологии, инструменты и средства разработки, выбранные для данного проекта.
– Техническая – вся сопровождающая разработку документация. Сюда входят различные документы,
поясняющие работу системы на уровне отдельных модулей. Как правило, пишется в виде комментариев к
исходному коду, которые впоследствии структурируются в виде HTML-документов.
– Пользовательская – включает справочные и поясняющие материалы, необходимые конечному
пользователю для работы с системой. Это, к примеру, Readme и Userguide, раздел справки по программе.
– Маркетинговая – включает рекламные материалы, сопровождающие выпуск продукта. Ее цель – в красочной
форме представить функциональность и конкурентные преимущества продукта.

8.

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

9.

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

10.

Модели жизненного цикла, принципы и методологии
разработки программного обеспечения (ПО)

11.

Модели жизненного цикла
Среди моделей жизненного цикла программного обеспечения наиболее известны следующие:
1.
Каскадная модель (она же “водопадная” - waterfall)
2.
Итерационные модели (Iterative model)
3.
Спиральная модель (Spiral model)
4.
V - модель (V-model)

12.

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

13.

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

14.

Каскадная модель: плюсы и минусы
+
Полное документирование каждого этапа;
+
Четкое планирование сроков и затрат;
+
Прозрачность процессов для заказчика;
-
Необходимость утверждения полного объема требований к системе еще на первом этапе;
-
В случае необходимости внесения изменений требований позднее – возврат к первой стадии и переделка
заново всей проделанной работы;
-
Увеличение затрат средств и времени в случае необходимости изменения требований.

15.

Каскадная модель: когда использовать
– В проектах с четко определенными требованиями, для которых не предусматривается их изменений в
процессе разработки;
– Для проектов, которые мигрируют с одной платформы на другую. То есть, требования остаются те же,
меняется только системное окружение и/или язык программирования;
– Когда от компании-разработчика не требуется проводить тестирования – к примеру, его обеспечением
займется сам заказчик или сторонняя фирма.
По оценкам экспертов, значительная часть ERP-систем, программ, предназначенных для строительства,
медицины, работы с государственными контрактами, промышленностью и подобных фундаментальных
целей разрабатывается при помощи той или иной модификации «водопада».

16.

Итеративная модель
Итеративная модель – ориентирована на проекты, где требования могут меняться по ходу разработки. Проект
состоит из итераций (от 1-2 до 6 недель).
Каждая итерация может включать в себя этап анализа, проектирования, реализации, тестирования.
Имеет большие накладные расходы на организацию
процесса, чем каскадная модель, однако стоимость
исправления ошибки в зависимости от длительности
проекта не так высока.
Следующие методологии реализуют итеративную
модель: Scrum, XP, отчасти Kanban.

17.

Итеративная модель: плюсы и минусы
+
Раннее создание работающего ПО;
+
Гибкость – готовность к изменению требований на любом этапе разработки;
+
Каждая итерация – маленький этап, для которого тестирование и анализ рисков обеспечить проще, чем для
всего жизненного цикла продукта.
-
Каждая фаза – самостоятельна, отдельные итерации не накладываются;
-
Могут возникнуть проблемы с реализацией общей архитектуры системы, поскольку не все требования
известны к началу проектирования.

18.

Итеративная модель: когда использовать
– для крупных проектов;
– когда известны, по крайней мере, ключевые требования;
– когда требования к проекту могут меняться в процессе разработки
Итеративная модель является ключевым элементом так называемых «гибких» (Agile) подходов к разработке
программного обеспечения

19.

Спиральная модель
Спиральная модель – это модель процесса разработки программного
обеспечения с учетом рисков. Это комбинация модели водопада и
итеративной модели.
Суть ее в том, что весь процесс создания конечного продукта
представлен в виде условной плоскости, разбитой на 4 сектора, каждый
из которых представляет отдельные этапы его разработки: определение
целей, оценка рисков, разработка и тестирование, планирование
новой итерации.
Каждая фаза спиральной модели в разработке программного
обеспечения начинается с определения цели проектирования и
заканчивается тем, что клиент просматривает прогресс.
Радиус спирали в любой точке представляет собой затраты (стоимость)
проекта на данный момент, а угловой размер представляет прогресс,
достигнутый на текущий момент.

20.

Спиральная модель
Главная особенность спиральной модели – концентрация на возможных рисках. Для их оценки даже выделена
соответствующая стадия. Основные типы рисков, которые могут возникнуть в процессе разработки ПО:
— Нереалистичный бюджет и сроки;
— Дефицит специалистов;
— Частые изменения требований;
— Чрезмерная оптимизация;
— Низкая производительность системы;
— Несоответствие уровня квалификации специалистов разных отделов.

21.

Спиральная модель: плюсы и минусы
+
улучшенный анализ рисков;
+
хорошая документация процесса разработки;
+
гибкость – возможность внесения изменений и добавления новой функциональности даже на относительно
поздних этапах;
+
раннее создание рабочих прототипов
-
может быть достаточно дорогой в использовании;
-
управление рисками требует привлечения высококлассных специалистов;
-
успех процесса в большой степени зависит от стадии анализа рисков;
-
не подходит для небольших проектов.

22.

Спиральная модель: когда использовать
Когда требуются частые изменения.
Когда проект большой.
Когда требования нечеткие и сложные.
Когда изменения могут потребоваться в любое время.
Крупные и высокобюджетные проекты.
Подобная модель используется Агентстве перспективных оборонных исследовательских проектов (DARPA) США.

23.

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

24.

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

25.

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

26.

V - модель: когда использовать
В проектах, в которых существуют временные и финансовые ограничения;
Для задач, которые предполагают более широкое, по сравнению с каскадной моделью, тестовое покрытие.
V-модель используется для управления процессом разработки программного обеспечения для немецкой
федеральной администрации. Сейчас она является стандартом для немецких правительственных и оборонных
проектов, а также для производителей ПО в Германии.

27.

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

28.

Гибкие методологии разработки

29.

Agile, что это?
Гибкая методология разработки (agile software development, agile-разработка) — обобщающий термин для
целого ряда подходов и практик, основанных на ценностях Манифеста гибкой разработки программного
обеспечения (Agile Manifesto) и 12 принципах, лежащих в его основе.
Применяется как эффективная практика организации труда небольших групп (которые делают однородную
творческую работу) в объединении с управлением ими комбинированным (либеральным и демократическим)
методом.
Большинство гибких методологий нацелены на минимизацию рисков путём сведения разработки к серии коротких
циклов, называемых итерациями, которые обычно длятся две-три недели. Каждая итерация сама по себе выглядит
как программный проект в миниатюре и включает все задачи, необходимые для выдачи мини-прироста по
функциональности: планирование, анализ требований, проектирование, программирование, тестирование и
документирование. Хотя отдельная итерация, как правило, недостаточна для выпуска новой версии продукта,
подразумевается, что гибкий программный проект готов к выпуску в конце каждой итерации. По окончании каждой
итерации команда выполняет переоценку приоритетов разработки.

30.

Agile
Agile не похож на предшествующие подходы, которые описывали процесс разработки в деталях.
Agile краток: состоит из 4-х ценностей и 12-ти принципов
Ценности Agile :

31.

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

32.

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

33.

Agile - философия, а гибкие методологии разработки - ее
реализация

34.

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

35.

Kanban
Cистема постановки задач и организации рабочих процессов для эффективного достижения поставленных целей.
Японское слово «канбан» означает «рекламный щит» или «вывеска», а методология, получившая это название,
позволяет регулировать процесс за счет обмена специальными карточками.
Любая задача/проект/активность разбивается на последовательные этапы. Канбан-доску можно сравнить с
движением автобуса, где конечная — это финальная цель, остановки — промежуточные этапы, а сам автобус —
карточки на канбан-доске. Все участники доски знают, какова конечная цель команды, видят, какие существуют
промежуточные этапы, когда и кому нужно подключиться. Таким образом, главное преимущество канбана —
хорошая визуализация процессов.
Имеет всего 3 правила:
• визуализация процесса разработки с помощью канбан-доски
• ограничение на количество задач на каждом этапе
• постоянное измерение производительности команды и улучшения.

36.

Kanban - доска

37.

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