PONTIFICIA UNIVERSIDAD CATLICA DEL

ECUADOR PUCESI

DATOS INFORMATIVOS

Nombre: Kimberly Paredes

Fecha: 2014/06/03

Nivel:Quinto

ENSAYO

La ingeniera de Software naci en 1952, nadie hacia software antes, as que las primeras personas que empezaron
a hacerlo imitaban los modelos de ingeniera de hardware o de las otras ingenieras, en el ao 1968 fue la primera
conferencia sobre ingeniera de software, fue la primera vez en que se empieza a hablar sobre este tema. La mayor
parte de programacin se la hace artesanalmente pero deberamos hacer software industrialmente, adems
deberamos separar la parte de diseo de la parte de construccin.

Antes de la construccin es el diseo

Una de las claves que un proyecto gil es el uso de un ciclo de vida iterativo, a veces tambin incremental, frente al
ciclo de vida en cascada. La caracterstica que mejor identifica un proyecto gil, sin duda, esta sera el ciclo de vida
iterativo. Que aunque en muchas ocasiones se considere algo novedoso, o revolucionario, es conveniente recordar,
e incluso tranquilizante, que el veterano ciclo de vida iterativo e incremental es incluso ms antiguo que el ciclo de
vida en cascada, y que se empez a aplicar al software en los 60.

Existen otras dos prcticas esenciales: La integracin continua que consiste en que diariamente se crear una versin
ejecutable del producto, es decir, cada fichero es compilado, enlazado con las libreras correspondientes,
desplegado, etc. Y por si esto fuera poco la integracin continua an puede alcanzar mayor valor si viene
acompaada de la segunda prctica, el llamado smoke test que es conjunto de comprobaciones preliminares a
las que se somete la versin para evaluar si funciona correctamente y la calidad con que ha sido desarrollada. La
dificultad de integrar es inversamente proporcional a la frecuencia en que se realizan las integraciones, y la
integracin continua permite que los problemas y riesgos de la integracin se minimicen.

El smoke test es una de las prcticas ms efectivas para reducir los problemas de calidad de las versiones, ya que
permite que los problemas de calidad se vayan observando poco a poco, de manera diaria, cuando an son fciles
de solucionar.

Cuando se habla de metodologas giles es el uso de la documentacin. Aunque el manifiesto gil no rechaza el que
se documente en los proyectos, si antepone otras muchas cosas frente a documentar, y muchos proyectos han
interpretado esto como que en un proyecto gil no se debe escribir ningn documento. Y esto es un error, y muchos
proyectos, con los aos, han sufrido mucho este problema, e incluso se han visto imposibilitados a la hora de
cambiar de proveedor de desarrollo software.

Sin embargo, la ineficacia de los primeros documentos de diseo, no es argumento para su eliminacin. En el
desarrollo gil se llega a la comprensin mediante la experimentacin con el sistema software, sin duda una de las
maneras ms efectivas de aprender. Sin embargo, esta manera de aprender slo est disponible para los
diseadores que crearon el diseo, y no para aquellos que les seguirn y que no han podido participar directamente
en la creacin del diseo.

Documentar el software en el cdigo es imprudente, redunda en la pesadilla de intentar mantener la duplicacin de

informacin coherente. Necesitamos documentos de diseo a un mayor nivel de abstraccin, sin detalles
tecnolgicos innecesarios y estrechamente asociados a conceptos del domino y los requisitos. Estos documentos
no slo ayudan a ver el bosque que se oculta en el mar de cdigo, tambin a documentar los principios bsicos del
diseo y a servir como el principal medio de comunicacin entre los actores del sistema. Con la excepcin de los
sistemas relativamente pequeos, llevar el diseo de alto nivel en el cdigo (como recomienda, por ejemplo,
Extreme Programming) es imprudente.

Debiera haber documentacin de diseo gil, que mantenga y enlace el diseo y la codificacin. Y el esfuerzo
realizado en documentar debiera ser proporcional al tamao del diseo.

Uno de los retos de Scrum, y de las metodologas giles en general, es cmo se puede aplicar en equipos distribuidos,
lo que algunos llaman Global Software Development. De manera resumida, los principales problemas en este tipo
de entornos vienen de que la comunicacin e interaccin entre los miembros del equipo, que es una pieza
fundamental en un desarrollo gil, al estar en ubicaciones fsicas diferentes es mucho ms compleja.

Un error que se ha cometido durante muchos aos ha sido pensar que las metodologas giles, sin adaptacin al
caso concreto y real sobre el que operan, eran la mejor opcin para todo tipo de proyectos. Pero la realidad dice que
la cosa es ms complicada, y que cada proyecto, empresa, producto, lnea de negocio, etc., requiere de una
metodologa especfica, o de diferentes maneras de adaptar una metodologa, por eso sabemos que aunque en la
mayora de las ocasiones las metodologas giles son la mejor opcin, hay ocasiones en que incluso una
metodologa gil no es la mejor alternativa. Lo difcil es saber el punto medio exacto y ms recomendable para
cada proyecto, e incluso buscar el punto intermedio entre gil y tradicional. Sabemos que hay una metodologa
concreta para cada proyecto.

No olvidemos que aunque metodologas como Scrum son una muy buena prctica como cualquier otra puede
fallar, actualmente, usar SCRUM en un desarrollo global de software plantea una serie de retos a superar y que
vienen, principalmente y como era de esperar, de la distancia fsica, la diferencia cultural y horaria. Los anteriores
impactan principalmente en la comunicacin entre los miembros del equipo, y a las diferentes reuniones necesarias
y que son pieza fundamental en SCRUM.

Uno de los temas que ms ha dado que hablar en los ltimos tiempos ha sido si las metodologas giles y los modelos
de procesos (CMMI, ISO 15504 SPICE, etc.) podan trabajar juntos. Quizs ese enfrentamiento venia de algo que
hoy en da es un mito, y que es la creencia de que proceso es sinnimo de ciclo de vida en cascada, cosa que no es
as.

En cualquier caso, hoy en da son cada vez ms las empresas que han sabido combinar ambos enfoques,
aprovechando las ventajas de las metodologas giles y de modelos como CMMi o ISO 15504.