Семинар ФКН: современные подходы к разработке ПО -...

СОВРЕМЕННЫЕПОДХОДЫ К РАЗРАБОТКЕПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

ХАРЬКОВСКИЙ НАЦИОНАЛЬНЫЙ УНИВЕРСИТЕТ ИМЕНИ В. Н. КАРАЗИНАФАКУЛЬТЕТ КОМПЬЮТЕРНЫХ НАУК

КАФ. ИСКУССТВЕННОГО ИНТЕЛЛЕКТА И ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

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

ПРАКТИКИ РАЗРАБОТКИSoftware Development Methods

ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Каскадная модель

Waterfall model

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

Принципы модели

модель состоит из набора фаз.

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

переходов назад либо вперёд илиперекрытия фаз — не происходит.

Основные фазы

Определение требований.

Проектирование.

Реализация.

Верификация (тестирование и отладка).

Инсталляция и поддержка.

Существует множество модификаций данной модели.

Критика модели

Недостаточная гибкость.

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

plan–do–check–act

Iterative modelИтеративная модель

Основные принципы

Программная система разделяется наэтапы (increments).

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


Исследование

Разработка.

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

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


Реализация

Переход.

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

На данной фазе система передается в промышленноеиспользование.


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

Архитекторы и аналитики обычно работаютна 1 шаг впереди, чем разработчики.

Сравнение с моделью водопада

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

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

Agile Software Development

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

Agile Manifesto

Люди и взаимодействие важнеепроцессов и инструментов.

Работающий продукт важнееисчерпыващей документации.

Сотрудничество с заказчиком важнеесогласований условий контракта.

Готовность к изменениям важнееследования первоначальному плану.


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

Изменение требованийприветствуется, даже на позднихстадиях разработки.


Agile-процессы позволяютиспользовать изменения дляобеспечения заказчикуконкурентного преимущества.

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


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

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


Непосредственное общение являетсянаиболее практичным и эффективнымспособом обмена информацией как ссамой командой, так и внутри команды.

Работающий продукт – основнойпоказатель прогресса.


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

Постоянное внимание к техническомусовершенству и качествупроектирования повышает гибкостьпроекта.


Простота – искусство минимизациилишней работы – крайне необходима.

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


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

Методология Scrum

Scrum Methodology

Scrum

Спринт (Sprint).

Скрам-мастер (Scrum Master).

Жестко фиксированные и небольшие по времени итерации.

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

Проводит совещания (Scrum Meeting) и следит за соблюдением всех принциповскрам, разрешает противоречия и защищает команду от отвлекающихфакторов.

Scrum

Владелец продукта (Product Owner).

Скрам-команда (Scrum Team).

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

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

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

XP Programming

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

Короткий цикл обратной связи

Разработка через тестирование.

Игра в планирование.

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

Используются бумажные карточки с пожеланиями заказчика (stories) ипримерный план работы по выпуску следующих версий продукта.Необходимым условием является разделение в принятии решений: заказчикпринимает бизнес-решения, команда разработчиков – технические решения.

Короткий цикл обратной связи

Заказчик всегда рядом.

Парное программирование.

Конечный пользователь программного продукта («заказчик») должен быть всёвремя на связи и доступен для вопросов.

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

Непрерывный процесс

Непрерывная интеграция.

Рефакторинг.

Интеграция должна выполнятся несколько раз в день после успешноговыполнения всех тестов.

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

Частые небольшие релизы.Готовые версии продукта (release) должны поступать в эксплуатацию какможно чаще. Каждая версия должна нести полезную бизнес-составляющую.

Понимание, разделяемое всеми

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

Метафора системы.Метафора системы являтся аналогом архитектуры – представления окомпонентах системы и их взаимодействии. Выбор хорошей метафорыоблегчает понимание системы разработчиками.

Понимание, разделяемое всеми

Коллективное владение кодом.

Стандарты кодирования.

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

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

Благосостояние программиста

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

Бережливая разработка

Lean Software Development

Принципы

Усиленное изучение.

