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

1. СОВРЕМЕННЫЕ
ПОДХОДЫ К РАЗРАБОТКЕ
ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
ХАРЬКОВСКИЙ НАЦИОНАЛЬНЫЙ УНИВЕРСИТЕТ ИМЕНИ В. Н. КАРАЗИНА
ФАКУЛЬТЕТ КОМПЬЮТЕРНЫХ НАУК
КАФ. ИСКУССТВЕННОГО ИНТЕЛЛЕКТА И ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
К.Ф.М.Н., ДОЦ. КАФ. ИСКУССТВЕННОГО ИНТЕЛЛЕКТА И ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
ГАХОВ АНДРЕЙ ВЛАДИМИРОВИЧ

2. ПРАКТИКИ РАЗРАБОТКИ
Software Development Methods
ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

3. Каскадная модель
Waterfall model

4. Первое формальное описание «модели
водопада» было дано в статье У. У.
Ройса (Winston W. Royce) 1970 года, в
которой он представил эту модель и
описал ее недостатки.

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

6. Основные фазы
Определение требований.
Проектирование.
Реализация.
Верификация (тестирование и отладка).
Инсталляция и поддержка.
Существует множество модификаций данной модели.

7. Критика модели
Недостаточная гибкость.
Самоцель - формальное управление
проектом в ущерб срокам, стоимости
и качеству.

8. plan–do–check–act
Iterative model
Итеративная модель

9. Основные принципы
Программная система разделяется на
этапы (increments).
На каждом этапе каждая порция
функциональности продукта
проходит все фазы от разработки
требований до доставки (deployment).

10. Основные фазы
Исследование
Разработка.
На данной фазе оценивается масштаб проекта,
функциональные и нефункциональные требования, риски
и происходит оценка работы.
На данной фазе разрабатывается архитектура с учетов
уменьшения рисков и нефункциональных требований.

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

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

13. Сравнение с моделью водопада
В моделе водопада бизнес-ценность
появляется один раз и в самом конце
разработки проекта.
В итерационной модели возможна
обратная связь и коррекция процесса.

14. Agile Software Development

15. В феврале 2001 г. в штате Юта, США
был выпущен «Agile Manifesto» как
альтернатива управляемым
документацией, «тяжеловесным»
практикам разработки ПО.

16. Agile Manifesto
Люди и взаимодействие важнее
процессов и инструментов.
Работающий продукт важнее
исчерпыващей документации.
Сотрудничество с заказчиком важнее
согласований условий контракта.
Готовность к изменениям важнее
следования первоначальному плану.

17. Основные принципы
Найвысший приоритет –
удовлетворение потребностей
заказчика благодаря регулярной и
ранней поставке ценного ПО.
Изменение требований
приветствуется, даже на поздних
стадиях разработки.

18. Основные принципы
Agile-процессы позволяют
использовать изменения для
обеспечения заказчику
конкурентного преимущества.
Работающий продукт следует
выпускать как можно чаще, с
периодичностью от 2х недель до 2х
месяцев.

19. Основные принципы
На протяжении всего проекта
разработчики и представители бизнеса
должны ежедневно работать вместе.
Над проектом должны работать
мотивированные профессионалы.
Чтобы работа была сделана, создайте
условия, обеспечьте поддержку и
полностью доверьтесь им.

20. Основные принципы
Непосредственное общение является
наиболее практичным и эффективным
способом обмена информацией как с
самой командой, так и внутри команды.
Работающий продукт – основной
показатель прогресса.

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

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

23. Основные принципы
Команда должна систематически
анализировать возможные способы
улучшения эффективности и
соотвественно корректировать стиль
своей работы.

24. Методология Scrum
Scrum Methodology

25. Scrum
Спринт (Sprint).
Скрам-мастер (Scrum Master).
Жестко фиксированные и небольшие по времени итерации.
Возможности ПО к реализации на очередном спринте определяются в начале
спринта на этапе планирования и не могут изменяться на всем его
протяжении. При этом строго фиксированная небольшая длительность придает
процессу разработки предсказуемость и гибкость.
Проводит совещания (Scrum Meeting) и следит за соблюдением всех принципов
скрам, разрешает противоречия и защищает команду от отвлекающих
факторов.

