Жизненный цикл ПО и методологии программирования

- Корпорация Rational Software регулярно выпускает обновленные версии Rational Unified Process.

- Он предоставляется оперативно, с использованием технологии Web, поэтому для разработчиков он буквально доступен с клавиатуры.

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

- Он составляет единое целое с множеством средств разработки программного обеспечения от корпорации Rational Software, поэтому для каждого элемента процесса предлагается подробное руководство разработчика.

Подход к процессу как к программному продукту имеет следующие преимущества.

- Процесс никогда не устаревает; через определенные промежутки времени компании получают новые версии, содержащие новые и исправленные методы.

- Все участники проекта могут по внутренней сети получить последнюю версию процесса.

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

- Гиперссылки позволяют перемещаться от одной части процесса к другой, обращаться к инструментальному средству разработки программного обеспечения, внешнему справочнику или руководству разработчика.

- В процесс легко включаются специальные процедуры; могут модернизироваться и изменяться логические, проектные или другие аспекты процесса.

- В каждом проекте или отделе может использоваться собственная версия процесса.

Кто использует Rational Unified Process?

- Телекоммуникация: Ericsson, Alcatel, MCI

- Транспорт, авиационно-космическая отрасль, оборонная промышленность: Lockheed-Martin, British Aerospace

- Промышленность: Xerox, Volvo, Intel

- Финансы: Visa, Merrill Lynch, Schwab

- Интеграторы систем: Ernst & Young, Oracle, Deloitte & Touche



13. Модель Rational Unified Process

Модель жизненного цикла RUP является довольно сложной, детально проработанной итеративно-инкрементной моделью с элементами каскада. В модели RUP выделяются 4 основные фазы, 9 видов деятельности (процессов). Кроме того, в модели описывается ряд практик, которые следует применять или руководствоваться для успешного выполнения проекта. RUP ориентирован на поэтапное моделирование создаваемого продукта с помощью языка UML (см. рис. 6.9).

Рис. 6.9. Модель Rational Unified Process

Основными фазами RUP являются:

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

- Фаза проработки (Elaboration). Основная цель этой фазы -- на базе основных, наиболее существенных требований разработать стабильную базовую архитектуру продукта, которая позволяет решать поставленные перед системой задачи и в дальнейшем используется как основа разработки системы.

- Фаза построения (Construction). Основная цель этой фазы -- детальное прояснение требований и разработка системы, удовлетворяющей им, на основе спроектированной ранее архитектуры.

- Фаза передачи (Transition). Цель фазы -- сделать систему полностью доступной конечным пользователям. Здесь происходит окончательное развертывание системы в ее рабочей среде, подгонка мелких деталей под нужды пользователей.

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

Деятельности (основные процессы) RUP делятся на пять рабочих и четыре поддерживающие. К рабочим деятельностям относятся:

- Моделирование предметной области (бизнес-моделирование, Business Modeling). Цели этой деятельности -- понять бизнес-контекст, в котором должна будет работать система (и убедиться, что все заинтересованные лица понимают его одинаково), понять возможные проблемы, оценить возможные их решения и их последствия для бизнеса организации, в которой будет работать система.

- Определение требований (Requirements). Цели -- понять, что должна делать система, определить границы системы и основу для планирования проекта и оценок ресурсозатрат в нем.

- Анализ и проектирование (Analysis and Design). Выработка архитектуры системы на основе ключевых требований, создание проектной модели, представленной в виде диаграмм UML, описывающих продукт с различных точек зрения.

- Реализация (Implementation). Разработка исходного кода, компонент системы, тестирование и интегрирование компонент.

- Тестирование (Test). Общая оценка дефектов продукта, его качество в целом; оценка степени соответствия исходным требованиям.

Поддерживающими деятельностями являются:

- Развертывание (Deployment). Цели -- развернуть систему в ее рабочем окружении и оценить ее работоспособность.

- Управление конфигурациями и изменениями (Configuration and Change Management). Определение элементов, подлежащих хранению и правил построения из них согласованных конфигураций, поддержание целостности текущего состояния системы, проверка согласованности вносимых изменений.

- Управление проектом (Project Management). Включает планирование, управление персоналом, обеспечения связей с другими заинтересованными лицами, управление рисками, отслеживание текущего состояния проекта.

