Модели разработки ПО Flashcards
(12 cards)
Водопадная модель
фазы проекта следуют строго друг за другом, выполняются однократно. Во время работы над этой фазой, команда видит только эту фазу проекта, никак не обращаясь к предыдущим. Модель достаточно устаревшая и сейчас мало используется. Плоха тем, что тестирование здесь появляется только на середине проекта.
Общее планирование > Пользовательские требования > Системные требования > Техническая архитектура > Детализированный дизайн > Разработка и отладка > Интеграция и модульные тесты > Инсталяционное тестирование > Системное тестирование > Приёмочное тестирование > Итоговая отчетность
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 помогает наладить такой
устойчивый процесс разработки.
Постоянное внимание к техническому совершенству и качеству
проектирования повышает гибкость проекта.
Простота — искусство минимизации лишней работы — крайне необходима.
Самые лучшие требования, архитектурные и технические решения рождаются
у самоорганизующихся команд.
Команда должна систематически анализировать возможные способы
улучшения эффективности и соответственно корректировать
стиль своей работы.
