Контрольная работа по дисциплине «Информационные системы в экономике» для ТулГУ, пример оформления

СОДЕРЖАНИЕ Введение. 3 1.Понятие зкстремального программи́рования. 4 2.Классификация экстремальное программирование. 5 3.Техническая характеристика XP. 7 3.1.Основы приемов XP. 16 4.Плюсы и минусы.. 18

5. Исторические факты использования. 19

Заключение. 20 Список  используемой литературы.. 21                                 Введение Актуальность темы. Экстремальное программирование (XP) — это набор методов, которые помогут вам написать лучший код. Экстремальное программирование, часто называемое XP, — это разработка программного обеспечения и бизнес-дисциплина в разработке программного обеспечения, которая направляет усилия обеих сторон (программистов и бизнесменов) на общие, достижимые цели. Команды, использующие XP, производят высококачественное программное обеспечение с очень высокой скоростью. Методы, которые являются частью дисциплины XP, выбраны потому, что они основаны на человеческом творчестве и предположении, что человек является нестабильным и подверженным ошибкам существом. XP часто представляется как набор приемов, но сама XP не является финишной чертой. Нет необходимости практиковаться и разрабатывать XP, чтобы получить долгожданную золотую звезду в конце этого процесса. Наоборот, XP — это стартовая линия. XP поднимает вопрос: «Насколько минимальными могут быть наши усилия, чтобы мы могли продолжать выпускать высококачественное программное обеспечение?» Экстремальное программирование — это упрощенный метод организации производства для команд небольших и средних специалистов, занимающихся разработкой программного продукта в условиях неясных или быстро меняющихся требований. Целью данной контрольной работы является изучение экстремального программирования. Для достижения оставленной цели необходимо решить следующие задачи:         1.Понятие зкстремального программи́рования Экстремальное программирование (XP) — одна из гибких методологий разработки программного обеспечения. Авторами методологии являются Кент Бек, Уорд Каннингем, Мартин Фаулер и другие. XP — это упрощенный, эффективный, гибкий, предсказуемый, научно обоснованный и очень приятный способ разработки программного обеспечения с низким уровнем риска. XP отличается от других методов следующими способами: Благодаря использованию чрезвычайно коротких циклов разработки, XP обеспечивает быструю, реальную и постоянно работающую обратную связь. В контексте XP используется прогрессивное планирование, поэтому общий план проекта представляется довольно быстро, однако следует понимать, что этот план развивается на протяжении всей жизни проекта. В рамках XP используется гибкий график реализации конкретной функции, которая улучшает реакцию на изменения характера бизнеса и меняющиеся требования клиентов в этом отношении. XP основана на автоматизированных тестах, разработанных как программистами, так и клиентами. Благодаря этим тестам можно отслеживать процесс программирования, обеспечивать правильное развитие системы и немедленное обнаружение неисправностей в системе. XP основан на словесном обмене информацией, тестах и ​​исходном коде. Эти три инструмента используются для обмена информацией о структуре системы и ее поведении. XP опирается на развивающийся процесс проектирования, который длится до тех пор, пока существует сама система. XP основана на тесном взаимодействии программистов с самыми популярными навыками и возможностями. XP основана на методах, которые удовлетворяют как краткосрочные инстинкты отдельных программистов, так и долгосрочные интересы всего проекта. XP — это дисциплина разработки программного обеспечения. Это дисциплина, потому что в XP есть определенные вещи, которые вы должны сделать, если собираетесь использовать XP. Вы не должны выбирать, писать тесты или нет, потому что если вы этого не сделаете, то программирование, которое вы делаете, нельзя назвать экстремальным. Техника XP предназначена для работы над проектами, над которыми могут работать от двух до десяти программистов, которые не ограничены жесткими рамками существующей компьютерной среды и в которых вся необходимая работа, связанная с тестированием, может быть выполнена в течение одного дня.     2.Классификация экстремальное программирование Где начинается экстремальное программирование? При том понимании, что типичная позиция отечественного разработчика программного обеспечения требует максимального снижения затрат на разработку. И для этого необходимо интенсивно работать с заказчиком, понимать его интересы и в конечном итоге делать именно то, что он хочет: ни больше, ни меньше. Экстремальное программирование не основано на определенных методах, как это обычно принято, а только на четырех основных принципах: общение, простота, обратная связь и смелость. Вы должны начать с них. Экстремальное программирование предлагает готовое решение: сделайте все как можно проще, держите клиента при себе или оставайтесь с ним, позволяйте ему активно следить за процессом разработки, приветствовать изменения — и успех почти гарантирован. . В командах, работающих над методом XP, общение всегда приветствуется — самый быстрый способ обмена информацией и опытом. Это очень важно, когда требуется максимальная скорость программирования. Но общение, как и любое другое полезное начинание, требует постоянной поддержки. Поэтому, кто-то в команде должен взять на себя ответственность за мониторинг коммуникаций, чтобы стать так называемым дипломатом. Общение и необходимость объяснять свои действия другим членам команды заставляют вас делать все как можно проще. Если это не работает в первый раз, они все больше и больше работают над упрощением, пока не достигнут главной цели — максимальной понятности кода для других программистов. Что бы мы ни делали — вставляем нитку в иголку или идем на вечеринку — мы всегда стремимся достичь какой-то цели. Если мы замечаем, что мы отходим от этого, то мы соответствующим образом корректируем свои действия. А теперь представьте, насколько труднее попасть в иголку с закрытыми глазами или красиво одеться без зеркала! Но во время разработки программы это часто происходит: мы делаем что-то, результат чего нам не виден. Поэтому в экстремальном программировании общепризнанно видеть результат своих действий как можно быстрее. Или, с технической точки зрения, предоставьте максимально быструю обратную связь. Экстремальное программирование спрашивает нас: почему бы не набраться смелости в себе? Ведь это очень важно на работе. Можно ли взять на себя ответственность за выполнение задачи без смелости даже в определенный момент времени? Можно ли без смелости осознать, что вы зашли в тупик, сделать шаг назад и искать обходной путь? И, наконец, что позволит разработчику признать свою ошибку при оценке задачи и своевременно предупредить остальных, вместо того, чтобы столкнуться с фактом, когда все сроки прошли? Преимущества смелости очевидны, и любой успех, даже при самых маленьких задачах, может развить эту смелость.   3.Техническая характеристика XP Экстремальное программирование (XP) возникло как эволюционный метод разработки программного обеспечения снизу вверх. Этот подход является примером так называемого метода гибкой разработки. Группа «живых» методов включает в себя, помимо экстремального программирования, методы SCRUM, DSDM (метод разработки динамических систем, метод разработки динамических систем), ориентированное на ресурсы развитие (разработка, управляемая функциями системы) и т. д. , Основные принципы разработки «живого» программного обеспечения зафиксированы в манифесте «живой» разработки, появившемся в 2000 году.

