Lo importante de las Metodologías de desarrollo en un proyecto 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.

9 comentarios
  1. Ramon dijo:

    Muy interesante el articulo, pero me gustaria saber como poner en marcha estos principios en el departamento de sistemas compuesto por el responsable y un tecnico junior.
    La verdad, llevo 20 años en esto y la experiencia me dice que hay que poner en la balanza el tiempo, el coste y los recursos y, casi siempre, la documentacion se queda fuera.
    Cual es tu receta?

  2. Ramon dijo:

    No quiero decir que no sea importante, al contrario, pero si hay que dejar de hacer algo, por los motivos que he comentado antes, que dejamos?

    • jummp dijo:

      Ante la falta de recursos no hay más receta que adaptar la metodología a lo que realmente puedes afrontar, plantearse otra cosa es un error, ya que te cargará de trabajo a cambio de nada, ya que afectará a la calidad de las tareas del día a día y la metodología no se aplicará de manera adecuada.

      • Ramon dijo:

        Hablando de metodologia, veo que te decantas por un subconjunto de Metrica.
        Yo en su dia lo intente, pero era demasiado para un departamento de solo 2 miembros.

        Tienes alguna documentacion sobre algo aplicable a esta escala?

        Yo utilizo algo que, francamente, dista mucho de llamarse metodologia…

      • jummp dijo:

        Realmente Métrica es tan general que practicamente cualquier enfoque “clásico” del desarrollo de software tiene cabida en ella. No obstante, sí que se puede considerar que el planteamiento que utilizamos en mi organización es un subconjunto de Métrica, lo que pasa es que dicho así parece que detrás de cada proyecto hay una infinidad de documentación y no es así (aunque nuestros proveedores lo puedan pensar en más de una ocasión).

        Para poder darte una mayor orientación necesitaría tener más información, en el sentido de si el desarrollo/mantenimiento de vuestro software es mayoritariamente interno o está externalizado, de si las tareas de mantenimiento correctivo y evolutivo son de pequeña o gran escala, del número de usuarios que tenéis, el grado de criticidad de los sistemas, etc…

        También sería interesante conocer si contáis con herramientas de gestión de incidencias/peticioes, gestión de proyectos, etc… y en el caso de que no la tengáis cómo registráis en la actualidad ese tipo de información.

  3. Ramon dijo:

    El desarrollo lo venimos haciendo de forma que nosotros, es decir yo, hacemos el analisis funcional en detalle y subcontratamos horas de desarrollo externo en algunos casos y en otros lo hacemos nosotros mismos.

    Damos soporte a unos 200 usuarios de los cuales 80 utilizan una aplicacion critica desarrollada por nosotros e integrada con nuesta gestion en AS/400. Tenemos tambien un sistema critico que es el SGA por terminales wifi que diariamente mueven unos 400 palets.

    Utilizamos una herramienta web (manage engine help dsk) para administrar las peticiones de soporte.

    En fin lio hay mucho, tiempo para adoptar una metodologia clara, poco.

    • jummp dijo:

      Está claro que tiempo no os sobra, pero hay algo casi más crítico que los sistemas y ese eres tú, ¿qué pasa si te decides a cambiar de empresa?, ¿hay suficiente información para que alguien pueda continuar tu trabajo sin que se vea afectada la continuidad de los sistemas?.

      Creo que la respuesta a esa pregunta es el principio a partir del cual construir vuestra metodología.

      En cualquier caso, además de poder llevar el día a día, que no es poco, sí que tenéis unos ciertos procesos, en el sentido de que registráis las peticiones e incidencias y que tenéis controlado el desarrollo, dado que hacéis vosotros mismos el análisis funcional.

      Es decir, estáis funcionando en la forma en que estáis trabajando y eso es lo más importante, el siguiente paso sería ir optimizando poco a poco el método.

      Dada la carga de trabajo que tenéis, podríais centraros en mantener actualizados los diagramas de despliegue y los manuales de usuario, además de almacenar los diversos funcionales que vayáis haciendo. Otros aspectos importantes como el modelado de datos se podrían rescatar en un momento dado por ingeniería inversa.

      Dado que también realizáis la administración de los servidores, también sería recomendable que tengáis actualizado los manuales de operación de cada aplicación.

      ¿Es demasiado? Habrá que priorizar entonces, ¿a qué le das más importancia? la respuesta te la puedes dar tu mismo y te indico cómo en el último párrafo de este comentario.

      Pero una metodología no es solo elegir los entregables documentales, sino en establecer una estrategia para los diversos procesos que envuelven al proceso de desarrollo.

      Entrar en más detalle requeriría tener más información tanto de cómo funcionáis en el día a día y de cómo realizáis todo el proceso de desarrollo del software, desde que se decide realizar un correctivo o un evolutivo hasta que implantáis el parche, como comento en algunos artículos, soluciones generales hay, pero la efectividad de las mismas requiere de su adaptación a cada caso concreto.

      Termino este comentario, con la pregunta con que terminé el primer párrafo, ¿te puede sustituir alguien en un tiempo razonable para que no se vea afectada la continuidad de los sistemas?, ¿qué necesitarías en el caso de que fueras tú el que te sustituyeses?, por ahí debería comenzar la optimización de los métodos de trabajo.

Responder a Ramon Cancelar respuesta

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s

A %d blogueros les gusta esto: