16. Тяжеловесные и облегченные процессы разработки пс.

Традиционно для упорядочения и ускорения программных разработок предлагались строго упорядочивающие тяжеловесные (heavyweight) процессы. В этих процессах прогнозируется весь объем предстоящих работ, поэтому они называются прогнозирующими (predictive) процессами. Порядок, который должен выполнять при этом человек-разработчик, чрезвычайно строг — «шаг вправо, шаг влево — виртуальный расстрел!». Иными словами, человеческие слабости в расчет не принимаются, а объем необходимой документации способен отнять покой и сон у «совестливого» разработчика.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   2. Общение

   3. Уважение

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

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

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

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

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