[Pfc-prolog-cvs] prolix-doc/pfc-es/proceso metodologia.tex,1.1,1.2

[<iva...@us...>]

Update of /cvsroot/pfc-prolog/prolix-doc/pfc-es/proceso
In directory sc8-pr-cvs1:/tmp/cvs-serv12138

Modified Files:
	metodologia.tex 
Log Message:
Borrado metodologia - Contenido inadecuado

Index: metodologia.tex
===================================================================
RCS file: /cvsroot/pfc-prolog/prolix-doc/pfc-es/proceso/metodologia.tex,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -d -r1.1 -r1.2
*** metodologia.tex	20 Aug 2003 18:43:15 -0000	1.1
--- metodologia.tex	20 Aug 2003 20:27:31 -0000	1.2
***************
*** 1,87 ****
- %
- %  Proceso de desarrollo::metodologia
- %
- % Especificación formal del requisitos
- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
- 
- \section{Metodología de desarrollo}
-  Para el desarrollo de \texttt{Prolix} se utilizó una metodologia compendio de otras. Principalmente:
- 
- \begin{itemize}
-   \item Proceso tradicional de desarrollo
-   \item Proceso Unificado
-   \item Extreme programming, XP, o programación extrema.
- \end{itemize}
- 
-  Por \emph{Proceso tradicional de desarrollo} nos referimos al dividido en tres etapas: análisis, diseño e implementación. El mas conocido y utilizado por el desarrollador hasta la fecha de comenzar el proyecto. Influenció un intento de análisis completo de la aplicación, que presentó numerosas complejidades, principalmente por la introducción de un aspecto totalmente nuevo como era el desarrollo de una aplicación Web.
- 
-  El \emph{Proceso Unificado} tal como se explica en el libro <<UML y patrones>>, fue la segunda influencia en el proyecto. Añade al proceso tradicional la idea de iteraciones en el sentido de funcionalidades que se le añaden al programa. Esto simplificó la primera aproximación al proyecto, pero es un proceso que requiere numerosa documentación y sigue lastrando el desarrollo con mucho <<metatrabajo>>.
- 
-  Pero sin duda fue \emph{XP o Programación Extrema} la metodologia más influyente en el desarrollo. A pesar de estar orientada a otro tipo de proyectos, en los que hay involucrado mayor numero de personas, algunas de sus ideas resultaron útiles en el desarrollo de \texttt{Prolix}.
- 
-  Para entender la verdadera utilidad de XP, es necesario conocer el problema de los planteamientos tradicionales a la hora de desarrollar software. El crecimiento en el tamaño de los programas, continuo desde el nacimiento de la informática ha ido planteando problemas que se han intentado resolver desde distintos frentes. Principalmente por un proceso de desarrollo ordenado (analisis-diseño-implementación) y por unos lenguajes de programación que facilitasen el reaprovechamiento del software y los mecanismos necesarios para construir programas más fiables. Este ultimo aspecto fue el más potenciado, desde los lenguajes que no admitian subrutinas, hasta los lenguajes como Java orientados a objetos, pasando por los lenguajes procedurales, sin embargo hasta hace muy poco tiempo no se planteó la duda de si el problema podria estar en el primer aspecto que comentarmos: el proceso de desarrollo. 
- 
-  Uno de los problemas tradicionales es el de la descoordinación de los requerimientos iniciales con los del usuario/cliente en el momento de la entrega del software, y su solución se planteó durante mucho tiempo en el terreno de los lenguajes: construirlos mas modulares, en piezas mas pequeñas y reaprovechables, para poder adaptar el programa si no se cumplen los requerimientos previstos, o estos cambian en un plazo razonable. 
- 
-  Sin embargo esta solución se demuestra insuficiente, pues las aplicaciones siguen creciendo y los problemas no desaparecen, sino que cambian de terreno: se complica el diseño, aumentan los artefactos que lo rodean en forma de tablas, diagramas, esquemas, \dots
- 
-  Enfocando el tema desde otro punto de vista, si observamos la evolución del software libre, podemos observar como se desarrollan programas cada vez mayores, cada vez mas complejos, en el que hay involucradas muchas más personas. Y son programas que funcionan, que crecen bien, y con un rendimiento y fiabilidad asombrosas, sin necesidad de un proceso muy complejo de desarrollo, ni una autoridad central que coordine de forma exacta el trabajo. ¿Donde esta el truco?
- 
-  Desde hace relativamente poco tiempo, se ha planteado la cuestión de si el problema es el esquema analisis-diseño-implementación. Y la solución esta en el modelo <<iterativo>>, aunque hay muchas formas de plantearlo. El <<proceso unificado>> antes comentado, introduce la idea de iteración en el proceso, lo que le da mayor flexibilidad, pero sigue manteniendo un demasiada parafernalia a su alrededor como para aprovechar todo su rendimiento.
- 
-  \emph{XP} lleva a sus ultimas consecuencias el concepto de iteración, rodeandolo de muchas ideas novedosas que llevan a una forma totalmente nueva desarrollar software. 
- 
- \subsection{Programación extrema}
- 
-  Programación extrema se define a si misma como una <<metodologia ligera para el desarrollo de programas en un entorno de requerimientos que varian muy rapido>>.
- %FIXME cita adecuada.
- 
-  Establece cuatro variables para valorar un proyecto:
- \begin{itemize}
-   \item Coste del programa
-   \item Tiempo de desarrollo
-   \item Calidad del producto
-   \item <<Alcanze>> en el sentido de funcionalidad obtenida.
- \end{itemize}
- 
-  Lo que se pretende es minimizar el coste y tiempo, maximizar la calidad, y ajustar la funcionalidad exactamente a lo que el cliente (o usuario) necesita. Este ultimo punto es clave: obtener funcionalidad \emph{util} que nos permita centrarnos en problemas que es necesario resolver sin introducir dificultades nuevas e innecesarias en el proyecto. Este aspecto resulta un tanto sorprendente comparado con la idea intuitiva de desarrollar un programa con la mayor funcionalidad posible.
- 
-  La idea de XP para lograr estos objetivos es minimizar el <<coste del cambio>>, que la modificación del programa para añadir nuevas caracteristicas o mejoras las anteriores sea el mínimo posible. Parece utópico, sin embargo resulta posible siguiendo lo que se conoce como los 4 valores:
- 
- \begin{itemize}
-    \item Comunicación
-    \item Simplicidad
-    \item Retroalimentación (<<feedback>>)
-    \item Valor
- \end{itemize}
- 
-  XP esta orientado al trabajo en equipo. Aunque como veremos mas adelante sus ideas también resultaron utiles en el desarrollo de un proyecto en solitario, como es por definición un proyecto fin de carrera. El trabajo en equipo que propone XP esta basado en una continua comunicación entre los programadores, tanto entre si mismos, como con el cliente. Todo el mundo sabe o puede saber todo del proyecto que se desarrolla. Para ello se promueve la simplicidad: el código más sencillo posible que cumpla con la funcionalidad deseada. La retroalimentación implica la comunicación con el usuario: saber continuamente que le parece el proyecto, que opina de uno u otro aspecto, que funcionalidad necesita,\dots
- 
-  El valor se refiere al miedo natural del programador: hacer cambios en un programa en funcionamiento siempre provoca miedo, con la filosofia de trabajo de XP puede aparecer un problema grave que implique cambios profundos cuando no queda demasiado tiempo para la entrega del proyecto\dots Siendo consciente de estos miedos y motivando al programador a asumir y apreciar su trabajo, se puede lograr una facilidad de cambio mucho mayor.
- 
-  Estos cuatro valores, se plasman finalmente en 12 <<prácticas>> que hacen funcionar un proyecto en XP:
- 
- \begin{enumerate}
-   \item El juego del diseño. Planificar rapidamente la funcionalidad a añadir en el siguiente lanzamiento del programa, teniendo en cuenta los problemas técnicos y los deseos del cliente.
-   \item Lanzamientos del programa cada poco tiempo. Poner un sistema simple en producción lo más rapidamente posible y luego sacar versiones con nueva funcionalidad cada poco tiempo.
-   \item Metafora. Entendido como mantener por medio de una historia comprensible el objetivo del proceso de desarrollo.
-   \item Diseño simple. Hacer un diseño de lo que se necesita en ese momento, lo más simple que funcione posible. 
-   \item Pruebas. Escribir y ejecutar continuamente test del sistema, utilizando las herramientas de test automático para comprobar que todo sigue funcionando despues de cambiar las cosas.
-  \item Refactorizar. Estar dispuesto continuamente a reescribir y rediseñar el codigo que sea necesario para simplificarlo, hacerlo mas legible, sin añadir o quitar características.
-  \item Programación en parejas. La figura tradicional de programador ahora se sustituye por la de 2 programadores trabajando en un ordenador: la comunicación entre esos dos programadores producirá código mas claro y sencillo.
-  \item Propiedad colectiva. Cualquier puede cambiar cualquier cosa del programa. No existe <<mi>> código que nadie puede modificar.
-  \item Integración continua. Lo mas rapidamente posible se deben integrar los cambios en el proyecto, y comprobar que todo sigue funcionando.
-  \item 40 horas a la semana. Es la forma de definir que se trabaja siempre lo mismo: una cantidad de tiempo a la semana. Esto evita periodos de inactividad que terminan en el stress de una entrega en un plazo imposible de cumplir.
-  \item Cliente <<en casa>>. Durante todo el desarrollo hay alguien que representa al cliente (a ser posible el cliente real) para poder consultarle todo lo necesario.
-  \item Estándares de codificación. Es indispensable para que un proyecto con esta filosofia funcione establecer unos estándares en la forma de escribir código que faciliten la comunicación. Promueve las buenas practicas de programación.
- \end{enumerate}
- 
-  Con la aplicación de estas prácticas junto con unas cuantas sugerencias más, es posible el desarrollo de proyectos reales. Existen empresas que desarrollan software con esta metodología. Adjuntamos en la bibliografia algunos enlaces interesantes respecto a este tema.
- 
- \subsection{Metodologia utilizada en \texttt{Prolix}}
- 
-  La aplicación de XP en el proyecto se puede considerar más <<filosofica>> que práctica, en el sentido de que muchas de las prácticas sugeridas no pueden ser acatadas en un proyecto fin de carrera. Sin embargo las ideas de codificar rápido, de forma lo mas sencilla posible, con el valor suficiente para refactorizar cuando hace falta si que fue posible aplicarla. 
- 
-  El resultando final fue un proceso iterativo planificado en un principio: se decidieron cuantas iteraciónes con qué funcionalidades y en que plazos se realizarian, con una planificación mas parecida al proceso unificado que al XP. En cada iteración se realizó una planificación de los pasos necesarios para obtener la funcionalidad requerida. Especialmente en las primeras, donde el aprendizaje de nuevas tecnologias ocupaba gran parte del tiempo de desarrollo.
- 
-  
\ No newline at end of file
--- 0 ----