Студопедия

КАТЕГОРИИ:


Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748)

Введение. Экстремальное Программирование (Extreme Programming)

Экстремальное Программирование (Extreme Programming)

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

 

Тяжеловесные методологии (heavyweight methodology) имеют много правил и практик и документов. Требуется жёсткая дисциплина для того чтобы следовать всему этому достаточно чётко.

 

Легковесная методология (lightweight methodology) вводит всего несколько правил и практик, причём только те из них, которым легко следовать.

 

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

 

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

 

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

 

Эти условия привели к тому, что в последнее время для разработки автоматизированных систем для бизнеса всё чаще предпочтение отдаётся не тяжеловесным процессам, требующим большого объёма документации и других вспомогательных процессов и задач, что приводит как к удорожанию конечного продукта, так и, что наиболее важно, в увеличенному времени его создания, т.е. к плохому удовлетворению требования Time To Market, а более лёгким (или гибким, Agile) методологиям. Одной из таких методологий является Экстремальное Программирование.

 

Экстремальное программирование, несмотря на своё название, представляет собой весьма строгую и дисциплинированную методологию построения жизненного цикла ПО. Эта методология существует уже более 8 лет и уже доказала свою эффективность во многих компаниях и больших и маленьких.

 

Основной причиной успеха XP является его ориентированность на удовлетворённость заказчика. Основной принцип методологии – это доставка того ПО которых хочет заказчик и тогда когда он в нём нуждается. XP позволяет разработчикам реагировать на изменение требований заказчиком даже на поздих этапах его жизненного цикла.

 

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

 

XP улучшает проектные работы четырьмя способами:

  • Общение (communication)
  • Простота (simplicity)
  • Обратная связь с заказчиком (feedback)
  • Персональное вовлечение (courage)

 

 

<== предыдущая лекция | следующая лекция ==>
Введение в Rational Unified Process | Кодирование. В основе экстремального программирования лежит ряд практик
Поделиться с друзьями:


Дата добавления: 2014-01-05; Просмотров: 427; Нарушение авторских прав?; Мы поможем в написании вашей работы!


Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет



studopedia.su - Студопедия (2013 - 2024) год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! Последнее добавление




Генерация страницы за: 0.009 сек.