- Управление средой проекта (Environment). Настройка процесса под конкретный проект, выбор и смена технологий и инструментов, используемых в проекте.

Основной причиной широкого распространения RUP является его системный характер. Это одна из немногих методологий, которая пытается дать ответ на основные вопросы реализации проекта, а именно кто выполняет? что выполняет? как выполняет? и когда, которые представлены в RUP четырьмя базовыми элементами моделирования:

- Исполнители: кто;

- Виды деятельность: как;

- Артефакты: что;

Технологические процессы: когда.

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

Таким образом, стремление RUP к универсальности привело к необходимости использования лишь иллюстративной модели жизненного цикла, что, в свою очередь, привело к появлению инструментов и методов их применения, не связанных с моделью жизненного цикла, адекватной проекту. В результате все эти средства, в какой бы то ни было CASE-системе, ориентированной на RUP, будут лишь коллекцией, а не комплексом поддержки процессов конкретных методологий. Это, однако, не означает отрицание инструментов CASE-систем RUP, которые оказываются очень полезными для реализации различных методологических подходов, чем во многом и объясняется их популярность.

14. Модель процессов MSF

Модель процессов MSF (MSF process model) представляет общую методологию разработки и внедрения IT_решений. Особенность этой модели состоит в том, что благодаря своей гибкости и отсутствию жестко навязываемых процедур она может быть применена при разработке весьма широкого круга программных проектов. Эта модель сочетает в себе свойства двух стандартных производственных моделей: каскадной и спиральной.

Стремясь достичь максимальной отдачи от IT_проектов, Майкрософт выпустил в свет пакет руководств по эффективному проектированию, разработке, внедрению и сопровождению решений, построенных на основе своих технологий. Эти знания базируются на опыте, полученном компанией при работе над большими проектами по разработке и сопровождению программного обеспечения, опыте консультантов Майкрософт, разрабатывавших проекты на предприятиях заказчиков, и лучшем из того, что накопила на данный момент индустрия разработки ПО. Все это представлено в виде двух связанных и хорошо дополняющих друг друга областей знаний: Microsoft Solutions Framework (MSF) и Microsoft Operations Framework (MOF). Создание бизнес-решения в рамках отведенного времени и бюджета требует наличия испытанной методологической основы. MSF предлагает проверенные методики для планирования, проектирования, разработки и внедрения успешных IT-решений.

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

Методология MSF состоит из принципов, моделей и дисциплин по управлению персоналом, процессами, технологическими элементами и связанными со всеми этими факторами вопросами, характерными для большинства проектов. Одна из особенностей технологии MSF состоит в том, что она ориентирована не просто на создание программного продукта, удовлетворяющего определенному набору требований, а на поиск решения проблем, стоящих перед заказчиком.

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

Поэтому, в технологии MSF большое внимание уделяется анализу проблем заказчика и разработке вариантов системы для поиска их приемлемого решения

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

Каскадная модель	Спиральная модель	Модель жизненного цикла MSF

Рис. 6.10. Построение модели жизненного цикла MSF на базе каскадной и спиральной моделей

Модель жизненного цикла MSF ориентирована на «вехи» (milestones) - ключевые точки проекта, характеризующие достижение какого-либо существенного результата. Этот результат может быть оценен и проанализирован. В модели предусматривается наличие основных вех (завершение главных фаз модели) и промежуточных, отражающих внутренние этапы главных фаз.

15. Базовые принципы MSF

Модель процессов MSF тесно связана со следующими четырьмя базовыми принципами:

Единое видение проекта

Успех коллективной работы над проектом немыслим без наличия у членов проектной группы и заказчика единого видения (shared vision), т.е. четкого, и, самое главное, одинакового, понимания целей и задач проекта. Как проектная группа, так и заказчик изначально имеют собственные предположения о том, что должно быть достигнуто в ходе работы над проектом. Лишь наличие единого видения способно внести ясность и обеспечить движение всех заинтересованных в проекте сторон к общей цели.

Формирование единого видения и последующее следование ему являются столь важными, что модель процессов MSF выделяет для этой цели специальную фазу (фаза “Выработка концепции”), которая заканчивается соответствующей вехой.

