MODELOS AGILES

Nuevas tcnicas para aplicar las prcticas esenciales de la programacin extrema y mtodos giles para
desarrollar sistemas orientados a objetos se encuentre la metodologa gil. Es cuando el desarrollo de
software es incremental (entregas pequeas de software, con ciclos rpidos), cooperativo (cliente y
desarrolladores trabajan juntos constantemente con una cercana comunicacin), sencillo (el mtodo en
s mismo es fcil de aprender y modificar, bien documentado), y adaptable (permite realizar cambios de
ltimo momento)
El modelado gil tambin abarca un conjunto de principios esenciales. Adems delos principios
esenciales de la programacin extrema, el modelado gil agrega principios tales como "modelar con un
propsito", "el software es su meta principal" y "viajar con poco equipaje", una forma de decir que
poca documentacin es suficiente.
Entre las metodologas giles identificadas:
Extreme Programming
Scrum
Familia de Metodologas Crystal
Feature Driven Development
ProcesoUnificado Rational, unaconfiguracingil
Dynamic Systems Development Method
Adaptive Software Development
Open Source Software Development
MODELOS PREDICTIVOS
Las metodologas no giles son aquellas que estn guiadas por una fuerte planificacin durante todo el
proceso de desarrollo; llamadas tambin metodologas tradicionales o clsicas, donde se realiza una
intensa etapa de anlisis y diseo antes de la construccin del sistema.
Todas las propuestas metodolgicas antes indicadas pueden considerarse como metodologas
tradicionales por el especial nfasis que presenta en cuanto a su adaptacin a las condiciones del
proyecto (mediante su configuracin previa a aplicarse), realizando una configuracin adecuada, podra
considerarse gil.
La inspiracin usual para las metodologas han sido disciplinas como las ingenieras civil o mecnica.
Tales disciplinas enfatizan que hay que planear antes de construir. Los ingenieros trabajan sobre una
serie de esquemas que indican precisamente qu hay que construir y cmo deben juntarse estas cosas.
Muchas decisiones de diseo, como la manera de controlar la carga sobre un puente, se toman
conforme los dibujos se producen. Los dibujos se entregan entonces a un grupo diferente, a menudo
una compaa diferente, para ser construidos. Se supone que el proceso de la construccin seguir los
dibujos. En la prctica los constructores se encuentran con algunos problemas, pero stos son
normalmente poco importantes.
Como los dibujos especifican las piezas y cmo deben unirse, actan como los fundamentos de un plan
de construccin detallado. Dicho plan define las tareas que necesitan hacerse y las dependencias que
existen entre estas tareas. Esto permite un plan de trabajo y un presupuesto de construccin
razonablemente predecibles. Tambin dice en detalle cmo deben hacer su trabajo las personas que
participan en la construccin. Esto permite que la construccin requiera menos pericia intelectual,
aunque se necesita a menudo mucha habilidad manual.
As que lo que vemos aqu son dos actividades fundamentalmente diferentes. El diseo, que es difcil
de predecir y requiere personal caro y creativo, y la construccin que es ms fcil de predecir. Una vez
que tenemos el diseo, podemos planear la construccin. Una vez que tenemos el plan de construccin,
podemos ocuparnos de la construccin de una manera ms predecible. En ingeniera civil la

construccin es mucho ms costosa y tardada que el diseo y la planeacin.

As el acercamiento de muchas metodologas es: queremos un plan de trabajo predecible que pueda
usar gente del ms bajo nivel. Para hacerlo debemos separar el plan de la construccin. Por
consiguiente necesitamos entender cmo hacer el diseo de software de modo que la construccin
pueda ser sencilla una vez que el plan est hecho.
Qu forma toma este plan? Para muchos, ste es el papel de notaciones de diseo como el UML.
(Lenguaje de Modelado Unificado) Si podemos hacer todas las decisiones significativas usando UML,
podemos armar un plan de construccin y entonces podemos dar planes a los programadores como una
actividad de construccin.
Pero aqu surgen preguntas cruciales. Es posible armar un plan que sea capaz de convertir el cdigo en
una actividad de construccin predecible? Y en tal caso, es la construccin suficientemente grande en
costo y tiempo para hacer valer la pena este enfoque?
Todo esto trae a la mente ms preguntas. La primera es la cuestin de cun difcil es conseguir un
diseo UML en un estado que pueda entregarse a los programadores. El problema con un diseo tipo
UML es que puede parecer muy bueno en el papel, pero resultar seriamente fallido a la hora de la
programacin. Los modelos que los ingenieros civiles usan estn basados en muchos aos de prctica
guardados en cdigos ingenieriles. Adems los problemas importantes, como el modo en que juegan las
fuerzas, son dciles al anlisis matemtico. La nica verificacin que podemos hacer con los diagramas
UML es la revisin cuidadosa. Mientras esto es til trae errores al diseo que slo se descubren durante
la codificacin y pruebas. Incluso los diseadores experimentados se sorprenden a menudo cuando
convierten dichos diseos en software.
Otro problema es el costo comparativo. Cuando se construye un puente, el costo del esfuerzo en el plan
es aproximadamente un 10% del total, siendo el resto la construccin. En software la cantidad de
tiempo gastada codificando es mucho, mucho menor. Se sugiere que para un proyecto grande, slo 15%
del proyecto son cdigo y pruebas unitarias, una inversin casi perfecta de las proporciones de la
construccin del puente. Aun cuando se consideren las pruebas parte de la construccin, el plan es
todava 50% del total. Esto genera una pregunta importante sobre la naturaleza del diseo en software
comparado con su papel en otras ramas de la ingeniera.
MODELOS AGILES

MODELOS PREDICTIVOS

Su cdigo se puede dividir en actividades

Hay que hacer actividades que se van deduciendo

de las anteriores

Falta de documentacin
Flexibilidad a los cambios
Ideologa de colaboracin