Una multitud de herramientas a las que se enfrentan ya con soltura desarrolladores web (especialmente sobre plataforma Microsoft) y para las que nadie cae ya en la dificultad inicial y conceptual que representa la pregunta: ¿dónde se ejecutan las cosas?

Pregunta que sin lugar a dudas es fundamental resolver al inicio, para formaciones orientadas a nuevos profesionales del desarrollo web, especialmente para aclarar muchos conceptos derivados del funcionamiento de ASP.NET, y su transformación/creación al vuelo de HTML, CSS y Javascript… por no hablar de temas específicos de comunicación cliente-servidor y mantenimiento del estado de la página mediante uso del ViewState, Session, etc.

Un concepto tan básico para desarrolladores ya iniciados, como que cuando entramos en una web esta no se visualiza en el “limbo”, si no que es descargada una copia en local (seguramente después de un procesado de página en el servidor web) y que lo único que hace el navegador es abrir dicha copia en local y renderizarla, no es algo que tengan tan claro los recién iniciados en este mundillo. Hay que saber contarlo y empezar por ahí, ya que con esto comenzaremos a asentar conocimientos básicos de arquitectura, del mismo modo que empezaremos a dar margen a pensar en la usabilidad y tiempos de respuesta de la página al usuario (no es lo mismo ejecutar arriba que ejecutar abajo, ni resolver problemas mediante una llamada a servidor o mediante n, ni de forma síncrona o asíncrona).

Este punto debería ser pieza clave, a la hora de comenzar el: Capítulo IV. Replicando en Web. El cual describíamos en el artículo Metodología de Formación para Nuevos Profesionales del Software

Saludos.

Miguel.

Puntualizar que la experiencia ha sido siempre lanzada utilizando como base tecnología Microsoft.NET, la cual dispone de herramientas que dan cobertura completa a los conceptos de arquitectura a trasladar, pero esto no quiere decir que este método no pueda ser aplicado utilizando otras tecnologías de cobertura completa (Java por ejemplo) o incluso en combinación de varias (bajo mi punto de vista sería el objetivo a cumplir tras la primera fase del “curso” que hoy os vamos a trasladar).

Objetivos

En el momento de finalizar el curso el alumno debe haber asentado su conocimiento sobre los siguientes conceptos

1) Entorno de desarrollo tipo
2) Desarrollo de arquitecturas orientadas a n-capas
3) Desarrollo de aplicaciones SOA
4) Buenas y malas prácticas de programación
5) Diferencias fundamentales en el desarrollo de aplicaciones web y escritorio
6) Trabajo colaborativo y en equipo
7) Importancia de las pruebas en el proceso de desarrollo
Despliegue de aplicaciones en entornos no accesibles
9) Dinámica de proyecto

Mientras que los objetivos del instructor son

1) Adaptar la formación a un escenario tipo de proyecto, el alumno desde el primer día debe entrar en la dinámica del día a día de un proyecto real
2) Identificar áreas de mejora de los alumnos, tanto técnicas como no técnicas
3) Identificar puntos fuertes y puntos de mejora del alumno
4) Identificar puntos de mejora del propio método de formación

Requerimientos Previos

Referidos a los alumnos (en orden de importancia):

1) Programación orientada a objetos
2) Definición de modelos entidad-relación
3) HTML básico

La falta de conocimiento de alguno de estos puntos, requerirá que el instructor incorpore a la formación módulos adicionales que cubran la visión necesaria al respecto.

Otros valores deseables ajenos a las capacidades técnicas

1) Pro actividad
2) Eficacia
3) Eficiencia
4) Trabajo en equipo
5) Liderazgo
6) Confianza
7) Capacidad de trabajo
Nivel de interlocución

Es labor del instructor identificar puntos de mejora también en estos aspectos, potenciándolos durante el proceso formativo. No solo estamos formando a nivel técnico, también estamos formando profesionales que van a ser parte fundamental de proyectos de desarrollo que requerirán de aptitudes no solo técnicas para lograr el éxito del proyecto.

Referidos al instructor:

1) Profesional consolidado en conocimientos de arquitectura y en la tecnología/tecnologías de desarrollo que se desarrollan en el curso.
2) Experiencia de trabajo en proyectos, habiendo participado/liderado procesos de captura de requerimientos, definición de arquitecturas y procesos de implantación/despliegue, gestión de equipos, diseños funcionales, diseños técnicos, supervisión del trabajo de otros programadores y construcción.
3) Nivel de interlocución medio-alto
4) Experiencia en sesiones formativas