Проявляйте гибкость - будьте готовы к переменам

Традиционная дисциплина управления проектами и каскадная модель исходят из того, что все требования могут быть четко сформулированы в начале работы над проектом, и далее они не будут существенно изменяться. В противоположность этому MSF основывается на принципе непрерывной изменяемости условий проекта при неизменной эффективности управленческой деятельности.

Концентрируйтесь на бизнес-приоритетах

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

Обычно продукт не может приносить отдачу до того, как он полностью внедрен. Поэтому модель процессов MSF включает в свой жизненный цикл не только разработку продукта, но и его внедрение.

Поощряйте свободное общение

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

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

По этой причине модель процессов MSF предлагает проведение анализа хода работы над проектом в определенных временных точках. Документирование результатов делает ясным прогресс, достигнутый в работе над проектом - как для проектной команды, так и для заказчика и других заинтересованных в проекте сторон.

Основными фазами модели MSF являются:

- Создание общей картины приложения (Envisioning).На этом этапе решаются следующие основные задачи: оценка существующей ситуации; определение состава команды, структуры проекта, бизнес-целей, требований и профилей пользователей; разработка концепции решения и оценка риска. Устанавливаются две промежуточные вехи: «Организован костяк команды» и «Создана общая картина решения».

- Планирование (Panning). Включает планирование и проектирование продукта. На основе анализа требований разрабатывается проект и основные архитектурные решения, функциональные спецификации системы, планы и календарные графики, отбираются среды разработки, тестирования и пилотной эксплуатации. Этап состоит из трех стадий: концептуальное, логическое и физическое проектирование. На стадии концептуального проектирования задача рассматривается с точки зрения пользовательских и бизнес-требований и заканчивается определением набора сценариев использования системы. При логическом проектировании задача рассматривается с точки зрения проектной команды, решение представляется в виде набора сервисов. На стадии физического проектирования, где задача рассматривается с точки зрения программистов, уточняются используемые технологии и интерфейсы.

- Разработка (Developing). Создается вариант решения проблемы, в виде кода и документации очередного прототипа, включая спецификации и сценарии тестирования. Основная веха этапа - «Окончательное утверждение области действия проекта». Продукт готов к внешнему тестированию и стабилизации. Кроме того, заказчики, пользователи, сотрудники службы поддержки и сопровождения, а также ключевые участники проекта могут предварительно оценить продукт и указать все недостатки, которые нужно устранить до его поставки.

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

- Развертывание (Deploying). Выполняется установка решения и необходимых компонентов окружения, проводится его стабилизация в промышленных условиях и передача проекта в руки группы сопровождения. Кроме того, анализируется проект в целом на предмет уровня удовлетворенности заказчика.

К сожалению, авторы подхода MSF не совсем точны в своих оценках модели. Как и в случае с RUP, в этой модели очевидно стремление к универсальности, которое неизбежно приводит к огрублению ситуации в конкретных случаях и к необходимости словесного дополнения схемы. Недостатки моделей, основанных на раскручивающейся спирали, присущи ей в полной мере: невозможность отслеживания временных соотношений между сроками выполнения работ, трудности добавления специфичных этапов. К тому же ориентация на всеобщность лишает модель и тех преимуществ, которые демонстрирует, например, модель Боэма, снабженная конкретным механизмом интерпретации.

Изучение методологии, провозглашаемой MSF, позволяет сделать вывод о том, что ее авторы достаточно тщательно проработали процессы менеджмента, когда основой организации коллектива разработчиков считается проектная группа с рассредоточенными ролями. Но опять-таки в модели жизненного цикла это обстоятельство никак не отражено, что вполне объяснимо стремлением к всеобщности. Отсюда следует, что обсуждаемое предложение всегда в конкретных проектах должно адаптироваться. Сделать это проще, чем, к примеру, в случае RUP или других жестких схем, однако до уровня стратегии быстрого развития предложения MSF не доходят и занимают промежуточное положение между жесткими и гибкими методологиями.

16. Жизненный цикл в методологиях быстрого развития проектов

