Depurando, depurando y con el mazo dando…

image

Un día, un usuario me llama por el teléfono rojo, «oye Juan, resulta que estaba yo en tal formulario y de repente no se donde he pulsado y creo que se me ha borrado el texto en las observaciones….», incrédulo empiezo a pensar… ¿ lunes ?, este no sabe que ha pasado…. a saber que ha estado haciendo el fin de semana… por si acaso activo Defcon 1…

Después de un tiempo, me llama otro usuario y me dice: «Juan, resulta que estaba yo en tal formulario y de repente no se donde he pulsado y parece que se ha borrado el texto en las observaciones….», «Joder como me suena…. «, tendré que revisar el código… pasamos a Defcon 2….

Abro el formulario, empiezo a investigar, buscando las dichosas «observaciones», después de un tiempo nada, ninguna referencia…., lo dejo estar… ¿ será un virus o una rata que se ha comido un trozo de fibra?….

De nuevo otro día recibo la dichosa llamada. Decido activar todas las alarmas…. ¡¡¡¡señores!!!! estamos en !!!!!!!!!!!!!!!!! DEFCON 3 ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡

¿ Será un trigger que se activa por algún motivo ? Buscando en la base de datos nada, ni rastro…, continuo indagando y por fin veo en un menú una opción «Actualizar datos…», me pregunto ¿quien ha introducido esto aquí… ?, desde luego llama a un Store Procedure que actualiza las observaciones dejándolas en blanco, fue una opción que solicitaron años atrás cuando se traspasaron los datos de un sistema anterior, y claro seguía activa, muy cerca en el menú, de otra bastante utilizada, los usuarios a veces se equivocaban y pulsaban esta opción eliminando el texto, me digo: no la voy a eliminar, no vaya a ser que el usuario X la utilice algún día, introduciré un messagebox que le pregunte ¿ Si pulsa «si», las observaciones se irán al carajo…. ? y voila….

Al cabo de unos días me llama un usuario y me dice: «oye Juan, resulta que estaba yo en tal formulario y de repente, no se donde he pulsado, me ha salido un mensaje «no se que del carajo…», he dado enter, y resulta que me han desaparecido las observaciones. Pienso «arghghghghghghgh,  te vas a enterar….», entro al código, introduzco 10 messageBox mas, le añado una clave de encriptación basada en CuaimaCrypt y lo pongo en producción.

Después de cierto tiempo, me llama otro usuario y me dice: «oye Juan, resulta que estoy intentando borrar las observaciones con la utilidad que me hicistes y llevo pulsando no se cuantas veces al si para se vayan al carajo de una vez, después de media hora, me aparece una pantalla para que introduzca una clave de 200 dígitos alfanuméricos…, pero no me acuerdo del dígito 199, ¿era una z o una p?……. y nada, que no me deja eliminar las p%$tas…. observaciones estas…..». Con la soga al cuello y a punto de saltar por la ventana… decido utilizar el control usuarios, habilito la opción para el usuario que la utiliza, elimino los mensajes y la clave y deshabilito la opción para todos los demás, haciéndola invisible en el menú.

Este tipo de situaciones se dan a menudo en los procesos de depuración y desarrollo, a veces, cuando desarrollamos, nos centramos en realizar validaciones para evitar errores y no nos damos cuenta que es mucho mas fácil evitar el error eliminando la posibilidad de cometerlo. La utilización de una simple mascara evitara varias operaciones posteriores, validación, notificación al usuario de su error, limpiar el campo, situar de nuevo el foco en el control, etc.

Debemos centrarnos en evitar el error, no en controlarlo y sobre todo «utilizar el sentido común»….   desgraciadamente algunos carecemos de esto…

image

Por cierto…, deja de mirar a la chica y ponte a trabajar… que es lunes….

Maldivas Interfaces 1 – Sistemas de Búsqueda

Una de las funcionalidades mas importantes en la mayoría de los programas de gestión son las interfaces de búsqueda, un interface de búsqueda debe ser rápido y usarse con facilidad, de el depende en gran medida la versatilidad del programa. En Maldivas utilizamos varias formas diferentes de realizar búsquedas, el primero lo conocí en una Entidad Bancaria hace varios años y desde entonces siempre lo implemento en mis aplicaciones. La mayor parte de los interfaces de búsqueda que he visto, suelen partir de una lista de campos que permiten que el usuario seleccione uno de ellos, introduzca un valor y realice la búsqueda.

El sistema que presento aquí, es relativamente sencillo de implementar y aporta varias ventajas.

El primer paso cuando pulsamos sobre el botón de búsqueda, es situar el formulario en blanco. Quedaría mas o menos así:

image

Si el usuario introduce el valor en el campo identificativo, la búsqueda se realiza de forma automática, ya que este campo es único. En este caso, cuando introduzco el valor 23 en el código, el registro es buscado y mostrado de forma automática.

image

Cuando realizamos una búsqueda por otros campos podemos introducir información en varios de ellos, en el ejemplo siguiente introducimos varios valores. Utilizamos para activar el proceso dos teclas de función, F11 que realiza la búsqueda del primer registro coincidente y F12 que realiza la búsqueda de todos los registros que cumplan las condiciones determinadas por los valores introducidos. En este último caso, si el proceso encuentra un solo registro, este se muestra directamente en el formulario.

image

