exam05 3_1 - stankin/design-part-1 GitHub Wiki

Назначение и способы применения методологий RUP, Agile, XP, Scrum в разработке программных средств

Реферат к лекции 5. Проектирование и разработка программных средств.

Выполнил: Глущенко Дмитрий

Проверил: Беркаль Виктор

Основные термины: методология разработки программного обеспечения

Метод (от др.-греч. μέθοδος — путь исследования или познания, от μετά- + ὁδός «путь») — систематизированная совокупность шагов, действий, которые нацелены на решение определённой задачи или достижение определённой цели.

Методология (от греч. μεθοδολογία — учение о способах) — учение о методах, способах и стратегиях исследования предмета.

В методологии можно выделить следующую структуру:

  • Основания методологии: философия, логика, системология, психология, информатика, системный анализ, науковедение, этика, эстетика.
  • Характеристики деятельности: особенности, принципы, условия, нормы деятельности.
  • Логическая структура деятельности: субъект, объект, предмет, формы, средства, методы, результат деятельности, решение задач.
  • Временная структура деятельности: фазы, стадии, этапы.
  • Технология выполнения работ и решения задач: средства, методы, способы, приемы.

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

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

RUP

Методология RUP (Rational Unified Process) описывает абстрактный общий процесс, на основе которого организация или проектная команда должна создать специализированный процесс, ориентированный на ее потребности.

В основе RUP лежат следующие принципы:

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

Основные характеристики:

  1. Разработка требований. Для описания требований в RUP используются прецеденты использования (use cases). Каждый прецедент использования – это описание сценариев взаимодействия пользователя с системой, полностью выполняющего конкретную пользовательскую задачу. Все функциональные требования должны быть представлены в виде прецедентов использования.

  2. Итеративная разработка. Проект RUP состоит из последовательности итераций. Перед началом очередной итерации определяется набор прецедентов использования, которые будут реализованы к её завершению.

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

none

В терминах RUP участники проектной команды создают так называемые артефакты (work products), выполняя задачи (tasks) в рамках определенных ролей (roles). Артефактами являются спецификации, модели, исходный код и т.п. Задачи разделяются по девяти процессным областям, называемым дисциплинами (discipline):

  • Бизнес-моделирование (Business Modeling) – исследование и описание существующих бизнес-процессов заказчика, а также поиск их возможных улучшений.
  • Управление требованиями (Requirements Management) – определение границ проекта, разработка функционального дизайна будущей системы и его согласование с заказчиком.
  • Анализ и проектирование (Analysis and Design) – проектирование архитектуры системы на основе функциональных требований и ее развитие на протяжении всего проекта.
  • Реализация (Implementation) – разработка, юнит-тестирование и интеграция компонентов системы.
  • Тестирование (Test) – поиск и отслеживание дефектов в системе, проверка корректности реализации требований.
  • Развертывание (Deployment) – создание дистрибутива, установка системы, обучение пользователей.
  • Управление конфигурациями и изменениями (Configuration and Change Management) – управление версиями исходного кода и документации, процесс обработки запросов на изменение (Change requests).
  • Управление проектом (Project Management) – создание проектной команды, планирование фаз и итераций, управление бюджетом и рисками.
  • Среда (Environment) – создание инфраструктуры для выполнения проекта, включая организацию и настройку процесса разработки.

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

Agile

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

Гибкая методология разработки (англ. Agile software development) — серия подходов к разработке программного обеспечения, ориентированных на использование итеративной разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля.

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

Практически все аgile-команды сконцентрированы в одном офисе (bullpen). Офис включает product owner – заказчика, который и определяет требования к продукту. В качестве заказчика может выступать бизнес-аналитик, менеджер проекта или клиент. Кроме того, в офис могут входить и дизайнеры интерфейса, тестировщики, технические писатели. То есть методы Agile направлены в первую очередь на непосредственное общение.

