Hola a todos, después de un breve tiempo de ausencia regreso con los resultados del 13o Concurso Nacional de Minirobótica que se llevó a cabo en la ciudad de Santiago de Querétaro los días 1 y 2 de Mayo del presente. Para ello divido el presente en 3 secciones: Cómo nos fue, Cómo estuvo todo, Cómo estuvieron los demás y mis conclusiones. La categoría en la que participamos fue Categoría Lego educacional abierta, específicamente en la "subcategoría" Robot transportador de Lego.
Además, es importante que toda aquella persona o institución que lea esto no se sienta ofendidad ni nada por el estilo, son más bien críticas constructivas que persiguen el puro objetivo de mejorar nuestro nivel académico, mejorar el funcionamiento de algunas instituciones en cuanto a tramités "burocráticos" y cuestiones de este estilo. Bueno, sin más preámbulos, iniciamos...
¿Cómo nos fue?
Bastante bien :D considerando que fue nuestro primer concurso de este tipo. En concreto, Roberto, Germán y yo hemos de haber quedado entre 10o y 15vo lugar :( .... de 39 equipos! Lamentablemente no pasamos a las finales, sólo los mejores 8 primeros lugares... Pero aquí viene lo bueno... Francisco y Santiago quedaron en 4o lugar!!! Y pasaron a las finales!!! :D Ya en las finales aunque lograron avanzar más lejos con la caja al parecer quedaron en el mismo 4o lugar, cuando muy bajo en quinto lugar. Nos comentaron que los resultados serían publicados en la página pero que únicamente habían considerado publicar los tres primeros lugares, la doctora María del Pilar Pozos Parra (quien fue nuestra asesora) les pidió de favor a los jueces que hablaran con los organizadores y que al menos consideraran publicar los mejores 8 equipos esto para demostrar que en verdad hubo un equipo de nosotros que quedó entre los primeros 8 mejores de 39!!! Además, de seguro que la UJAT (nuestra universidad, la Universidad Juárez Autónoma de Tabasco) preguntará cómo nos fue y así platicadito quién sabe si alguien nos crea!! :D
¿Cómo estuvo todo?
Personalmente y como en muchos concursos hubieron cosas que no me agradaron y no porque no hayamos ganado... Creo que aún no hemos aprendido que las reglas se hicieron para romperse o al menos a "doblarlas" para así obtener la flexibilidad deseada (o al menos es lo que muchos ya entendieron y así lo hacen!). A la mera hora habían escenarios que eran 3 cm. más largos o más anchos, hubo un equipo que participó con su propio escenario (y que por cierto quedaron en 2o lugar!). Héctor Ortiz-Parada (también integrante de uno de los 2 equipos que concursamos) compartió con nosotros la idea de chocar con las paredes para "enderezar" el robot? Resulta que cuando empezamos a hacer pruebas todos los equipos, NINGUNO más que nosotros utilizaba esa técnica. Habían algunos que chocaban pero por error y no porque fuese su intención. Sin embargo, como a los 15 min. en eso que estamos haciendo fila y esperando nuestro turno para hacer nuestras pruebas, empezamos a ver que ya muchos equipos hacían lo que nosotros hacíamos, pues ya habían visto nuestras pruebas!!!
¿Cómo estuvieron los demás?
Pues en la primera ronda (todos los equipos tuvimos 3 min., en estos 3 min. podíamos hacer cuanto reintentos pudiéramos si se chocaba nuestro robot o no se comportaba como quisiéramos) hasta por el equipo número 20 y la mayoría cuando mucho llegaba a donde nosotros llegabamos, es decir, estuvo bastante parejo. Algunos otros de plano fallaban muy gacho y no avanzaban mucho, se chocaba su robot antes del primer empuje a la caja, etc., etc. Sólo un equipo logró resolver el problema (de hecho, ese equipo fue el primer lugar; por cierto, implementaron unas llantitas laterales lo que le permitía al robot desplazarse bien aún cuando chocara con las paredes laterales, prácticamente lo que usted nos sugirió cuando le colocamos el "bigote" al robot, en fin, sin comentarios)...
Conclusiones
Para ser nuestro primer concurso de este tipo y contra todas las prisas y contratiempos, presiones, considerando que la Uni por poquito y no nos apoya, ya que un día antes es que aprueban el apoyo, considerando que fueron 2 días sin tocar cama! El día que llegamos a Puebla, a casa del Sr. Héctor, luego luego a seguir trabajando, nada de dormir, los taxis no nos querían levantar en Querétaro pues llevábamos la caja, ahí nos veían tirando nuestros abrigos encima del taxi para no rayarles el taxi al poner el escenario encima, en fin... El 90% de los equipos concursantes usaron el LEGO Mindstorms (un programa donde se programa el robot por diagrama de bloques o como se llame), tuve la oportunidad de platicar con un muchacho que ha de haber sido de los pocos que manejaron algún otro lenguaje, pues el uso Bricks-C o algo así me parece que se llama... Estoy seguro que fuímos los únicos en manejar Java ; ) .
EN ESENCIA: QUE UVM DE QUERETARO, QUE IPN, QUE VERACRUZANA NI QUE NADA!! DIMOS LATA!!! Con todo respeto para los compañeros estudiantes de esas universidades y no los estos menospreciando, es sólo que quiero que consideren que el sureste SI tiene calidad, sí damos batalla, la UJAT pelea hasta el final!! Y eso que sólo trabajamos como 2 semanas cuando mucho y trabajabamos sólo de 3 a 4 horas cuando mucho! Sin que comer, sin mucho dinero, sin todos esos "lujos y ventajas" que poseen estudiantes de universidades pagadas!! Nos medimos y estamos a la altura!!! Y ese es el mejor premio que pude haber recibido! Lástima que no llegó ningún equipo de la UNAM! :) O de alguna universidad extranjera!
2008/05/05
2008/04/10
Sobre nuestra situación académica como estudiantes de la ciencia informática
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.
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/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)