- •1.Проблемы создания больших программ.
- •2. Основные понятия
- •3. Состав жизненного цикла по
- •1.Анализ требований
- •4.Стандартизация процессов жизненного цикла программ
- •5. Модели жизненного цикла программного обеспечения.
- •6.Техническое задание на разработку.
- •7.Документирование программ.
- •8.Выбор архитектуры по.
- •9.Структурный и объектный подходы к разработке программ.
- •10. Метод структурного анализа и проектирования sadt (idef0)
- •11. Диаграммы потоков данных dfd.
- •12. Диаграмма сущность – связь erm
- •13. Методы объектно-ориентированного анализа и проектирования. Язык uml.
- •14. Методы разработки структуры программной системы
- •15.Выбор языка программирования. Стиль программирования.
- •16.Защитное программирование.
- •17.Тестирование и отладка
- •18.Типичные ошибки
- •19.Отладка программных продуктов
- •20.Ввод в зксплуатацию
- •21.Ускорение разработки по. Технология rad
- •22. Экстремальное программирование
22. Экстремальное программирование
Одним из наиболее известных примеров практической реализации подхода быстрой разработки ПО является экстремальное программирование (Extreme Programming — ХР). Этот метод предназначен для небольших компактных команд, нацеленных на получение более высокого качества и продуктивности, и достигает этого посредством насыщенной, неформальной коммуникации, придания на персональном уровне особого значения умению и навыкам, дисциплине и пониманию, сводя к минимуму все промежуточные рабочие продукты. Экстремальное программирование — методология быстрой разработки ПО — состоит из набора методик и принципов, позволяющих как по отдельности, так и в комплексе оптимизировать процесс разработки. Этот подход так же регламентирует права разработчиков и заказчиков.
В экспериментальном программировании четко описаны все роли. Две ключевые роли – заказчик и разработчик
Заказчик- это человек или группа людей заинтересованных в разработке конкретного ПП. Имеют следующие права и обязанности.
-Фиксировать сроки выпуска версий продукта
-Принимать решения относительно запланированных составляющих программы.
-Знать ориентировочную стоимость каждой функциональной составляющей
-Принимать важные бизнес решения
-Знать текущее состояние системы
-Изменять требования к системе, когда это действительно важно
-Для успешного использования своих прав заказчик должен полагаться на данные предоставляемые разработчиками.
Разработчик – человек или группа людей от 2-х до 10 человек, занимающихся непосредственно программированием и сопутствующими инженерными вопросами. Права и обязанности:
-Получить достаточно знаний о задачах, которые должны быть запрограммированы.
-Иметь возможность выяснения деталей в процессе разработки.
-Предоставлять ориентировочные, но откровенные оценки трудозатрат на каждую функциональную часть или история пользователя.
-Предоставлять оценку рисков, связанных с использование конкретных технологий.
На стороне заказчика определены следующие вспомогательные роли:
Составитель истории – это человек или группа людей ответственных за написание истории пользователя и прояснения недопонимания со стороны программистов.
Приемщик - человек, контролирующий правильность функционирования системы, хорошо владеющий предметной областью.
Большой босс - следит за работой всех звеньев. Он может быть также инвестором проекта.
Вспомогательные роли на стороне разработчика:
Программист - человек, занимающийся кодированием и проектированием на низком уровне.
Инструктор - опытный разработчик, хорошо владеющий всем процессом разработки и его методиками; несет ответственность за обучение команды аспектам процесса разработки.
Наблюдатель - член команды разработчиков, пользующийся доверием всей группы и следящий за прогрессом разработки. Он сравнивает предварительные оценки трудозатрат и реально потраченные, выводя количественные показатели работы команды.
Дипломат - коммуникабельная личность, инициирующая общение между членами команды. Дипломат регулирует и упрощает общение между заказчиками и разработчиками, являясь важным звеном па собраниях.
Одно из требований экстремального программирования — заказчик всегда доступен. Он должен не просто помогать команде разработчиков, а быть ее членом. Все фазы проекта требуют коммуникации с заказчиком, лучше всего лицом к лицу — на месте.
Для описания функциональных требований к разрабатываемой системе заказчик с помощью разработчиков пишет истории пользователя, рассказы пользователя (User Stories). История пользователя — это описание того, как система должна работать.
Заказчик помогает удостовериться, что большинство желаемых функций системы покрыто историями пользователей.
Типичная история пользователя занимает одну-три недели идеального времени. Идеальное время — это количество времени, которое, по мнению разработчика, займет выполнение задачи, если ничто больше не будет его отвлекать.
План выпуска версий программы разрабатывают на собрании по планированию. Релиз-планы дают описание всего проекта и используются в дальнейшем для планирования итераций. Планирование очередной версии программы представляет набор правил, позволяющих всем участникам принимать свои решения. Эти правила определяют метод выработки плана работ, удовлетворяющего всех.
Сущность собрания по планированию версии для команды разработчиков заключается в том, чтобы оценить каждую историю в идеальных неделях. Заказчик решает, какие задачи наиболее важны или имеют наибольший приоритет.
Скорость проекта (скорость) — это мера того, как быстро выполняется работа в проекте. Для измерения скорости проекта необходимо посчитать объем историй или сколько (по времени) задач было выполнено за определенный период времени. Затем подсчитывают суммарное время оценки объема работы (идеальное время).
В процессе работы возможны небольшие изменения скорости проекта. Однако при значительном изменении скорости необходимо провести перепланирование версии.
Если руководителей проекта не устраивают сроки завершения, не следует уменьшать планируемые объемы работ. Во избежание подобной ситуации необходимо вести переговоры с менеджерами, разработчиками и заказчиками до тех пор, пока не будет выработан приемлемый для всех план разработки версии программы.
Для ответа на сложные технические вопросы и обоснования тех или иных технологических решений следует создавать пробные решения. При принятии любого технологического решения существует риск, поэтому пробные решения предназначены для его уменьшения: они воспроизводят исследуемую проблему и игнорирует все остальное. Большинство пробных решений не предназначены для последующего использования, а значит, они будут выброшены. Цель их создания — уменьшить риск принятия неправильного технического решения или дать более точную оценку времени, необходимого для реализации истории пользователя.
Итеративная разработка (рис. 1.30) увеличивает гибкость процесса. План выпуска версии программы нужно разделить на итерации продолжительностью от двух до трех недель, при этом сохранять постоянную продолжительность итерации на время проекта. Итерации в таком случае будут пульсом проекта. Это тот ритм, который позволит сделать измерение прогресса и планирование простым и надежным.
Разработчики разбирают задачи и оценивают продолжительность времени, необходимого для их выполнения. Таким образом, каждый разработчик оценивает, сколько времени решение задачи займет именно у него.
Перед началом работы выбирают метафору системы (System Metaphor) — простую и понятную концепцию, чтобы члены команды называли все вещи одинаковыми именами. Для понимания системы и исключения дублирующего кода чрезвычайно важно то, как разработчик называет объекты. Следует создать систему имен для своих объектов так, чтобы каждый член команды мог пользоваться ею без специальных знаний о системе.
Тесты отдельных модулей (Unit tests) играют ключевую роль в экстремальном программировании, так как позволяют быстро менять код. Тест модуля пишут для каждого класса, он должен проверять все аспекты работы класса — тестировать все, что может не работать. Тест для класса должен быть написан раньше самого класса;
Не следует экономить на тестах модулей, когда для завершения разработки остается мало времени. Практикой доказано, что чем сложнее написать тест, тем больше времени подработчик потом сэкономит.
Тесты модулей позволяют осуществить коллективное владение кодом, относительно легко пересматривать плохой код, а также в любой момент иметь стабильно работающую систему.
Схема этапа разработки показана на рис. 1.31. Первоначальным звеном является проведение короткого собрания, на котором обсуждают проблемы и их решения.
Ежедневное короткое собрание позволит избежать многих других собраний и сэкономит больше времени на осуществление проекта.
Для работы над проектом создается команда разработчиков. Состав команды может меняться, поэтому никто не пишет код в одиночку (код принадлежит всем) (рис. 1.32). Бывают случаи, когда для агрессивного и экстремального продвижения вперед необходимо понять и скорректировать чужой код. При этом разработчики должны удалить или изменить дублирующий код, проанализировать и улучшить чужие классы и т. п.
Коллективное владение кодом стимулирует разработчиков подавать идеи для всех частей проекта, а не только для своих модулей.
Для разработки структуры системы командой используют так называемые CRC-карточки (CRC — Class, Responsibilities, Collaboration — класс, обязанности, взаимодействие), представляющие собой экземпляр объекта. В ходе CRC-сессии участники используют обычно небольшое число карточек. Идеальный вариант — в процессе проектирования принимает участие вся команда.
Простую структуру всегда легче реализовать, чем сложную, поэтому необходимо стремиться к выбору самого простого решения, которое может работать.
Решения необходимо сохранять насколько возможно простыми и как можно дольше. Не стоит добавлять функциональность на будущее, до того как в этом появляется необходимость. Однако следует иметь в виду, что сохранять структуру разрабатываемой системы простой — довольно тяжелая работа.
Безжалостно переделывать.Убирая избыточность, улучшая устаревшую структуру проекта, убирая неиспользуемые куски, программист совершает переделку проекта, которая в конечном итоге экономит время и улучшает качество продукта.
Оставляйте оптимизацию на потом.
Весь код для выпускаемой системы, возможно, за исключением пробных решений, пишется парами. Два разработчика сидят рядом: один набирает, другой смотрит; время от времени они меняются местами. Не разрешается работать в одиночку.
Необходимо периодически менять задачи у разработчиков для уменьшения риска концентрации знаний и узких мест в коде. Если только лишь один человек в команде может работать в данной области и этот человек уходит или просто много работы скопилось в данном сегменте программы, может обнаружиться, что проект еле-еле продвигается вперед.
.При начале новой итерации каждый разработчик должен перейти на новую задачу. Парное программирование помогает преодолеть проблему адаптации. Это значит, что новый разработчик может начать работать в паре с опытным в данной области разработчиком. Такая практика также стимулирует появление новых идей и улучшение кода.
Разработчики, по возможности, должны интегрировать и выпускать свой код каждые несколько часов, по крайней мере, никогда нельзя держать изменения дольше одного дня.
Каждая пара разработчиков должна отдавать свой код, как только для этого появляется разумная возможность. Она предоставляется, когда все тесты отдельных модулей проходят полностью на 100%. Отдавая изменения несколько раз в день, можно свести проблемы интеграции практически к нулю.