archivo

Archivo de la etiqueta: libro blanco

Si en el nivel 3 de CMMI se entra en el detalle de cómo obtener los requisitos resulta razonable que no ignore los procesos de diseño y construcción y de esto trata este área de proceso.

Es muy importante no caer en la trampa de definir procesos poco flexibles que no permitan una adaptación a la tipología de sistemas de información y circunstancias que pueden producirse en el desarrollo y mantenimiento de los mismos. Puede ser razonable hacerlo en entornos controlados, pero en entornos variantes (como son la mayoría) hay que establecer una serie de pautas que normalicen el proceso de diseño y construcción de manera que lo que se marque sea un camino con la suficiente anchura como para elegir dentro de él la trayectoria más adecuada al proyecto pero lo suficientemente estrecho como para tener un control de la manera en que se diseñan y construyen los sistemas.

Dentro de este área de proceso se determina en qué condiciones se deben ofrecer alternativas de solución y cuál es la información que se debe suministrar en cada caso, qué criterios utilizar para seleccionar una de ellas, qué criterios, técnicas, estrategias, precondiciones, etc… tener en cuenta a la hora de realizar el diseño del sistema, qué circunstancias se deben tener en cuenta a la hora de elegir la opción más ventajosa para obtener la solución que se demanda (comprar, reutilizar o construir), qué prácticas se deben seguir para realizar la construcción del sistema y para escribir la documentación de soporte.

¿Se basa este proceso en tener y seguir un libro blanco? Hay aspectos de este área de proceso que escapan de un libro blanco convencional, como aspectos de un libro blanco convencional que van más allá de este área de proceso, no obstante para imaginarnos qué contenido tendría un proceso como este es una buena aproximación, si bien equipararlos, tal y como acabo de comentar sería caer en el error.

Todo lo que sea huir de métodos artesanales en los procesos de desarrollo de software supone tiempo y dinero o lo que es lo mismo dinero y dinero.

1) Intenta que todos los desarrollos de la empresa sigan un mismo framework siempre que sea posible (en ocasiones las imposición de una determinada arquitectura o tecnología por el cliente lo impide, pero en el resto de casos, siempre que se pueda, haz uso del framework). El framework además es recomendable que esté recogido en un libro blanco de desarrollo (que va más allá del framework, lógicamente) y mantener ese libro blanco actualizado. Este framework único facilita la movilidad de los programadores entre proyectos y la mantenibilidad de los sistemas. No tengas miedo en actualizar el framework o el libro blanco, si aparece o encuentras alguna librería, componente, arquitectura, etc… mejor que la que usas, más estable, más robusta y/o que te permite una mayor productividad no dudes en cambiar el framework, eso sí, debe hacerse con prudencia y con un espacio de tiempo razonable entre cambio y cambio.

2) Intenta que el framework se base en estándares.

3) Si además del framework base, se tienen componentes software concretos y completos que resuelven problemáticas cada uno de ellos en diferentes tipos de proyectos, mejor que mejor.

4) Si se tienen productos completos que simplemente requieren su personalización en función del cliente, todavía mejor.

5) Siempre se habla de reutilizar código, pero si se consiguen reutilizar requisitos de proyectos o lo que es lo mismo la experiencia, también resulta de gran importancia. Para esto hay que documentar y establecer mecanismos que permitan localizar en la documentación de proyectos lo que se quiere y de esta forma obtener conocimiento.

6) La documentación de los proyectos queda obsoleta por la evolución de los mismos y resulta muy costosa mantenerla, por lo tanto, lo mejor es tener poca documentación pero buena y mantenerla actualizada. Por otro lado, toda aquella documentación que se pueda automatizar bienvenida sea y toda aquella documentación que se pueda sustituir mediante la aplicación de ingeniería inversa sobre cualquiera de los elementos del programa, sustitúyase.

7) Si existe software de gestión de versiones, MAVEN y herramientas software para definir entornos de integración continua, utilícense. Eso sí, bien. De nada te vale tener los fuentes en SVN si no tienes una buena política de etiquetado, de nada te vale usar MAVEN si no estrujas su potencial para automatizarte tareas, etc…

8) Independientemente de que se definan buenas prácticas hay que verificar que se siguen. Si puedes ten uno o más arquitectos que vayan sondeando el estado tecnológico de cada proyecto.

9) Ten documentado como es el proceso de implantación de software en tus clientes, permitirá ahorrar mucho tiempo.

10) Nunca es una pérdida de tiempo cada minuto que dediques a probar la aplicación antes de entregarla al cliente.

De la última migración de versión del sistema de gestión de base de datos utilizado en mi organización, he sacado varias conclusiones:

– Los desarrollos de nuestra organización deben tender a una sola tecnología.

En mi organización ya decidimos hace tiempo que esa tecnología era Java, por lo que el camino ya está iniciado, no obstante, debemos comenzar cuanto antes la migración de todo lo que no está en Java a esa tecnología.

– Los desarrollos de nuestra organización deben tender a un solo framework.

