El blog de Juan Irigoyen en Geeks·ms

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

 

 

 

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.

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.

Como punto de partida os contare que actualmente mi equipo y yo, estamos desarrollando un sistema ERP para la empresa en la que trabajamos, lo hemos bautizado como «Maldivas», voy a describiros algunos de los procesos más interesantes que estamos implementando. Tratare de explicar el funcionamiento de aquellas partes que os parezcan más interesantes.

La arquitectura del sistema está basada en n-capas, utilizando como base el patrón Entity Data Model, «muy similar al EDM que Microsoft acaba de presentar», que pena que llevemos dos años de desarrollo y nos lo hayamos tenido que currar todo.

                La capa de presentación está basada principalmente en librerías de controles personalizadas que utilizan controles de terceros de la marca «devexpress», para los interesados www.devexpress.com y por supuesto de algún control propio de .net, todos los formularios maestros heredan de un formulario base que realiza todas las llamadas de forma genérica a la capa de negocios.

La capa de negocios está basada en librerías de clases que principalmente interaccionan con la capa de datos y la de presentación, además de  incorporar las reglas de negocio. Estas capas las hemos diseñado utilizando generics, por anticiparos algo realizamos llamadas de este tipo.

Manager<Clientes> manager = new Manager<Clientes>();

manager.GetAll();  me devolvería una colección de entidades de tipo cliente.

manager.Get(‘000001′) me devolvería una entidad de tipo cliente

manager.Get(Filters) me devolvería una colección de clientes filtrados por una o varias condiciones.

manager.Data.Nombre = «prueba»;  Guardaria en la entidad el nombre de un cliente

manager.SaveChanges();  Salvaria los cambios en la base de datos.

Estas funciones generan en tiempo de ejecución sentencias sql de tipo:

SELECT [Nombre],[Apellidos]… FROM dbo.Interlocutores WHERE Tipo = ‘1′ // Clientes

o

UPDATE dbo.Interlocutores SET [Nombre] = «prueba» WHERE [Codigo]= ‘000001′ AND [Nombre]  = @valorAnterior

En algunos casos podemos optimizarlas generando directamente los procedimientos almacenados para realizar la operación y cacheamos muchos de los datos que reutilizamos.

De esta forma minimizamos el código utilizado para trabajar con múltiples entidades, dedicare un post entero a mostraros esta arquitectura, ahora mismo estoy migrando parte para adaptar el EDM de Microsoft.

Posteriormente añadiremos otra capa basada en ws, para aprovechar reglas de negocios y funciones de la capa de acceso a datos que serán utilizadas en el sistema de comercio electrónico y los dispositivos móviles.

                Como la aplicación no va orientada al público en general, es muy específica para el sector en el que trabajamos, decidimos centrarnos únicamente en Sql Server y aprovechar al máximo su potencial, utilizamos procedimientos almacenados de forma masiva y muchas de las características propias sql como particionamiento de tablas, funciones, triggers, sinónimos y otros aspectos propios de la base de datos, creando una dependencia total con el Software de Base de datos.

Sé que hoy en día y con las arquitecturas existentes, así como las maneras diferentes que existen de abordar un problema, muchos no estarán de acuerdo con esta arquitectura, alguna persona me ha preguntado, ¿Como no lo hicisteis todo en aspx utilizando ws ? o ¿ Como no utilizáis Entreprise Library para crear un acceso más independiente de la base de datos ?  o ¿ Por qué no habéis desarrollado toda la parte de la capa cliente en WPF en lugar de Windows Forms ? , etc.

Tratare de explicar porque hemos tomado estas decisiones, además de los errores y aciertos que hemos cometido a lo largo del proceso de desarrollo, aspectos relacionados con el trabajo en equipo, diseño, adopción de herramientas, y otros que os darán una perspectiva amplia de los proyectos con los que trabajamos. Dedicare también algún post a hablar de las herramientas que utilizamos en el desarrollo (TFS, Team Suit, Team for Database Professional, CodeRush, Refactor, Resharper, Pruebas Unitarias, fxCop, Herramientas de generación de código propias utilizando Codedoom, etc),  y un poco sobre algún aspecto de la metodología de trabajo utilizada en este proyecto «Scrum».

Me gustaría mucho oír vuestras opiniones y críticas al respecto.

Siempre me ha gustado «fisgar» las aplicaciones de los demás, de ellas he sacado la mayoría de las funcionalidades que implemento en los programas que desarrollo. Como una imagen vale más que mil palabras os dejo algunos formularios del programa que iré desgranando en los sucesivos post, espero que os gusten.