En este caso la búsqueda solo encuentra un registro que cumple las condiciones especificadas y lo muestra.

image

Si realizamos una búsqueda de las zonas que tengan el valor «Nacional» el sistema encuentra varios registros y los muestra en un formulario diferente.

image

En el, podemos seleccionar el registro que nos interese visualizar o realizar otras funciones como filtrar mas los resultados o imprimir el conjunto de registros seleccionados, para realizar este tipo de operaciones el sistema permite limitar los campos que se quieren imprimir, puesto que en un informe A4, seria difícil poder visualizar todos los campos, en el ejemplo limitaremos los campos al código, nombre y la zona_iva.

image

Después de esto, el formulario muestra las columnas seleccionadas.

image

A continuación podríamos exportarlos a PDF quedando el informe así:

image

Ventajas:

Este sistema permite realizar búsquedas complejas utilizando varios campos, con la ventaja de aprovechar posteriormente los resultados para realizar informes sencillos en varios formatos.

Al usuario le resulta muy cómodo de utilizar ya que habitualmente conoce la ubicación de los campos y no tiene que perder tiempo en buscarlos a través de una lista de campos.

Evitaremos tener que introducir los códigos que muchas veces desconocemos, en el siguiente ejemplo, vemos que será mas sencillo realizar la búsqueda a partir de la selección del valor de un combo que acordarnos del código de la forma de pago, en este caso «Compensación» que corresponde con el valor «0002», que es el utilizaríamos para realizar la búsqueda en otros sistemas.

image

 

¿ Como funciona ?

Si utilizamos una entidad, dataset o cualquier objeto enlazado al formulario debemos crear un nuevo objeto vacío y mostrarlo en el formulario. Una vez introducidos los datos el sistema, este debe comparar los valores del objeto con uno vacío para obtener aquellos campos y valores que han cambiado. Esta información conjuntamente a la información de los metadatos del objeto, permiten generar en tiempo de ejecución una sentencia Sql para realizar la búsqueda.

Si utilizáis un modelo basado en DataSet necesitareis la información de la clase para obtener los metadatos y el estado de las filas para realizar la comparación. Podéis encontrar mas información en:

http://msdn.microsoft.com/es-es/library/system.data.datarowstate(VS.80).aspx

Si vuestra intención es utilizar Entity FrameWork deberéis utilizar de los metadatos de la entidad y comparar los valores anteriores con los actuales. Podéis encontrar mas información en:

http://msdn.microsoft.com/en-us/library/system.data.objects.objectstateentry.aspx

En Maldivas utilizamos la técnica de reflexión para obtener la información de los metadatos y los valores de la clase para realizar la consulta. De esta forma podemos generar una sentencia sql en tiempo de ejecución en base a los campos que han cambiado similar a esta:

«SELECT * FROM Gestion.Interlocutores_zonas WHERE Nombre LIKE ‘%’ + @nombre+ ‘%’ AND Zona_iva LIKE ‘%’ + @zonaIva + ‘%’)»

Si os fijáis introducimos la cláusula like en los campos de tipo string, para buscar valores que se encuentren en cualquier parte del campo.

 

Busqueda Rápida

Otro de los sistemas de búsqueda que hemos incorporado es el que se observa en la barra de herramientas situada en la parte superior del formulario.

image

Este proceso nos permite realizar búsquedas de una forma mucho mas «rápida», en cuanto al trabajo por parte del usuario se refiere y funciona de la siguiente manera:

El usuario introduce cualquier valor, un número, una fecha, una cadena, etc, el sistema analiza los campos de la entidad que tienen el mismo tipo del valor buscado, en el caso por ejemplo de una fecha el sistema solo preguntara por aquellos campos que sean de tipo datetime, en este ejemplo vamos a introducir una cadena, «Interior«, vemos como el sistema realiza una búsqueda y obtiene un conjunto de registrosque tienen esta cadena en cualquiera de sus campos de tipo string.

image

La gran ventaja de este sistema es la facilidad de uso por parte del usuario, y la gran desventaja es que la velocidad de búsqueda es mas baja ya que la sentencia Sql que se genera tiene que evaluar todos los campos de tipos similares, para ver esto la consulta del ejemplo anterior seria algo como:

«SELECT * FROM Gestion.Interlocutores_zonas WHERE Codigo LIKE ‘%’ + @valor + ‘%’ OR Zona_iva LIKE ‘%’ + @valor + ‘%’ OR Zona_politica LIKE ‘%’ + @valor + ‘%’ OR Zona_tipo LIKE ‘%’ + @valor + ‘%’ OR Zona_cc LIKE ‘%’ + @valor + ‘%’ OR Nombre LIKE ‘%’ + @valor + ‘%’ )»

Por supuesto si la tabla tiene 100 campos, la sentencia que se puede generar es inmensa, aunque las pruebas que hemos realizados sobre tablas de unos 10000 registros con 200 campos se realiza en menos de tres segundos. Lógicamente esto dependerá de diferentes factores como Hardware del Servidor, Índices y otros factores.

Busqueda Sincronizada

Por último el sistema de búsqueda que nos proporciona el uso de los controles que utilizamos, de la marca Devexpress, en este caso el grid situado a la izquierda nos permite cambiar el orden y buscar sobre cualquier campo.

image

Al igual que en la cláusula like de Sql si eliminamos el símbolo % filtraría todos los registros que comiencen por el valor introducido

