Personal tools
You are here: Home OSA: Методологии разработки
Document Actions

OSA: Методологии разработки

by admin_jr last modified 2003-07-03 10:51

Среди разработчиков свободного программного обеспечения существует множество споров относительно плюсов и минусов определенных методов разработки. Одним людям нравятся насыщенность и качество Pair Programming ( или Extreme Programming), в то время, как другие предпочитают быструю разработку и быструю отдачу Rapid Application Development. Есть много различных методов создания программного обеспечения, и зачастую сложно принять решение относительно того, какую технологию применить для решения отдельной проблемы.

Rapid Application Development

Rapid Application Development (RAD - Быстрая Разработка Приложений) является технологией разработки, стремящейся к выпуску работоспособного программного обеспечения в течение 60-90 дней. Она используется прежде всего сервисными компаниями, разрабатывающими программное обеспечение для специфического пользователя. Принося в жертву надежность, приспособляемость к масштабу и качество кода, пользователь получает быструю разработку и уменьшенную стоимость разработки, что может иметь жизненно важное значение для его проекта.

Walter Maner's take on RAD

Extreme Programming

Extreme Programming (XP) стремится, хоть и не явно, к специализации по выпуску кода высокого качества для оправдания постоянно меняющихся ожиданий пользователей. В отличие от RAD, Extreme Programming не стремится к выпуску всеобъемлющего продукта за 2-3 месяца, а, напротив, стремится к выпуску множества небольших продуктов за больший промежуток времени. Extreme Programming придает большое значение написанию текстов перед написанием самого кода программного продукта, чтобы гарантировать, что код, будучи уже выпущен, не будет иметь одних и тех многократно возникающих ошибок; это также позволяет программистам писать код программ, опираясь на созданные тексты, тем самым повышая его эффективность, поскольку цели написания написания кода уже ясны. Pair Programming, который не только дает множеству людей возможность просмотреть один и тот же код, но также увеличивает обмен знаниями и предотвращает возможность того, что только один человек будет «знать» ту или иную часть системы. Постоянный пересмотр кода предотвращает становление кода нечитабельным и неподдерживаемым, а также предохраняет базу основного кода от чрезмерного раздутия ненужными функциональными возможностями и плохого качества кода.
XP (Extreme Programming) имеет свои проблемы. Так устранение формальных письменных требований к разработке делает его уязвимым к постоянно возникающим изменениям программы. Избыточность pair programming может иногда замедлять процесс разработки программного обеспечения. Отсутствие детальных требований и непродуманное планирование приводят к тому, что система может иметь в целом негодный дизайн. Пересмотр кода – это очень хорошо, но это только попытка устранить проблемы, возникшие на фундаментальном уровне разработки дизайна.

ExtremeProgramming. org детальное описание процесса

SoftwareReality.com разъяснение проблем, связанных с Extreme Programming

Rational Unified Process

Rational Unified Process (Rup) отличается от XP по некоторым основным направлениям. Это – меньшее количество привлеченных к работе над проектом основных разработчиков, подразумевающее более деятельное предварительное планирование и дизайн системы, разработку требований к программе, более интенсивный предварительный процесс, предшествующий началу работы разработчиков, и больше бюрократии. Также устраняется неэффективность некоторых ресурсов, в связи с отсутствием Pair Programming элемента, ротации позиций участников проекта ; но при этом существует своя неэффективность, исходящая от наличия бюрократии. Испольэование User Cases (вместо User Stories) делает возможным более точное определение ситуаций, с которыми придется иметь дело готовому программному продукту, по сравнению с User Stories у XP, которое более стандартно. Вто время, как Cases ведут к более жестким требованиям к программному обеспечению, они могут иметь слишком узкую направленность и упускать из виду некоторые проблемы, которые могут возникнуть при использовании программного продукта.

Rational Systems whitepaper on Rational Unified Process
 


View My Stats