Quiero compartir con uds. mis conclusiones personales que he obtenido durante el desarrollo de un trabajo "extra-académico", del cual basta decir que ha servido para demostrar aquellos “huecos” y fortalezas en nuestra documentación y desarrollo de un software, esto como estudiantes de la ciencia informática.
Nuestro trabajo consistió en estudiar una serie de "postulados" y analizar si han sido puestos en práctica en alguno de nuestros desarrollos de software, y las conclusiones son las siguientes.
En la mayoría de las ocasiones (por dar una crifra, el 9 de cada 10 proyectos), existen aspectos que no son llevados a cabo debido principalmente al corto periodo de tiempo con el que se cuenta para el desarrollo de los proyectos (se habla de periodos semestrales, no obstante estos periodos "semestrales" más bien son de cuando mucho, cinco meses. Y señores, en cinco meses no se lleva a cabo un buen proyecto considerando muchos factores que muy bien muchos catedráticos y estudiantes conocemos muy bien -días "festivos", falta de disponibilidad cuando necesitamos orientación, cierto egoísmo para compartir ideas e información, etc., etc.).
Así mismo, otro factor importante en el progreso, y principalmente para la conclusión de un proyecto académico, son la orientación y experiencia del personal que imparten las distintas asignaturas que requieren el desarrollo de un software.
Al no existir un documento o una estructura estándar para el desarrollo y documentación de un proyecto de software, son muchas las posibilidades para documentar y desarrollar el mismo, por lo que, un maestro podría seguir un enfoque mientras que otro seguiría algún otro enfoque, lo que sin lugar a dudas resulta en documentación “incompleta” e “inexacta” y con un gran abanico de posibilidades, que, a la larga, termina por satisfaces a todos y a nadie a la vez. En esencia, al momento de evaluar enfoques dado lo que un estilo considera el otro no, y viceversa, es imposible satisfacer a todos con un solo enfoque.
En lo que respecta a la experiencia es otro factor relevante en el desarrollo y puesta en marcha de un proyecto de software. Ciertamente se puede poseer un gran conocimiento teórico en lo que se refiere a cómo documentar y desarrollar el proyecto, sin embargo, sin la experiencia que da el realmente poner en práctica esos conocimientos, éstos decrementan su importancia debido a que no hay nada mejor que probar las cosas, llevarlas a cabo en el mundo real y analizar, estudiar y evaluar esos conocimientos teóricos que poseemos y sobre todo, ver si realmente los resultados son los que, en teoría se espera.
Es por ello, que en muchos de nuestros proyectos de desarrollo de software, los resultados esperados no siempre han sido los mismos, ya que el éxito de un proyecto no depende solamente de los conocimientos que podamos adquirir y que nuestros maestros puedan compartir con nosotros, existen otros factores como la disponibilidad de tiempo del cliente, la preparación y cultura tecnólogica del cliente, entre otros, que definitivamente transforman el progreso del proyecto y obligan a hacer ajustes a esos conocimientos teóricos que poseemos, y que, como estudiantes impacta significativamente en nuestros tiempos, calidad y avance de nuestros proyectos.
Agradeceré sus comentarios al respecto... Críticas constructivas y que aporten elementos interesantes siempre serán bienvenidas.
2008/04/10
2008/04/02
Metodologías de desarrollo de software
Hola a todos de nuevo. Me he ausentado un periodo de tiempo debido a que estoy trabajando con el desarrollo de mi proyecto de tesis usando JSF (JavaServer Faces). En esta nueva entrada compartiré con ustedes algunos opiniones personales y algunas otras que son bastante compartidas en cuanto a las metodologías para el desarrollo de software.
En esta ocasión les platicaré un poco sobre la metodología XP (eXtremme Prograamming) pues igual en ella me apoyo para el desarrollo de mi proyecto. El interés se debe a que en pláticas con algunos compañeros existe la confusión si UML (Unified Modeling Language; Lenguaje Unificado de Modelado) es una metodología, y antes de empezar a platicarles un poco sobre XP me gustaría aclarar un poco esto en base a lecturas previas y razonamiento sobre qué es UML y qué se puede hacer con él.
En esencia, UML NO ES UNA METODOLOGIA, como su nombre lo indica, es un lenguaje para modelar las especificaciones de un sistema de desarrollo. Por tanto, UML es independiente de la metodología de desarollo, de ésta manera pueden trabajar con XP por ejemplo y apoyarse en las notaciones UML para los diagramas de clase, casos de uso, etc. UML NO ESPECIFICA COMO DESARROLLAR el software.
Ahora bien, les platicaré un poco sobre XP. eXtremme Programming es una metodología propuesta por Kent Beck y sus puntos esenciales son:
* Desarrollo del proyecto por parejas. Esto permite una retroalimentación y evita las situaciones donde entre tanta gente involucrada en el desarrollo es díficil tomar decisiones.
* Orientando todo a las pruebas, se realizan pruebas de unidad de los módulos.
* 40 horas de trabajo semanal, las horas extras mitigan los ánimos de los desarrolladores.
* Procura una homegenoidad y/o estandarización en el código.
* KISS = Keep it simple stupid!!. Mantener las cosas lo más simple posible es garantía de enredos lógicos de programación y una ardúa tarea de depuración. Lograr que funcionen las cosas como deben de funcionar y al nivel más fácil de comprender. Los "arreglos" (mejoras de eficiencia en el código, reducción del código innecesario, mayor separación entre clases de objetos, etc.) serán llevados a cabo una vez concluido el proyecto, o en su defecto, cada módulo del mismo.
De estos puntos apoyo firmemente la idea del trabajo en parejas. Ciertamente, 3, 4, 5, ..., n cerebros piensan más que 2 pero sin lugar a dudas, sin una buena organización y definición de las funciones que cada miembro del equipo de desarrollo tiene, a mediano plazo resultará en un caos donde todos piensan tener la razón y/o quieran implementar las cosas de acuerdo a sus criterios.
Un elemento MUY importante que deben de considerar es mantener una homegeneidad en el código. Me ha tocado ver aplicaciones en X herramienta (por mencionar una, Delphi) en donde los nombres de los objetos y componentes visuales de la aplicación son imprecisos. Qué más impreciso puede ser: TextEdit1 ¿? Los equipos de desarrollo deben de procurar siempre seguir lineamientos en cuanto a las nomenclaturas de objetos e inclusive en la estructura de directorios del proyecto, vaya, CADA COSA EN SU LUGAR.
Así por ejemplo, almacenen las imagenes en una carpeta imgs por ejemplo, las clases que pertenecen al modelo del problema dentro de un paquete específico, etc. Nomenclaturas "estándares" para los componentes visuales de la aplicación. Estas son prácticas y hábitos que aquel que se considere como programador debe tener muy en cuenta. Además, estas prácticas reducen el impacto "negativo" de agregar una nueva persona al equipo de desarrollo, dado que lo que esta persona debe de saber son esos lineamientos y con ello, no habrá tanto pierde.
Bueno, pues por el momento es todo. Los puntos mencionados sobre XP son los más relevantes, aunque difiero de la opinión de 40 horas a la semana, soy más de los que apoyan la idea e incluso haría más honor al nombre: ¡Programación Extrema!
En esta ocasión les platicaré un poco sobre la metodología XP (eXtremme Prograamming) pues igual en ella me apoyo para el desarrollo de mi proyecto. El interés se debe a que en pláticas con algunos compañeros existe la confusión si UML (Unified Modeling Language; Lenguaje Unificado de Modelado) es una metodología, y antes de empezar a platicarles un poco sobre XP me gustaría aclarar un poco esto en base a lecturas previas y razonamiento sobre qué es UML y qué se puede hacer con él.
En esencia, UML NO ES UNA METODOLOGIA, como su nombre lo indica, es un lenguaje para modelar las especificaciones de un sistema de desarrollo. Por tanto, UML es independiente de la metodología de desarollo, de ésta manera pueden trabajar con XP por ejemplo y apoyarse en las notaciones UML para los diagramas de clase, casos de uso, etc. UML NO ESPECIFICA COMO DESARROLLAR el software.
Ahora bien, les platicaré un poco sobre XP. eXtremme Programming es una metodología propuesta por Kent Beck y sus puntos esenciales son:
* Desarrollo del proyecto por parejas. Esto permite una retroalimentación y evita las situaciones donde entre tanta gente involucrada en el desarrollo es díficil tomar decisiones.
* Orientando todo a las pruebas, se realizan pruebas de unidad de los módulos.
* 40 horas de trabajo semanal, las horas extras mitigan los ánimos de los desarrolladores.
* Procura una homegenoidad y/o estandarización en el código.
* KISS = Keep it simple stupid!!. Mantener las cosas lo más simple posible es garantía de enredos lógicos de programación y una ardúa tarea de depuración. Lograr que funcionen las cosas como deben de funcionar y al nivel más fácil de comprender. Los "arreglos" (mejoras de eficiencia en el código, reducción del código innecesario, mayor separación entre clases de objetos, etc.) serán llevados a cabo una vez concluido el proyecto, o en su defecto, cada módulo del mismo.
De estos puntos apoyo firmemente la idea del trabajo en parejas. Ciertamente, 3, 4, 5, ..., n cerebros piensan más que 2 pero sin lugar a dudas, sin una buena organización y definición de las funciones que cada miembro del equipo de desarrollo tiene, a mediano plazo resultará en un caos donde todos piensan tener la razón y/o quieran implementar las cosas de acuerdo a sus criterios.
Un elemento MUY importante que deben de considerar es mantener una homegeneidad en el código. Me ha tocado ver aplicaciones en X herramienta (por mencionar una, Delphi) en donde los nombres de los objetos y componentes visuales de la aplicación son imprecisos. Qué más impreciso puede ser: TextEdit1 ¿? Los equipos de desarrollo deben de procurar siempre seguir lineamientos en cuanto a las nomenclaturas de objetos e inclusive en la estructura de directorios del proyecto, vaya, CADA COSA EN SU LUGAR.
Así por ejemplo, almacenen las imagenes en una carpeta imgs por ejemplo, las clases que pertenecen al modelo del problema dentro de un paquete específico, etc. Nomenclaturas "estándares" para los componentes visuales de la aplicación. Estas son prácticas y hábitos que aquel que se considere como programador debe tener muy en cuenta. Además, estas prácticas reducen el impacto "negativo" de agregar una nueva persona al equipo de desarrollo, dado que lo que esta persona debe de saber son esos lineamientos y con ello, no habrá tanto pierde.
Bueno, pues por el momento es todo. Los puntos mencionados sobre XP son los más relevantes, aunque difiero de la opinión de 40 horas a la semana, soy más de los que apoyan la idea e incluso haría más honor al nombre: ¡Programación Extrema!
Suscribirse a:
Entradas (Atom)