Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Чеканин.docx
Скачиваний:
1
Добавлен:
01.07.2025
Размер:
2 Мб
Скачать
☆

43) Схема процесса разработки программного обеспечения в технологии

экстремального программирования XP.

  1. Тестирование

  2. Игра в планирование (Основная цель игры в планирование — быстро сформировать приблизительный план работы и постоянно обновлять его по мере того, как условия задачи становятся всё более чёткими)

  3. Заказчик всегда рядом («Заказчик» в XP — это не тот, кто оплачивает счета, а конечный пользователь программного продукта. XP утверждает, что заказчик должен быть всё время на связи и доступен для вопросов.)

  4. Парное программирование (Парное программирование предполагает, что весь код создается парами программистов, работающих за одним компьютером. Один из них работает непосредственно с текстом программы, другой просматривает его работу и следит за общей картиной происходящего.)

  5. Непрерывная интеграция (Если выполнять интеграцию разрабатываемой системы достаточно часто, то можно избежать большей части связанных с этим проблем. В традиционных методиках интеграция, как правило, выполняется в самом конце работы над продуктом, когда считается, что все составные части разрабатываемой системы полностью готовы. В XP интеграция кода всей системы выполняется несколько раз в день, после того, как разработчики убедились в том, что все тесты модулей корректно срабатывают.)

  6. Рефакторинг (Рефакторинг (refactoring) — это методика улучшения кода без изменения его функциональности. XP подразумевает, что однажды написанный код в процессе работы над проектом почти наверняка будет неоднократно переделан.)

  7. Частые небольшие релизы

  8. Простота проектирования

  9. Метафора системы (Метафора системы (system metaphor) — это аналог того, что в большинстве методик называется архитектурой.Метафора системы даёт команде представление о том, каким образом система работает в настоящее время, в каких местах добавляются новые компоненты, и какую форму они должны принять.Архитектура — это представление о компонентах системы и их взаимосвязях между собой.)

  10. Стандарты кодирования (Все члены команды в ходе работы должны соблюдать требования общих стандартов кодирования. Благодаря этому:

  • члены команды не тратят время на глупые споры о вещах, которые фактически никак не влияют на скорость работы над проектом;

  • обеспечивается эффективное выполнение остальных практик.)

  1. Коллективное владение (Коллективное владение означает, что каждый член команды несёт ответственность за весь исходный код. Таким образом, каждый вправе вносить изменения в любой участок программы.)

44) Основные положения технологии экстремального программирования xp.

а) Экстремальный цикл (в основе экстремального программирования — очень короткий, постоянно повторяющийся цикл разработки, составляющий одну-три недели. К концу каждого цикла вы должны иметь полностью рабочий, функциональный и протестированный релиз приложения. Эти циклы должны быть повторяющимися и бесперебойными на протяжении всего проекта)

б) Позднее принятие решений ("Поздний анализ" означает "принимайте конкретные решения только тогда, когда это нужно". В большинстве случаев принятые на начальной стадии решения относительно кода приходилось отменять под влиянием новых требований или других обстоятельств)

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

г) Идеальный день разработчика и фактор загрузки (важным первичным инструментом при расчетах является идеальный день разработчика — то есть день, когда разработчик полностью концентрируется на решении проблем проекта. Фактор загрузки — это отношение реальных календарных рабочих дней к идеальным дням разработчика; он характеризует "температуру" разработки.)

д) Скорость проекта (скорость проекта — это скорость реализации частей программы, определенных для заданного цикла. В качестве основных ориентиров прогресса в разработке выступают реализации историй пользователей.)

е) История пользователей (история пользователей — это аналог Use Case, но имеющий несколько другой оттенок. История пользователя — это компактный документ (предположительно около трех предложений) составленный пользователем и описывающий одну отдельную операцию для данного пользователя в духе "я захожу в программу и...". )

ж) План релиза (план релиза, утверждаемый на специальном совещании, дает точный ответ на вопрос, какие именно истории пользователей будут реализованы в данном релизе.)

з) План итераций (План итераций ограничивает количество заданий, которые будут выполняться в данной итерации)

и)Тесты приемки (Тесты приемки создаются на основании историй пользователей и желательно до, а не после создания программных модулей. Без прохождения тестов история не может считаться реализованной ни в какой мере)

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

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

м) Простота и эффективность используемого кода (Фактически, все члены команды изначально должны выбрать технологии, которыми владеют все или большинство членов команды)

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

о) Тестирование модулей (тестирование модулей — это сугубо технологическая проверка корректности классов на основании готовой или созданной специально для этих целей автоматизированной системы.)

п) Групповое авторство.