Está en la página 1de 4

¿Cómo encajar el diseño de un buen S.R.

S dentro de
los procesos descritos en el PMBOK?

Glosario

S.R.S - Software Requirement Specification. Especificación de requerimientos de


Software.
W.B.S. – Work Breakdown Structure – Estructura de tareas de descomposición en
cascada.

El problema.

Cuando una empresa se ve en la necesidad de desarrollar un nuevo software o incluso


desarrollar una gran modificación de un software que se posee, debe encarar una serie
de pasos que conllevan costo y tiempo.

El problema que se plantea, es que previo al desarrollo de un software dado, es


necesario cubrir una serie de etapas:

- Decisión de hacer o comprar


- Especificación de requerimientos (SRS).

De los pasos anteriores se puede lograr gran parte de lo que se indica en el PMBOK
como “Proceso de Planificación”.
¿Y cuál es el problema?, dirán algunos. Pues otros dirán que es muy difícil completar
las etapas de planificación sin tener un SRS.
Recordemos que el “Proceso de Planificación” consiste de los siguientes pasos:
- Planificación del alcance.
- Definición del alcance.
- Definición de actividades.
- Estimación del costo
- Elaboración del presupuesto.
- Planificación de Recursos Humanos
- Identificación de Riesgos
- Planificación de las respuestas ante los riesgos.
- Planificación de las compras y adquisiciones.

En muchos de estos sub-procesos, el WBS es una entrada necesaria y éste consiste en


una definición de tareas a realizar para consumar el proyecto. Y aquí surge el problema,
¿cómo podemos construir un WBS si no tenemos idea de las especificaciones del
sistema?.
Algunos pueden decir que es un proceso previo, pero como tal (y los que han realizado
algún SRS saben) conlleva un costo asociado y un tiempo necesario....que caería por
fuera del proyecto y en una organización orientada a proyectos, caería en una especie de
agujero o falta de presupuesto.
Otros pueden decir que se haga en la etapa de Planificación, pero si bien esto puede ser
cierto para algunos proyectos de software (lo más pequeños y simples), para la gran
mayoría, implicaría un costo muy grande en que se estaría incurriendo al mismo tiempo
en que se está elaborando la estimación de costos del propio proyecto!!. Para los que
están imbuidos en programación, incurriríamos en una especie de loop de presupuesto.

Dos aproximaciones posibles.

1) Existe una escuela que propone realizar la planificación inicial del proyecto en
base a experiencia previa (propia y/o de terceros) y realizar todos los entregables
de éste proceso con una óptica de perfectibilidad posterior. Es decir, todos los
documentos son perfectibles en la medida que el proyecto vaya avanzando y se
logre mayor profundidad en los procesos involucrados a la ejecución del mismo.
Este enfoque evidentemente tendrá un fuerte impacto en la Planificación e
Identificación de riesgos y en el control de cambios posterior.
La visión que viene subyacente es “mejor tener información incompleta que no
tenerla”.
2) Hay otra escuela que propone realizar estas tareas como un proyecto en sí,
previo al desarrollo del proyecto final. Es mucho más fácil y abordable realizar
estimaciones de costo y tiempo para tareas más simples, como es un análisis de
“Hacer o Comprar” y un SRS, que para todo un proyecto de desarrollo de final
imprevisible. Con el primer enfoque, somos de la opinión, que corremos el
riesgo de embarcarnos en un proyecto de final desconocido con costes en
permanente alza, tanto de tiempo como de dinero.
De ésta manera, al final este proyecto previo, los patrocinadores (stackeholders)
tendrán en sus manos gran parte de los valores necesarios para planificar con un
márgen mucho más pequeño de error. De esta forma, valores esenciales como
son los costos y el tiempo estimado, se realizarán con una base mucho más
firme.

Obviamente, de la redacción se desprende, proponemos el enfoque de la segunda


opción.

Sin embargo, hay quienes nos dirán que esto se podría resolver de forma iterativa. Si se
estructurase el proyecto en sucesivas fases, dividiendo el proyecto en partes, cada una
tendría su propia etapa de planificación y costos asociados, con lo cual la estimación
sería mucho más precisa.
Lo anterior puede ser verdad, pero la realidad es que los patrocinadores, no solo piden,
sino que exigen tener una idea bastante cercana al costo del total del proyecto antes de
embarcarse en una erogación que a “priori” nadie tiene idea. Con el enfoque de fases los
patrocinadores irían descubriendo la pintura por partes y solo al final, sumando, sabrían
cuánto costó el proyecto. Esto que sería como una inversión en cuotas y en muchos
casos, un enfoque de inversión muy acertado, es independiente de la necesidad de
información que tienen los patrocinadores. Ellos quieren, necesitan y exigen saber el
monto final y cuándo estará pronto. Luego, muy probablemente (con los tiempos y
números a la vista) estarán muy complacidos si esa inversión, que puede ser algo
intimidante, se puede erogar en plazos.
Por otro lado, el enfoque del punto (1) haría, en nuestra opinión, no solo un uso muy
extendido de los procesos de control de cambio, sino que se incurriría hasta en un abuso
de los mismos. La realidad sería que los patrocinadores se embarcarían en una aventura
de dinámica totalmente imprevisible y lo que sucedería a la larga, muy probablemente,
sería un desgaste en las relaciones. Jugar con ajustes permanentes es casi jugar con
fuego.
Los mecanismos de control de cambio son una parte muy importante en la gestión de un
proyecto, pero deben ser usados con mucho cuidado. Recordemos que todo proyecto
debe comenzar y terminar…en un tiempo razonable y normalmente: previsto.