26. Scrum
Владелец продукта (Product Owner).
Скрам-команда (Scrum Team).
Представляет интересы конечных пользователей и других заинтересованных
сторон.
Команда разработчиков проекта, состоящая из специалистов разных профилей:
тестировщиков, архитекторов, аналитиков, программистов и т.д. Размер
команды в идеале 5-9 человек. Команда является единственным полностью
вовлеченным в процесс участником и отвечает за результат как единое целое.
Никто, кроме команды не может вмешиваться в процесс разработки на
протяжении спринта.

27. Экстремальное программирование
XP Programming

28. Подход экстремального
программирования создал Кент Бек
(Kent Beck) и описал в своей книге
«Extreme Programming Explained -
Embrace Change» в 1999 году.

29. Короткий цикл обратной связи
Разработка через тестирование.
Игра в планирование.
Основное внимание уделяется тестированию модулей (unit testing) и
функциональному тестированию. Тесты позволяют быть уверенному в
правильности кода, понять назначение того или иного фрагмента кода, логику
работы. Наличие тестов являются неободимым условием рефакторинга.
Приоритетным является подход Test Driven Development (TDD, разработка через
тестирование) - сначала пишется тест, а потом реализуется логика.
Используются бумажные карточки с пожеланиями заказчика (stories) и
примерный план работы по выпуску следующих версий продукта.
Необходимым условием является разделение в принятии решений: заказчик
принимает бизнес-решения, команда разработчиков – технические решения.

30. Короткий цикл обратной связи
Заказчик всегда рядом.
Парное программирование.
Конечный пользователь программного продукта («заказчик») должен быть всё
время на связи и доступен для вопросов.
При парном программировании исходный код создаётся парами людей,
программирующих одну задачу, сидя за одним рабочим местом. Один
программист («driver») управляет компьютером и думает над кодированием в
деталях. Другой программист («navigator») сосредоточен на картине в целом и
непрерывно просматривает код, производимый первым программистом.
Обычно, каждые полчаса они меняются ролями. Как правило, такие пары не
фиксированы и могут меняться при решении разных задач.

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

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

33. Понимание, разделяемое всеми
Коллективное владение кодом.
Стандарты кодирования.
Каждый член команды несет отвественность за весь код. Действует правило:
«Испортил - исправь». Парное программирование и наличие хорошего набора
тестов, позволяет не беспокоиться при изменениях любого участка кода.
Команда должна сформировать набор правил и все члены команды должны
их соблюдать. Не нужно тратить много времени на первоначальный набор
правил – сделайте их простыми и усложняйте только при необходимости.

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

35. Бережливая разработка
Lean Software Development

36. Принципы
Усиленное изучение.
Решай как можно позже.
Процесс разработки – это непрерывный процесс изучения. Вместо добавления
большего количества документации или более детального планирования
разные идеи должны быть опробованы в коде! Процесс изучения ускоряется
за счет коротких итераций (каждая из которых сопровождается рефакторингом
и интеграционными тестами). Благодаря коротким периодам заказчик и
разработчики лучше понимают как потребности пользователей, так и
особенности предметной области. Обязательны частые контакты с заказчиком.
Лучшие результаты получаются за счет подхода, основанного на разработке
продукта по опциям. Принимаем решение с задержкой до тех пор, пока новая
опция не будет основываться на реальных фактах, а не предположениях. Это
не означает отсутствие планирования!

37. Принципы
Доставляй как можно быстрее.
Доверие к команде и мотивация.
В современном мире выживает не большие, а быстрые. Чем быстрее продукт
будет доставлен без критических ошибок, тем быстрее будут получены отзывы
пользователей, а значит факты для следующей итерации.
Отлично работает стратегия «just-in-time», заключающаяся в определении
необходимого результата и предоставлении возможности команде
самоорганизоваться и выделить задачи, необходимые для достижения
результата.
Со статистической точки зрения люди – это ресурсы, но в разработке ПО это
совсем не так. Людям необходима мотивация. Разработчик должен иметь
доступ к заказчику, а Team Lead должен быть вовлечен в поддержку
пользователей в сложных ситуациях.
Find good people and let them do their job.

38. Принципы
Целостность видения.
Интегрирование.
Современная программная система это не просто сумма своих частей, это
продукт их взаимодействия. Важным является стандартизация процессов
разработки и разделение всем разработчиками принципов бережливости.
Think big, act small, fail fast; learn rapidly!
Заказчик получает целостный продукт, отдельные компоненты системы
работают хорошо друг с другом как единое целое. Целостность достигается
изучением предметной области и решением задачи в одно и тоже время (а не
последовательно).
Главным инструментом сохранения целостности системы выступает
рефакторинг (и тестирование).

