Planificamos bien los tiempos, los documentamos, probamos los procesos y las cargas de datos ante todas las situaciones y contingencias que se nos ocurrieron, pero a pesar de ello, aparecieron situaciones no controladas que tuvimos que ir resolviendo sobre la marcha.

Uno de los problemas fundamentales, la diferencia de entorno, probamos sobre desarrollo, probamos sobre integración, pero no es posible realizar un ensayo general previo sobre producción, y muchas veces, casi todas, las condiciones de dicho entorno cambian, algunas desde el punto de vista de software (eso no debería variar) y otras desde el punto de vista de hardware y comunicaciones (siempre).

Por otro lado, el conjunto de datos, podemos intentar obtenerlos antes del despliegue del entorno de producción y realizar una prueba general sobre ese conjunto de datos en otro entorno, pero normalmente esta combinación no está disponible, ya que el cliente, como es normal, no acepta que sus datos de producción salgan del entorno productivo.

Más situaciones, la participación de terceros, cuando trabajamos con entornos sobre los que no tenemos acceso, terceras personas realizan los pasos del despliegue a partir de la documentación generada por el equipo de proyecto. En Estos casos el error humano se abre camino, tanto en la redacción del documento, en la interpretación por el operador, etc.

Y para mí otra de las más importantes, cada despliegue es nuevo, realizando procesos normalmente diferentes, no estamos replicando procesos iguales de forma repetida en el tiempo; no estamos haciendo edificios uno igual que otro una y otra vez, estamos jugando en cada ocasión con N variables que pueden afectar al proceso.

En fin, este trabajo es así.

Un saludo.

Miguel.

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.

Proyectos que incluyen todo: análisis funcional, diseño técnico, construcción, implantación, coste de licencias de software de los productos implicados (seguramente incluso no tan solo la plataforma software si no también la hardware), etc.

Y sobre los que no se sabe nada o casi nada (cinco páginas de requerimientos a altísimo nivel no es saber).

¿Por qué se siguen aceptando estos modelos de trabajo?

Todos pierden:

* Proveedor: aún analizando riesgos, márgenes, alcances, etc; la probabilidad de error en proyectos de tamaño medio/alto es altísima… y más teniendo en cuenta lo apretado del mercado actual, la gran dificultad de gestionar alcances con semejante nivel de definición y la complejidad y competencia en las tarifas actuales.

* Cliente: cree saber lo que quiere y lo que necesita, pero aún nadie le ha ayudado a aterrizar ni su propio funcionamiento ni las prioridades que tiene cada uno de los conceptos en su negocio; las consecuencias son avances en falso, rework en forma de cientos de gestiones de cambio posteriores, expectativas incumplidas, etc.

¿Por qué no empezamos por el principio?

El éxito de un proyecto de software se consigue cuando lo construido corresponde al requerimiento y el requerimiento corresponde con lo que se necesitaba. Focalicemos el esfuerzo en este primer gran bloque (vendamos únicamente esta parte) y luego ya estimaremos/valoraremos el siguiente conjunto de fases disponiendo como artefacto de entrada de un documento que realmente ha sido analizado de forma concienzuda: de entre la paja se ha localizado lo verdaderamente importante, se ha priorizado y se ha detallado.

Para aquel módulo que se solicitó una complejidad altísima seguramente nunca se llegarán a emplear ni la mitad de la funcionalidad; mientras para aquel conjunto de detalles (requerimientos funcionales y técnicos) a los que nadie dio importancia, serán los fundamentales finalmente para que el proyecto salga adelante. Tristemente casi siempre es así.

Un saludo.

Miguel.

http://www.adobe.com/products/livecycle/

Un saludo.

Mañana día 7 de marzo participo en las Jornadas NEOcom en el Centro Politécnico Superior de Zaragoza.

De 17 a 18h vamos a estar hablando de conceptos asociados Aplicaciones Distribuidas sobre Arquitecturas N-Capas y SOA; valorando entre otras cosas qué son, qué aportan y cómo las empresas pueden utilizar estas tecnologías en su beneficio.

NEOcom 2011

Un saludo.

Miguel.

Mucho ánimo a todos.

Un saludo.

—

1.2.3 View 3: Internal vs. External Quality

External Quality is the fitness for purpose of the software, i.e. does the software what it is supposed to
do?. The typical way to measure external quality is through functional tests and bugs measurement.
Some of the properties that determine the external quality of software are:

• Conformance to the product specifications and user expectations.

• Reliability: Is the software working with the same level performance under different conditions
and during all the time.

• Accuracy: Does the software do exactly what is supposed to do.

• Ease of use and comfort: Is the software easy to use and responds in an amount time according
to user expectations?

• Robustness: Does the software adapt to unforeseen situations, e.g. invalid input parameters,
connectivity lost…

• Openness: Can the software be extended/adapted for future use cases.

Internal Quality is everything the software does not do. It’s the implementation, which the customer
never directly sees, and often does not want to spend time or money on. Ironically enough, it’s often
what determines whether projects succeed or not.

Internal quality is related with the design of the software and it is purely in the interest of development.

If Internal quality starts falling, the system will be less amenable to change in the future. Due to that,
code reviews, refactoring and testing are essential as otherwise the internal quality will slip. An
interesting analogy with debts and bad code design was developed by Ward [REF3].

Some of the properties that enable the process of product with good internal quality are:

• Concision: The code does not suffer from duplication.

• Cohesion: Each [module|class|routine] serves a particular purpose (e.g. it does one thing) and
does it well

• Low coupling: Minimal inter-dependencies and interrelation between objects and modules.

• Simplicity: The software is always designed in the simplest possible manner so that errors are
less likely to be introduced.

• Generality: Specific solutions are only used if they are really needed.

• Clarity: the code enjoys a good autodocumentation level so that it is easy to be maintained.

The external quality is sometimes compared with “Doing the right things” as opposed to “Doing the
things right” which should define what internal quality is.

External quality is checked through validation (usually through functional tests) while Internal quality is
checked through verification.

Lanzad el traductor de google a través de este link

Pepito de Lomo pronunciado en Inglés-Googleliano

Y pulsad el botoncito de reproducir el sonido en la parte “inglesa”.

Me parto.

Un saludo.

Miguel.

Estos señores también tienen uno de estos

Google Chart

Gracias por la referencia Jóse.

Un saludo.

Miguel.

Microsoft Chart Controls se presenta como una opción gratuita disponible en aplicaciones web y escritorio, para cubrir esta demanda; el paquete MS-Chart fue incluido en el Framework desde la v3.5 SP1.

Especificaciones

Descarga

Un saludo.

Miguel.