Предмет: Информатика
Тип: Курсовая работа
Объем: 32 стр.
|
Закрыть
|
Экстремальное программирование (XP)
Содержание
Введение 3
1 Экстремальное программирование (XP) 6
1.1 Участие Бека в проекте 9
1.2 Риск: основная проблема 11
1.3 Тестирование 13
1.4 Игра в планирование 13
1.5 Парное программирование 14
1.6 Простота дизайна 15
1.7 Стандарты кодирования 16
1.8 Коллективное владение 17
2 Быстрая разработка ПО 18
2.1 Возможные ошибки быстрой разработки ПО 18
2.2 Рабочий программный продукт и исчерпывающая документация 19
2.3 Совместная работа с заказчиком и обсуждение условий контракта 20
2.4 Реакция на изменения и соблюдение плана 22
2.5 Принципы быстрой разработки ПО 24
Заключение 29
Список используемой литературы 32
Введение
Экстремальное программирование - это упрощенная методика организации производства для небольших и средних по размеру команд специалистов, занимающихся разработкой программного продукта в условиях неясных или быстро меняющихся требований. Данная книга предназначена для того, чтобы помочь определить, оправдано ли применение ХР в вашей ситуации.
Для многих ХР выглядит набором вполне приемлемых и оправданных с точки зрения здравого смысла методов организации труда. Тогда почему программирование в соответствии с методиками ХР называется экстремальным? Дело в том, что ХР доводит использование многих общепринятых и широко используемых принципов программирования до экстремальных уровней.
1 Экстремальное программирование (XP)
Экстремальное программирование (англ. Extreme Programming, XP) -сокращенно, XP - является ответом сообщества программистов на наступление формальных подходов к созданию программных продуктов и призвано вернуть в среду разработчиков дух творчества.
ХР - это упрощенный, эффективный, гибкий, предсказуемый, научно обоснованный и весьма приятный способ разработки программного обеспечения, предусматривающий низкий уровень риска. От других методик ХР отличается по следующим признакам.
1.1 Участие Бека в проекте
В конце 1998 года, в процессе усердной работы над кодированием процес¬са Object-Mentor, я случайно наткнулся на работу Кена по экстремальному про¬граммированию (ХР). Фрагменты статьи были размещены на Web-узле Уорда Каннингема (Ward Cunningham) под названием, где они были представле¬ны вперемешку с работами других авторов. С некоторым трудом мне удалось понять суть того, о чем говорил Кен. Я был заинтригован, но настроен весь¬ма скептически. Некоторые из аспектов, которые были отображены в идеологии экстремального программирования, в точности совпадали с моей концепцией про¬цесса разработки. Другие аспекты, такие как отсутствие четкого описания этапов проектирования, напротив, привели меня в некоторое замешательство.
1.2 Риск: основная проблема
Существующие дисциплины разработки программного обеспечения не срабатывают и не дают желаемого экономического эффекта. Эта проблема обладает огромным экономическим и гуманитарным значением. Мы нуждаемся в новом способе разработки программного обеспечения.
Основная проблема разработки программного обеспечения – это риск.
Вот несколько примеров риска.
• Смещение графиков – наступает день сдачи работы, и вы вынуждены сообщить заказчику, что разрабатываемая система не будет готова еще в течение шести месяцев.
• Закрытие проекта – после нескольких смещений графика и переносов даты сдачи проект закрывается, даже не будучи доведен до стадии опробования в рабочих условиях.
• Система теряет полезность – разработанное программное обеспечение успешно устанавливается в реальной производственной рабочей среде, однако после пары лет использования стоимость внесения в нее изменений и/или количество дефектов увеличиваются настолько, что становится дешевле заменить систему новой разработкой.
1.3 Тестирование
В XP особое внимание уделяется двум разновидностям тестирования:
тестирование модулей (unit testing);
приемочное тестирование (acceptance testing).
Разработчик не может быть уверен в правильности написанного им кода до тех пор, пока не сработают абсолютно все тесты модулей разрабатываемой им системы.
Тесты модулей позволяют разработчикам убедиться в том, что их код работает корректно. Они также помогают другим разработчикам понять, зачем нужен тот или иной фрагмент кода и как он функционирует. Тесты модулей также позволяют разработчику без каких-либо опасений выполнять рефакторинг (refactoring).
1.4 Игра в планирование
Основная цель игры в планирование - быстро сформировать приблизительный план работы и постоянно обновлять его по мере того, как условия задачи становятся все более четкими. Артефактами игры в планирование является набор бумажных карточек, на которых записаны пожелания заказчика (customer stories), и приблизительный план работы по выпуску следующих одной или нескольких небольших версий продукта. Критическим фактором, благодаря которому такой стиль планирования оказывается эффективным, является то, что в данном случае заказчик отвечает за принятие бизнес-решений, а команда разработчиков отвечает за принятие технических решений. Если не выполняется это правило, весь процесс распадается на части.
1.5 Парное программирование
Парное программирование предполагает, что весь код создается парами программистов, работающих за одним компьютером. Один из них работает непосредственно с текстом программы, другой просматривает его работу и следит за общей картиной происходящего. При необходимости клавиатура свободно передается от одного к другому. В течение работы над проектом пары не фиксированы: рекомендуется их перемешивать, чтобы каждый программист в команде имел хорошее представление о всей системе. Таким образом, парное программирование усиливает взаимодействие внутри команды.
1.6 Простота дизайна
Простота дизайна XP исходит из того, что в процессе работы условия задачи могут неоднократно измениться, а значит, разрабатываемый продукт следует проектировать заблаговременно целиком и полностью. Если в самом начале работы вы пытаетесь от начала и до конца детально спроектировать систему, вы напрасно тратите время. XP предполагает, что проектирование – это настолько важный процесс, что его необходимо выполнять постоянно в течение всего времени работы над проектом. Проектирование должно выполняться небольшими этапами, с учетом постоянно изменяющихся требований. В каждый момент времени мы пытаемся использовать наиболее простой дизайн, который подходит для решения текущей задачи. При этом мы меняем его по мере того как условия задачи меняются.
1.7 Стандарты кодирования
Все члены команды в ходе работы должны соблюдать требования общих стандартов кодирования. Благодаря этому:
1.8 Коллективное владение
Коллективное владение означает, что каждый член команды несёт ответственность за весь исходный код. Таким образом, каждый вправе вносить изменения в любой участок программы. Парное программирование поддерживает эту практику: работая в разных парах, все программисты знакомятся со всеми частями кода системы. Важное преимущество коллективного владения кодом — в том, что оно ускоряет процесс разработки, поскольку при появлении ошибки её может устранить любой программист.
2 Быстрая разработка ПО
2.1 Возможные ошибки быстрой разработки ПО
Из-за быстрой разработки ПО повторяются ошибки, а также напрас¬но затрачиваются усилия. В результате заказчики выражают недовольство из-за смещения графиков проекта и ухудшения его качества. Разработчики впадают в уныние наблюдая обратную зависимость между объемом трудозатрат и каче¬ством разрабатываемого программного обеспечения.
2.2 Рабочий программный продукт и исчерпывающая документация
Поставка программы без сопровождающей документации может привести к негативным последствиям. Программный код сам по себе не является идеаль¬ным средством, позволяющим взаимодействовать по законам логически непроти¬воречивой и структурированной системы. Настоятельно рекомендуется разрабо¬тать документацию, удобную для восприятия человеком, в которой описывается система, а также приводится логическое обоснование принимаемых в ходе осу¬ществления проекта решений.
2.3 Совместная работа с заказчиком и обсуждение условий контракта
Процедура заказа программ весьма отличается от действий, предпринимае¬мых в процессе заказа обычного товара. Недостаточно просто составить описание требуемого программного продукта, а затем попросить кого-либо разработать его в рамках четко определенного графика за фиксированную цену. Во многих случа¬ях попытки трактовать подобным образом программные проекты терпят полный крах. Иногда эти провалы являются весьма болезненными.
2.4 Реакция на изменения и соблюдение плана
Очень часто успех или неудача программного проекта определяется способ¬ностью реагировать на изменения. В процессе формирования планов следует удо¬стовериться в том, что эти документы обладают достаточной гибкостью и мо¬гут адаптироваться в соответствии с изменениями, вносимыми в процесс работы и технологию.
2.5 Принципы быстрой разработки ПО
Вышеприведенные положения послужили причиной появления 12 принципов быстрой разработки ПО, заменяющих традиционный громоздкий процесс раз¬работки.
Заключение
Проанализировав работу, можно сделать следующие выводы:
Экстремальное программирование (англ. Extreme Programming, XP) - одна из гибких методологий разработки программного обеспечения. Авторы методологии - Кент Бек, Уорд Каннингем, Мартин Фаулер и другие.
Двенадцать основных приёмов экстремального программирования (по первому изданию книги Extreme programming explained) могут быть объединены в четыре группы:
Список используемой литературы
1. Кент Бек: Экстремальное программирование — Питер, 2002
2. Кент Бек, Мартин Фаулер: Экстремальное программирование: планирование — Питер, 2003.
3. Кент Бек: Экстремальное программирование: разработка через тестирование — Питер, 2003.
4. Кен Ауэр, Рой Миллер: "Экстремальное программирование: постановка процесса с первых шагов и до победного конца" — Питер, 2003