En resumen y por poner un símil en consultoría, las habilidades esperadas de un Jefe de Equipo.

Bases Fundamentales de la Metodología

* Dinámica de proyecto desde el primer día
* Curso eminentemente práctico
* Grupos de formación pequeños (entre 5 y 10 alumnos máximo por instructor)
* No solo centrarse en las habilidades técnicas
* Que el alumno de el primer paso: resolver el problema de forma completa con el conocimiento actual del alumno, a medida que se vayan incorporando conceptos nuevos (a posteriori) el alumno deberá resolver de forma completa el problema adaptando su solución e incorporando los nuevos conceptos adquiridos.
* El instructor no es el protagonista

Capítulo I: Definiendo requerimientos

Todo proyecto comienza a partir de un conjunto de requerimientos, por lo que si uno de nuestros principales objetivos es introducir al alumno en la dinámica del proyecto deberemos partir de un conjunto de requerimientos base. No es objetivo de esta formación introducir al alumno en el proceso de toma de requerimientos, por lo que nos mantendremos ajenos a él. Nuestro punto de partida puede ser un pequeño documento que describa un pequeño escenario o si queremos empezar desde ya a identificar capacidades no técnicas, un pequeña conversación (poniéndose el instructor la gorra del cliente) donde se describan los requerimientos a cubrir; es aquí donde el alumno debe comenzar a tomar notas y hacerse un pequeño esquema mental de la solución. No es una toma de requerimientos en sí, ya que lo que hará el instructor será recitar verbalmente los requerimientos como si los estuviera leyendo.

Dependiendo de a dónde queramos llegar elegiremos uno de los dos métodos, eso sí, es fundamental que sea cual sea el formato seleccionado, se abra un espacio para dudas y preguntas por parte del alumno. Es así como comenzaremos a matizar el alcance, reglas de negocio, otros requerimientos, etc; además de comenzar a identificar habilidades no técnicas del alumno.

¿Y qué vamos a construir? Bajo mi punto de vista deberíamos definir una herramienta que motive al alumno, pero cuyo funcionamiento a bajo nivel resulte algo ajeno. Es decir, evitaría temas muy comunes como el desarrollo de una aplicación de gestión para bibliotecas o temas muy complejos como el desarrollo de una herramienta de gestión de cálculo de declaraciones de renta. Como un ejemplo no muy complejo tendríamos una herramienta tipo Facebook o Google+.

Capítulo II: Plazos e hitos

La propia definición de proyecto lo lleva de serie, los plazos. No hay proyecto sin un plazo de ejecución límite, por lo que el alumno debe desde el primer día ser consciente de esta realidad, trasladándole la tensión (que no presión) necesaria para mantener su motivación y dedicación al proyecto.

Este es el momento de trasladar al alumno cuál es la planificación de su primer proyecto (la planificación del curso), con cada uno de sus hitos intermedios y su hito final. Tanto el instructor como el alumno son los responsables de que dicha planificación se cumpla (no solo el instructor), cumpliendo adicionalmente todos los objetivos establecidos para el curso.

Para cada tarea el instructor establecerá tiempos límite. El objetivo es que el alumno empiece a jugar con el tiempo, a saber cuándo puede dilatarlo y cuándo puede (normalmente más que puede debe) contraerlo. No podemos irnos por las ramas, atascarnos de forma permanente; si no podemos tomar un camino, busquemos otra alternativa. La calidad de los resultados tiene relación también con el tiempo, hay que saber jugar con estos conceptos.

Capítulo III: Desarrollo de aplicación de escritorio

Fase 1 – Familiarizarse con el entorno y la tecnología

Como comentábamos al inicio, las formaciones de este tipo siempre han venido de la mano de tecnología Microsoft .NET, por lo que el hilo argumental se basará en la experiencia con dicha tecnología. Es en este punto donde cada instructor deberá adaptar los conceptos y herramientas a la tecnología seleccionada.

En nuestro caso entonces, nuestro entorno de desarrollo podría ser Visual Studio 2010 y nuestro framework el .NET Framework 4.0 (adaptar también dependiendo de los objetivos a lograr).

En esta primera fase, el instructor trasladará al alumno el funcionamiento básico del entorno de desarrollo:

* Tipos de proyecto
* Menús
* Teclas de acceso rápido

y de la tecnología

* Framework .NET 4.0 (en nuestro caso de partida)
* Orientación a eventos

Fase 2 – Solucionar el problema con lo puesto, premisa: todo va en memoria