image

El control esta sincronizado con el formulario, de manera que si nos situamos en cualquiera de los registros del grid, el formulario muestra sus datos.

image

Otra de las ventajas de estos controles es que permiten visualizar y modificar las condiciones de filtrado en tiempo de ejecución:

image

Además de estas opciones de búsqueda, hemos implementado el sistema de desplazamiento de registros, ordenación y filtrado que permite al usuario trabajar con un conjunto de registros, hablare de ellos, en el próximo post sobre Interfaces.

Maldivas Arquitectura 2 – Entidades y Reflexión

Como he contestado en algún Post, Maldivas es un Framework que propone una solución concreta para un momento determinado, en que la tecnología de Microsoft solo permitía utilizar su modelo de datos basado casi exclusivamente en Dataset o tenias que utilizar frameworks de terceros como n-hibernate, nace de una necesidad en concreto para dar solución a un proyecto que comenzó al finales del año 2005, en ningún caso propongo este Framework para utilizar en otras aplicaciones. Este modelo está basado por completo en el Entity Relationship Model, que existe hace mas de 30 años y al que hemos dotado de funcionalidad adicional para minimizar el código requerido y dotarle de otras características.

Si tuviera que desarrollar de nuevo este proyecto, seguramente, utilizaría el Entity Framework, que se basa en un modelo de entidades similar al que presento aquí. En cualquier caso el proceso de reflexión se utiliza en gran parte del framework de .net y os puede servir para aplicarlo en algunos procesos de vuestros desarrollos, un ejemplo claro lo podéis ver cuando desarrolláis sobre Web Services en que la información de los contratos, serialización y otros se realiza en forma de atributos.

El primer proceso es el de representar en nuestro lenguaje, en este caso c#, las entidades correspondientes a cada una de las tablas, vistas, funciones y otros objetos de la base de datos con los que nos queramos interactuar, para que podamos trabajar con ellas desde nuestro lenguaje. En este caso cada clase que denominaremos «Entidad» es la representación de una tabla de nuestra base de datos. Partiremos de una entidad sencilla que almacena la información de una tabla de la base de datos, esta entidad compuesta de cuatro campos, está decorada con varios atributos que definen varios aspectos de la tabla a la que hace referencia. Es lo que habitualmente denominamos Metadatos. Como se observa en este ejemplo, la entidad es una clase en c# que representa una de las tablas de la base de datos.

using System;

using Maldivas.Entities.Attributes;

namespace Maldivas.Entities.Gestion

{

[Serializable]

[EntityStructure(DataBase = «Maldivas_oran», Schema = «Gestion», Name = «Articulos_embalajes_tipos», EntityType = «Table»)]

public class Articulos_embalajes_tipos : Entity, IEntities<Articulos_embalajes_tipos>

{

#region Fields enum

 public enum Fields

{

Codaux, Codigo, Descripcion, Observaciones,

}

#endregion

[EntityAttributes(FieldName = «Codaux», IdentityValue = 1, IdentityStep = 1, Lenght = 10, IsReadOnly = true)]

public int Codaux { get; set; }

[EntityAttributes(FieldName = «Codigo», PrimaryKey = 1, Lenght = 2)]

public string Codigo { get; set; }

[EntityAttributes(FieldName = «Descripcion», AllowNull = true, Lenght = 50)]

public string Descripcion { get; set; }

[EntityAttributes(FieldName = «Observaciones», AllowNull = true, Lenght = 8000)]

public string Observaciones { get; set; }

#region IEntities<Articulos_embalajes_tipos> Members

public virtual Articulos_embalajes_tipos Clone()

{

Articulos_embalajes_tipos articulos_embalajes_tipos = new Articulos_embalajes_tipos();

articulos_embalajes_tipos.Codaux = Codaux;

articulos_embalajes_tipos.Codigo = Codigo;

articulos_embalajes_tipos.Descripcion = Descripcion;

articulos_embalajes_tipos.Observaciones = Observaciones;

return articulos_embalajes_tipos;

}

 public virtual void Copy(Articulos_embalajes_tipos ent)

{

Codaux = ent.Codaux;

Codigo = ent.Codigo;

Descripcion = ent.Descripcion;

Observaciones = ent.Observaciones;

}

 #endregion

 public new static string ToString()

{

return «Articulos_embalajes_tipos»;

}

}

}

Existen dos tipos de atributos en la clase, el primero que decora la clase:

[EntityStructure(DataBase = «Maldivas_oran», Schema = «Gestion», Name = «Articulos_embalajes_tipos», EntityType = «Table»)]

Este atributo nos indica algunas propiedades de la base de datos como el Nombre de la base de datos el esquema, el nombre y el tipo de entidad» Tabla, Vista, Función, etc.

Y el segundo que decora cada columna de la tabla con un atributo similar a este:

[EntityAttributes(FieldName = «Codigo», PrimaryKey = 1, Lenght = 2)]

En el se indican las propiedades de cada columna, estas serán utilizadas a lo largo de toda la aplicación y nos permitirán obtener la información relativa a la configuración de cada campo en la tabla.

Hemos incluido dos métodos, el primero «Clone» nos permite realizar una copia de cualquier entidad en un nuevo objeto y el segundo «Copy», nos permite copiar la información de otra entidad en la actual, estos métodos son utilizados por diferentes secciones a lo largo del programa. Pensamos también incorporar el patrón Observer, pero al final lo descartamos ya que en principio, no nos iba a hacer falta.

