Os dejo un enlace a un pdf que me ha llamado mucho la atención, se trata
de un caso práctico llevado a cabo en un entorno universitario, donde varios grupos debe realizar la gestión de un proyecto a partir de un conjunto de requerimientos iniciales.
Las conclusiones lo mejor, no descubren nada nuevo, pero es cuanto menos curioso, ya que a lo que respecta al alcance y a los requerimientos hace mucho hincapié en la necesidad de disponer del total conocimiento al inicio, cuando, desgraciadamente es algo que no ocurre nunca.
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.
Hace unos días se incorporó un artículo muy similar que hablaba de problemas de autorización de recursos al utilizar AjaxControlToolkit.
Hoy solventamos un problema muy similar, cuando estamos utilizando el control de ASP.NET Report Viewer en una aplicación que utiliza la seguridad de ASP.NET
En este caso el location que deberéis añadir es el siguiente:
Os dejo un link donde se muestra un pequeño manual donde se describen las principales funcionalidades incluidas en los proyectos de pruebas unitarias incluidos en Visual Studio 2008.
En el artículo se describen los siguientes puntos:
Paso a describir uno de los típicos problemas que suele aparecer a las personas que desarrollan normalmente aplicaciones de escritorio y que entrar a participar en un proyecto en el que se requiere desarrollos web.
En escritorio, es algo muy común el utilizar propiedades estáticas (shared en VB.NET, static en C# y Java) para almacenar información que la aplicación necesita desde que arranca hasta que se cierra, o en algún formulario específico donde se esté trabajando de manera desconectada de la base de datos. Por ejemplo, la información del usuario activo, o el listado de facturas que se están presentando en un formulario en concreto. En este ámbito el uso de propiedades estáticas funciona a las mil maravillas ya que la aplicación se ejecuta en el contexto del usuario y hay un único usuario accediendo a la posición de memoria reservada por la propiedad estática.
El problema viene cuando intentamos hacer lo mismo en web, por ejemplo en la capa de presentación web, donde tenemos una página (aspx, php, jsp, jsf…) que muestra las facturas relacionadas a un determinado cliente, facturas que además, tras cada transacción que realizamos contra el formulario, van modificando su información. Si en este ámbito utilizamos una propiedad estática para almacenar las facturas, de igual manera que con la aplicación de escritorio, estamos compartiendo una única instancia de la lista, pero esta vez con una pequeña diferencia, aunque tengamos 1 o 100 usuarios accediendo al formulario, todos están trabajando contra la misma aplicación, por lo que todos están trabajando con la misma lista de facturas. La consecuencia de esto es obvia, ante las modificaciones que realicen cualquiera de los usuarios sobre la lista (al ser la misma para todos), afectará al trabajo del resto de usuarios.
¿Soluciones? Para la web existen otro tipo de soluciones dependiendo del tipo de información a almacenar y del rendimiento que queráis obtener: Sesión, Caché, Viewstate (para aplicaciones ASP.NET), campos Hidden (vale, vale, se está liando mucho la cosa, pero funcionar funciona, aunque le tengas que meter muchas horas), y, por supuesto, guardando en base de datos, que viene siento lo habitual y más recomendable en la mayoría de los casos.
Cualquier duda sobre algún problema en particular, dejad vuestro caso en los comentarios e intentaremos encontrar la solución más eficiente para vuestro contexto. Por favor, indicad problema y requerimientos de sistema.
Este patrón de diseño sobrepasa lo técnico, incluso lo funcional, quedándose en el ámbito representado por una persona con conocimiento funcional, que en su día tuvo algún conocimiento técnico y que ahora mismo se dedica a la acción comercial.
También lo aplican otros perfiles, muchos veces en el ámbito de la consultoría, que para preparar sus documentos funcionales y las estimaciones no tienen en cuenta u obvian los conocimientos técnicos necesarios para hacer valoraciones realistas.
Es muy sencillo de aplicar, ante cualquier problema, el sujeto aplicará el patrón de formas similares a esta:
Requerimiento funcional 1
Una vez la información asociada al cálculo infinitesimal necesario para calcular una parábola alrededor del universo conocido haya sido introducida en el modelo de datos de la aplicación actual, podrá ser exportada en el formato xml definido por la corporación e integrado en el módulo de sap activo.
Aplicación del Patrón
No hay problema, será tan sencillo como seleccionar el cálculo, botón derecho, y hacer click en “migrar”, estará listo en dos jornadas.
Requerimiento Funcional 2
El diagrama almacenado en un archivo de imagen jpg, y que muestra la información de un gráfico de barras que representa los beneficios de los anteriores 10 años de actividad de la empresa, será transformado y la información mostrada en imagen pasará a formar parte del modelo de datos de la nueva aplicación de la empresa.
Aplicación del Patrón
No hay problema, seguro que extraer la información del jpg es muy sencillo, será tan sencillo como seleccionar el fichero de la imagen, pulsar botón derecho y hacer click en “transformar imagen”.
Ánimo a todos los que disfrutais construyendo cosas!