En mi organización se ha están sentando las bases para que todos los desarrollos sigan un mismo marco, de ahí el libro blanco que rige los desarrollos, el cual está en pleno y continuo proceso de evolución.

– El framework debe ser lo más cerrado posible.

También estamos sentando las bases para conseguir esto, ya que las evoluciones del libro blanco van encaminadas a acotar este framework cada vez más. Evidentemente la evolución de la tecnología va a provocar que con el paso del tiempo haya aspectos que varíen en el framework de desarrollo, pero evidentemente será una situación mucho más aceptable que tener muchos proyectos desarrollados en tecnología Java, siguiendo estrategias distintas.

Es fundamental para la mantenibilidad de las aplicaciones (además de que estén bien documentadas y exista una correcta gestión de la configuración) que en la medida de lo posible, las soluciones técnicas sean lo más parecidas que se pueda. Desde mi punto de vista, la consecución de este objetivo tendrá un ahorro de costes importante a medio plazo.

En mi departamento seguimos dando pasos pequeños, pero firmes para tener una infraestructura de desarrollo de software en condiciones.

– El uso de Subversion ya es generalizado, por lo que tenemos un control absoluto sobre los fuentes de las aplicaciones.
– El uso de Artifactory también es generalizado, por lo que también tenemos un control absoluto sobre las librerías que se utilizan y las tenemos en un espacio distinto a los fuentes.
– El uso de maven para las entregas e implantación también es generalizado y se está generalizando la implantación mediante Hudson.
– Tenemos un libro blanco de desarrollo que de un tiempo a esta parte ha orientado los desarrollos a una arquitectura y una tecnología común, lo que facilita la reutilización y el mantenimiento. En la actualidad se está retocando dicho libro para actualizarlo tecnológicamente, acotar un poco más el abanico de posibilidades y soluciones a utilizar y modificar drásticamente la forma de documentar los proyectos, basándonos en una herramienta CASE (independientemente de que haya documentación extra-CASE).
– La metodología de peticiones de entregas y de comunicación de incidencias en las pruebas con las empresas desarrolladoras también se está generalizando.
– La documentación de los proyectos está centralizada en un ECM (en nuestro caso Alfresco), con una estructura de carpetas por proyectos. Esta forma de organizar la documentación va a variar con la nueva versión del libro blanco que como he comentado se va a basar en el uso de una herramienta CASE.
– Se ha terminado de implantar una herramienta para gestionar los proyectos de manera que no tengamos la gestión en diversas herramientas y soluciones. A partir de ahora vamos a tratar de que la gestión de todos los proyectos esté centralizada en Redmine. Probablemente más adelante “truquemos” Redmine para comunicarlo con Alfresco, para añadirle alguna característica como la gestión de incurridos, etc…

Todavía nos queda mucho camino por recorrer, pero creo que la dirección que hemos tomado es adecuada. Mi único mérito en todo este asunto ha sido escuchar y dejarme aconsejar por gente que sabe mucho, muchísimo de lo que es el proceso de desarrollo de software. También hay que destacar la acogida que ha tenido esta infraestructura entre mis compañeros porque sin su colaboración nada hubiera sido posible.

Tanto si tienes externalizadas las tareas de programación, como si no o tu empresa se dedica al desarrollo de software, resulta esencial la existencia de un libro blanco de desarrollo que marque una línea tecnológica y de arquitectura para los sistemas de información.

De esta forma el desarrollo de los proyectos es homogéneo y facilita las tareas de mantenimiento. Además, supone un ahorro de costes, ya que el desarrollo bajo un paraguas común facilita la existencia de un framework y de una colección de componentes estable.

El libro blanco de desarrollo supone también una métrica cualitativa de medida de la calidad de los desarrollos en cuento a lo que a tecnología y arquitectura se refiere, algo que resulta fundamental.

El libro blanco de desarrollo debe centrarse en la selección de buenas prácticas, tecnologías, patrones y arquitecturas para el desarrollo de software para cada uno de los paradigmas de sistemas de información en los que se desarrolle. El libro blanco debe marcar un camino y digo camino y no línea, ya que es recomendable ser flexible para determinadas soluciones, dando la posibilidad de utilizar distintas alternativas. Además debe huir de soluciones “propietarias” (en el sentido de que sean soluciones particulares de una empresa en cuestión) a nivel de framework y adoptar componentes que resuelvan problemáticas funcionales recurrentes sean o no “propietarios” en el sentido indicado anteriormente.

Evidentemente si trabajas en una empresa de desarrollo de software debes desarrollar según las directrices tecnológicas que te marque el cliente, pero en el caso de desarrollos internos, desarrollos I+D o desarrollos para clientes que no te marquen una directriz tecnológica sí que resulta muy interesante el uso de un libro blanco de desarrollo.

Otros aspectos importantes que debe cubrir un libro blanco debe ser la organización del software y el procedimiento de entregas, es decir, qué sistema de control de versiones utilizar, cómo utilizarlo, cuál debe ser la política de etiquetado, qué solución utilizar para automatizar la realización de pruebas unitarias, despliegues, cuál es la política a seguir para el paso a pruebas y/o producción del sistema, etc…