Una de las primeras preguntas que nos hacemos es: ¿cómo podemos acceder a esta información que almacenamos en forma de atributos en una clase?, la respuesta seria utilizando reflexión. Reflexión es una tecnología que nos permitirá preguntar al ensamblado de una clase información acerca de esta, básicamente lo que hace es abrir el archivo del ensamblado y buscar la información del atributo con el que hemos decorado la clase. Para entender el proceso os voy a poner un ejemplo sencillo, uno que nos permita únicamente almacenar el nombre de la base de datos de una clase. El primer paso sería el de crear una clase que deriva de Attribute y nos permita almacenar la información que queramos. Para más información podeís ver en http://msdn.microsoft.com/es-es/library/z0w1kczw(VS.80).aspx

/// Creación del atributo

using System;

namespace Maldivas.Entities.Attributes

{

[Serializable, AttributeUsage(AttributeTargets.Class, AllowMultiple = false, Inherited = false)]

public sealed class EntityStructure : Attribute

{

/// <summary>

/// Permite configurar el nombre de la Base de datos

/// </summary>

/// <param name=»database»>Nombre de la Base de datos</param>

public EntityStructure(string databaseName)

{

DBName = databaseName;

}

/// <summary>

/// Propiedad que permite acceder y configurar al nombre de la tabla

/// </summary>

public string DBName { get; set; }

}

}

 

/// Creación de la clase que lo utiliza

[EntityStructure(«AdventureWorks»)]

public class Ejemplo

{

}

/// Creación de un metodo que nos permite leer el atributo de la clase

public class ReadDataBaseAttribute()

{

string DataBaseName = null;

Type type = typeof(Ejemplo);    

/// Aqui se realiza el proceso de reflexión

object[] oestructure = type.GetCustomAttributes(typeof(EntityStructure), false);

/// Comprueba que haya leido algún valor

if (oestructure != null && && oestructure.Length > 0)

{

EntityStructure es = oestructure[0] as EntityStructure;

if (es != null)

DataBaseName = es. DBName;

}

return DataBaseName;

}

De esta forma la variable DataBaseName obtendría su valor AdventureWorks.

Debido a que el proceso de reflexión tiene un alto coste, ya que hay que abrir el ensamblado y buscar la información, puede ser aconsejable cachear la información si la vamos a utilizar muchas veces, nosotros tenemos un proceso, en el que, cuando se solicita información de una entidad la primera vez, esta se almacena en cache, de esta forma minimizamos el coste del proceso.

Escribir una clase similar a la del primer ejemplo por cada una de las tablas que tengamos, puede ser un proceso muy costoso, para automatizar este proceso, desarrollamos un pequeño programa que automatiza la creación de los ficheros de entidades utilizando Codedom, del que intentare escribir un post en entradas posteriores, podéis ver un pequeño ejemplo aquí http://www.15seconds.com/issue/020917.htm , aunque existen otras formas de hacerlo, esta es la más adecuada, ya que nos permitirá generar código en diferentes lenguajes. El aspecto de nuestra herramienta es el siguiente:

De igual forma Entity Framework dispone de una herramienta para realizar este proceso de forma automática.

A petición de Eduardo Obregon, mi compañero de trabajo, que me preguntaba sobre cuánto es de costosa la reflexión y la ganancia que se obtiene cacheando datos, he adjuntado un archivo de test para realizar esta comprobación, en el equipo donde lo he probado, mis resultados son los siguientes. Para leer 10 millones de atributos de una entidad, el equivalente a 100000 tablas con unos 100 campos por tabla, el equipo ha tomado un tiempo aproximado de 40 segundos, cacheando se ha reducido a los 3 segundos, ya que el atributo solo ha sido leído una vez, en realidad el tiempo de cacheo será algo mayor ya que la inicialmente la lectura de los atributos a cachear siempre se tiene que realizar la primera vez. Despues del test creo que el cacheo no tiene mucho sentido. Cada uno que saque sus propias conclusiones.

Os dejo el fichero que contiene el ejemplo Test Atributos y Reflexión

 

¿Debemos cambiar la forma de vender Software?, continuación…

Acabo de recibir un comentario de Rafa en el post original, creo que es un resumen, en muchos aspectos, de lo que piensa la gran mayoría de la gente, por eso he decidió hablar un poco mas de este tema.

El post en concreto dice:

Hola Juan, es mi primer comentario en tu blog, pero no he podido resistirme al ver tu post y los comentarios.