Как утверждают сторонники быстрого развития, их методологии не нуждаются в том, чтобы четко фиксировать этапы развития разработки программного проекта. Однако они понимают, что само понятие жизненного цикла полезно для представления процесса разработки в концептуальном плане. Что же касается деятельности менеджера, то в этом подходе в противовес жестким методологиям провозглашаются самодисциплина и сотрудничество вместо дисциплины и подчинения; планирование, контрольные и другие функции носят здесь такой характер, который позволяет менеджеру в большей мере сосредоточиться на руководстве командой, чем на управлении. В результате отслеживание процесса не требует, к примеру, специальных документов о достигнутых результатах и проблемах, для которых нужна специальная поддержка. По этой причине модели жизненного цикла быстрого развития не претендуют на инструментальность, и в таком ключе их рассматривать не имеет смысла. Тем не менее, понятия контрольных точек и контрольных мероприятий, распределения ресурсов, оценки остаются, хотя их содержание становится менее формализованным.

Жизненный цикл любой методологии быстрого развития можно описать следующим образом.

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

- Серия максимально коротких итераций, состоящих из шагов:

- выбор реализуемых требований (в экстремальном программировании -- пользовательских историй);

- реализация только отобранных требований;

- передача результата для практического использования;

- короткий период оценки достигнутого (в зависимости от объема работ периода его можно назвать этапом или контрольным мероприятием).

- Фаза заключительной оценки разработки проекта.

Реальные быстрые методологии конкретизируют эту схему, дополняют ее теми или иными методиками.

До последнего времени быстрые процессы было не принято формализовывать настолько, чтобы их можно было предлагать в качестве стандарта. И сегодня не приходится говорить, например, о сертифицировании команды как «правильно» работающей по быстрой методологии, подобном тому, что требует CMM. Тем не менее, вопрос о сертификации быстрого процесса приобретает актуальность, так как он завоевывает все большую популярность. Существуют опасения, что стремление к сертификации может формализовать гибкие методологии до такой степени, что их нельзя уже будет называть гибкими.

Тем не менее, сегодня уже появилась компания, выполняющая проекты по методологии экстремального программирования, которая получила сертификат по одному из общепризнанных стандартов ISO 9001:2000, свидетельствующий об определенных гарантиях качества организации проектной деятельности и получаемых результатов. Это произошло весной 2003 года по прошествии примерно года с момента подачи заявки на сертификацию. Все, что для этого потребовалось сделать, свелось к приведению соответствия между процессами экстремального программирования и процессами, поддерживаемыми стандартом. В остальном процедура сертификации не нарушила процессы производства программ в компании. Не потребовалось никакой настройки процесса, доведения его до требований стандарта. Не претерпела изменений база данных, в которой сохранялись пользовательские истории со сведениями о работе с ними. Документация, предназначенная для пользователей, построенная на базе априорного тестирования, признана соответствующей требованиям качества и т.д.

17. Экстремальное программирование (ХР)

Экстремальное программирование (Extreme Programming или сокращённо ХР) является одним из направлений методологии быстрой разработки программного обеспечения. Представляет собой набор средств и методик для эффективного построения устойчивых и надёжных программ. Включает в себя поддержку изменчивости и противоречивости требований к разрабатываемым системам и тесные связи с заказчиком. Экстремальное программирование было анонсировано Кентом Беком в 1995 году в компании Chrysler. Является сравнительно новой методологией, но тем не менее хорошо зарекомендовавшей себя в кругах профессиональных разработчиков.

Экстремальное программирование применяется для создания программ коллективом от 2-х до 10 программистов при заранее заданных сроках сдачи проекта.

Тезисно суть экстремального программирования можно выразить следующим образом:

- все задание разбивается на формулировки подзадач, каждая формулировка должна иметь срок выполнения от 1 до 3-х недель, если больше, то - следует разделить, меньше - объединить;

- путем равновесия объема, времени, ресурсов и качества составляется структурный план выпуска версий программы на основании пользовательских формулировок;

- при выполнении очередной итерации проекта важно не добавлять функциональности раньше времени;

- перед началом новой итерации создается ее подробный план: формулировки разбиваются па задачи сроком от 1 до 3-х дней и сортируются по важности, добавляются задачи, которые не смогли пройти тест приемки;

- проводятся ежедневные утренние планерки, желательно стоя, чтобы не занимали слишком много времени;