39. ТЕХНИКИ РАЗРАБОТКИ
Software Development techniques

40. TDD
Test-Driven Development (TDD) —
техника разработки ПО, которая
основывается на повторении очень
коротких циклов разработки: тест ->
код -> рефакторинг.
Тест — это процедура, позволяющая
подтвердить либо опровергнуть
работоспособность кода.

41. Test-Driven Development
Создание теста.
Запук всех тестов: тесты не проходят.
Добавление каждой новой функциональности начинается с написания тестов.
Для успешного написания тестов необходимо понимать требования,
рассмотрев все возможные сценарии.
После написания новых тестов необходимо убедиться, что они не проходят –
иначе тест написан не верно или необходимая функциональность уже
присутствует в системе.

42. Test-Driven Development
Написание кода.
Запук всех тестов: тесты проходят.
Необходимая функциональность реализуется в коде, причем главной целью
является прохождение теста. Не следует добавлять лишней функциональности,
которая не покрыта тестом.
Если тесты проходят, следовательно разработанный код удовлетворяет всем
требованиям. Пришло время для улучшения кода.

43. Test-Driven Development
Рефакторинг.
Повторение цикла.
Когда функционально код готов, необходимо его «подчистить» - внести
изменения во внутреннюю структуру (не затрагивая функциональность, т.е. ее
внешнюю структуру) с целью облегчить понимание, улучшить дизайн и
устранить возможное дублирование кода.
Указанный цикл повторяется снова и снова, реализуя новую функциональность
небольшими шагами – 1-10 изменений между запусками тестов. Если новый
код не удовлетворяет новым тестам или старые тесты перестают проходить, то
необходимо вернуться к отладке.

44. BDD
Behavior-Driven development (BDD) -
процесс разработки ПО, основанный на
TDD, но использующий также идеи
дизайна на основе предметной области
(DDD) с целью разработки ПО
«имеющего смысл».

45. Behavior-Driven Development
User story (пользовательские истории).
В BDD пользовательские истории выступают в качестве основных документов,
описывающих поведение системы, над которым совместно работают
разработчики и бизнес-аналитики. Каждая user story должна иметь
определенную структуру.
Спецификация - Ubiquitous Language
Ubiquitous Language (общеупотребительный язык) - термин, использованный
Эриком Эвансом (Eric Evans, создатель Domain Driven Design) для описания
языка, одинаково понятного разработчикам, так и пользователям .
Инструментальная поддержка
Важное значение в BDD (как и в TDD) отдается наличию инструментов,
поддерживающих автоматизацию спецификаций и их проверку (JBehave,
Cucumber и др.).

46. User story
Title (название).
Каждая история должна иметь простое и понятное название.
Narrative (поветствование, содержание).
Краткое описание, дающее ответы на следующие вопросы:
Who? – Кто является заинтересованной стороной в данной истории?
Which? – Какой эффект заинтересованная сторона ожидает получит?
What? – Что за бизнес-ценность будет получена от данного эффекта?
Acceptance criteria (критерии приемки).
Описание сценариев приемки для каждого случая повествования в формате:
• Начальные условия (считающиеся выполнеными в начале сценария).
• Определение события, которое начинает выполнение сценария.
• Определение ожидаемого результата.

47. User story - пример
As a Scrum Master I want to see Lead/Cycle time progress.
As a Scrum Master
I want to see Lead/Cycle time progress
So that I know whether we are improving our development process or not.
Scenario #1
Given Reports section in project and Bug Tracking practice is disabled
When I navigate to Lead and Cycle Time Report
Then I see Lead Time chart
And chart contains 1 line for stories
Scenario #2
Given Reports section in project and Bug Tracking practice is disabled
When I navigate to Lead and Cycle Time Report
Then I see Cycle Time
And chart contains 1 line for stories

48. TDD vs BDD
BDD – это «правильное» TDD.
BDD делает упор на то, какой система должна быть, в то время как TDD
больше озабочено тем, как реализовать систему. Очень часто в TDD
разработчики настолько увлечены тем, «как» сделать тест, забывая «для чего»
необходимо его сделать, отрываясь от проблем и задач предметной области.
BDD понятно не только разработчикам.
Одной из целей BDD является преодоление разрыва между разработчиками,
тестировщиками и пользователями. Использование user story существенно
облегчает понимание.