Cinco elementos clave en una buena externalización del desarrollo software (II/II)


(Segunda parte del post sobre cinco elementos clave en una buena externalización del desarrollo software)
3 – Los requerimientos a cumplir por la fábrica de desarrollo software
Aunque muchas veces no es garantía total de éxito, es bastante recomendable requerir un mínimo de indicios sobre la calidad de la organización a la que vamos a externalizar un desarrollo software. Algo que es ya un requerimiento mínimo para toda empresa de desarrollo son las certificaciones de la calidad de sus procesos software, normalmente el cumplimiento de modelos como CMMI o ISO 15504 (y que pueden acompañarse de muchas otras certificaciones). En este punto es bastante recomendable saber el nivel de madurez de la organización que en un futuro recibirá la externalización, eso sí, sin engañarnos y sin olvidar aquello que hace un tiempo comentábamos: Una certificación de la calidad de los procesos no siempre asegura un producto de calidad, muchas veces es condición necesaria pero no suficiente de éxito. Aunque si bien la calidad del proceso (CMMI o ISO 15504) es normalmente el requerimiento más demandado a los subcontratistas, últimamente este requisito está acompañando de otras certificaciones, como son aquellas de carácter personal y que debiera cumplir el equipo de desarrollo, donde el abanico es más amplio, y junto a las relacionadas con tecnologías de programación podemos requerir otras también famosas como CISA, PMP, CSQE, ITIL, ISTQB, etc.
4 – La especificación de los trabajos a desarrollar
Por mucho que se repita nunca es suficiente: los requisitos, su gestión y especificación, es uno de los puntos más vitales del éxito de un proyecto software, principal riesgo y estadísticamente la principal causa de que los proyectos software fallen. Y todo ello se multiplica en un entorno de desarrollo externalizado. Cuanto más detallados estén los requisitos mejor, y cuantos más requisitos detallados podamos poner en el contrato, mucho mejor. Y no sólo requisitos funcionales, muchas veces nos centramos en la funcionalidad y olvidamos la no-funcionalidad, que muchas veces es igual de crítica: especificar la tecnología de programación, el rendimiento de la aplicación, la disponibilidad, e incluso hasta el IDE y las versiones de las librerías que debe utilizar el equipo de desarrollo
5 – La recepción del producto y la evaluación de su calidad
Un punto fundamental, y que tiene un gran impacto, es cómo se va a recepcionar la entrega y cómo se va validar. De no definir nada, y que nos den el software en un CD o un ftp, a que especifiquemos que el software se deja en nuestra herramienta de control de versiones (un subversión, por ejemplo), y que se va a compilar con nuestro maven y nuestro juego de librerías oficial (para tener control total del mantenimiento futuro del software), y se van a pasar cierta bateria de pruebas… hay un mundo. En este punto es necesario haber definido una normativa de calidad a superar por el software, que esta sea conocida por el desarrollador y que evaluemos que el software la cumple; y por ejemplo: evaluar el porcentaje de código duplicado, la densidad de complejidad ciclomática, la cobertura de pruebas unitarias, si se ha seguido el estilo de codificación establecido, etc. Y la evaluación puede (o debe) no sólo referir al software, también a productos intermedios del ciclo de vida, como la definición de la arquitectura, análisis, etc.

0 comentarios en “Cinco elementos clave en una buena externalización del desarrollo software (II/II)”

  1. Pingback: Cinco elementos clave en una buena externalización del desarrollo software (I/II) | Javier Garzás

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This
Ir arriba