Методы Agile были разработаны еще в начале 2000-х как альтернатива малоэффективным традиционным IT методам. Основной метрикой agile-методов является рабочий продукт. Отдавая предпочтение непосредственному общению, agile-методы уменьшают объём письменной документации по сравнению с другими методами.

Основные идеи гибкой методологии разработки:

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

Принципы Agile:

  • Удовлетворение клиента за счёт ранней и бесперебойной поставки ценного программного обеспечения.
  • Приветствие изменений требований даже в конце разработки.
  • Частая поставка рабочего программного обеспечения (каждый месяц, по возможности ещё чаще).
  • Тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта.
  • Проектом занимаются мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием.
  • Рекомендуемый метод передачи информации — личный разговор (лицом к лицу).
  • Работающее программное обеспечение — лучший измеритель прогресса.
  • Спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределённый срок.
  • Постоянное внимание улучшению технического мастерства и удобному дизайну.
  • Простота — искусство не делать лишней работы.
  • Лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды.
  • Постоянная адаптация к изменяющимся обстоятельствам.

Главные преимущества Agile:

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

XP

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

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

Основными принципы XP:

  1. Итеративность. Разработка ведется короткими итерациями при наличии активной взаимосвязи с заказчиком. За одну итерацию группа программистов обязана реализовать несколько свойств системы, каждое из которых описывается в пользовательской истории. Пользовательские истории (ПИ) являются начальной информацией, на основании которой создается модуль. ПИ пишутся самими пользователями, которые в XP являются частью команды.
  2. Простота решений. Принимается первое простейшее рабочее решение. Экстремальность метода связана с высокой степенью риска решения, обусловленного поверхностностью анализа и жестким временным графиком.
  3. Интенсивная разработка малыми группами (не больше 10 человек) и парное программирование (когда два программиста вместе создают код на одном общем рабочем месте), активное общение в группе и между группами. Все это нацелено на как можно более раннее обнаружение проблем (как ошибок, так и срыва сроков).
  4. Обратная связь с заказчиком, представитель которого фактически вовлечен в процесс разработки.
  5. Достаточная степень смелости и желание идти на риск.

Обычно XP характеризуют набором из 12 приемов (практик), которые могут быть объединены в четыре группы:

1. Короткий цикл обратной связи (Fine-scale feedback)

  • Разработка через тестирование (Test-driven development)
  • Игра в планирование (Planning game) — быстро сформировать приблизительный план работы и постоянно обновлять его по мере того, как условия задачи становятся всё более чёткими.
  • Заказчик всегда рядом (Whole team, Onsite customer)
  • Парное программирование (Pair programming) — предполагает, что весь код создается парами программистов, работающих за одним компьютером. Один из них работает непосредственно с текстом программы, другой просматривает его работу и следит за общей картиной происходящего.

2. Непрерывный, а не пакетный процесс

  • Непрерывная интеграция (Continuous integration) — интеграция кода всей системы выполняется несколько раз в день, после того, как разработчики убедились в том, что все тесты модулей корректно срабатывают.
  • Рефакторинг (Design improvement, Refactoring) — подразумевается, что однажды написанный код в процессе работы над проектом почти наверняка будет неоднократно переделан.
  • Частые небольшие релизы (Small releases) — версии (releases) продукта должны поступать в эксплуатацию как можно чаще. Работа над каждой версией должна занимать как можно меньше времени.

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

  • Простота (Simple design) — в процессе работы условия задачи могут неоднократно измениться, а значит, разрабатываемый продукт не следует проектировать заблаговременно целиком и полностью. Проектирование должно выполняться небольшими этапами. В каждый момент времени следует пытаться использовать наиболее простой дизайн, который подходит для решения текущей задачи.
  • Метафора системы (System metaphor) — разработчикам необходимо проводить анализ архитектуры программного обеспечения для того, чтобы понять, в каком месте системы необходимо добавить новую функциональность, и с чем будет взаимодействовать новый компонент.
  • Коллективное владение кодом (Collective code ownership) – означает, что каждый член команды несёт ответственность за весь исходный код. Таким образом, каждый вправе вносить изменения в любой участок программы.
  • Стандарт кодирования (Coding standard or Coding conventions) — необходимо добиться того, чтобы было сложно понять, кто является автором того или иного участка кода, — вся команда работает унифицировано, как один человек.