• Люди, вовлеченные в проект и его коммуникацию, важнее, чем процессы и инструменты.
• Рабочая программа важнее, чем полная документация.
• Сотрудничество с заказчиком важнее, чем обсуждение деталей контракта.

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

• Тем не менее, XP имеет свою собственную схему процесса разработки (хотя, как правило, широко используемое понимание «процесса разработки» как довольно жесткой схемы действий противоречит самой идее «живости» развития), показанной на рис. 1.
• По мнению авторов XP, этот метод не следует общим шаблонам действий, поскольку он применяет комбинацию следующих методов. Кроме того, по словам Кента Бека, одного из авторов этого подхода, наряду с Уордом Каннингемом и Роном Джеффрисом, каждая техника важна, и без ее использования считается, что разработка не основана на XP.
• Планирование в реальном времени (планирование игры)

Его работа заключается в том, чтобы как можно скорее определить объем работы, которую необходимо выполнить перед следующей версией программного обеспечения. Решение принимается, во-первых, на основе приоритетов клиента (т.е. его потребностей, того, что ему нужно от системы для более успешной компании) и, во-вторых, на основе технических оценок ( или оценки сложности разработки, совместимости с другими элементами системы и т. д.). Планы меняются, как только они начинают расходиться с реальностью или желаниями клиента. Рис.1 Схема потока работ в XP  

• Частая смена версий (small releases)

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

• Метафора (metaphor) системы

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

• Простые проектные решения (simple design)

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

• Разработка на основе тестирования (test—driven development)

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

• тестирование модулей (unit testing);
• приемочное тестирование (acceptance testing).