- приветствуется простой дизайн проекта;

- создаваемым классам даются простые имена;

- осуществляется постоянный контакт с заказчиком;

- отслеживается качество исходных текстов;

- используется парное программирование - два программиста за одним компьютером;

- практикуется перемещение программистов на другие участки работы после завершения задачи;

- используется частая интеграция кода в общий проект для придания уверенности программистам в правильности их работы;

- решительно переделывается старый, работающий, но малоэффективный код;

- система оптимизируется в последнюю очередь;

- команда не работает сверх графика;

- используются тесты создаваемого «черного ящика» как можно чаще.

Методология ХР исходит из предположения, что в основе любого проекта лежат четыре переменные:

1. затраты;

2. время;

3. качество;

4. объем работ.

Принципы ХР относительно этих переменных:

затраты - чем больше денег, тем легче работать, однако слишком большое количество денег в начале проекта создает больше проблем, чем требуется решить;

время - с увеличением объема времени, выделяемого на проект, у вас появляется возможность повысить качество разрабатываемой программы и расширить объем работ, однако отзывы о системе, которая уже эксплуатируется в реальных условиях гораздо ценнее, чем любые другие отзывы;

качество - это переменная, которая контролируется хуже всего;

объем работ - сократив объем работ можно повысить качество и сократить время проекта.

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

Ограничения, связанные со временем реализации проекта, как правило, появляются извне. Зачастую время не контролируется со стороны менеджеров проекта, его контролируют заказчики.

Настаивая на улучшении качества, вы можете завершить проект быстрее, чем запланировано. Или можете сделать больший объем работ за отведенное время. Существует зависимость между внутренним и внешним качеством. Измерением внешнего качества занимается заказчик, внутреннее качество оценивается программистами. Если вы намерены временно пожертвовать внутренним качеством для того, чтобы сократить время разработки, и при этом надеетесь на то, что внешнее качество не пострадает слишком сильно, то имейте в виду, что вы стремитесь к краткосрочной цели. Со временем количество внутренних проблем может увеличиться настолько, что разрабатываемую систему будет чрезвычайно сложно сопровождать и развивать. Кроме того, с качеством связан дополнительный человеческий фактор. Каждый хочет делать свою работу хорошо, и каждый работает существенно лучше, если он чувствует, что делает свою работу хорошо.

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

Рис. 6.11. Стоимость внесения изменений в разрабатываемый программный продукт по мере разработки

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

Одно из основных предположений ХР: если стоимость внесения изменений растет медленно, вы можете откладывать решение важных задач на более поздние сроки. У вас есть возможность принимать важные решения настолько поздно, насколько это возможно. Это делается для того, чтобы уменьшить риск связанных с этим решением затрат и повысить вероятность того, что принятое вами решение является правильным. Другими словами, сегодня вы должны реализовать лишь то, без чего сегодня не обойтись, при этом вы можете рассчитывать на то, что проблемы, решение которых вы отложили до завтра перестанут быть актуальными.

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

- простой дизайн, в котором отсутствуют лишние элементы: никаких идей, которые в настоящий момент не используются, но предположительно, могут использоваться в будущем;

- автоматические тесты, благодаря которым можно узнать, что после внесения изменений в систему ее поведение изменилось;

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

В итоге разрабатывается подход к разработке ПО: каждое решение принимается быстро. Оно защищается с применением автоматических тестов. Команда готова менять дизайн системы в том случае, если понимает, что существует более удачный дизайн, чем тот, что реализован в настоящий момент.

Четыре ценности ХР

1. Коммуникации

2. Простота

3. Обратная связь

4. Храбрость

Коммуникация: проблемы, возникающие в процессе работы над проектом, почти всегда связаны с тем, что кто-то не сказал кому-то о чем-то важном. В рамках ХР существует специальное ответственное лицо - инструктор, который следит за тем, чтобы люди общались, когда это нужно.

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

Чем больше вы общаетесь, тем яснее становится понимание, что должно быть сделано, а чего делать не надо. Чем проще система, тем меньше тем для обсуждения, особенно если вы упрощаете систему до того, что для работы над ней требуется меньше программистов.

