IEDGE – Proyectos de TI: Alcance


1.- Gestión del Alcance

En el post “IEDGE – Estándares para la Gestión de TI, segunda parte” describíamos las 9 áreas de conocimiento que define el PMBOK. De estas áreas de conocimiento hoy vamos a revisar la que quizás tiene un mayor y más importante papel en el éxito de los proyectos: la Gestión del Alcance.

Ilustración 1: Procesos en la Gestión del Alcance (PMBOK)

 Según un estudio realizado por Clive Finkelstein (uno de los padres de la ingeniería de la información) más de la mitad de los problemas que se presentan los proyectos de desarrollo de software, se deben a problemas relacionados recopilación de los requerimientos, muy por encima de problemas de diseño técnico o programación.

Ilustración 2: Origen de los Problemas en el Desarrollo de Software (Finkelstein)

Si nos fijamos bien, los mayores problemas se producen en las fases más tempranas de los proyectos, mientras que en la práctica los problemas en fases posteriores como la programación, no afectan de una forma tan significativa al proyecto, ya que son mucho más sencillos de resolver.

2.- La ingeniería de requisitos

La idea que tiene el ingeniero de software y la que tiene el usuario o cliente sobre el alcance puede estar muy alejada una de otra. Hay que ser capaces de compartir esa “imagen mental” que cada uno tiene sobre el sistema que hay que construir, algo que es especialmente complicado por el carácter inmaterial del software, que hace muy difícil describir cual debe ser el alcance que debe tener.

Para resolver en cierta medida esta problemática ha surgido lo que se ha venido en denominar la ingeniería de requisitos. Aunque seguramente llamar ingeniería a estas técnicas es un poco exagerado, da muestra del esfuerzo para ser capaces de fijar de forma clara y unívoca el alcance de los sistemas.

Existen una serie de técnicas formales para obtener y reflejar los requisitos, pero al fin y al cabo, dependerá de la capacidad y experiencia de los analistas el realizar las preguntas correctas e identificar las lagunas o problemas que puedan surgir. Por muchas reuniones que mantengamos, es difícil saber si nos hemos olvidado algo. Muchas veces cuando describimos los requisitos nos fijamos en las características más importantes o novedosas y olvidamos o no hacemos hincapié en otras menos relevantes. Un analista con experiencia es clave para obtener toda la información necesaria para saber el ámbito del proyecto.

3.- Los cambios en los requisitos

En muchos casos, y por mucho que nos esforcemos, los requisitos no van a poderse mantener fijos durante la vida del proyecto y van a surgir cambios de alcance. En ocasiones estos cambios van a ser fruto de elementos externos: cambios en el mercado, cambios en la legislación. Pero en otras muchas ocasiones van a ser fruto de especificaciones poco definidas o de nuevas ideas que van surgiendo a la vista de lo que se va desarrollado.

La existencia de los cambios debe aceptarse, no es posible ignorarlos. Pero los cambios deben gestionarse y no incorporarlos al alcance del proyecto sin más. Cada cambio debe ser valorado, analizando el impacto que tiene sobre el trabajo ya realizado, revisada la coherencia que tiene con el resto de requisitos del sistema, identificando el efecto que puede tener en coste y plazo.

Una vez realizado una correcta identificación de las consecuencias de un cambio de alcance, es cuando se puede proceder a su aprobación, a poder ser formal, que permita comunicar a todos los involucrados en el proyecto, que se ha producido un cambio y que por lo tanto, el alcance original del proyecto y posiblemente su coste y/o plazo se han visto afectados.

En siguiente post revisaremos la complejidad y problemática de la estimación de esfuerzo en los proyectos de TI y las soluciones que se han ido dando para aumentar la precisión en esta materia.

¡Quedo a la espera de sus comentarios!

Pablo Almunia

Profesor de Dirección de Sistemas y Tecnologías de la Información

Nota: aprender de una forma práctica y rápida como poner en marcha, desarrollar y controlar planes totalmente eficaces de Sistemas y Tecnologías de la información para pymes, les invitamos a que consulten la Especialidad Europea en Gestión de Sistemas y Tecnologías de la Información

* Los contenidos publicados en este post son responsabilidad exclusiva del Autor.

¡Pronto grandes sorpresas en Facebook y Twitter!:


Comentarios


  1. Fernando Pulido Soto
    comento el día 28 de septiembre a las 8:03 pm (#)


    Hola Pablo,
    Que blog tan interesante y bien explicado. Me gusto mucho el ejemplo del arquitecto y el cliente. Dfinitivamente muchas veces queremos algo y por no sabernos comunicar no obtenemos la respuesta deseada o no obtenemos respuesta. Y si no sabes decir tus requerimiento de manera clara es difícil que la otra persona losa adivine.
    Saludos
    Fernando


  2. Lorenzo Hombria
    comento el día 13 de octubre a las 9:22 pm (#)


    Hola Pablo:
    ¿Cuando nuestro proyecto tiene los requisitos bien definidos y cuando solo una coleccion de pantallas e informes (proyectos TI)? Me parece que sin conocimientos funcionales -además de la metodologia que estamos discutiendo- nos costara mucho distinguir lo uno de lo otro. ¿Hay forma de distinguirlo?
    Saludos.


Abrir Whatsapp
¿Cómo podemos ayudarte?
© IEDGE AI Business School
Soy Laura Rodríguez, del Dpto. de Admisiones de IEDGE AI Business School. ¿Cómo puedo ayudarte?