Como se puede apreciar, un libro blanco de desarrollo bien hecho, no está al alcance de cualquiera, de hecho se escapa, en mi caso, varios millones de leguas de mi capacidad técnica. La persona o personas que lo realicen deben tener un gran conocimiento de arquitecturas y tecnologías software, estar muy al día de todas ellas y tener una gran experiencia en el desarrollo y gestión de proyectos de desarrollo de software.

Uno de los aspectos que más me preocupan en el desarrollo de proyectos informáticos es que el producto llegue al entorno de producción con el menor número de errores funcionales, que tenga un buen rendimiento y sea fácilmente mantenible a nivel de código y de documentación.

Esto que parece de perogrullo, es tremendamente difícil sobre todo si nos encontramos con proyectos de una gran envergadura con un parque de usuarios heterogéneo en localizaciones dispersas con distintos nivel de calidad en su ancho de banda.

Después de analizar las metodologías de desarrollo clásicas como Métrica v.3 y tratar de hacer uso de ella en mis proyectos (más bien un subconjunto de ella, pero aunque sea un subconjunto, por definición de Métrica v.3 sigue siendo Métrica v.3) he llegado a la conclusión de que sin ser una mala opción, hay algunos aspectos que sí es conveniente centrarse y en otros menos:

– Plan de proyecto. Contendrá el cronograma del proyecto (lo mejor es que ese cronograma se mantenga con una herramienta informática compartida: Redmine, dotProject, etc…), por lo que valdrá con una referencia a la url donde se puede seguir el cronograma del proyecto, el equipo de proyecto (igualmente lo mejor es que ese equipo de proyecto se vaya actualizando, por tanto lo mejor es una herramienta informática compartida y si es la misma que la del cronograma, mejor que mejor y se sepa si así lo desea el cliente su imputación de horas al proyecto) y la documentación que deberá acompañar al proyecto.

– Lo fundamental en un proyecto de desarrollo de software son los requisitos. La empresa que posea analistas con la suficiente capacidad para obtener del usuario lo que quiere (cosa tremendamente difícil) tienen una ventaja muy importante respecto a sus competidores. Este catálogo de requisitos es fundamental tenerlo actualizado en todas las fases del proyecto, incluido el mantenimiento. Si es necesario dedicar tiempo a una fase del proyecto concreta esta es el análisis de requisitos. El catálogo de requisitos debe ser completo y fácilmente inteligible por el usuario. Si hay presupuesto en el proyecto y puede facilitar el proceso de desarrollo el analista puede trabajar con los diagramas de casos de uso.

– Modelo de datos. Muy importante tenerlo documentado en la versión 1 del proyecto. Para posteriores versiones, si en el mantenimiento hay presupuesto y tiempo (aspectos no siempre disponibles) se puede mantener la documentación del modelo de datos, en caso contrario no pasa nada, siempre hay herramientas que te los puede obtener por ingeniería inversa a través de la base de datos.

– Interfaz de usuario. Es fundamental que el usuario conozca y valide la interfaz de usuario, ya que es donde ellos van a trabajar, de nada vale saber lo que quiere el usuario si después la interfaz de usuario no es ágil. Por este motivo también conviene invertir en esta fase del proyecto. Cuanto más se aproxime esta interfaz de usuario a su implementación real, más conciencia tendrá el usuario de lo que se va a encontrar y por tanto más posibilidades de éxito existen en el proyecto.

– Arquitectura del sistema. Debe ser breve, conciso y cuanto más gráfico mejor. Es importante para proyectos donde se deleguen funcionalidades en terceras herramientas (motor de tramitación, plataformas de autenticación y firma electrónica, etc…).

– Plan de pruebas (unitarias, integración, sistema, implantación y aceptación). Aunque es una realidad que nosotros, los clientes, tengamos nuestros propios medios para garantizar la calidad de las entregas, son absolutamente necesarias dos premisas: Que la empresa desarrolladora realice un primer filtro de pruebas muy importante (nunca es perdido el tiempo que se dedica a probar) y que se entregue un manual de pruebas al cliente donde como mínimo se pueda garantizar, tras realizar las pruebas, que el sistema funciona y que además verifica los requisitos funcionales y no funcionales más importantes.

– Manual de usuario. Debe estar siempre actualizado. Ser muy completo y tener casos de uso reales en los que se refleje, al menos, el 90% de la casuística del programa. Si el manual está accesible on-line por los usuarios mejor que mejor, independientemente de eso es aconsejable que sea también fácilmente imprimible.

A todo lo anterior es necesario sumar la necesidad de utilizar un sistema de control de versiones buenos, como por ejemplo Subversion y hacer un buen uso del mismo (política correcta de etiquetado de versiones, etc…), utilizar unos mecanismos estándar para el despliegue de los proyectos: MAVEN + Hudson + Artifactory, por ejemplo y algo fundamental, un libro blanco de desarrollo que homogeinice los desarrollos que se realizan para tu organización.