He acudido a varios cursos de Rodrigo sobre administración de proyectos, metodologías agiles y demás. Con la experiencia que tengo en este mundo, ya van 11 años, mi opinión es que estas metodologías solo sirven para grandes o grandísimos proyectos en los que estén metidos asesores externos y personal técnico del cliente o para proyectos internos, es decir para los propios proyectos de empresas de software. ¿Por qué?, yo creo que primero el cliente no sabe lo que quiere, o mejor matizo, sabe perfectamente lo que quiere pero no sabe como plasmarlo en un desarrollo informático. El cliente solo paga cuando el trabajo está hecho, es muy bonito que el cliente vaya pagando según los módulos entregados, pero la verdad es que si el cliente no tiene todo, la típica frase es: «No tengo nada». La implicación del cliente o del máximo responsable de tu cliente la mayoría de las veces es escasa o más bien nula, y lo entiendo, esto es diferente a todo lo demás, yo si me compro un armario empotrado le digo lo que quiero al carpintero, pero no me va ensañando las baldas que va haciendo, si me compro un coche, pues no me voy a la fabrica, si me compro una casa, está en la mayoría de los casos es «estándar» como el software y cuando esta me la entregan no se adapta a mis necesidades (como dicen mis clientes con sus programas), pero lo único que puedo hacer es joderme y esto está asumido por la gente, no así en el caso del software. Realmente es un mundo y un tema para tesis doctoral, yo en este mega comentario no aporto nada, lo sé, pero es que no tengo ni idea de que aportar…. Esto sirve muchas veces de terapia, lo sé, los psicologos deben de tener sus consultas llenas de jefes de producto.

Hola Rafa, te agradezco tus comentarios, pero no comparto la mayoría de tus opiniones, en primer lugar te diré, que todos aportamos, de hecho y gracias a tu comentario me he animado a escribir otro post, tu opinión es tan válida como la de cualquier experto y además aprendemos los unos de los otros, ¿De eso se trata? no…. cada uno aporta en base a su experiencia y sus conocimientos, si lo compartes será enriquecedor para todos.

Sé que en el mercado en que nos movemos, muchos piensan que vender un proyecto de esta forma es como un «sueño», pero, depende de nosotros que podamos hacerlo realidad, si te fijas en otro tipo de proyectos, por ejemplo cuando un constructor realiza un edificio, o el gobierno encarga la realización de un tramo de autovía, los proyectos se comportan así por necesidad, es decir, se van realizando paulatinamente y las empresas van pagando según el trabajo que se va acometiendo, en estos casos la imposibilidad de hacer una obra de tal magnitud debido sobre todo al coste económico que supone, hace inviable que el coste se pueda asumir hasta el final, si en un momento dado la empresa no puede continuar el trabajo o el cliente no está satisfecho, siempre existirá otra que pueda terminarlo y el cliente habrá pagado por aquello que se ha realizado.

Lo que cuento en el post es sobre todo, parte de la experiencia que he tenido en mis proyectos, en ningún caso, lo que me han enseñado las metodologías, entiendo que las metodologías nacen para dar una «solución» a muchos de los problemas que se presentan en los proyectos como una necesidad para aquellos que buscan una solución para estos problemas, además han sido probadas con éxito en multitud de proyectos, si no, nadie las utilizaría, en este caso la metología que usamos se adapta perfectamente a esta problemática y surge precisamente para ofrecer una solución.

Desde luego no comparto en absoluto que este tipo de metologías estén pensadas solamente para proyectos grandes, la metología te asegura que realices el trabajo día a día, qué más da si el proyecto tiene una duración de 15 días o 5 años, al final hacemos lo mismo, solo que a la hora de estimarlo y venderlo nos resultara más sencillo.

Creo que los proyectos de desarrollo no son comparables a cuando encargamos un armario, en cualquier caso si te quieres asegurar de que el armario cumple tus expectativas, seguro que le echas un vistazo a las baldas.

El cliente es el que mejor conoce su problemática y por eso, para llevar a cabo cualquier proyecto debemos contar con él, tiene que formar parte indisoluble del equipo, creo que este es uno de los factores donde cometemos la mayoría de los errores, a veces creemos que nosotros sabemos más que él, otras que no sabe transmitirnos los que realmente quiere, en cualquier caso la culpa siempre se la echamos al «cliente». Yo creo que es nuestra obligación conocer en detalle toda la problemática del cliente, si esto no se cumple tenemos muy pocas posibilidades de que nuestro proyecto llegue a buen término. Los proyectos fracasan por diferentes motivos, a veces nos equivocamos al estimar el coste, otras el cliente no sabe muy bien lo que quiere y eso redunda de nuevo en el coste, en otros casos no entendemos lo que el cliente nos quiere transmitir, la mayor parte son causados por «una falta de comunicación». La solución que propongo pasa desde luego por convencer al cliente, si no somos capaces de convencer al cliente, tampoco seremos capaces de realizar un proyecto exitoso sin contar con su colaboración, entiendo que es complicado, sobre todo para empresas que no tienen claras las cosas o simplemente que han tenido experiencias negativas. En cualquier caso, somos nosotros quien marcamos las reglas, si de antemano sabemos que debemos acometer un proyecto y que no vamos a tener la colaboración del cliente, tenemos muchas posibilidades de fracasar, llegados a este punto quizás sea mejor no comenzarlo.

Creo que es importante reflexionar, en el sentido, de que somos nosotros los primeros que cometemos el error «No sabemos vender correctamente un proyecto ni marcar las reglas que regirán a lo largo del proceso». Inicialmente marcamos nuestras propias normas, la mayoría de las empresas suelen investigar al posible cliente para saber si es o no solvente, y exigir un pago antes de comenzar el proyecto. No conozco a ninguna empresa que comience un proyecto de desarrollo con un cliente desconocido, si antes no ha cobrado un porcentaje de su costo. Hacemos esto porque es una norma en la que creemos.

