archivo

Archivos Mensuales: junio 2009

Me comentaba hace un poco un jefe sobre un aspecto del que se hablaba mucho, pero que él no conocía ningún caso y me decía que era como el quinto polvo, algo del que todo el mundo había oído hablar pero que nadie conocía a alguien que hubiera llegado a él o había experimentado en persona si era cierto.

Pues hay otro mito por ahí, que es la tercera certificación en Java. Estoy harto de revisar currículums de personas en los últimos años y todavía no me he encontrado con nadie, absolutamente nadie, que presente al menos tres certificaciones oficiales Java. Un número reducido presenta la certificación SCJP, un número todavía más reducido presenta la SCJP y la SCWCD, un número aún más reducido presenta la combinación SCJP y la SCBCD, pero más allá de esto no me he encontrado a nadie que tenga tres certificaciones Java.

Utilizando el ejemplo que me puso uno de mis jefes y haciendo una analogía, es igual de complicado llegar al quinto polvo que sacarse la tercera certificación Java y ajustando un poco el planteamiento, tal vez solo sean capaces de llegar al quinto polvo aquellos que consigan obtener la tercera certificación Java.

Anuncios

¿En cuántos proyectos en los que ha participado o desarrollado tu organización habéis empezado desde cero, es decir, desde el framework (si es que hay framework)?.

Si se tiende a cero, mala cosa, por muy potente o poderoso que sea el framework.

Me pongo a analizar algunas empresas desarrolladoras de software de éxito, sobre todo alguna emergente en los últimos años y no me canso de ver el mismo producto base revendido hasta la saciedad o bien adaptaciones del mismo (sin ser productos excepcionales, ni novedosos). Por muy baratos que los vendan (que además no siempre se venden baratos), el beneficio es prácticamente íntegro.

Hay muchos proyectos que por necesidades del cliente sí que se tienen que hacer desde cero e incluso con variaciones en el framework si así lo estiman las normas de desarrollo del cliente. En esto no entro. Sí que entro en otros proyectos donde el cliente tenga unas normas de desarrollo más relajadas y lo que le interese sea obtener un producto que colme sus necesidades, con un precio y plazo de ejecución razonable.

Salvo proyectos muy específicos, en la mayoría de los casos siempre hay partes que se pueden reutilizar de un proyecto a otro. En muchos posts he hablado ya no solo de la necesidad de disponer de un framework lo más potente posible, sino de disponer de un catálogo de componentes de más alto nivel reutilizables. En este post voy más allá, existirán proyectos donde lo que se puede reutilizar es la misma aplicación en sí, variando lo que se tenga que cambiar en la capa cliente (ya sabemos todos que simplemente cambiando la capa cliente una misma aplicación puede parecer otro totalmente distinta aunque la funcionalidad sea la misma) y en la capa de negocio o de acceso a datos. Para que un analista pueda hacer eso, necesita tener un conocimiento general de las aplicaciones que se desarrollan en la casa. Es por esto (aunque el objetivo no sea enseñar los productos para que se reutilicen) por lo que muchas empresas, de vez en cuando (una vez cada cuatro meses o semestralmente), hacen unas jornadas de divulgación entre los empleados, enseñándole a los mismos los proyectos más significativos que han terminado su ejecución en ese período o que están a punto de terminar.

También es cierto que es más complicado reutilizar cuando eres agente pasivo en una contratación, es decir, ganas un concurso (con esto no quiero decir que no se pueda reutilizar, pero digamos que la iniciativa, la lleva como es lógico el que contrata y te puede poner una serie de restricciones en el proyecto que te impidan en gran medida la reutilización), pero es más sencillo si eres agente activo, es decir, tienes un software que resuelve una temática concreta de un negocio y lo vendes a un tercero. Eso sí, en el acuerdo de venta debe quedar muy claro, hasta donde va a llegar la personalización, ya que en caso contrario, te puedes encontrar con que te desvistan entero el producto y sea lo mismo que empezar desde cero.

Hay algo a lo que todavía no me he acostumbrado y es a lo desproporcionado que le parece a personal no relacionado con la informática el coste del desarrollo de proyectos informáticos.

Es una situación que no alcanzo a entender sobre todo cuando esas personas que se sorprenden incluso cuando comentas cantidades irrisorias se gastan muchísimos dinero en hacer otras actuaciones que sí que son realmente caras en relación al precio de los proyectos informáticos.

Esto provoca que en muchas ocasiones se subestime el coste de un proyecto informático con todos los problemas que esto supone, ya que como he comentado en otras ocasiones, los profesionales de la informática no tenemos una varita mágica que haga surgir un análisis y su codificación posterior de la nada, por lo que si el importe del proyecto es inferior a lo que cuesta realmente lo más probable es que el proyecto no vaya bien, por muy diligente que sea el responsable del proyecto y por muchas horas que dediquen los programadores.