Разработчик не может быть уверен в правильности написанного им кода до тех пор, пока не сработают абсолютно все тесты модулей разрабатываемой им системы. Тесты модулей позволяют разработчикам убедиться в том, что их код работает корректно. Они также помогают другим разработчикам понять, зачем нужен тот или иной фрагмент кода и как он функционирует. Тесты модулей также позволяют разработчику без каких-либо опасений выполнять рефакторинг (refactoring). Приемочные тесты позволяют убедиться в том, что система действительно обладает заявленными возможностями. Кроме того, приемочные тесты позволяют проверить корректность функционирования разрабатываемого продукта. Для XP более приоритетным является подход называемый TDD (Test Driven Development), сначала пишется тест, который не проходит, затем пишется код, чтобы тест прошел, а уже после делается рефакторинг кода.

• Постоянная переработка (refactoring)

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

• Программирование парами (pair programming)

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

• Коллективное владение кодом (collective ownership)

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

• Постоянная интеграция (continuous integration)

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

• 40-часовая рабочая неделя

Сверхурочная работа рассматривается как признак больших проблем в проекте. Не допускается сверхурочная работа 2 недели подряд — это истощает программистов и делает их работу значительно менее продуктивной. Человек, особенно если он программист, ради дела способен на многое: задержаться на работе, выйти на работу на выходные, отказаться от отпуска, несколько суток не спать, сидя за клавиатурой… В общем, чего только не сделаешь ради любимого занятия. Но экстремальное программирование категорически против такого самопожертвования и нарушения принятых норм трудового права. Это продиктовано не только соображениями законности и гуманности, а — в первую очередь — необходимостью повышения эффективности работы и строгой организации. Ведь экстремальное программирование — коллективная игра, рассчитанная не на индивидуумов, а на всю группу целиком. А такая вещь, как, например, парное программирование, возможна лишь при синхронизации биоритмов ее участников. И она невозможна, если один человек будет приходить на работу к девяти, а второй к двенадцати или один решит, что ему лучше поработать в субботу и воскресенье, а другому это неудобно. Но самое главное — человеку, чтобы сохранить здоровье и работоспособность, необходим полноценный отдых. Восьмичасовой рабочий день и пятидневная рабочая неделя установлены именно из соображений максимальной продуктивности. Во многих западных фирмах поздний уход с работы расценивается как неуспеваемость или неспособность правильно распорядиться своим рабочим временем. В большинстве случаев это так и есть. Да и с медицинской точки зрения, задержки на работе ведут к постоянной усталости, раздражительности и снижению мозговой деятельности. Разве это эффективно? А как в таком коллективе организовать постоянное открытое общение между разработчиками, и возможно ли будет парное программирование? Ответ отрицательный. Нормы есть нормы, и их стоит придерживаться.

• Включение заказчика в команду (on—site customer)

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

• Использование кода как средства коммуникации

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

• Открытое рабочее пространство (open workspace)

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

• Изменение правил по необходимости (just rules)

Каждый член команды должен принять перечисленные правила, но в случае необходимости команда может изменить их, если все ее члены согласны с этим изменением. Как видно из используемых методик, XP предназначена для использования в небольших группах (не более 10 программистов), что также подчеркивается авторами этой методики. Большая команда разрушает простоту общения, необходимую для успеха, и делает невозможным использование многих из этих методов.   3.1.Основы приемов XP Двенадцать основных методов экстремального программирования (согласно объяснению первой редакции экстремального программирования) можно сгруппировать в четыре группы:

• Короткая петля обратной связи (точная обратная связь)

o Разработка через тестирование (разработка через тестирование) o Расписание игры o Клиент всегда рядом (вся команда, клиент на месте) о парное программирование

• Непрерывный процесс, без периодического процесса

o Непрерывная интеграция o Рефакторинг (улучшение дизайна, рефакторинг) o Частые небольшие публикации

• Понимать, разделяемый всеми

o Простота (простой дизайн) Системная метафора o Коллективное владение кодом или выбранные шаблоны проектирования o Стандарт кодирования или условные обозначения кодирования

• Социальная защита программиста (благосостояние программиста):