Somos nosotros los marcamos nuestras propias reglas, aunque para hacerlo hay que creer en que, lo que estamos haciendo es lo más adecuado. Dudamos de que esta sea la solución más adecuada, en algunos casos porque nunca lo hemos probado, otras veces porque no tenemos la suficiente disciplina para utilizar una metodología y la mayoría de las veces por que el «cambio» siempre suele significar mayor complejidad y solemos seleccionar el camino más fácil, «el que conocemos». Las implicaciones que tiene el poder realizar un proyecto con estas restricciones son importantes, debemos conocer la metodología y ser estrictos para llevarla a cabo, es el precio que debemos pagar, si queremos cambiar la forma de trabajar y sobre todo de realizar proyectos exitosos.

Sé que este puede ser el «sueño» de muchas empresas, y que existen muchos problemas para la realización de un proyecto tal y como lo expongo en el post, algunas nos vienen dadas por el departamento comercial o impuestas por empresas que llevan muchos años en el mercado. Pero si preguntamos a cualquier cliente, la realidad nos dice, que la mayoría no están satisfechos con sus proveedores, y esto es debido a que no hacemos las cosas bien.

Cuando vendemos un proyecto de software, algo completamente intangible, nuestras reglas conforman parte del producto en sí mismo. Si cambiamos estas en base, únicamente a las exigencias del cliente, estaríamos vendiendo un producto diferente en el cual no creemos. Si no estamos dispuestos a marcar nuestros límites no podremos tener éxito en nuestros proyectos.

Todos hemos oído frases similares a las siguientes, «es que el cliente no me atiende, ya verás cuando vayamos a implantarlo», «nadie sabe cómo funciona esto, no sé cómo solucionarlo.», «en el Dpto de contabilidad me dicen que haga esto, pero en el otro me dicen todo lo contrario….» Si no somos capaces a la hora de vender un desarrollo trasladar al cliente nuestra forma de trabajar y como hay que hacer para desarrollar un proyecto, difícilmente podremos llevarlo a cabo y esto es culpa nuestra, no de el cliente.

Si queremos mejorar, debemos cambiar nuestra forma de pensar y desde luego establecer nuestras propias reglas.

¿Debemos cambiar la forma de vender software?…

Uno de los problemas más graves en el desarrollo de aplicaciones, sobre todo en los desarrollos a largo plazo, se produce cuando se realiza la estimación, los factores que la rodean como los plazos, personas que conforman el equipo de trabajo, nivel de formación, necesidades y otros factores hacen que este sea uno de los procesos más complicados de realizar.

La mayoría de las veces, las empresas suelen fijarse en desarrollos similares para realizar una estimación, otras simplemente tiran un dado al aire, lo multiplican por un factor determinado para evitar pillarse las manos y se lo ofrecen al cliente.

Lógicamente, muchos proyectos realizados de esta forma no cumplen las expectativas o simplemente fracasan, en otros, los menos, el cliente ha pagado un sobreprecio por la solución. Cuando esto sucede se suelen producir daños colaterales, la empresa que, inicialmente ha estimado mal el proyecto, traslada la presión y la culpa al equipo de desarrollo que en muchos casos ni siquiera participa de las decisiones comerciales.

¿Cómo se puede estimar un proyecto, del que es prácticamente imposible conocer todas sus interioridades, porque un análisis a fondo nos llevaría casi más tiempo que el propio desarrollo, y del que desconocemos muchas de las implicaciones que tiene a lo largo del proceso de implantación?

A veces el cliente acostumbra a hacerse una idea equivocada, de una solución que desconoce, que en muchos casos ve por primera vez cuando se realiza el proceso de implantación, es decir cuando el proyecto está prácticamente terminado. Este, cuando ve la aplicación observa que hay algunas cosas que no le gustan y procede a cambiarlas, los cambios se producen una vez el desarrollo a finalizado y suelen provocar que gran parte del proyecto se tenga que volver a reconstruir, con el consiguiente coste, difícil de repercutir y que genera numerosos problemas dañando la relación empresa-cliente.

Pienso que una estimación a largo plazo es completamente imposible de realizar en base a un análisis exhaustivo, en cambio será mucho más sencillo estimar lo que vamos a realizar a corto plazo. Creo que se debe cambiar la forma de vender software, ya que estos errores se arrastran a lo largo de todo el proyecto.

La venta de software debería basarse en ideas como las que proponen las metodologías agiles. El cliente debe formar parte imprescindible del equipo de trabajo, del que recibiremos el feedback y nos ayudara a lo largo del proceso de desarrollo, la entrega paulatina de pequeños «módulos» completamente funcionales que conformaran la solución, permiten que el cliente pueda probar parte de su aplicación, observar el progreso que se va realizando y alterar o mejorar su funcionamiento a lo largo de todo el proceso de desarrollo, los pequeños cambios y propuestas de mejora se producirán de forma paulatina evitando rehacer gran parte de la aplicación. El cliente ira pagando de forma progresiva el trabajo realizado, contento, porque sabe que su aplicación va cumpliendo los objetivos acordados y que además está abierta a sufrir cualquier tipo de variación si es necesaria a lo largo del proceso de desarrollo.

Cambiar el hábito de vender una aplicación que normalmente puede sufrir muchos cambios, es algo muy difícil de comprender para las empresas y todavía más difícil para los clientes que quieren comprar un desarrollo de software, esto fundamentalmente se debe a las malas experiencias que han tenido y quieren a toda costa cerrar un presupuesto y obtener un compromiso serio por parte de la empresa.

