Ingeniería de Software, Gestión de Proyectos, Programación, BPM, Arquitectura de Software, .NET, J2EE
Por favor, echadle una ojeada a este pequeño artículo, me he quedado encantado:
http://desdesarrollodesoftware.blogspot.com/2009/02/cual-es-el-error.html
Un poco más ampliado el sentido del artículo anterior, lo podéis encontrar en el artículo siguiente:
http://desdesarrollodesoftware.blogspot.com/2009/02/la-respuesta-cual-es-el-error-la.html
Saludos.
Miguel.
Me hace mucha gracia, porque de vez en cuando veo algún capítulo de “House” en la 4, y hay una escena que se repite prácticamente en todos los capítulos, cuando House suelta su típico “¡Diagnóstico Diferencial!” con todo el grupo de médicos alrededor intentando, a partir de algunos síntomas lograr encontrar la fuente del problema.
Esta es una escena que, se repite también a diario en el mundo del software, sobre todo en fases de estabilización, o en herramientas que ya están trabajando en entornos de pre-producción y producción. De repente, algo falla en el sistema, ahí es cuando llega nuestro enfermo. El “sujeto” presenta algunos síntomas, descritos en el error que mostró la aplicación cuando se produjo el problema, o la traza ampliada del error en el log, o el listado de conjunto de pasos que recuerda dar el usuario antes de que se diera el fallo, una captura de pantalla, etc.
A partir de aquí, la misma escena, grupo de expertos que estudian los mensajes e intentan obtener a partir de la información con la que cuentan, la fuente del error. Se producen además las siguientes coincidencias:
1) Primera y básica, ambos funcionamos contra-reloj. El error puede estar bloqueando nuestro sistema, o creando inconsistencia de datos en el mismo. Hay que resolverlo en el menor tiempo posible, sobre todo dependiendo de la gravedad del problema.
2) Los mensajes, síntomas, pueden dar pistas que ayuden a encontrar fácilmente el problema, aunque a veces son poco descriptivos y no dan mucha información, y otras, incluso dan información que no ayudan a encontrar el problemas, es más, te llevan a conclusiones erroneas que hacen perder mucho tiempo para encontrar la fuente.
3) Otra forma de buscar la solución es mediante radiografías, escáneres del enferno, en nuestro caso, empezamos a revisar el código fuente de la zona que creemos afectada, el conjunto de datos almacenado en la base de datos… intentando así haciendo pequeñas incisiones en la “cara interna” de nuestro paciente, logramos encontrar el problema.
4) Dependiendo de la zona afectada, consultamos con diferentes expertos, Administradores de Bases de Datos, Arquitectos de Software, Arquitectos de Sistema, Analistas Funcionales y Desarrolladores. Según cuál sea además el problema, tendrán que actuar unos u otros para resolver.
Curioso cuanto menos.
Saludos!
Miguel.
Recientemente he tenido la oportunidad de participar en una presentación de Solid RAD, la herramienta para el desarrollo rápido de aplicaciones, ofrecida bajo el sello y garantía de calidad del equipo de Solid Quality Mentors
Jesús López y Daniel Seara (con el cual he tenido nuevamente el placer de coincidir) han sido los dos mentores de Solid que realizaron la presentación de forma conjunta.
A partir de la propia arquitectura y orientación de Solid RAD, la cual podréis conocer consultando el video provisto en el siguiente enlace mms://solidq.com/SolidRad (copiar el link y ejecutar pegando en la barra de dirección de Internet Explorer), destacar la inmensa oportunidad que supone compartir durante parte de una mañana, y de forma directa y personalizada, de los conocimientos y opiniones de los dos mentores. Lo que ha dado una pequeña “discusión” sobre el uso de las transacciones es algo que me gustaría exponer en un próximo artículo. A mi la visión me ha parecido genial.
Destacar entre otras cosas de Solid RAD, otras ideas fantásticas, como las de partir de un modelo de objetos de negocio para exponer el conocimiento a otras capas, pero sin orientar el modelo de objetos directamente a las entidades de datos, tal como haría un ORM, si no a las vistas definidas sobre dichas entidades de datos. Es una idea simplemente genial combiándola al mismo tiempo con el generador de código de Solid RAD, que automatiza la generación de las entidades de transporte de datos a partir de las propiedades de cada una de las vistas sobre la que es accedida.
Saludos.
Miguel.
[Actualizado a 05/10/2008]
A continuación os planteo un típico problema de modelo entidad-relación en base de datos, en el que se debe modelar una situación bastante común en un desarrollo de software. Os pediría que intentarais resolver el problema sin ver antes las tres soluciones que marco al “ejercicio” en la parte final del post, y comprobar así finalmente cuál ha sido el tipo de solución más habitual. Os agradecería además que razonarais la respuesta. En el caso de que vuestra solución no se ajuste a ninguna de las tres descritas, por favor, enviadme un diagrama a info@miguelmatas.es para que pueda adjuntarla al artículo. Sería estupendo además que en el razonamiento de vuestra solución no se limitara a las razones estríctamente del modelo y la base de datos, si no que estuviera acompañada de algún razonamiento relacionado con arquitectura de software, orientación al negocio, eficiencia a nivel de datos, protección del dato, etc. En el caso de que no queráis “perder” tanto tiempo, me doy por satisfecho si contestáis al post indicando si vuestra solución se acerca a una de las tres primeras o ha sido otra 
Gracias!
Enunciado:
Una conocida empresa de Rent a Car quiere informatizar su sistema de gestión de vehículos. En esencia, dicha empresa alquila de forma temporal los coches de los que dispone, y, en un primer proceso de ingeniería necesita contar con una descripción técnica de cómo se almacenarían el repositorio de los diferentes coches con los que cuenta en cartera.
La empresa cuenta con diferentes tipos de coches, son realmente los tipos de coches que maneja lo que la diferencia de los Rent a Car al uso, ya que los usuarios tienen la oportunidad de alquilar coches anfibios, coches voladores y coches oficiales blindados. Estos tres tipos de coche tienen algunas características en común que se desean conocer, como son la matrícula, el número de puertas y la marca. Además, de forma específica se necesita conocer el máximo de nudos a la hora a la que puede navegar un coche anfibio, los milímetros de blindaje y el tipo de blindaje de un coche oficial blindado, y la autonomía de horas de vuelo con las que cuenta un coche volador.
Posibles soluciones de modelado entidad-relación:
Os pediría por favor que no consultarais las soluciones hasta que hayáis desarrollado vuestra propia solución, para así no interferir en el resultado.
Solución 4 [nuevo 05/10/2008]
Saludos y gracias
Miguel.