Основы программирования

Процесс разработки - Элемент ХР-разработки
Индекс материала
Процесс разработки
Рабочие потоки процесса
Технические артефакты
Идентификация риска
Анализ риска
Планирование управления риском
Этап НАЧАЛО (Inception)
Этап РАЗВИТИЕ (Elaboration)
Этап КОНСТРУИРОВАНИЕ (Construction)
Этап ПЕРЕХОД (Transition)
Этап НАЧАЛО
Этап РАЗВИТИЕ
Этап КОНСТРУИРОВАНИЕ
ХР-реализация
ХР-итерация
Элемент ХР-разработки
Коллективное владение кодом
Взаимодействие с заказчиком
Объектно-ориентированное тестирование
Особенности тестирования объектно-ориентированных «модулей»
Объектно-ориентированное тестирование правильности
Тестирование, основанное на ошибках
Тестирование, основанное на сценариях
Тестирование поверхностной и глубинной структуры
Тестирование разбиений на уровне классов
Стохастическое тестирование
Тестирование разбиений
Листинг 16.1.
Листинг 16.5.
Листинг 16.10
Листинг 16.15.
Листинг 16.20.
Автоматизация конструирования визуальной модели программной системы
Создание диаграммы последовательности
Создание диаграммы классов
Создание компонентной диаграммы
Заключение
Все страницы
Элемент ХР-разработки

 

Структура элемента ХР-разработки показана на рис. 15.18.

День ХР-разработчика начинается с установочной встречи. Ее цели: обсуждение проблем, нахождение решений и определение точки приложения усилий всей команды.

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

 

Рис. 15.18. Структура элемента ХР-разработки

 

Весь день ХР-разработчика проходит под лозунгом коллективного владения кодом программной системы. В результате этого происходит фиксация ошибок и добавление новой функциональности в систему.

Следует удерживаться от соблазна добавлять в продукт функциональность, которая будет востребована позже. Полагают, что только 10% такой функциональности будет когда-либо использовано, а потери составят 90% времени разработчика. В ХР считают, что дополнительная функциональность только замедляет разработку и исчерпывает ресурсы. Предлагается подавлять такие творческие порывы и концентрироваться на текущих, запланированных задачах.