o 40-часовая неделя (устойчивый темп, 40-часовая неделя) Игра в планирование Наш мир слишком нестабилен и непредсказуем, чтобы полагаться на постоянство ситуации. То же самое происходит при разработке программного обеспечения: о редкой системе можно сказать, что ее окончательная форма была подробно известна в самом начале разработки. Как правило, аппетит клиента приходит во время еды: он постоянно хочет что-то изменить, что-то улучшить и вообще что-то выкинуть из системы. Это разнообразие требований, которых все так боятся. К счастью, человеку предоставляется возможность прогнозировать возможные варианты и, таким образом, держать ситуацию под контролем. В экстремальном программировании планирование является неотъемлемой частью разработки, и тот факт, что планы могут меняться, учитывается с самого начала. Точка опоры, техника, позволяющая предвидеть ситуацию и безболезненно переносить изменения, является игрой планирования. Во время такой игры вы можете быстро собрать известные системные требования, оценить и спланировать их развитие в соответствии с приоритетами. Как и в любой другой игре, планирование имеет своих участников и цель. Клиент, очевидно, является ключевой фигурой. О необходимости определенных функций сообщается. Разработчики дают приблизительную оценку каждой функциональности. Прелесть планировочной игры заключается в единстве цели и сплоченности между разработчиком и заказчиком: в случае победы все выигрывают, в случае неудачи все проигрывают. В то же время каждый участник подходит к победе по-своему: клиент выбирает наиболее важные задачи в соответствии с бюджетом, а программист оценивает задачи в соответствии со своими навыками для их реализации. Экстремальное программирование предполагает, что разработчики могут решить, как долго выполнять свою работу, кто из них больше готов решить проблему, а кто еще. В идеале игра планирования с заказчиком и программистом должна проводиться каждые 3-6 недель до начала следующей итерации разработки. Это позволяет легко вносить коррективы на основе успехов и неудач предыдущей итерации.         4.Плюсы и минусы Преимуществами XP, если они могут быть применены, являются большая гибкость, возможность быстро и точно вносить изменения в программное обеспечение в ответ на изменения требований и индивидуальных пожеланий клиентов, высокое качество получаемого кода и отсутствие нужно убедить клиентов, что результат соответствует их ожиданиям. Недостатками этого подхода являются невыполнимость в этом стиле достаточно крупных и сложных проектов, невозможность планировать время и сложность проекта на достаточно длительный срок и четко прогнозировать результаты длительного проекта с точки зрения соотношения качество результата и затраты времени и ресурсов. Также можно отметить непригодность XP для тех случаев, когда возможные решения не сразу основаны на предыдущем опыте, а требуют предварительных исследований.  

5. Исторические факты использования

XP как совокупность описанных техник впервые было использовано в ходе работы на проектом C3 (Chrysler Comprehensive Compensation System, разработка системы учета выплат работникам компании Daimler Chrysler). Из 20-ти участников этого проекта 5 (в том числе упомянутые выше 3 основных автора XP) опубликовали еще во время самого проекта и в дальнейшем 3 книги и огромное количество статей, посвященных XP. Приведенные ниже данные иллюстрируют проблемы некоторых техник XP при их применении в достаточно сложных проектах. Проект стартовал в январе 1995 года. С марта 1996 года, после включения в него Кента Бека, он проходил с использованием XP. К этому времени он уже вышел за рамки бюджета и планов поэтапной реализации функций. Команда разработчиков была сокращена, и в течение примерно полугода после этого проект развивался довольно успешно. В августе 1998 года появился прототип, который мог обслуживать около 10 000 сотрудников. Первоначально проект должен был быть завершен в середине 1999 года, и полученное в результате программное обеспечение будет использоваться для управления платежами 87 000 сотрудников. Он был прекращен в феврале 2000 года после 4 лет работы над XP из-за полного несоблюдения сроков и бюджета. Созданное программное обеспечение никогда не использовалось для работы с данными для более чем 10 000 сотрудников, хотя было показано, что оно будет обрабатывать данные для 30 000 сотрудников компании. Человек, сыгравший роль клиента, входящего в состав проектной команды, ушел после нескольких месяцев этой работы, не выдержав нагрузки, и не получил адекватной замены до конца проекта.         Заключение Все эти методы не собраны случайно. Его последовательная комбинация способна привнести процесс разработки в интеллектуальный резонанс, значительно повысив качество продукта и сократив время его выпуска. Основная прелесть всех экстремальных программ — предсказуемость и минимизация затрат на разработку; предоставить клиенту продукт, который он желает получить во время запуска; и, конечно же, общение на рабочем месте и обучение разработчиков. Мнения о предлагаемой методологии могут отличаться. Важно понимать, что экстремальное программирование не предназначено для замены существующих технологий разработки. Напротив, XP позволяет дать дополнительный импульс командам, которые используют традиционные подходы. Не ищите здесь ответов на все ваши вопросы. Это не технология программирования, а технология организации работы, и именно так вы имеете право на жизнь.                             Список  используемой литературы