Решай как можно позже.

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

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

Принципы

Доставляй как можно быстрее.

Доверие к команде и мотивация.

В современном мире выживает не большие, а быстрые. Чем быстрее продуктбудет доставлен без критических ошибок, тем быстрее будут получены отзывыпользователей, а значит факты для следующей итерации.Отлично работает стратегия «just-in-time», заключающаяся в определениинеобходимого результата и предоставлении возможности командесамоорганизоваться и выделить задачи, необходимые для достижениярезультата.

Со статистической точки зрения люди – это ресурсы, но в разработке ПО этосовсем не так. Людям необходима мотивация. Разработчик должен иметьдоступ к заказчику, а Team Lead должен быть вовлечен в поддержкупользователей в сложных ситуациях.Find good people and let them do their job.

Принципы

Целостность видения.

Интегрирование.

Современная программная система это не просто сумма своих частей, этопродукт их взаимодействия. Важным является стандартизация процессовразработки и разделение всем разработчиками принципов бережливости.Think big, act small, fail fast; learn rapidly!

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

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

TDD

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

Тест — это процедура, позволяющаяподтвердить либо опровергнутьработоспособность кода.

Test-Driven Development

Создание теста.

Запук всех тестов: тесты не проходят.

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

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


Написание кода.

Запук всех тестов: тесты проходят.

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

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


Рефакторинг.

Повторение цикла.

Когда функционально код готов, необходимо его «подчистить» - внестиизменения во внутреннюю структуру (не затрагивая функциональность, т.е. еевнешнюю структуру) с целью облегчить понимание, улучшить дизайн иустранить возможное дублирование кода.

Указанный цикл повторяется снова и снова, реализуя новую функциональностьнебольшими шагами – 1-10 изменений между запусками тестов. Если новыйкод не удовлетворяет новым тестам или старые тесты перестают проходить, тонеобходимо вернуться к отладке.

BDD

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

Behavior-Driven Development

User story (пользовательские истории).В BDD пользовательские истории выступают в качестве основных документов,описывающих поведение системы, над которым совместно работаютразработчики и бизнес-аналитики. Каждая user story должна иметьопределенную структуру.

Спецификация - Ubiquitous LanguageUbiquitous Language (общеупотребительный язык) - термин, использованныйЭриком Эвансом (Eric Evans, создатель Domain Driven Design) для описанияязыка, одинаково понятного разработчикам, так и пользователям .

Инструментальная поддержкаВажное значение в BDD (как и в TDD) отдается наличию инструментов,поддерживающих автоматизацию спецификаций и их проверку (JBehave,Cucumber и др.).

User story

Title (название).Каждая история должна иметь простое и понятное название.

Narrative (поветствование, содержание).Краткое описание, дающее ответы на следующие вопросы:

Who? – Кто является заинтересованной стороной в данной истории?Which? – Какой эффект заинтересованная сторона ожидает получит?What? – Что за бизнес-ценность будет получена от данного эффекта?

Acceptance criteria (критерии приемки).Описание сценариев приемки для каждого случая повествования в формате:

• Начальные условия (считающиеся выполнеными в начале сценария).• Определение события, которое начинает выполнение сценария.• Определение ожидаемого результата.

User story - примерAs a Scrum Master I want to see Lead/Cycle time progress.

As a Scrum MasterI want to see Lead/Cycle time progressSo that I know whether we are improving our development process or not.

Scenario #1Given Reports section in project and Bug Tracking practice is disabledWhen I navigate to Lead and Cycle Time ReportThen I see Lead Time chartAnd chart contains 1 line for stories

Scenario #2Given Reports section in project and Bug Tracking practice is disabledWhen I navigate to Lead and Cycle Time ReportThen I see Cycle TimeAnd chart contains 1 line for stories

TDD vs BDD

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

BDD понятно не только разработчикам.Одной из целей BDD является преодоление разрыва между разработчиками,тестировщиками и пользователями. Использование user story существеннооблегчает понимание.

Семинар ФКН: современные подходы к разработке ПО -...

Technology