Pre requisitos para la Construcción de Software
El desarrollo de software profesional y empresarial es una actividad compleja, con muchos actores, infinidad de metodologías y herramientas.
Aunque hay estándares de referencia y la Ingeniería de Software se considera una rama científica no hay más que ver la entrada sobre Ingeniería de Software en Wikipedia para ver que hay discrepancias a todos los niveles:
La Ingeniería de Software es una de las ramas de las ciencias de la computación que estudia la creación de software confiable y de calidad, basándose en métodos y técnicas de ingeniería. Brindando soporte operacional y de mantenimiento, el campo de estudio de la ingeniería de software.1 Integra ciencias de la computación, ciencias aplicadas y las ciencias básicas en las cuales se encuentra apoyada la ingeniería.
¿Quiere esto decir que no se puede crear software sin usar los métodos y técnicas de ingeniería? Pues no, por supuesto, no hay más que ver la amplia oferta de cursos gratuitos en los que se ofrece "aprender a programar en un mes" o la infinidad de webs, tutoriales, ejemplos de código disponibles.
La diferencia está en las palabras "software confiable y de calidad".
Por confiable es lo menos que se espera de un trabajo profesional: que cumpla su cometido.
Pero si el software ya es en sí algo intangible, ¿a que nos referimos cuando hablamos de calidad de software?
Volvemos a Wikipedia:
"En el desarrollo de software, la calidad de diseño acompaña a la calidad de los requisitos, especificaciones y diseño del sistema. La calidad de concordancia es un aspecto centrado principalmente en la implementación; Si la implementación sigue al diseño, y el sistema resultante cumple con los objetivos de requisitos y de rendimiento, la calidad de concordancia es alta"
El concepto de calidad de concordancia es clave y no siempre se tiene en cuenta cuando se aborda la calidad de software, quizás porque su importancia es implícita.
La especialización necesaria en sistemas complejos crea problemas de coordinación que no siempre es fácil de diagnosticar.
En la encuesta de la semana pasada se enumeraban algunas de las carencias habituales que hacen que la construcción de software no cumpla con las expectativas.
Puede resultar sorprendente que la mayoría de los participantes señalen la baja calidad de la especificación de funcionalidades como la principal carencia cuando a priori parecería que no es de las tareas más complejas.
Una vez más se produce una indefinición respecto a lo que se entiende por gestión de requisitos.
En algunos casos la definición de los requisitos sencillos o de bajo nivel la asumen los programadores.
En demasiados casos esto acaba suponiendo que los desarrolladores acaben asumiendo la gestión de los requisitos, lo cual genera múltiples problemas ya que es una sobrecarga adicional a sus responsabilidades efectivas, no suelen tener la responsabilidad formal para poder rechazar peticiones, no tienen la formación ni las herramientas para llevar a cabo esta labor, etc.
ALERTA: Una de las falacias más frecuentes introducidas por partes interesadas apelan a los "equipos de desarrollo autogestionados".
Un equipo autogestionado debe tener todas las habilidades necesarias para la gestión de todo el ciclo de vida del desarrollo y además tener medios y responsabilidad real y efectiva sobre su proceso.
Si intentamos enumerar las responsabilidades del equipo respecto a la gestión de requerimientos de menor a mayor responsabilidad podríamos identificar unos cuantos niveles.
A medida que subimos el nivel de responsabilidad claramente el tipo de tarea se aleja bastante de lo que se entiende como el rol de Desarrollador o Developer.
Podríamos decir que las tareas de nivel 2 o 3 son asumibles por los desarrolladores, pero más allá claramente pertenecen a otro rol.
Un equipo autoegestionado deberá tener roles mixtos para cubrir las tareas de nivel 4 y superiores:
Esta es una relación breve de responsabilidades sin la pretensión de ser exahustiva.
El objetivo es poner de manifiesto que la gestión de requerimientos puede ser una tarea en que el programador colabore o asuma ciertas responsabilidades, pero no es coherente ceder la responsabilidad total de tareas que pueden tener impacto económico o ir en contra de las políticas de sistemas, objetivos de negocio etc.
Como se comentaba en la encuesta "Prueba a construir un edificio de ingeniería civil sin planos".
Por tanto, volviendo a la calidad del software una incorrecta gestión de requisitos tiene un impacto mayor en la calidad de concordancia del producto final que otras cuestiones más técnicas.
Como responsable TIC.. haz números