Обратная связь: тезис инструктора ХР «Не спрашивай у меня, спроси у системы» (т.е. напиши тестовый случай). Обратная связь обеспечивает точные и конкретные данные о состоянии системы. Оптимизм - это болезнь программирования, обратная связь - лекарство от этой болезни. Эксплуатация системы в реальных производственных условиях начинается как только система становится способной решать хотя бы небольшую часть возложенных на нее обязанностей. Необходимо поддерживать эксплуатацию системы в реальных условиях и одновременно развивать ее, разрабатывая новую функциональность.

Это обратная связь в масштабе недель и месяцев. Обратная связь в масштабе минут и дней обеспечивается написанием тестов.

Храбрость: в контексте первых трех ценностей необходимо действовать с максимально возможной скоростью. Для этого нужна храбрость. И прежде всего для отказа от ранее разработанного кода.



18. Базовые принципы ХР

Помогают нам выбирать между несколькими альтернативами. Основные принципы:

1. быстрая обратная связь;

2. приемлемая простота;

3. постепенное изменение;

4. приемлемое изменение;

5. качественная работа.

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

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

Постепенное изменение - объемные изменения, в рамках которых за один раз меняется абсолютно все не срабатывают, поэтому любая проблема решается при помощи серии небольших изменений, в результате которых достигается желаемый эффект.

Приемлемое изменение - лучшей стратегией является та, которая решает актуальную для вас проблему и при этом сохраняет для вас максимальную свободу дальнейших действий.

Качественная работа - никто не любит плохо работать. Каждый хочет выполнять свою работу на «отлично». Но качество не является свободно изменяемой переменной. Как говорит К. Бек, для качества есть только две оценки «превосходно» и «невероятно превосходно» и выбор в пользу первой может быть сделан только в том случае, если на карту поставлены человеческие жизни. Иначе члены коллектива теряют мотивацию, работа им не нравится, они начинают выполнять ее плохо и проект постепенно скатывается в категорию провальных.

19. Основные методики ХР

Игра в планирование (planning game)-- быстро определяет перечень задач (объем работ), которые необходимо реализовать в следующей версии продукта. Для этого рассматриваются бизнес-приоритеты и технические оценки. Если со временем план перестает соответствовать действительности, происходит обновление плана.

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

Метафора (metaphor) -- эта простая общедоступная и общеизвестная история, которая коротко описывает, как работает вся система. Эта история управляет всем процессом разработки.

Простой дизайн (simple design) -- в каждый момент времени система должна быть спроектирована так просто, как это возможно. Чрезмерная сложность устраняется, как только ее обнаруживают.

Тестирование (testing) -- программисты постоянно пишут тесты для модулей. Для того чтобы разработка продолжалась, все тесты должны срабатывать. Заказчики пишут тесты, которые демонстрируют работоспособность и завершенность той или иной возможности системы.

Переработка (refactoring) -- программисты реструктурируют систему, не изменяя при этом ее поведения. При этом они устраняют дублирование кода, улучшают коммуникацию, упрощают код и повышают его гибкость.

Программирование парами (pair programming) -- весь разрабатываемый код пишется двумя программистами на одном компьютере.

Коллективное владение (collective ownership) -- в любой момент времени любой член команды может изменить любой код в любом месте системы.

Непрерывная интеграция (continuous integration) -- система интегрируется и собирается множество раз в день. Это происходит каждый раз, когда завершается решение очередной задачи.

40-часовая_неделя (40-hour week) -- программисты работают не более 40 часов в неделю. Это правило. Никогда нельзя работать сверхурочно две недели подряд.

Заказчик па месте разработки (on-site customer) -- в состав команды входит реальный живой пользователь системы. Он доступен в течение всего рабочего дня и способен отвечать на вопросы о системе.

Стандарты кодирования (coding standards) -- программисты пишут весь код в соответствии с правилами, которые обеспечивают коммуникацию при помощи кода

Методология экстремального программирования является характерным примером сочетания итеративного наращивания возможностей с прототипированием. И как всякая другая модель жизненного цикла, основанная на этих принципах, она имеет свои ограничения на область применения, о которых следует помнить, принимая решение в пользу выбора методологии ХР для использования в конкретном проекте.

Размещено на Allbest.ru

...