В.В. Кулямин - Технологии программирования. Компонентный подход (1133554), страница 15
Текст из файла (страница 15)
Распределениеобъемов работ по дисциплинам в ходе проекта выглядит, согласно руководству по RUP, примернотак, как показано на Рис. 14.Рисунок 14. Распределение работ между различными дисциплинами в проекте по RUP.Напоследок перечислим техники, используемые в RUP согласно [3].• Выработка концепции проекта (project vision) в его начале для четкой постановки задач.• Управление по плану.• Снижение рисков и отслеживание их последствий, как можно более раннее начало работ попреодолению рисков.43•••••••••Тщательное экономическое обоснование всех действий — делается только то, что нужнозаказчику и не приводит к невыгодности проекта.Как можно более раннее формирование базовой архитектуры.Использование компонентной архитектуры.Прототипирование, инкрементная разработка и тестирование.Регулярные оценки текущего состояния.Управление изменениями, постоянная отработка изменений извне проекта.Нацеленность на создание продукта, работоспособного в реальном окружении.Нацеленность на качество.Адаптация процесса под нужды проекта.Экстремальное программированиеЭкстремальное программирование (Extreme Programming, XP) [4] возникло как эволюционныйметод разработки ПО «снизу-вверх».
Этот подход является примером так называемого метода«живой» разработки (Agile Development Method). В группу «живых» методов входят, помимоэкстремального программирования, методы SCRUM, DSDM (Dynamic Systems DevelopmentMethod, метод разработки динамичных систем), Feature-Driven Development (разработка,управляемая функциями системы) и др.Основные принципы «живой» разработки ПО зафиксированы в манифесте «живой»разработки [5], появившемся в 2000 году.• Люди, участвующие в проекте, и их общение более важны, чем процессы и инструменты.• Работающая программа более важна, чем исчерпывающая документация.• Сотрудничество с заказчиком более важно, чем обсуждение деталей контракта.• Отработка изменений более важна, чем следование планам.«Живые» методы появились как протест против чрезмерной бюрократизации разработки ПО,обилия побочных, не являющихся необходимыми для получения конечного результатадокументов, которые приходится оформлять при проведении проекта в соответствии сбольшинством «тяжелых» процессов, дополнительной работы по поддержке фиксированногопроцесса организации, как это требуется в рамках, например, CMM.
Большая часть таких работ идокументов не имеет прямого отношения к разработке ПО и обеспечению его качества, апредназначена для соблюдения формальных пунктов контрактов на разработку, получения иподтверждения сертификатов на соответствие различным стандартам.«Живые» методы позволяют большую часть усилий разработчиков сосредоточить собственнона задачах разработки и удовлетворения реальных потребностей пользователей. Отсутствие кипыдокументов и необходимости поддерживать их в связном состоянии позволяет более быстро икачественно реагировать на изменения в требованиях и в окружении, в котором придется работатьбудущей программе.Тем не менее, XP имеет свою схему процесса разработки (хотя, вообще говоря, широкоиспользуемое понимание «процесса разработки» как достаточно жесткой схемы действийпротиворечит самой идее «живости» разработки), приведенную на Рис.
15.По утверждению авторов XP, эта методика представляет собой не столько следование каким-тообщим схемам действий, сколько применение комбинации следующих техник. При этом каждаятехника важна, и без ее использования разработка считается идущей не по XP, согласноутверждению Кента Бека (Kent Beck) [4], одного из авторов этого подхода, наряду с УордомКаннингемом (Ward Cunningham), и Роном Джефрисом (Ron Jeffries).• Живое планирование (planning game)Его задача — как можно быстрее определить объем работ, которые нужно сделать доследующей версии ПО. Решение принимается, в первую очередь, на основе приоритетовзаказчика (т.е. его потребностей, того, что нужно ему от системы для более успешного44ведения своего бизнеса) и, во вторую, на основе технических оценок (т.е. оценоктрудоемкости разработки, совместимости с остальными элементами системы и пр.).
Планыизменяются, как только они начинают расходиться с действительностью или пожеланиямизаказчика.ИсториииспользованияНовая историяиспользованияСкорость проектаТребования«Вброс»архитектурыМетафорасистемыПланированиеверсииНенадежныеоценкиТестовыесценарииПлан версииУверенныеоценкиОшибкиИтерацияПоследняяверсияПриемочныетестыНебольшиеверсииОдобрениепользователейНовая итерация«Вброс»решенияРисунок 15. Схема потока работ в XP.••••••Частая смена версий (small releases)Самая первая работающая версия должна появиться как можно быстрее и тут же должнаначать использоваться. Следующие версии подготавливаются через достаточно короткиепромежутки времени (от нескольких часов при небольших изменениях в небольшойпрограмме, до месяца-двух при серьезной переработке крупной системы).Метафора (metaphor) системыМетафора в достаточно простом и понятном команде виде должна описывать основноймеханизм работы системы.
Это понятие напоминает архитектуру, но должно гораздопроще, всего в виде одной-двух фраз описывать основную суть принятых техническихрешений.Простые проектные решения (simple design)В каждый момент времени система должна быть сконструирована настолько просто,насколько это возможно. Не надо добавлять функции заранее — только после явнойпросьбы об этом. Вся лишняя сложность удаляется, как только обнаруживается.Разработка на основе тестирования (test-driven development)Разработчики сначала пишут тесты, потом пытаются реализовать свои модули так, чтобытесты срабатывали.
Заказчики заранее пишут тесты, демонстрирующие основныевозможности системы, чтобы можно было увидеть, что система действительно заработала.Постоянная переработка (refactoring)Программисты постоянно перерабатывают систему для устранения излишней сложности,увеличения понятности кода, повышения его гибкости, но без изменений в его поведении,что проверяется прогоном после каждой переделки тестов.
При этом предпочтениеотдается более элегантным и гибким решениям, по сравнению с просто дающими нужныйрезультат. Неудачно переработанные компоненты должны выявляться при выполнениитестов и откатываться к последнему целостному состоянию (вместе с зависимыми от нихкомпонентами).Программирование парами (pair programming)Кодирование выполняется двумя программистами на одном компьютере. Объединение впары произвольно и меняется от задачи к задаче.
Тот, в чьих руках клавиатура, пытаетсянаилучшим способом решить текущую задачу. Второй программист анализирует работу45первого и дает советы, обдумывает последствия тех или иных решений, новые тесты, менеепрямые, но более гибкие решения.• Коллективное владение кодом (collective ownership)В любой момент любой член команды может изменить любую часть кода. Никто не долженвыделять свою собственную область ответственности, вся команда в целом отвечает за веськод.• Постоянная интеграция (continuous integration)Система собирается и проходит интеграционное тестирование как можно чаще, понесколько раз в день, каждый раз, когда пара программистов оканчивает реализациюочередной функции.• 40-часовая рабочая неделяСверхурочная работа рассматривается как признак больших проблем в проекте. Недопускается сверхурочная работа 2 недели подряд — это истощает программистов и делаетих работу значительно менее продуктивной.• Включение заказчика в команду (on-site customer)В составе команды разработчиков постоянно находится представитель заказчика, которыйдоступен в течение всего рабочего дня и способен отвечать на все вопросы о системе.
Егообязанностью являются достаточно оперативные ответы на вопросы любого типа,касающиеся функций системы, ее интерфейса, требуемой производительности, правильнойработы системы в сложных ситуациях, необходимости поддерживать связь с другимиприложениями и пр.• Использование кода как средства коммуникацииКод рассматривается как важнейшее средство общения внутри команды. Ясность кода —один из основных приоритетов. Следование стандартам кодирования, обеспечивающимтакую ясность, обязательно.
Такие стандарты, помимо ясности кода, должны обеспечиватьминимальность выражений (запрет на дублирование кода и информации) и должны бытьприняты всеми членами команды.• Открытое рабочее пространство (open workspace)Команда размещается в одном, достаточно просторном помещении, для упрощениякоммуникации и возможности проведения коллективных обсуждений при планировании ипринятии важных технических решений.• Изменение правил по необходимости (just rules)Каждый член команды должен принять перечисленные правила, но при возникновениинеобходимости команда может поменять их, если все ее члены пришли к согласию поповоду этого изменения.Как видно из применяемых техник, XP рассчитано на использование в рамках небольшихкоманд (не более 10 программистов), что подчеркивается и авторами этой методики.
Большийразмер команды разрушает необходимую для успеха простоту коммуникации и делаетневозможным применение многих перечисленных приемов.Достоинствами XP, если его удается применить, является большая гибкость, возможностьбыстро и аккуратно вносить изменения в ПО в ответ на изменения требований и отдельныепожелания заказчиков, высокое качество получающегося в результате кода и отсутствиенеобходимости убеждать заказчиков в том, что результат соответствует их ожиданиям.Недостатками этого подхода являются невыполнимость в таком стиле достаточно больших исложных проектов, невозможность планировать сроки и трудоемкость проекта на достаточнодолгую перспективу и четко предсказать результаты длительного проекта в терминахсоотношения качества результата и затрат времени и ресурсов. Также можно отметитьнеприспособленность XP для тех случаев, в которых возможные решения не находятся сразу наоснове ранее полученного опыта, а требуют проведения предварительных исследованийXP как совокупность описанных техник впервые было использовано в ходе работы напроектом C3 (Chrysler Comprehensive Compensation System, разработка системы учета выплат46работникам компании Daimler Chrysler).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