Manos a la obra, el alumno ya dispone de una versión mínima de funcionamiento del entorno y del framework y conoce los requerimientos a cubrir. El primer objetivo a proponer al alumno es el de construir un aplicativo de escritorio que cubra los requerimientos demandados por el cliente, obviando una de las partes fundamentales de una herramienta de gestión, como es el almacenamiento de la información en un modelo de persistencia no volátil (una base de datos o un conjunto de ficheros).

En este punto el instructor únicamente marca las siguientes premisas:

1) El alumno deberá describir en un pequeño documento las principales entidades implicadas y sus relaciones (no estamos hablando de un modelo relacional formal, simplemente queremos ver que el alumno ha entendido el requerimiento y se ha construido un mapa mental con la información a gestionar y las relaciones que existen entre ella).

2) Antes de iniciar la codificación, el alumno deberá diseñar en primer lugar las interfaces de usuario a partir del entorno visual (WYSWYG) que provee el propio Visual Studio. Interfaces sin comportamiento únicamente descripción de las pantallas.

3) Límite temporal para realizar estas actividades.

Adicionalmente, el instructor puede esperar a ver con qué herramientas soluciona el problema del almacenamiento en memoria el alumno o trasladar una pista inicial que es el uso de listas genéricas, que es donde el instructor pretende que el alumno llegue. Una u otra opción dependerá del plazo temporal que estipulemos para esta primera fase.

El objetivo de esta primera fase se considera alcanzado cuando el alumno ha sido capaz de construir un aplicativo libre de errores con las nociones básicas de programación en objetos de las que cuenta, las nociones de entorno, de framework y la formación en el uso de listas genéricas. Nuestro aplicativo es un aplicativo que cubre el requerimiento sobre una aplicación de escritorio, pero con el pequeño gran defecto de que al cerrar el aplicativo toda la información almacenada en memoria se pierde.

Fase 3 – Primeras Pruebas

En este punto el alumno cuenta con una aplicación que cubre los requerimientos descritos por el cliente (o que debería cumplirlos) y que está preparado para su uso masivo por parte del mismo (esperamos).

Es este el momento para trasladar la importancia del proceso de pruebas. Lo más normal es que el instructor en menos de 5 minutos haya conseguido explotar tanto vulnerabilidades del sistema (objetos no referenciados, validaciones que fallan, problemas de seguridad de acceso, navegaciones ineficientes, etc) y requerimientos que no se cumplen parcial o totalmente. Se debe estudiar cada una de las aplicaciones y trasladar de forma global a los alumnos cuáles han sido los problemas que se han detectado. Es fundamental que el instructor traslade al alumno la importancia del proceso de pruebas y verificación; se la ha de poner en la piel del cliente. El alumno debe afianzar la visión del cliente y quedarse con la máxima “me da igual cómo esté hecho por dentro, lo que te haya costado hacerlo y lo que cueste mantenerlo (esto último no debería darle igual pero ya hablaremos de ese tema otro día), necesito que funcione y solucione mi problema fácil y rápidamente”. La definición técnica y de arquitectura es básica para el éxito del aplicativo y su posterior mantenimiento, pero debemos transmitir a fondo en esta fase que ésta no es la prioridad principal del cliente, por lo que el desarrollador debe darle tanta importancia a los factores técnicos como a los factores de “cliente”. Como ya muchos de vosotros sabréis, los éxitos técnicos son estupendos y maravillosos (seguramente os hayan acusado de románticos más de una vez), pero no son suficientes si el aplicativo no hace lo que tiene que hacer o falla intentándolo; si el aplicativo no es usado, no hay éxito.

Resumiendo, no es objetivo de esta fase validar técnicamente el aplicativo, únicamente el instructor se debe poner la gorra del cliente y revisar el aplicativo a nivel de uso, siendo muy exigente con el resultado obtenido. Es buen momento para trasladar ciertas nociones de usabilidad al alumno y de establecer los mecanismos básicos de herramientas para llevar a cabo pruebas unitarias y funcionales.

Fase 4 – Trasladando buenas prácticas

El punto de entrada de esta fase es una aplicación que representa lo que el requerimiento dictamina, de forma usable y con una tasa de errores no significativa.

Es ahora el momento en el que el instructor deberá analizar cada uno de los aplicativos desarrollados por los alumnos de forma interna, evaluando cuáles son los principales problemas detectados. El nivel de conocimiento previo del alumno es el que va a marcar el camino a seguir a partir de ahora. Resalto a continuación los principales temas identificados como puntos de mejora en desarrolladores con experiencia media-baja.

