Модели разработки ПО Flashcards
Водопадная модель
фазы проекта следуют строго друг за другом, выполняются однократно. Во время работы над этой фазой, команда видит только эту фазу проекта, никак не обращаясь к предыдущим. Модель достаточно устаревшая и сейчас мало используется. Плоха тем, что тестирование здесь появляется только на середине проекта.
Общее планирование > Пользовательские требования > Системные требования > Техническая архитектура > Детализированный дизайн > Разработка и отладка > Интеграция и модульные тесты > Инсталяционное тестирование > Системное тестирование > Приёмочное тестирование > Итоговая отчетность
V-образная модель
Является логическим развитием водопадной модели. Разница этой модели в том, что здесь на каждом этапе происходит контроль текущего процесса, чтоб убедиться в том, что переход на следующую стадию возможен. Для каждого этапа предусмотрен свой тест-план. Во время тестирования на текущем этапе, идёт разработка стратегии тестирования следующего, определяются ожидаемые результаты тестирования, критерии выхода.
Итерационная инкрементальная модель
Данный подход отличается тем, что процесс разработки разделен на отдельные стадии - итерации, итогом итерации является улучшение - инкремент.
Модель итерационная, так как все действия повторяются, модель инкрементальная, так как с каждой итерацией происходит добавление новых функций. Каждая итерация может включать в себя элементы других моделей, например водопадной. В конце каждой итерации мы получаем промежуточный билд
Тестирование присходит на протяжении всей разработки
Спиральная модель
Разновидность итерационно-инкрементальной модели. Особое внимание здесь уделяется управлению рисками. Вся разработка разбита на 4 сектора: определение целей, оценка рисков, разработка и тестирование, планирование новой итерации. Как и следует из названия, модель изображается в виде спирали, которая начавшись на этапе планирования, раскручивается с прохождением каждого шага. На выходе из каждого витка мы в итоге получаем готовый протестированный прототип, который дополняет существующий билд.
В 1 поле - Определение задач, альтернатив и ограничений - требования собираются от клиентов, цели определяются, анализируются. Затем предлагаются альтернативные решения
Во 2 поле - Оценка альтернатив, выделение рисков, способы борьбы с ними. Оцениваются все возможные решения, выбираются лучшие. Затем выявляются риски, связанные с этим решением, они устраняются с использованием налиучшего решения. Создается прототив для наилучшего возможного решения. Риск - любая неблагоприяная ситуация, которая может повлиять на успех проекта
В 3 поле - Разрабокта и верификация очередной части продукта. Выбранные функции разрабатываются и проверяются посредством тестирования.
В 4 поле - Планирование следующих итераций - Заказчики оценивают текущий билд, полученный в результате 3 поля, планируется следующий этап.
Agile
Agile-манифест
Agile - набор методов и принципов гибкого управления проектами
Преимущества - можно менять требования, возврашаться к предудищим итерациям
Agile-манифест
4 основополагающих ценности:
Люди и взаимодействе важнее процессов и инструментов. Если в команде есть принципы, условия, инструменты которые могут помешать работе, то от них нужно избавляться, а наоборот строить рабочий процесс, так чтобы все способствовало плодотворному взаимодействию
Работающий продукт важнее исчерпывающей документации. Документация не должна быть избыточной и на нее не нужно тратить слишком много времени и ресурсов
Сотрудничество с заказчиков важнее согласнования условий контракта. Не должно быть строгой привиязки к контракту, в первую очередь комфортное сотрудничество и хорошие отношения
Готовность к изменениям важнее следования первоначальному плану
Scrum
Scrum — это набор правил для организации гибкого рабочего процесса, который заключается в командном подходе, работе итерациями, фокусировке на цели каждой итерации и нестандартном распределении обязанностей внутри коллектива
Scrum команда
Product owner - Управление бэклогом продукта, описание бэклога. Это наборт тех требований, которые должны быть реализованы, чтобы продукт работал. Продакт овнер работает с этими требованиями, занимается их описанием, уточнением, делает его понятным для команды разработки, расставляет приоритеты. Бизнес аналитику в скраме нет, его задачи выполняет продакт оунер
Development team - команда разработки. 3-9 человек обычно. Когад проект гибкий, постоянно происходят изменения, с небольшой командой проще работать. Свойственны: самоорганизация (не нужен руководитель, который говорит, что нужно делать. Каждый голос должен быть услышан), Кроссфункциональность (каждый участинк обладает всеми необходимыми компетенциями, чтобы выполнять и другую работу над проектом), коллективная ответственность.
Scrum master - отдельный человек, который знает все о скраме, знает как он должен работать, знает этапы, артефакты, помогает, обучает, направляет команду. В разработке не участвует, может подсказать как лучше сделать.То есть он фасилитирует работу команды и отвечает за то, чтобы все работали согласну скраму
События в SCRUM
Спринт - временной отрезок (обычно 2-4 недели), в течение которого создается инкремент продукта.
Планирование спринта - сбор скрам команды, проводится в начале спринта. Решается каким будет инкремент в конце спринта. Как организвать работу
Ежедневный скрам - daily scrum. Проводится раз в день. Что ты делал вчера? Что ты будешь делать сегодня? Какие есть препятствия для выполнения цели?
Обзор спринта - Подводим итоги спринта, что реализовали, все ли задачи выполнены. Демо - демонстрация инкремента заказчику. На обзоре спринта демо не показывается, это отдельное мероприятие
Ретроспектива - Основная цель чтобы выяснить все ли задачи выполнены, но по отношению к людям. То есть как улучшить процесс. Что шло хорошо в спринте? Какие проблемы были в спринте? Как можно улучшить работу? Озвучивание идей.
Артефакты SCRUM
Бэклог продукта
Уточнение бэклога продукта (Product Backlog Refinement) - цель мероприятие - уточнение, оценка и упорядочивание элементов в бэклоге.
Критерии подготовленности и критерии готовности - Definition of Ready, Definition of Done
Критерии подготовленности фокусируются на уровне бэклога. То есть есть какие-то юзер-стори в бэклоге, и мы оцениваем насколько хорошо и понятно они прописаны.
Критерии готовности фокусятся на уровне спринта или релиза. Они относятся к оценке степени готовности функциональности.
Пользовательские истории (User Stories) - формулировка намерения, описывающая что-то что система должна делать для пользователя
As a (Role)
I can (Functionality)
So that (Rationale)
Acceptance Criteria
Пример: как новый пользователь в системе я бы хотел купить телефон
Критерии приёмки - Acceptance Criteria
То есть это требование, которое мы должны реализовать
Покер планирование - оценка юзер стори
Каждый по разному оценивает сложность и важность юзер стори. Если мнение участников команды отличается, происходит обсуждение
У задач есть стори поинты (очки), которые определяют насколько сложной является задачей. Цель - вместе с командой прийти к общему значению для задач
Бэклог спринта - что именно реалзиуется в спринте
Просто из бэклога продукта что-то перетягиватся сюда.
Инкремент продукта - все то что разработали ДО и разрабатываем в данной итерации
Экстремальное программирование
Экстремальное программирование или XP, eXtreme Programming — гибкая методология разработки программного обеспечения. На основе agile
Название методологии исходит из идеи применить полезные традиционные методы и практики разработки программного обеспечения, подняв их на новый «экстремальный» уровень. Так, например, практика выполнения ревизии кода, заключающая в проверке одним программистом кода, написанного другим программистом, в «экстремальном» варианте представляет собой «парное программирование», когда один программист занимается кодированием, а его напарник в это же время непрерывно просматривает только что написанный код.
Непрерывная интеграция (Continuous integration) — В XP интеграция кода всей системы выполняется несколько раз в день, после того, как разработчики убедились в том, что все тесты модулей корректно срабатывают
Рефакторинг (Design improvement, Refactoring) — XP подразумевает, что однажды написанный код в процессе работы над проектом почти наверняка будет неоднократно переделан.
Тесты модулей позволяют разработчикам убедиться в том, что их код работает корректно. Они также помогают другим разработчикам понять, зачем нужен тот или иной фрагмент кода и как он функционирует.
Простота (Simple design) — XP исходит из того, что в процессе работы условия задачи могут неоднократно измениться, а значит, разрабатываемый продукт не следует проектировать заблаговременно целиком и полностью. Проектирование должно выполняться небольшими этапами, с учётом постоянно изменяющихся требований. В каждый момент времени следует пытаться использовать наиболее простой дизайн, который подходит для решения текущей задачи, и менять его по мере того, как условия задачи меняются.
Коллективное владение кодом (Collective code ownership) или выбранными шаблонами проектирования (Collective patterns ownership) -означает, что каждый член команды несёт ответственность за весь исходный код. Таким образом, каждый вправе вносить изменения в любой участок программы. Парное программирование поддерживает эту практику: работая в разных парах, все программисты знакомятся со всеми частями кода системы. Важное преимущество коллективного владения кодом — в том, что оно ускоряет процесс разработки, поскольку при появлении ошибки её может устранить любой программист.
Стандарт кодирования (Coding standard or Coding conventions) — в рамках XP необходимо добиться того, чтобы было сложно понять, кто является автором того или иного участка кода, — вся команда работает унифицированно, как один человек.
Kanban
подход к реализации принципов agile при разработке ПО.
Методика предполагает обсуждение производительности в режиме реального времени и полную прозрачность рабочих процессов. Рабочие задачи визуально представлены на доске Kanban, что позволяет участникам команды видеть состояние каждой задачи в любой момент времени.
Kanban включает в себя два простых правила:
производственная станция имеет план производства деталей («backlog»). План отсортирован по приоритету, и может меняться в любое время (к примеру станция производящая слишком много левых зеркал должна иметь возможность переключиться на правые как можно скорее);
количество задач, выполняемых на станции одновременно ограничено (т.е. производить не более заданного количества зеркал одновременно). Это ограничение необходимо для управления скоростью производства на станции, а также скоростью реагирования на изменения плана.
Разница между скрам и канбан - В Scrum наша цель — закончить спринт, в Kanban — задачу
Scrum имеет более определенную структуру, которой в Kanban меньше. Kanban является менее структурированным и основывается на списке задач, которые нужно выполнить. Kanban не имеет установленного периода времени, когда элементы должны быть выполнены.
Основополагающие ценности Agile-манифеста
Мы следуем таким принципам:
Наивысшим приоритетом для нас является удовлетворение потребностей
заказчика, благодаря регулярной и ранней поставке ценного программного
обеспечения.
Изменение требований приветствуется, даже на поздних стадиях разработки.
Agile-процессы позволяют использовать изменения для обеспечения заказчику
конкурентного преимущества.
Работающий продукт следует выпускать как можно чаще, с периодичностью
от пары недель до пары месяцев.
На протяжении всего проекта разработчики и представители бизнеса должны
ежедневно работать вместе.
Над проектом должны работать мотивированные профессионалы. Чтобы
работа была сделана, создайте условия, обеспечьте поддержку и полностью
доверьтесь им.
Непосредственное общение является наиболее практичным и эффективным
способом обмена информацией как с самой командой, так и внутри команды.
Работающий продукт — основной показатель прогресса.
Инвесторы, разработчики и пользователи должны иметь возможность
поддерживать постоянный ритм бесконечно. Agile помогает наладить такой
устойчивый процесс разработки.
Постоянное внимание к техническому совершенству и качеству
проектирования повышает гибкость проекта.
Простота — искусство минимизации лишней работы — крайне необходима.
Самые лучшие требования, архитектурные и технические решения рождаются
у самоорганизующихся команд.
Команда должна систематически анализировать возможные способы
улучшения эффективности и соответственно корректировать
стиль своей работы.
