Si tienes alguna duda relacionada con la asignatura o con alguna clase, técnica, metodología, herramienta, etc…, puedes plantearla aquí y se intentará responder lo más pronto posible.
Archivos por mes: abril 2006
Desastres software
3er. tema de debate, grupo Rumbaugh. Plazo: hasta 6 de Mayo
Son famosas las recolecciones de los desastres causados por el ‘mal’ software. Por ejemplo, ‘software disasters‘ o ‘Collection of software bugs‘, incluso sobre errores en sistemas empotrados.
Un interesante artículo en MSNBC titulado ‘Software disasters are often people problems‘ opina que la mayoría de las veces están más relacionados con tomas de decisiones pobres o gestión de recursos humanos inadecuadas que con codigo de mala calidad.
Comenta David Crow en su blog que la mayoría de las profesiones mejoran a través del análisis de sus fallos y la corrección y evolución de las prácticas profesionales y de la formación de los ingenieros.
¿Ocurre esto en la Ingeniería del software y en la informática?, ¿Cree que es un problema de formación?, ¿de intrusismo?, ¿de dinero y tiempo?, ¿de falta de profesionalidad?
Comente un desastre que le haya llamado la atención y cómo se podría haber evitado, extraiga un aprendizaje.
Por qué no despega el AVE a Lleida… aún
3er. tema de debate (Grupo Jacobson) Fecha límite: 6 de Mayo
El problema para que el AVE a Lleida no pueda rodar por encima de los 200 Km/h no es político, ya tampoco geológico (¿se acuerdan de los socavones?), es… Informático. Como pueden leer en El Pais, es un problema de integración de tecnologías.
Para permitir a los trenes circular a velocidades superiores a los 300 km/h, varios países intentan desde principios de los años 90 definir un estándar técnico de señalización y seguridad que permita además superar las diferencias entre los distintos países de Europa.
La mayor parte de los problemas que está planteando el sistema ERTMS se centran en el ‘software’ de los equipos del tren que sirven para leer la información que transmite la vía. Sin esa información, el tren no puede calcular con precisión dónde se encuentra. A eso se le suma el hecho de que, en algunas ocasiones, el convoy pierde el contacto con el centro de control: ambos hechos provocan el frenado de emergencia del tren. ¿De quién es la culpa?
Varios expertos aseguran que el problema no es la tecnología en sí (el estándar no ha quedado definido totalmente, y está en continua adaptación), sino el hecho de poner a funcionar juntos equipos de distintos fabricantes. Éstos, aún más discretos, no hacen declaraciones oficiales, pero reconocen en voz baja que lo que funciona a la perfección en el laboratorio y por separado, no lo hace igual cuando se trata de ponerlo en marcha realmente.
Leo en Ciberpais, que la Asociación de Ingenieros en Informática ha solicitado que los fallos en ingeniería informática que se produzcan en las obras públicas estén sujetos a la responsabilidad civil.
Se te ha pedido que realices un breve informe en el que analices las causas en el ámbito de la Ingeniería del Software y articules medidas correctoras para futuros desarrollos
2º Debate, MDA, Grupo Jacobson
Mi jefe tenía dudas. Su metodología de desarrollo se había quedado algo obsoleta y el informe de los consultores ISO 90003 así lo confirmaba. Tantos proyectos estresantes, la presión de las fechas habían minado su capacidad de perspectiva, que desconociera las últimas tendencias de desarrollo.
-”Creo que conoces el problema, me piden que implemente un mecanismo de mejora continua del proceso de desarrollo software que facilite la innovación. Me recomiendan la instauración de metodologías como el Desarrollo de Software Dirigido por Modelos”-.
En alguna referencia había leido que la Arquitectura Dirigida por Modelos o Model-driven architecture (MDA) era una propuesta de diseño software propuesta por el OMG (Object Management Group1, 2).
Usando la metodología MDA, la funcionalidad del sistema se define como un modelo independiente de la plataforma (PIM), totalmente separado y aislado de la tecnología de implementación, usando un adecuado Lenguaje Específico del Dominio y luego traducido (mediante el uso de herramientas CASE automáticas) a uno o más modelos específicos de plataforma (PSM) para su implementación o incluso lenguajes de proposito general, como Java, C#, Python, etc…
El eterno sueño de una aplicación diseñada que perdurase años y años, decadas y decadas, siglos y siglos, pues el modelo apenas cambiaba, sólo la plataforma y la traducción del modelo a ésta era fácil y rápida.
Mirándome a los ojos como esperando la llave a sus problemas, como esperando una ráfaga de viento que disipara la neblina que cubría sus ideas, me dijo:
-”¿Crees que supondrá el fin de la programación?, ¿Crees que nos puede interesar esta metodología?, ¿Siempre?, ¿Nunca?, ¿Las software factories, se convertirá programar en ensamblar piezas como en un puzzle?
En fin, la vida del Ingeniero de Software, plagada siempre de dudas…
PD: Como se ha publicado un par de días más tarde, se amplía el plazo de entrega en dos días, hasta el 23.
2º Debate, Programación por Parejas, grupo Rumbaugh
El gerente de la empresa me había concedido la dirección de mi primer proyecto y esperaba que tomara decisiones.
-“¿Conoces las metodologías ágiles?”- me preguntó.
Raudo, y como si de un examen oral le contesté:
-”Las metodologías ágiles (como por ejemplo XP, SCRUM, DSDM, Crystal, etc..) forman parte del movimiento de desarrollo ágil de sotfware, que se basan en la adaptabilidad de cualquier cambio como medio para aumentar las posibilidades de éxito de un proyecto.
Se puede decir que, este movimiento empezó a existir a partir de febrero de 2001, cuando se reunieron los representantes de cada una de estas metodologías y terminaron poniendo en común sus ideas en una declaración conjunta (El Manifiesto Agil)“-
Con una sonrisa de complacencia, me completó:
-“La programación extrema (1, 2)es una metodología de desarrollo ligera (o ágil) basada en una serie de valores y de prácticas de buenas maneras que persigue el objetivo de aumentar la productividad a la hora de desarrollar programas. Este modelo de programación se basa en dar prioridad a los trabajos que dan un resultado directo y que reduzcan la burocracia que hay alrededor de la programación.”-
Pero de repente su sonrisa se tornó cruel y, a modo de prueba, me inquirió:
-”Una de sus prácticas recomendadas es la ‘Programación en parejas’ (3,4), uno de los principios más radicales y en el que la mayoría de gerentes de desarrollo pone sus dudas. Requiere que todos los programadores XP escriban su código en parejas, compartiendo una sola máquina. ¿Qué opinas de ella?, ¿La recomiendas?, ¿Siempre?, ¿Nunca?“-
Y es que así es la vida de los Ingenieros de Software, un examen continuo…
PD: Como se ha publicado un par de días más tarde, se amplía el plazo de entrega en dos días, hasta el 23.
