exam05 3
Выполнил Микешин Сергей, ИДБ-17-05
Проверила Торхова Анастасия, ИДБ-17-05
Методология разработки программного обеспечения – это система, представляющая собой процесс разработки программного обеспечения, состоящая из множества процессов и подпроцессов, порядок или состав которых может изменяться в зависимости от применяемой модели разработки и использующая определённые методы оценки и контроля, свойственные выбранной модели.
Адаптивные (гибкие) методологии нацелены на преодоление ожидаемой неполноты требований и их постоянного изменения.
Рассмотрим некоторые из них.
Методология RUP описывает абстрактный общий процесс, на основе которого организация или проектная команда должна создать специализированный процесс, ориентированный на ее потребности.
Основные характеристики:
-
Разработка требований. Для описания требований в RUP используются прецеденты использования (use cases). Каждый прецедент использования – это описание сценариев взаимодействия пользователя с системой, полностью выполняющего конкретную пользовательскую задачу. Все функциональные требования должны быть представлены в виде прецедентов использования.
-
Итеративная разработка. Проект RUP состоит из последовательности итераций. Перед началом очередной итерации определяется набор прецедентов использования, которые будут реализованы к её завершению.
Жизненный цикл проекта RUP состоит из четырех фаз: начало, проектирование, построение, внедрение. Последовательность этих фаз фиксирована, но число итераций, необходимых для завершения каждой фазы, определяется индивидуально для каждого конкретного проекта.
В терминах 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 software development, agile-методы) — серия подходов к разработке программного обеспечения, ориентированных на использование интерактивной разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля. К гибким методологиям относят экстремальное программирование, DSDM, Scrum, FDD, BDD и др.
Большинство гибких методологий нацелены на минимизацию рисков путём сведения разработки к серии коротких циклов, называемых итерациями, которые обычно длятся две-три недели. Каждая итерация сама по себе выглядит как программный проект в миниатюре и включает все задачи, необходимые для выдачи мини-прироста по функциональности: планирование, анализ требований, проектирование, программирование, тестирование и документирование. Хотя отдельная итерация, как правило, недостаточна для выпуска новой версии продукта, подразумевается, что гибкий программный проект готов к выпуску в конце каждой итерации. По окончании каждой итерации команда выполняет переоценку приоритетов разработки.
Практически все аgile-команды сконцентрированы в одном офисе (bullpen). Офис включает product owner – заказчика, который и определяет требования к продукту. В качестве заказчика может выступать бизнес-аналитик, менеджер проекта или клиент. Кроме того, в офис могут входить и дизайнеры интерфейса, тестировщики, технические писатели. То есть методы Agile направлены в первую очередь на непосредственное общение.
Методы Agile были разработаны еще в начале 2000-х как альтернатива малоэффективным традиционным IT методам. Основной метрикой agile-методов является рабочий продукт. Отдавая предпочтение непосредственному общению, agile-методы уменьшают объём письменной документации по сравнению с другими методами.
Основные идеи:
- Приоритет людей и общения над инструментами и процессами;
- Приоритет работающего продукта над полной документацией;
- Приоритет сотрудничества с заказчиков над утверждением контракта;
- Приоритет готовности меняться над следованием первоначально созданному плану.
Принципы Agile:
- удовлетворение клиента за счёт ранней и бесперебойной поставки ценного программного обеспечения;
- приветствие изменений требований даже в конце разработки (это может повысить конкурентоспособность полученного продукта);
- частая поставка рабочего программного обеспечения (каждый месяц или неделю или ещё чаще);
- тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта;
- проектом занимаются мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием;
- рекомендуемый метод передачи информации — личный разговор (лицом к лицу);
- работающее программное обеспечение — лучший измеритель прогресса;
- спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределённый срок;
- постоянное внимание улучшению технического мастерства и удобному дизайну;
- простота — искусство не делать лишней работы;
- лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды;
- постоянная адаптация к изменяющимся обстоятельствам.
Главные преимущества Agile:
- Качество web-продукта – вовлечение заказчика в процесс каждой итерации дает возможность корректировать процесс, что неизменно повышает качество.
- Высокая скорость разработки – итерация длится не более 3-х недель, к концу этого срока обязательно есть результат.
- Минимизация рисков – крупный проект дает возможность заказчику оплатить несколько итераций и в ходе работы понять, что он вовремя получит именно то, что хочет и за приемлемую цену. Водопадные модели (с применением спецификаций и технических заданий) таких возможностей не дают.
Экстремальное программирование (XP) – это упрощенная методология организации разработки программ для небольших и средних по размеру команд разработчиков, занимающихся созданием программного продукта в условиях неясных или быстро меняющихся требований.
Основными целями XP являются повышение доверия заказчика к программному продукту путем предоставления реальных доказательств успешности развития процесса разработки и резкое сокращение сроков разработки продукта. При этом XP сосредоточено на минимизации ошибок на ранних стадиях разработки. Практически все приемы XP направлены на повышение качества программного продукта.
Основными принципы XP:
- Итеративность. Разработка ведется короткими итерациями при наличии активной взаимосвязи с заказчиком. За одну итерацию группа программистов обязана реализовать несколько свойств системы, каждое из которых описывается в пользовательской истории. Пользовательские истории (ПИ) являются начальной информацией, на основании которой создается модуль. ПИ пишутся самими пользователями, которые в XP являются частью команды.
- Простота решений. Принимается первое простейшее рабочее решение. Экстремальность метода связана с высокой степенью риска решения, обусловленного поверхностностью анализа и жестким временным графиком.
- Интенсивная разработка малыми группами (не больше 10 человек) и парное программирование (когда два программиста вместе создают код на одном общем рабочем месте), активное общение в группе и между группами. Все это нацелено на как можно более раннее обнаружение проблем (как ошибок, так и срыва сроков).
- Обратная связь с заказчиком, представитель которого фактически вовлечен в процесс разработки.
- Достаточная степень смелости и желание идти на риск.
Обычно 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)
Процесс XP является неформальным, но требует высокого уровня самодисциплины. Если это правило не выполняется, то XP мгновенно превращается в хаотичный и неконтролируемый процесс. XP не требует от программистов написания множества отчетов и построения массы моделей. В XP каждый программист считается квалифицированным работником, который профессионально и с большой ответственностью относится к своим обязанностям.
Scrum предоставляет эмпирический подход к разработке ПО. Этот процесс быстр, адаптивен, умеет подстраиваться и отличен от каскадной модели. Scrum основан на повторяющихся циклах, это делает его более гибким и предсказуемым.
Роли, которые участвуют в процессе:
- Scrum Мастер (Scrum Master)
- Владелец продукта (Product Owner)
- Команда (Team)
Scrum Мастер – самая важная роль в методологии. Scrum Мастер отвечает за успех Scrum в проекте. Эту роль в проекте играет менеджер проекта или лидер команды (Team Leader). Scrum Мастер отслеживает прогресс команды при помощи Sprint Backlog, отмечая статус всех задач в спринте. Scrum Мастер может также помогать заказчику создавать список задач для команды.
Основные обязанности Scrum Мастера:
- создает атмосферу доверия;
- участвует в митингах в качестве фасилитатора – человека, обеспечивающего успешную групповую коммуникацию;
- устраняет препятствия;
- делает проблемы и открытые вопросы видимыми;
- отвечает за соблюдение практик и процесса в команде.
Владелец продукта (Product Owner) – это человек, отвечающий за разработку продукта. Обычно представитель заказчика для заказной разработки. Владелец продукта – это единая точка принятия окончательных решений для команды в проекте, поэтому это всегда один человек, а не группа.
Команда (Team) – в методологии Scrum команда является самоорганизующейся и самоуправляемой. Команда берет на себя обязательства по выполнению объема работ на спринт перед Владельцем продукта. Работа команды оценивается как работа единой группы. В Scrum вклад отдельных членов проектной команды не оценивается, так как это разваливает самоорганизацию команды. Команда в Scrum кроссфункциональна: в нее входят люди с различными навыками – разработчики, аналитики, тестировщики. Нет заранее определенных и поделенных ролей в команде, ограничивающих область действий членов команды.
В основе лежат короткие ежедневные встречи – Scrum и циклические 30-дневные встречи, называемые спринтом. Результатом спринта является готовый продукт, который можно передавать заказчику. Короткие спринты обеспечивают быструю обратную связь проектной команды с заказчиком. Заказчик получает возможность гибко управлять системой, оценивая результат спринта и предлагая улучшения к созданной функциональности. Такие улучшения попадают в список имеющихся на данный момент бизнес-требований и технических требований к системе (Product Backlog), приоритезируются наравне с прочими требованиями и могут быть запланированы на следующий спринт. В течение спринта делаются все работы по сбору требований, дизайну, кодированию и тестированию продукта. Цель спринта должна быть фиксированной. Это позволяет команде давать обязательства на тот объем работ, который должен быть сделан в спринте.
https://portal.tpu.ru/SHARED/i/IGSAVENKO/academic/Tab/Tab3/trpo_lections_230100_2014.pdf