1. Автоматизированные информационные технологии в бизнесе: Учебник / М.И. Семенов, И.Т. Трубилин, В.И. Лойко, Т.П. Барановская; По сумме. изд. Трубилина. — М .: Финансы и статистика, 2002. — 416 с .: илл.
2. Wirtschaftsinformatik / Под ред. П. В. Конюховский и Д. Н. Колесов. — СПб .: Питер, 2001. — 560 с., Ил.
3. Основы информационных систем: учебник. Пособие / А. Н. Морозевич, Н. Н. Говядинова, Б. А. Железко и др .; По сумме. под ред. А. Н. Морозевича. — Мн .: ООО «Мисанта», 1998. 438с.
4. Проектирование бизнес-информационных систем: учебник. Пособие / В.В. Стяжкина; Инструментальное состояние ун-т Тула, 1998,74с.
5. Мишенин А.И. Теория бизнес-информационных систем: Учебник. — 4-е издание, расширение и порабощение. — М .: Финансы и статистика. 2000. — 240 с .: Илл.

Экономическая информатика: Учебник / Под  ред. В.П.Косарева и Л.В.Еремина. – М.: Финансы и статистика, 2001. – 592с.: ил.

7. Смирнова Г.Н. и др. Проекты экономических информационных систем: Справочник / Г.Н.Смирнова, А.А. Сорокин Ю.Ф. Тельнов; Ред. Ю.Ф. Тельнова. — М .: Финансы и статистика, 2002. — 512 с .: Илл.
8. Подольский В.И. и др. Информационные системы учета: Учебник для вузов / Подольский В.И., Дик В.В., Уринцов А.И.; Ред. Подольский В.И. — М .: Аудит, ЕДИНСТВО, 1998. — 319 с.
9. Романов А.Н. Информационные системы для экономических консультаций: Уч. пособие для вузов / А.Н. Роянов Б.Е. Одинцов. — М .: УНИТИ, 2000 .— 478 с.
10. Информационные системы в экономике: учебник / В.В.Дик, Е.В. Беднева, В.П. Божко и др .; Ред. В.В.Дика. — М .: Финансы и статистика, 1996. — 270с.
11. Автоматизированные компьютерные технологии в экономике: учебник для вузов / В. В. Брага, Н. Г. Бубнова, Л. А. Вдовенко и др .; под руководством Г.А. Титоренко. — М .: ЕДИНСТВО, 2000. — 400 с.
12. Вендров А.М. Разработка программного обеспечения для экономических информационных систем: учебник для экон. университет / А.М. Vendrov. — М .: Финансы и статистика, 2000. — 352 с., Ил.
13. Вендров А.М. Практикум по разработке программного обеспечения для экономических информационных систем: Учеб. пособие для вузов / А.М. Vendrov. — М .: Финансы и статистика, 2002. — 192 с .: ил.
14. Информационные технологии (для экономистов): Учебник / Под общ. Издание А.К. Вялково. — М .: ИНФРА-М, 2001 .— 310с. — (Серия «Высшее образование»)
15. Информационные технологии. Руководство по новой экономике (серия бизнес-руководств «Проверено Ъ»). М .: КоммерсантЪ XXI, Альпина, 2002.— 320 с.
16. Романов А.Н., Торопцов В.С., Григорович Д.Б. Технологии дистанционного обучения в системе заочного экономического образования. — М .: ЕДИНСТВО-ДАНА, 2000 .— 303 с.
17. Костров А.В. Основы управления информацией: Учебник. пособие. — М .: Финансы и статистика, 2001. — 336 с .: ил.
18. Костров А.В., Александров Д.В. Уроки управления информацией. Мастерская: Учебник. пособие. — М .: Финансы и статистика, 2005. — 304 с .: ил.
19. Информационные системы / Петров В.Н. — СПб .: Питер, 2003.— 688 с .: ил.
20. «Бухгалтер и компьютер». Ежемесячное приложение к журналу «Бухгалтерский учет».
21. Компьютер для бухгалтера. Учебное пособие 2 / В. Филатова. — СПб.: Питер, 2004. — 315 с .: ил.
22. Рязанцева Н.А., Рязанцев Д.Н. 1С: Предприятие. Комплексная конфигурация. Секреты работы. — св. СПб .: БХВ-Петербург, 2004. — 624 с .: ил.
23. Технологии разработки программного обеспечения. Пособие для обучения. 2-е изд. / С.Орлов. — СПб.: Питер, 2003. — 480с.: Больной.