* No aplicación de patrones de diseño y otras herramientas provistas por la programación orientada a objetos
* No se encapsula
* No se orienta el código a su mantenibilidad
* No se emplean estándares de codificación
* No se comentan los métodos, ni los parámetros, ni los fragmentos de código más complejos
* No se aplican las listas genéricas (si no lo hemos trasladado en una fase anterior)
* No se usan constantes
* Se hardcodean parámetros configurables a partir de ficheros externos
* No se emplean excepciones
* No hay separación entre capas

El alumno tendrá que refactorizar su código atendiendo a todas estas clausulas, logrando disponer nuevamente de una herramienta que cubra los mismos requerimientos y que pase el proceso de pruebas nuevamente. Lo interesante sería que estos conceptos se vayan dando de uno en uno, para que el alumno los vaya asentando individualmente.

Fase 5 – Concepto de capa de acceso a datos

Uno de los problemas que seguramente haya surgido en la primera fase es que no haya separación entre capas, es decir, que el alumno haya construido un aplicativo en el que desde el propio interfaz se esté aplicando la lógica de negocio y accediendo a nuestro repositorio de datos (que por ahora tenemos en memoria).

En este punto es donde vamos a tener que proponer una refactorización importante de código, ya que todo lo que tenga que ver con acceso a datos el alumno deberá moverlo a un conjunto de clases independientes agrupadas por entidades de datos. La interfaz debe dejar de saber dónde estamos almacenando el dato, pudiendo en un momento dado cambiar el modelo de almacenamiento (de memoria a una base de datos física) sin necesidad de modificar una sola línea de código en la capa de presentación. En este punto es interesante trasladar el funcionamiento de patrones como DAO y DTO.

Nuevamente tras el desarrollo, el alumno deberá garantizar que la aplicación cubre los requerimientos y pasa el plan de pruebas, así como que ante un cambio de modelo de persistencia, la capa de presentación no va a sufrir ningún tipo de cambio.

Fase 6 – Definiendo un modelo relacional

El alumno ya debería estar en disposición en este punto de modelar relacionalmente la solución. Para ello, se le provee en este caso de un acceso a una instancia de SQL Server 2008, donde va a poder definir el modelo relacional. Es en este punto donde el instructor deja definir al alumno el modelo sin aplicar ningún tipo de premisa, con el objetivo de identificar necesidades formativas al respecto.

El instructor debería reforzar los siguientes conceptos

* Uso de claves primarias y foráneas
* Uso de relaciones 1-N y 1-1, definición de modelos entidad-relación basados en 3FN
* Abuso de la 3FN y problemas de rendimiento asociados
* Estándar de nomenclatura para campos y tablas
* Introducir comentarios descriptivos en campos y tablas
* Importancia de los índices
* Concepto y programación de procedimientos almacenados (muchos recién licenciados salen de la carrera sin que nadie les haya contado que es un procedimiento almacenado y para qué sirve).

Fase 7 – Almacenando la información de forma persistente

Ya tenemos una capa de acceso a datos que realizamos en la fase 5 y un modelo de datos desarrollado en la fase 6; ahora nos queda preparar nuestra capa de acceso a datos para cambiar el modelo de persistencia y comenzar a persistir sobre nuestra base de datos SQL Server 2008.

En este punto el instructor deberá seleccionar la tecnología de acceso a datos que considere. En caso de orientar la formación a un proyecto específico o tecnología esto nos llevaría a trabajar en este punto con una tecnología de acceso a datos concreta. En casos en los cuales no tengamos clara la salida del alumno, y a nivel general, recomiendo partir de las clases básicas de acceso a datos que provee el framework (ADO.NET; JDBC para formaciones Java), que accedan a los procedimientos almacenados que el alumno ha creado sobre la propia base de datos.

Esta fase va a generar una refactorización exclusivamente sobre la capa de acceso a datos (si hemos hecho bien el resto), y nuestra aplicación, sin necesidad de tocar una sola línea en el interfaz, va a pasar de almacenar la información en memoria a almacenar la información en base de datos.

Como siempre, tras este cambio, la aplicación va a tener que seguir cumpliendo el requerimiento y pasando el plan de pruebas.

Tras este desarrollo, el alumno debería percibir la importancia del trabajo en capas, la abstracción que supone el uso de capas separadas, reforzando el uso de clases con una alta cohesión y bajo acoplamiento.

Fase 8 – Concepto de capa de lógica de negocio