Creo que el proceso para convencer un cliente, pasa simplemente por realizar las primeras entregas de software, cuando el cliente observa que se esta entregando parte de su aplicación, y que paga únicamente por aquello que ya tiene, las dudas desaparecen. Si el módulo desarrollado es lo suficientemente independiente puede comenzar a amortizar la inversión de manera inmediata y no esperar a que se encuentre finalizada completamente.

Las gestión de estas pequeñas entregas de software que se van realizando, conformaran una estimación final mucho más real que cualquier estudio pormenorizado, y nos dará una visión del progreso mucho más real, proporcionándonos además un dato muy importante, la velocidad real de nuestro equipo de desarrollo, que nos ayudara a mejorar la estimación de las siguientes fases del proyecto. Estas estimaciones recogerán todas las desviaciones que se produzcan a lo largo del proceso conformando así parte del proyecto.

Os recomiendo la lectura de los posts de Rodrigo sobre estimaciones agiles y Scrum.

http://geeks.ms/blogs/rcorral/search.aspx?q=estimaci%c3%b3n

http://geeks.ms/blogs/rcorral/search.aspx?q=scrum

 

 

 

Mejorar el rendimiento de Visual Studio

El
entorno de Visual Studio dispone de varias opciones que permiten optimizar y acelerar operaciones habituales,
a continuación os dejo algunas de las que utilizamos habitualmente.

En
proyectos en los que utilizamos muchos controles, o tenemos addins que consumen
muchos recursos, se hace necesario además configurar VS, para aprovechar mejor
la memoria del sistema y evitar errores.

Deshabilitar
el arranque de la página de inicio.

·        
Abrir las propiedades del acceso directo de Visual
Studio.

·        
Agregar el parámetro /nosplash en
la propiedad target.

 

Mostrar
un entorno limpio al arrancar. Esta opción evita que cargue la información de
la página web inicial en VS.

·        
 Tools | Options  |Enviroment | Startup,
establecer Show empty enviroment.

Para realizar la compilación más rápida, deshabilitar
aquellos proyectos que no vamos a utilizar. En este caso tengo deshabilitados
los proyectos de Test.

Project – Properties

·        

 

 

 

 

 

 

 

 

 

 

Para realizar una arranque más rápido de la aplicación en
modo depuración


Utilizar Debug – Start New Instance en lugar de
F5

 

 

 

Deshabilitar la regeneración de la barra de herramientas con la opción AutopopulateToolbox y
solo habilitarla cuando vayamos a añadir nuevos controles.

Esta opción aumenta
mucho la velocidad si usamos librerías de controles cuando abrimos los
formularios evitando que se genere de nuevo el toolbox.

 

 

 

Aumentar el número de construcciones paralelas simultáneas
de proyectos. Por defecto tiene el valor 1.

Tools | Options | Build and Run

 Deshabilitar las utilidades de
animación.

·        
Tools | Options | Environment and uncheck Animate
environment tools
.  

 

 

  Si usas Resharper puedes
deshabilitar la opción Navigation Bar.

 

 

Y los consejos habituales…

Deshabilitar
el antivirus de los para las .pdb, .cs, .h, etc y solo chequear con el
antivirus cuando se modifiquen. Nunca
deshabilitar el antivirus del directorio donde se aloja la aplicación.

Se aconseja si es posible tener la solución en un disco
diferente al de la instalación de Visual Studio, se supone que el rendimiento
es mayor.

Desfragmentar el disco regularmente.

Post recomendados.

Como no, citar el post de Ibón Landa que tanto nos ayudo, si queréis que visual estudio
aproveche la memoria de vuestro equipo, y eliminar un montón de problemas sobre
todo si utilizáis addins o grandes librerías de controles, no dejéis de leerlo.

http://geeks.ms/blogs/ilanda/archive/2008/06/15/191-problemas-de-memoria-pues-no-me-acuerdo.aspx

 Otros post de interés:

http://weblogs.asp.net/scottgu/archive/2006/09/22/Tip_2F00_Trick_3A00_-Optimizing-ASP.NET-2.0-Web-Project-Build-Performance-with-VS-2005.aspx

http://weblogs.asp.net/scottgu/archive/2007/11/01/tip-trick-hard-drive-speed-and-visual-studio-performance.aspx

Si por cualquier motivo queréis dejar la configuración del
entorno en su estado original podéis utilizar la siguiente opción:

Visual Studio dispone de una opción en Tools –
Import and Export Settings


Estoy
seguro que existen más opciones, si alguien conoce alguna más, le agradeciera
las añadiese al post.

Maldivas Arquitectura 1 – El sentido común

Antes de nada, no pretendo dar un manual de cómo se deben abordar las aplicaciones de hoy en día, tan solo traslado parte de lo que he aprendido a lo largo de mis años de desarrollo, no me considero un experto en arquitectura, tan solo tengo la experiencia de varios proyectos en los que he trabajado, tratare de daros las pautas e informaros de los errores que he visto y cometido en estos años. Espero que os ayuden en vuestro trabajo.

La arquitectura de una aplicación es con mucho la parte más importante de cualquier proyecto, la toma de decisiones en este apartado marcara el éxito o el fracaso de nuestro trabajo, por ello, deberemos pensar muy bien qué hacer en esta primera fase de desarrollo. Es aquí donde se cometen la mayoría de los errores más graves de diseño de una aplicación.Mi recomendación a la hora de decidirme por una arquitectura es la siguiente:

Primero y lo más importante “UTILIZAR EL SENTIDO COMÚN” y no dar nada por concluido hasta que no estemos verdaderamente seguros de haber llegado a la solución adecuada.

No hace mucho tiempo, cuando estábamos trabajando en la arquitectura de la aplicación actual, un arquitecto nos explico cómo aplicar el patrón Entity relationship Model, después de varios días de trabajo, el proyecto era algo así, por cada entidad lógicamente teníamos que tener un manager que nos permitiese realizar una serie de operaciones comunes, obtener un registro, obtener una lista de registros, grabar un dato de una entidad, etc, etc, acabamos la semana con un mantenimiento sencillo, que permitía dar de alta, buscar, grabar datos y movernos de un registro a otro, con una pequeña apreciación, en el manager teníamos aproximadamente mil líneas de código y en el mantenimiento teníamos otras mil, la capa de datos la habíamos hecho más o menos genérica, yo al verlo dije, esto no es viable, la aplicación así no funcionara, si tengo que implementar mil líneas en cada formulario y otras tantas en cada manager, dos mil por mantenimiento y parto de la base en el que el sistema va a tener más de mil tablas, significa que estamos hablando de 2000000 de líneas de código, y si por cualquier motivo tengo que variar una función esto me obligaría a repetirlas en los sucesivos mantenimientos, tantas lineas me parecian imposibles de mantener.

Recuerdo varias discusiones con mi equipo de trabajo, en el que alguno me decía, la arquitectura es correcta, yo he realizado de forma similar mis mantenimientos toda la vida y las aplicaciones han funcionado, y tenía razón sus aplicaciones habían funcionado pero los requerimientos eran diferentes no era lo mismo trabajar y mantener pocas tablas que trabajar con cientos de ellas. En el desarrollo de un proyecto anterior habiamos logrando realizar mantenimientos complejos sin apenas añadir ninguna línea de código utilizando basicamente herencia visual, tan solo configurando algunas propiedades del formulario, asi que sabia que podriamos optimizar mucho mas las capas. La solución final, apenas 20 líneas de código por cada mantenimiento, manager de la capa de negocios y capa de datos. Nos llevo varios meses, y rehacer el proyecto de principio a fin varias veces. Recuerdo que alguno decía, si lo rehaces una vez más abandono el trabajo…

Si no tenemos la suficiente experiencia debemos aceptarlo, un desarrollador no tiene porque ser un experto en arquitectura, tan solo conocera aquellas en las que haya trabajado, posteriormente podemos estudiar diferentes alternativas y ver la que mejor se adecua a la solución que buscamos o rodearnos de aquellas personas que si entiendan de arquitectura y que tengan experiencia en desarrollos y soluciones de problemas similares. Si una empresa se tiene que gastar dinero en pagar a una buena consultora sobre cómo realizar la arquitectura de una solución, será mejor realizar la inversión al principio que cuando nuestro proyecto este paralizado, y nos obligue a tener que rehacer la mayoría del desarrollo asumiendo los costes e implicaciones que ello supone. Debemos tener sumo cuidado con la elección de los consultores, lo mejor es preguntar a varias y asegurarnos que están capacitadas para realizar el trabajo, solicitando información sobre sus proyectos e incluso hablando con los clientes que han utilizado sus servicios, he visto empresas con proyectos millonarios que han fracasado por culpa de las consultoras.

           He oido frases como: «La aplicación tiene que estar en 6 meses, hay que empezar a trabajar ya, no podemos dedicar un mes a ver como lo hacemos». Este es uno de los errores más comunes, no le damos la suficiente importancia a la arquitectura. Si no estamos dispuestos a pararnos y pensar cómo abordar la solución de un proyecto de la mejor forma posible, estamos condenados al fracaso. En arquitectura los errores que se cometen al principio se pagan caros al final.

Sobre los «arquitectos de software«, me he asombrado a veces cuando alguna personas me dice: Yo soy arquitecto de software, se que es un término que gusta, además creo que esta de moda hoy en día, ultimamente veo aparecer arquitectos de software como por arte de magia. Recuerdo una conversación con uno… ¿cuántos años tienes? 24, ¿Desde cuándo te dedicas a la informática?  Acabe la carrera a los 22, ¿Cuántos proyectos has realizado? Muchísimos, ¿Qué duración tenían?, el mayor 6 meses…

No digo que no puedan existir Arquitectos de Software de 24 años, pero será la excepción que rompe la regla, para ser un buen arquitecto no vale haber estudiado una carrera o haber leído varios libros sobre arquitectura, patrones de diseño y mejores prácticas, sobre todo los arquitectos han tenido que participar y trabajar en varios proyectos de diversa índole, deben tener la experiencia, haber fracasado, y haber solucionado con éxito infinidad de problemas que tienen todas fases de un desarrollo. De la misma forma que un Jefe de Proyectos no será bueno si antes no ha sido desarrollador, un Arquitecto debe tener una amplia experiencia en soluciones de software, haber participado en multitud de proyectos diferentes y sobre todo, debe saber transmitir sus ideas y escuchar a los que le rodean, ¿Quién sabe más de programación?, el que está escribiendo líneas todos los días o el que desde su despacho lee de arquitectura y te dice como tienes que trabajar.