Унифицированный процесс разработки ПС

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

Унифицированный процесс компонентно ориентирован. Это означает, что создаваемая программная система строится на основе программных компонентов, связанных хорошо определенными интерфейсами.

Специфичные аспекты UP заключаются в трех его характеристиках:

● управляется вариантами использования;

● является архитектурно-ориентированным;

● является итеративным и инкрементным.

Жизненный цикл унифицированного процесса

Жизненный цикл UP разбивается на циклы, каждый из которых завершается поставкой выпуска продукта. Каждый цикл развития состоит из четырех фаз — анализа и планирования требований, проектирования, построения, внедрения. Каждая фаза подразделяется на итерации.

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

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

 

18. XP – процесс.

Экстрема́льное программи́рование (англ. Extreme Programming, XP) — одна из гибких методологий разработки программного обеспечения. Авторы методологии — Кент Бек, Уорд Каннингем, Мартин Фаулер и другие.

Двенадцать основных приёмов экстремального программирования (по первому изданию книги Extreme programming explained) могут быть объединены в четыре группы:

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

a. Разработка через тестирование (Test driven development)

b. Игра в планирование (Planning game)

c. Заказчик всегда рядом (Whole team, Onsite customer)

d. Парное программирование (Pair programming)

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

a. Непрерывная интеграция (Continuous Integration)

b. Рефакторинг (Design Improvement, Refactor)

c. Частые небольшие релизы (Small Releases)

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

a. Простота (Simple design)

b. Общение

c. Уважение

d. Коллективное владение кодом (Collective code ownership) или выбранными шаблонами проектирования (Collective patterns ownership)

e. Стандарт кодирования (Coding standard or Coding conventions)

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

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

В XP процесс делится на очень маленькие ступеньки, по сравнению с планируемыми процессами. Это приводит к тому, что первые шаги могут занимать дни или недели вместо месяцев или даже лет для каждой ступени в модели «водопад». Сначала пишутся автоматические тесты, чтобы описать цели разработки. Потом идёт кодирование, которое заканчивается в тот момент, когда все тесты проходят, и программисты не могут придумать новых тестов. Дизайн делается теми же людьми, которые пишут код. (только последняя ступень — соединение дизайна и кода является общим для всех гибких процессов). Незаконченная, но функционирующая система показывается узкому кругу пользователей (чаще всего это сами разработчики). В этот момент начинают писать тесты для следующей наиболее важной части системы.

 

19. ICONIX – процесс.

ICONIX разработал Дуг Розенберг в компании ICONIX Software. Процесс ICONIX основан на вариантах испльзования, но не характеризуется множеством его недостатков. В этом процессе также применяется язык моделирования UML, но используется только базовая нотация из UML – это 20% языка. В основу процесса ICONIX положены четыре основных этапа разработки ПО на основе вариантов использования:

● моделирование предметной области;

● моделирование прецедентов;

● анализ пригодности требований (проверка на выполнение всех функциональных требований);

● построение диаграмм последовательности.

Основные этапы процесса следующие:

● Анализ требований

● Предварительное проектирование

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

● Реализация

Процесс основан на построении минимального количества моделей, которые отражают будущую систему. На этапе анализа создаются модели прецедентов (Use Case), модель пользовательского интерфейса и модель сущностей предметной области. На этапе предварительного проектирования создается диаграмма пригодности (Robustness Diagram). Также дополняется модель прецедентов и модель сущностей предметной области. На этапе детального проектирования создается диаграмма последовательности (SequenceDiagram) и создается диаграмма классов. На этапе реализации создается исходный код. При этом возможно создание диаграммы развертывания и диаграммы компонентов. каждый этап завершается вехой рецензирования, когда созданные диаграммы необходимо обсудить с коллегами.

 

20. SCRUM – процесс.

Scrum — это набор принципов, на которых строится процесс разработки, позволяющий в жёстко фиксированные небольшие промежутки времени (спринты от 2 до 4 недель) предоставлять конечному пользователю работающее ПО с новыми возможностями, для которых определён наибольший приоритет. Возможности ПО к реализации в очередном спринте определяются в начале спринта на этапе планирования и не могут изменяться на всём его протяжении. При этом строго-фиксированная небольшая длительность спринта придаёт процессу разработки предсказуемость и гибкость.

Главные действующие роли в Scrum: ScrumMaster — тот, кто ведёт Scrum митинги и следит, чтобы при этом соблюдались все принципы Scrum (роль не предполагает ничего кроме корректного ведения самого Scrum -а, руководитель проекта скорее относится к Product Owner и не должен являться ScrumMaster); Владелец Продукта (Product Owner) — человек, который представляет интересы конечных пользователей и других заинтересованных в продукте сторон; и кросс-функциональная Команда (Scrum Team), состоящая как из разработчиков, так и из тестировщиков, архитекторов, аналитиков и т. д. (при этом размер команды в идеале составляет 7±2 человека). Команда является единственным полностью вовлечённым участником разработки, и отвечает за результат как единое целое. Никто кроме команды не может вмешиваться в процесс разработки на протяжении спринта.

На протяжении каждого спринта создаётся функциональный рост программного обеспечения. Набор возможностей, которые реализуются в каждом спринте, происходят из этапа, называемого product backlog (документация запросов на выполнение работ), обладающего наивысшим приоритетом по уровню требований к работе, который должен быть выполнен. Запросы на выполнение работ (backlog items), определенных на протяжении совета по планированию спринта (sprint planning meeting), перемещаются в этап спринта. На протяжении этого собрания Владелец Продукта информирует о заданиях, которые должны быть выполнены. Тогда Команда определяет, сколько из желаемого они могут выполнить, чтобы завершить необходимые части на протяжении следующего спринта^[7]. Во время спринта команда выполняет определенный фиксированный список заданий (т. н. sprint backlog). На протяжении этого периода никто не имеет права менять список требований к работе, что следует понимать как заморозку требований (requirements) во время спринта.

Артефакты

Product backlog — это документ, содержащий список требований к функциональности, которые упорядочены по степени важности. Product backlog представляет собой список того, что должно быть реализовано. Элементы этого списка называются «историями» (user story) или элементами backlog’a (backlog items). Product backlog открыт для редактирования для всех участников Scrum-процесса.

Sprint Backlog — содержит функциональность, выбранную Product Owner из Product Backlog. Все функции разбиты по задачам, каждая из которых оценивается командой. Каждый день команда оценивает объем работы, который нужно проделать для завершения задач.

Burndown chart — показывает, сколько уже исполнено и сколько ещё остаётся сделать.

Встречи

Планирование спринта происходит в начале итерации(не более 4-8 часов), выбирается что будет сделано и обсуждается как это будет сделано.

Митинг Происходит каждый день в течение спринта(не более 15 минут), ищутся ответы на вопросы: что сделано? Что надо сделать? Какие есть проблемы?