10.02.08
Posted in Arquitectura, Bases de Datos, Metodologías, Software at 8:09 pm by 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 1
Solución 2
Solución 3
Solución 4 [nuevo 05/10/2008]
Saludos y gracias
Miguel.
Permalink
05.07.08
Posted in Herramientas, Metodologías, UML at 12:37 pm by Miguel
Vamos a aprovechar algún comentario en el blog al respecto de información asociada a UML para dejar para empezar algún link que pueda serviros de referente para empezar a empaparos.
Os los ordeno un poco en el orden que recomiendo leerlos para que os vaya quedando todo un poco más claro.
1) Historia de UML, qué es UML. Muestra superficial de algunos diagramas
2) Pequeños ejemplos de los diagramas UML más comunes
3) A fondo UML de casos de uso
4) A fondo UML diagrama de clases
Un saludo.
Miguel.
Permalink
11.03.07
Posted in Gestión de Proyectos, Libros, Metodologías at 7:21 pm by Miguel
Otro magnífico libro de la mano de Juan Palacio, el cual nos da la oportunidad de descargar gratuitamente en PDF o adquirirlo a través de http://www.lulu.com
Os dejo el link al artículo en su blog http://www.navegapolis.net/content/view/694/61/
Saludos.
Miguel.
Permalink
10.17.07
Posted in Gestor de Curriculums, Herramientas, Metodologías, UML at 9:29 pm by Miguel
Buceando por la red he encontrado una plantilla (en inglés) bastante buena para completar casos de uso.
Tanto me ha gustado que en el Documento de Casos de Uso que estoy preparando para el Gestor de Curriculum (no me he olvidado de su desarrollo, la cosa es que no tengo demasiado tiempo para dedicarle), voy a seguir la plantilla prácticamente al completo.
Como podréis ver, se incluye una descripción completa de cada uno de las entidades a rellenar en la plantilla.
Descargar Plantilla de Casos de Uso
Saludos.
Miguel.
Permalink
09.15.07
Posted in Gestión de Proyectos, Libros, Metodologías at 7:17 pm by Miguel
Extraigo la descripción de GTD que incorpora wikipedia en el siguiente link http://es.wikipedia.org/wiki/Getting_Things_Done
“GTD se basa en el principio de que una persona necesita borrar de su mente todas las tareas que tiene pendientes guardándolas en un lugar específico. De este modo, se libera a la mente del trabajo de recordar todo lo que necesita hacer, y permitiéndole concentrarse en la realización de aquellas tareas. La psicología de GTD se basa en hacer fácil el almacenamiento, seguimiento y revisión de toda la información relacionada con las cosas que necesitas hacer. Allen (desarrollador de la teoría) sugiere que muchos de los bloqueos mentales en los que nos encontramos a la hora de completar ciertas tareas vienen dados por una planificación insuficiente (p.e., para cualquier trabajo nosotros debemos aclarar lo que se debe conseguir y que acciones se deben llevar a cabo para completarlo). Según Allen, es más práctico hacerlo reflexionando previamente sobre ello, generando una serie de acciones que hacer más tarde sin necesidad de volverlo a planificar durante su realización.”
Puestos además en serio, me acabo de comprar el libro en Amazon.com
Título: Getting Things Done: The Art of Stress-Free Productivity
Autor: David Allen
Idioma: Inglés
En cuanto esté algo más empapado del tema… os cuento con más profundidad.
Saludos.
Miguel.
Permalink
09.13.07
Posted in Bases de Datos, Metodologías, Motivación, Programación at 8:25 pm by Miguel
A medida que voy conociendo nuevos proyectos y aplicaciones desarrolladas por otras personas, me doy aún más cuenta de la importancia de proteger y abstraer al desarrollador del modelo de datos en el que asienta una aplicación.
Proteger y abstraer siempre es algo básico, pero sobre todo, si el desarrollo de una aplicación va a llevarse en un modelo de desarrollo de Software-Factory. A continuación expongo alguna de las razones más importantes.
1) La volatidad de los profesionales que trabajan en este tipo de empresas es muy alta.
2) Es habitual que los proyectos estén integrados por un mayor porcentaje de profesionales con experiencia media/baja (becarios, programadores con un año o dos de experiencia…) elevado, liderados por un grupo reducido de profesionales con mayor experiencia (en proyectos de 4 o 5 personas estamos hablando de 1 profesional o 2 realmente qualificado).
3) La formación en las herramientas/tecnologías a utilizar por parte de los miembros del proyecto con menor experiencia es proporcional a los años de experiencia profesional que acumulan.
Con todo este panorama por delante, veo totalmente esencial que el acceso y manipulación del modelo de datos se deba llevar a cabo por los profesionales con más experiencia del grupo, abstrayendo al resto del problema, y centrándolos en el desarrollo de la vista y el controlador. Por supuesto que el desarrollo del controlador se va a basar en llamadas al modelo de datos que hemos protegido, siguiendo unos flujos que el analista funcional debe encargarse de transmitir a los programadores.
¿Cómo llevar a cabo dicha protección y abstracción? A mi modo de ver la mejor forma de realizar esta labor es llegando a crear la sensación al programador de que el modelo de datos no existe, que no hay base de datos. Únicamente disponemos de un conjunto de clases (agrupadas en un NameSpace, Package…), que representan el modelo de negocio y que cuentan ya con una serie de operaciones asociadas.
Y por supuesto dichas clases son una caja negra, de la cual sólo conocemos su estructura, pero para nada cómo funcionan por dentro. Con mi clase “Coche” podré realizar todas las operaciones asociadas a un Coche, es decir, Arrancar, Aparcar, Acelerar, Frenar, PonerFrenodeMano, BajarVentanilla, y podré acceder además a otra información como NumeroDePuertas, VelocidadActual, KilometrosRecorridos, Consumo, Marca, Modelo, Conductor…
Si necesito crear una aplicación que a partir de una ruta por una carretera calcule el consumo de diferentes modelos de coche dependiendo de su velocidad media y de si tiene las ventanillas bajadas, no tendría más que utilizar dos de mis clases Coche y Ruta de la siguiente manera.
// Definimos modelo de coche, abrimos la puerta
Coche.Modelo(Seat.SeisCientos);
Coche.AbrirPuerta();
// Creamos una nueva ruta a partir de alguna de las que tengamos definidas
Ruta.DefinirRuta(Rutas.Zaragoza-Barcelona-PorAP2);
// Asociamos la ruta al coche, marcamos velocidad, puertas y definimos que el viaje se hará
// con las ventanillas bajadas… arrancamos y ala, a viajar
Coche.EstablecerRuta(Ruta);
Coche.VelocidadMedia = 120;
Coche.NumeroPuertas = 3;
Coche.BajarVentanilla();
Coche.Arrancar();
Coche.RealizarViaje();
// Guardamos los datos asociados al viaje
Coche.AlmacenarDatosConsumo();
Como podemos ver la protección y la encapsulación es máxima. Sabemos que para poder realizar un viaje primero hay que arrancar el coche, pero no sabemos si el arrancar el coche guardará en alguna tabla alguna información al respecto. Por supuesto no sabemos cómo se realiza el cálculo del consumo de carburante respecto a la velocidad media, ruta y estado de las ventanillas… llamando a “RealizarViaje” se calculará todo. Y lo que es más importante, se habrá consultado información sobre la ruta, modelo del coche… tal vez entren en juego 5, 6 o 20 tablas, pero a nosotros nos trae sin cuidado. Y finalmente, a la hora de almacenar los datos de consumo, tal vez tengamos un histórico de consumos asociados al coche, a la ruta… no lo sabemos, de eso se encargará la clase.
¿Por cierto, quién nos asegura que la información se esté guardando en una base de datos relacional? ¿tal vez se esté llevando acabo en un excel, o en un fichero plano separado por comas… o en una mysql, en un sql server o un oracle? ¿Es necesario si quiera que el desarrollador sepa qué es una select o un insert o un update?
Nuestro modelo de datos está 100% protegido a modificaciones llevadas de forma incorrecta.
Y en cuanto a la seguridad, podríamos dar acceso a un modelo de negocio a una tercera empresa para que se encargara del desarrollo de la aplicación, pero sin mostrarle realmente lo que hay detrás (¿en una dll, en un servicio web?)
Y en cuanto a la motivación del equipo de desarrollo, siguiendo esta forma de desarrollo, ¿quién siente realmente que está moviendo al coche? ¿todos?
Saludos.
Miguel.
Permalink
05.15.07
Posted in Cursos, Metodologías at 8:54 pm by Miguel
Este es el título del último Curso al que he podido asistir. El curso es requisito indispensable para poder participar en las auditorías para obtener el nivel de madurez 2 del modelo CMMI. Certificación que ofrece el ESI, el Instituto Europeo de Software.
Curso de 21 horas en el Instituto Tecnológico de Aragón. Demasiado teórico a mi gusto, prácticamente 15 horas fueron teóricas. En parte es algo difícil de evitar, sobre todo porque partimos de la base de que sólo disponemos de 21 horas. La metodología necesita su tiempo para poder ver cómo está organizada, y como intenta abordar las diferentes areas de proceso.
La verdad es que por fin tuve la oportunidad de poder conocer in situ el funcionamiento del CMMI, y entender bastante mejor las críticas que conocía sobre el modelo.
Como rápido resumen sobre el modelo, digamos que su máxima es que la calidad de un producto depende directamente de la calidad de los procesos que se realizan para llevarlo a cabo. El problema de enfocar tanto la gestión a los procesos, es que almenos en la definición del modelo se está dejando de lado totalmente a las personas, y no nos da ningún tipo de guía al respecto.
Veremos ahora qué pasa con la auditoría. Tenemos hasta octubre para prepararla.
Saludos!
Miguel.
Permalink
04.27.07
Posted in Gestión del Mantenimiento, Metodologías, Programación at 5:45 pm by Miguel
De todos es sabido que los errores en el software son el pan nuestro de cada día. Alguna de las aplicaciones con las que nos toca trabajar dan más problemas que otras, y lo más normal es que si una aplicación se mantiene viva, con constantes actualizaciones y mejoras, los problemas vayan surgiendo a medida que se añaden nuevas funcionalidades. Por no hablar por supuesto de nuevas aplicaciones, recien salidas del horno, en las que tras una arquitectura moderna y robusta, puede esconderse una falta de testeo de algunos módulos o funcionalidades, o simplemente algunos descuidos de programación que aún no ha degenerado en error ya que para explotar necesitan verse inmersas bajo una serie de condicionantes que en entornos de desarrollo es difícil simular.
Y estoy hablando de errores, de errores de programación, típicos mensajes de alerta, con nuesto querido símbolo de admiración, o su triangulito… no de errores provenientes de una mala toma de requerimientos (modulos que no fallan pero no hacen lo que se supone que tenían que hacer). Petadas, reventadas, bugs… ya sabéis de lo que hablo.
Sobre prevención de errores hablaremos otro día, pero… ¿cómo resolvemos los errores de software una vez se han producido?
Si tenemos suerte y nuestro Proyecto cuenta con un Plan de Riesgos en el cual se ha contemplado el riesgo de errores en el software y se ha documentado cuales son los pasos que debemos seguir en caso de que se produzca un error… tendremos bastante ganado. Vamos a suponer que no es así, para hacer el “más difícil todavía”.
La posibilidad de resolver un error comienza cuando este se produce (obvio), lo que no es tan obvio es que debemos disponer de medios para detectar el error lo antes posible, cosa de la que a veces nos olvidamos. “Bueno, si falla ya llamarán”. “No ha llamado nadie en toda la mañana, eso es que va bien”. ¿Por qué debemos esperar a la llamada de un usuario para ponernos en marcha? ¿No sería mucho mejor que una vez se ha producido un error, la propia aplicación sea capaz de enviarnos una alarma al equipo de trabajo, y así poder ponernos a investigar prácticamente en el acto? Que bonito sería que antes de que llamara el usuario llamarle tú. Hola buenas tardes señor Fulanito, hemos observado que ha surgido un error en la Aplicación durante el proceso de blablabla, le informamos que tenemos el error controlado, que no ha afectado a la transacción que estaba llevando a cabo, y que tenemos ya a una persona resolviendo la incidencia. O… que te llamara el usuario… Ah si, buenas tardes sr Menganito, somos conocedores del error que se le ha producido en la aplicación, se ha realizado un análisis del mismo, y visto que su nivel de importancia es medio, y no produce ningún bloqueo en la aplicación, hemos postpuesto la publicación del parche a la primera hora de mañana, para así juntarlo con otras mejoras que teníamos pendientes.
Qué diferencia eh. Y no es tan difícil conseguir que una aplicación mande un SMS o un E-Mail cuando se ha producido una excepción en la aplicación.
Y para finalizar unas cuantas frases.
“Los errores de software desprestigian a la empresa, desprestigian al producto, desprestigian al grupo de trabajo y desprestigian al programador. Además, cabrean.”
“La confianza del usuario en un producto es inversamente proporcional al número de errores generados por la aplicación, multiplicado por la importancia de los mismos (y añadiría también por aquí algo sobre la media de la distancia de tiempo entre errores)”.
“Esta claro que no se puede tratar igual la gestión de errores de sistemas críticos como el de una central nuclear o un cohete espacial, pero eso no quiere decir que nos tengamos que olvidar de la gestión de errores de un simple editor de texto. Siempre que lo queramos vender, claro.”
Seguimos en la siguiente parte.
Saludos.
Miguel.
Permalink