Nuestro código dispone en este punto de una capa de presentación que no conoce de dónde proviene el dato que está manejando, pero que sí conoce la lógica del negocio. Es decir, si para nuestro negocio dar de alta un nuevo modelo de coche en nuestro software de gestión de flotas de vehículos supone, además de realizar una inserción en la tabla que almacena los modelos a través de nuestra nueva y reciente capa de acceso a datos, enviar 3 e-mails a 3 destinatarios diferentes, replicar un conjunto de datos asociado al modelo en otro contexto diferente al nuestro, generar un fichero de comunicación con otros sistemas, etc; en este punto todo este código seguramente estará ubicado en el propio evento “onClick” del botón dar de alta nuevo modelo de coche.

El objetivo de esta fase es que una vez finalizada, nuestro aplicativo cuente con una capa de negocio que encapsule todo este comportamiento. Nuestro botón “onClick” debería llamar a un único método llamado “DarDeAltaModeloCoche” que se encargara de realizar todas las acciones pertinentes (entre otras realizar la inserción del nuevo modelo de coche a través de la capa de acceso a datos). La capa de presentación no sabe dónde se almacena el coche, y qué significa para nuestro negocio el dar de alta un modelo de coche.

Nuevamente, el aplicativo deberá respetar los requerimientos y pasar el plan de pruebas.

Fase 9 – Otras capas: Caché, Validación

Incluimos a continuación nociones de uso de otras capas como Caché, Validación, etc. Es un bueno momento para trasladar al alumno teoría de algunos patrones como Singleton, Strategy, Factory, etc.

El aplicativo debería reflejar dichos ajustes.

Fase 10 – Librerías

Nuestro código, aunque separado perfectamente en diferentes capas, ha estado formando parte de la misma aplicación en todo momento. Es este el momento de incluir los conceptos de librería de clase, y dividir cada una de las capas en librerías diferenciadas por el proyecto inicial. Acceso a Datos, Negocio, Validación, Entidades de Negocio… son librerías diferenciadas que podrán ser actualizadas de forma independiente y reutilizadas.

Capítulo IV: Replicando en Web

Es precisamente en este punto donde vamos a comenzar a reutilizar el trabajo realizado en la última de las fases de desarrollo de aplicaciones de escritorio, ya que vamos a referenciar las librerías de negocio, acceso datos, caché, validación y otras capas que hayamos creado para la aplicación de escritorio. Todo el trabajo va a ser reutilizado a excepción de la capa de presentación que es la única que va a cambiar. El alumno deberá notar la potencia de haber desarrollado su anterior trabajo con esta orientación, limitándose a realizar una nueva interfaz.

En este punto el instructor debe trasladar conocimientos avanzados al respecto de

* HTML
* Javascript
* CSS
* ASP.NET

Una vez finalizado este capítulo, el alumno cuenta con dos aplicativos diferentes que realizan exactamente la misma función y sobre los que únicamente se diferencia la interfaz (ambos referencian a los mismos proyectos de tipo librería para realizar cálculos de negocio y almacenamiento de datos).

Capítulo V: Replicando en Dispositivos Móviles

Mismo trabajo en el punto de desarrollo de aplicaciones web, pero en este caso realizando desarrollo sobre proyecto de aplicación móvil.

Capítulo VI: Distribuyendo el negocio, concepto de servicio, arquitectura SOA, independencia del dispositivo

Nuestro aplicativo ha referenciado hasta ahora librerías locales. Ha llegado el momento de distribuir el conocimiento del negocio en un aplicativo distribuido: Windows Communication Foundation. Si todo ha ido bien, las tres capas de presentación diferenciadas con las que contamos en este momento (escritorio, web, móvil), únicamente deberán cambiar su referencia de las librerías locales a los servicios web publicados por el aplicativo WCF que también crearemos en este punto.

Hasta aquí la primera versión de este método, donde intento a alto nivel dar a entender el formato de formación que hasta ahora mejor resultado viene dando, permitiendo en un plazo de 3/4 semanas situar al alumno en una dinámica de proyecto lo más cercana a la realidad, habiendo repasado conceptos de arquitectura medios y avanzados que forman parte del día a día de los proyectos de software; todo ello en un ambiente divertido y de aprendizaje continuo.

Intentaré en próximos artículos bajar de nivel de abstracción alguno de los puntos, intentando dar algo más de detalle de cómo enfocarlos a más bajo nivel.

Un saludo.

Miguel.

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.

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.

Os dejo el link al artículo en su blog http://www.navegapolis.net/content/view/694/61/

Saludos.

Miguel.

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.

“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.

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.

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.

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.