4. Социальная защищённость программиста (Programmer welfare)

  • 40-часовая рабочая неделя (Sustainable pace, Forty-hour week)

none

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

Scrum

Scrum (англ. «схватка») — методология гибкой разработки ПО. Scrum предоставляет эмпирический подход к разработке ПО. Этот процесс быстр, адаптивен, умеет подстраиваться и отличен от каскадной модели. Scrum основан на повторяющихся циклах, это делает его более гибким и предсказуемым. Методология делает акцент на качественном контроле процесса разработки.

Роли, которые участвуют в процессе:

  1. Scrum Мастер (Scrum Master)
  2. Владелец продукта (Product Owner)
  3. Команда (Team)

Scrum Мастер – самая важная роль в методологии. Scrum Мастер отвечает за успех Scrum в проекте. Эту роль в проекте играет менеджер проекта или лидер команды (Team Leader). Scrum Мастер отслеживает прогресс команды при помощи Sprint Backlog, отмечая статус всех задач в спринте. Scrum Мастер может также помогать заказчику создавать список задач для команды.

Основные обязанности Scrum Мастера:

  • Создает атмосферу доверия.
  • Участвует в митингах в качестве человека, обеспечивающего успешную групповую коммуникацию.
  • Устраняет препятствия.
  • Делает проблемы и открытые вопросы видимыми.
  • Отвечает за соблюдение практик и процесса в команде.

Владелец продукта (Product Owner) – это человек, отвечающий за разработку продукта. Обычно представитель заказчика. Владелец продукта – это единая точка принятия окончательных решений для команды в проекте, поэтому это всегда один человек, а не группа. Зачастую Владелец продукта ответственен за предоставление ресурсов Команде.

Команда (Team) – в методологии Scrum команда является самоорганизующейся и самоуправляемой. Команда берет на себя обязательства по выполнению объема работ на спринт перед Владельцем продукта. Работа команды оценивается как работа единой группы. В Scrum вклад отдельных членов проектной команды не оценивается, так как это разваливает самоорганизацию команды. Команда в Scrum кросс-функциональна: в нее входят люди с различными навыками – разработчики, аналитики, тестировщики. Нет заранее определенных и поделенных ролей в команде, ограничивающих область действий членов команды.

none

В основе методологии лежат короткие ежедневные встречи – Scrum-митинги и циклические 30-дневные встречи, называемые спринтом. Результатом спринта является промежуточный или готовый продукт, который можно передавать заказчику. Короткие спринты обеспечивают быструю обратную связь проектной команды с заказчиком. Заказчик получает возможность гибко управлять системой, оценивая результат спринта и предлагая улучшения к созданной функциональности. Такие улучшения попадают в список имеющихся на данный момент бизнес-требований и технических требований к системе (Product Backlog), приоритезируются наравне с прочими требованиями и могут быть запланированы на следующий спринт. В течение спринта делаются все работы по сбору требований, дизайну, кодированию и тестированию продукта. Цель спринта должна быть фиксированной. Это позволяет команде давать обязательства на тот объем работ, который должен быть сделан в спринте.

Вывод

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

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

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

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

SCRUM - методология гибкой разработки ПО, основанная на повторяющихся циклах и делающая акцент на качественном контроле процесса разработки. Характеризуется разделением вовлеченных в разработку людей на три типа: Scrum Master, Product Owner и Scrum Team. Каждая часть команды выполняет свои задачи, при этом участвуя в ежедневных Scrum-митингах и отчитываясь о результатах разработки по окончании спринта (1-4 недели).

❌ Так в чем все же назначение этих методологий и какие способы их применения известны?

Ссылки на источники

1. Технология разработки программного обеспечения

2. Методологии разработки программного обеспечения

3. Семь основных методологий разработки ПО