METODOLOGIAS DE DESARROLLO
Una metodología de desarrollo de software se reere al entorno que se usa para estructurar, planicar y controlar el proceso de desarrollo de un sistema de información.
Una gran variedad de metodologías se han desarrollado a lo largo de los años, cada una de ellas con sus fortalezas y debilidades.
Una determinada metodología no es necesariamente aplicable a todo tipo de proyectos, ms bien cada tipo de proyecto tiene una metodología a la que se adapta me!or.
• Una "etodologia de desarrollo de software consiste en#
 –  Una losofía de desarrollo de sofware con una base de procesos de desarrollo de software
 –  "$ltiples herramientas, modelos y m%todos, para asistir en el proceso de desarrollo de software.
 –  &uele estar documentada y alguna clase de documentación formal.
 –  &uele estar promovida por alg$n tipo de organización ya sea esta p$blica o privada que es la que se encarga de promover esta metodología.
• 'iferentes enfoques sobre desarrollo de &oftware
 –  (ada metodología de desarrollo tiene ms o menos su propio enfoque de en lo que debería de consistir un proyecto de desarrollo de software.
 –  )ero todas ellas se basan en una serie de enfoques generalistas como son#
• *aterfall "odel + ineal
• apid /pplication 'evelopment 0/'1 22 iterativo
2.1.2 INCREMENTAL
 
(ombinación de metodologías iterativas y lineales con el ob!etivo primario de reducir los riesgos del proyecto, los proyectos se dividen en partes mas pequeñas, de esta manera tambi%n se facilitan los cambios durante el proceso de desarrollo.
• )ermite construir el proyecto en etapas incrementales en donde cada etapa agrega funcionalidad.
• (ada etapa consiste de anlisis, diseño, codicación y pruebas.
• )ermite entregar al cliente un producto ms rpido en comparación del modelo de cascada.
• educe los riesgos ya que# o )rovee visibilidad sobre el progreso a trav%s de sus nuevas
versiones. o )rovee retroalimentación a trav%s de la funcionalidad
mostrada.
o )ermite atacar los mayores riesgos desde el inicio.
• &e pueden hacer implementaciones parciales si se cuenta con la suciente funcionalidad.
• as pruebas y la integración es constante.
• 3l progreso se puede medir en periodos cortos de tiempo.
• esulta ms sencillo acomodar cambios al acotar el tamaño de los incrementos.
• &e puede planear en base a la funcionalidad que se quiere entregar primero.
Los principios fundamentaes son!
 
• 4inalmente el proceso culmina con la implantación del sistema en su con!unto 0otro mini2waterfall1
"enta#as • os clientes no esperan hasta el n del desarrollo para utilizar el
sistema. )ueden empezar a usarlo desde el primer incremento. • os clientes pueden aclarar los requisitos que no tengan claros
conforme ven las entregas del sistema. • &e disminuye el riesgo de fracaso de todo el proyecto, ya que se
puede distribuir en cada incremento. • as partes ms importantes del sistema son entregadas primero,
por lo cual se realizan ms pruebas en estos módulos y se disminuye el riesgo de fallos.
Des$enta#as • 3l modelo -ncremental no es recomendable para casos de sistemas
de tiempo real, de alto nivel de seguridad, de procesamiento distribuido, y5o de alto índice de riesgos.