Los profesionales de la informática tenemos que hacer sobre esto una labor didáctica, de manera que las personas con las que trabajamos y costean los proyectos entiendan que el desarrollo de software es una actividad tremendamente compleja y como tal tiene su coste.

Si se externalizan procesos completos, es necesario el establecimiento de acuerdos de nivel de servicio.

Dichos acuerdos, permiten que no se vaya a ciegas en la ejecución de un servicio y que se pueda demostrar de forma objetiva que el desempeño del mismo es positivo. Esto es bueno, tanto para el proveedor como el cliente.

El acuerdo de nivel de servicio establece un marco de referencia para el desarrollo de los servicios y propicia la mejora continua de los procesos ya que se basa en la medición de determinados indicadores para determinar si el servicio se está realizando de forma adecuada o no.

Ya he hecho referencia en posts anteriores en la importancia de la medición como pieza fundamental para mejorar la calidad, por tanto el establecimiento de acuerdos de nivel de servicio, permiten garantizar la calidad del servicio y una mejora continua del mismo.

Bien es cierto, que es complicado en ocasiones realizar la medición de los indicadores que determinan el cumplimiento del acuerdo de nivel de servicio, será la experiencia tras la implantación del servicio la que vaya buscando los indicadores más adecuados y busque las estrategias más óptimas para realizar el proceso de medición de los mismos.

Si algo funciona… no lo toques.

Los que nos dedicamos a la profesión informática tenemos la gran virtud de ser personas, por lo general, muy creativas, pero esa virtud se torna en defecto cuando la creatividad choca con la practicidad.

Vamos a ver, si tienes un producto que en otra organización similar ha funcionado, ¿para qué ponerse a tocar el núcleo de la aplicación?. Toca lo que haga falta de la capa de cliente y ajusta lo necesario en el negocio, pero no lo desvistas completamente para volverlo a vestir, porque probablemente se puede producir el mismo efecto que cuando compras un mueble que tienes que montar, ¿cuál es? que te sobre algún tornillo.

Si importante es un análisis de requisitos, no menos importante es hacer un buen modelo de datos.

Hacer un buen modelo de datos no consiste en abstraer la información que hay que persistir a una serie de entidades que verifican al menos la tercera forma normal. Sino en hacer un modelo de datos inteligible y que asegure un buen rendimiento del sistema. Si hay que desnormalizar algunas tablas se desnormaliza. De nada te vale una base de datos teóricamente perfecta si en la práctica hacer una consulta requiere el cruce de miles de registros.

El modelo de datos es importante y la posterior implementación en el sistema de gestión de base de datos final también, ya que además de verificar las directrices de implementación que indiquen los administradores de base de datos del cliente, se debe realizar una implementación que permita exprimir todas las posibilidades que ofrezca el sistema de gestión de base de datos.

Ya comenté la necesidad de especialistas en análisis de requisitos, aqui también resultaría interesante esa especialización o al menos la existencia de un arquitecto de la información que revise los modelos de datos de los diferentes proyectos, los optimice y se preocupe por realizar la implementación más adecuada en el sistema de gestión de base de datos destino.

Un problema que ocurre desgraciadamente con relativa frecuencia consiste en no tener dentro del departamento TIC de una organización un entorno de preproducción.

En muchos casos, existe un entorno que se utiliza para probar aplicaciones, pero que dista mucho de ser considerado entorno de preproducción, ya que suelen tener las siguientes características:

– No se tiene seguridad al 100% que si un producto funciona en el entorno de pruebas funcione en el entorno de producción. Esto va a provocar que se produzcan casos donde una misma versión de una aplicación funcione correctamente en pruebas y no en el entorno de producción y al revés, es decir, que funcione en producción, pero que no funcione en pruebas.

– Además del problema de la falta de coherencia con el entorno de producción, se le suelen dedicar muy poco recursos hardware, esto hace que tampoco resulten muy significativas las pruebas de rendimiento que se realicen. Esto provoca además, que la realización de pruebas funcionales o pruebas de aceptación sean desesperantes, ya que suelen ser entornos con un mal tiempo de respuesta.

Es cierto que mejor tener un entorno así que nada (pero la diferencia entre eso y la nada no es mucho), pero no es conveniente conformarse con eso. La inversión en un entorno de preproducción es algo esencial, evitará muchísimos problemas y además posee un rápido retorno de la inversión.

Por tanto un entorno de preproducción resulta esencial en todo departamento TIC, por lo que no hay que mimar solo las infraestructuras de producción, debiéndose dotar de recursos hardware, software y humanos suficientes al entorno de preproducción para que sea coherente con el de producción, garantizándose que si el producto funciona correctamente en preproducción, además de cumplir los requisitos de seguridad, rendimiento, etc…, tendrá un comportamiento similar en el entorno de producción.