¿Cómo sería entonces el proyecto?

Iniciación

El proceso de iniciación consistiría en el desarrollo de la sentencia preliminar de alcance


del proyecto, la cual variaría del proyecto original en el sentido que este sub-proyecto
previo, debe generar los entregables básicos para el proyecto de fondo.
O sea, que el alcance de este sub-proyecto previo sería la generación de los entregables
necesarios para el inicio del proyecto de fondo, y básicamente serían:
- Decisión de comprar o hacer.
- SRS.

Planificación.

La definición del alcance sería de alguna forma la definición del alcance del SRS, algo
fundamental para el proyecto de fondo. Si el alcance del SRS es reducido, así será el
alcance del proyecto de fondo.

La definición del actividades serían las necesarias para elaborar el SRS y el análisis de
hacer o comprar.

La estimación de costo y presupuesto se limitarían a las actividades mencionadas antes.

La planificación de recursos humanos, correspondería a la disponibilidad de los


recursos necesarios que el equipo que elabora el SRS entrevistará. Es necesario siempre
dar los necesarios tiempos y disponer que aquellas personas claves se hagan un espacio
en sus agendas para poder volcar sus necesidades en lo que será el SRS final.

La identificación y planificación de respuestas ante riesgos, será limitada a estos


procesos, pues es necesario que este subproyecto culmine en tiempo y forma para
abordar el de fondo.

La planificación de compras y adquisiciones se limitarán a los materiales y/o recursos


necesarios para la elaboración antedicha.
Ejecución, Monitoreo y Control

Ya, estos procesos discurren como cualquier proyecto.

La idea detrás del enfoque

El énfasis de este proyecto previo está en obtener la información más precisa y


necesaria para que los patrocinadores puedan resolver si se embarcan en el proyecto de
fondo o no. Es fundamental que la decisión de hacer o comprar se tome con el máximo
de análisis posible, evaluando todos los factores de riesgo que hay entrando por un
camino u otro. La recomendación final que se debe desprender de éste punto es clave
para el desarrollo del proyecto de fondo. Una cosa es encarar un proyecto de desarrollo
y otra muy diferente sería encarar un proyecto que se compre o desarrolle por una
tercera empresa que habría que controlar y monitorear.

Por otro lado, la profundidad del SRS debe ser lo más completa posible, de forma que
tanto para “hacer o comprar”, se tenga todo lo necesario. Aquellos que hagan o
suministren, deben saber bien lo que hay que hacer. Si se trata de un desarrollo que se
hará por parte de una tercera empresa, es necesario proveerla del máximo de detalle
para que pueda cotizar lo más ajustadamente posible.
Por otro lado, éste nivel de detalle es necesario para que este proyecto pueda elaborar
una estimación de costos y cronograma preliminar, de lo que sería el proyecto de fondo.
Ésta es la información vital para la toma de decisión (en la gran generalidad de casos).
Con esto a la vista, incluso se pueden realizar correcciones al alcance en la fase de
planificación del proyecto de fondo.

Se entiende entonces que los entregables de éste proyecto serán entradas para el
proyecto de fondo.
Si la recomendación fuese comprar, un entregable básico, serían las formas del llamado
para seleccionar la empresa que desarrolle o el paquete que se adquiera, la elaboración
de los lineamientos del contrato y demás.

Lo más importante de todo este proceso (los dos proyectos en sí), es que en todo
momento se ha llevado un correcto control de tiempos, costos y expectativas. Este
último ítem es de los más importantes para el final feliz de todo proyecto. Si hay
grandes expectativas (generadas en una fase muy temprana sin mucha información a la
vista), la posibilidad de desencanto, decepción y mal receptividad a la solución es de
muy alta probabilidad. Algo que hay que evitar a toda costa.

También es muy posible que el resultado final y a largo plazo de éste proyecto sea la no
realización del proyecto de fondo. Esto podría verse con una óptica negativa, pero no es
así. Lo importante y el éxito de éste proyecto se encuentra en que proveyó de la
suficiente información como para poder decidir no entrar en un proyecto