Tesis de Magíster

Administración de Requerimientos para Empresas cuyo

negocio principal no es la construcción de software
Tesista: Oscar A. Schivo

Directores: M. Ing. Enrique Fernández, M. Ing. Paola Britos

1. Introducción
A medida que los sistemas de software se integran más y más a las actividades cotidianas y
críticas de las empresas, la decisión sobre que cambios incorporar a los mismos se vuelve
más y más importante. La alta dirección debe contar con la información necesaria para
poder decidir que requerimientos priorizar, entendiendo por requerimientos a todo pedido o
necesidad de cambio solicitado al área de sistemas.

Enfocándonos en empresas cuya rama de negocio no es el software, pero que tienen un área
de desarrollo y mantenimiento de software dentro de su estructura organizacional (en
adelante Sistemas o Tecnología), nos encontramos con que su capacidad para atender
pedidos de usuarios se ve ampliamente superada por la cantidad y magnitud de esos
pedidos. Esta situación hace necesario pasar por un delicado proceso de priorización antes
de comenzar con su ejecución. El resultado final del proceso de priorización será una lista
priorizada de los requerimientos que se incluirán en el Plan de Sistemas de la Organización.

2. Descripción del problema

El proceso de priorización, en el área de sistemas, no es en absoluto trivial como pude serlo
en actividades que no requieran mano de obra especializada. Especialmente en sistemas, la
gran cantidad de tecnologías utilizadas crea en los recursos diferentes especializaciones
para poder ganar productividad. Esto nos enfrenta a los siguientes problemas en el
momento de priorizar requerimientos:
a) Brindar a la alta gerencia de la Empresa la información necesaria para poder
priorizar en forma adecuada cada uno de los requerimientos presentados.
b) Detectar, por parte de tecnología, posibilidades de sinergia entre requerimientos:
requerimientos similares presentados por distintas áreas de negocio.
c) Poder determinar, por parte de tecnología, si se cuenta o no con recursos suficientes
para ejecutar los requerimientos que se quiere incluir dentro del Plan de Sistemas de
la Organización.
d) Detectar, por parte de tecnología, que no se estén cambiando simultáneamente
componentes comunes o de un mismo sistema.

Instituto Tecnológico de Buenos Aires (ITBA) Página 1 de 4

Magíster en Ingeniería del Software
Tesis de Magíster

3. Solución propuesta
El presente trabajo será desarrollado para una empresa de la rama de las finanzas,
concretamente un banco, pero los puntos y conceptos vertidos en él pueden ser fácilmente
adaptables a cualquier tipo de empresa.

Siguiendo las fases descriptas en la unidad 3 del Magíster, este trabajo se orienta
concretamente a la Fase III-Elaboración del Plan de TI/SI, cuyo objetivo es la elaboración
del plan de TI/SI para los próximos 3-5 años. Aquí es donde realmente comienzan las
actividades de planificación. Basándose en el resultado de la fase anterior y a la estrategia
de negocio se detectan y priorizan los cambios o requerimientos de sistemas.

La solución incluye dos partes:

1) La construcción de un modelo de datos que contemple todos los atributos necesarios
para realizar las actividades de ingreso, priorización, elaboración, y seguimiento de
los distintos requerimientos recibidos por el área de sistemas; especialmente
aquellos que compondrán el Plan de Sistemas. Este modelo debe permitir saber
cuantos y cuales de los requerimientos formarán el Plan de Sistemas, cuantos y
cuales quedan afuera, y hacer seguimiento de ambos grupos de requerimientos
2) Desarrollar un prototipo que ayude a los participantes de la reunión de priorización
de requerimientos en la elaboración del Plan de Sistemas. Este prototipo será un
sistema tradicional que permitirá trabajar dinámicamente con los requerimientos,
viendo el impacto de su inclusión o no en el Plan de Sistemas con respecto a la
capacidad del área de Sistemas. El mismo deberá mostrar cuando se ha alcanzado el
umbral de recursos humanos con que cuenta el área para responder a los pedidos de
los usuarios en un momento determinado del proyecto, mostrando en forma
dinámica el impacto en recursos de humanos. De esta forma se podrá ver cuando se
excede la capacidad de los recursos humanos, pudiéndose renegociar requerimientos
en cualquier momento del proyecto. Se mitiga con este prototipo principalmente los
ítems a) y c), brindando soporte (datos) para poder mitigar también los puntos b) y
d) citados en el punto 2.

No se incluye dentro de la solución la elaboración propia del Plan de Sistemas, por tratarse
de una actividad de planificación estándar una vez definidas las iniciativas a incluir. Para el
desarrollo de la solución se utilizará la metodología Métrica v3, se trabajará sobre un
entorno visual, preferiblemente Web para hacerlo fácilmente portable y ejecutable.

El objetivo de la solución propuesta es tratar de hallar una solución simple que ayude a
focalizar la discusión en los requerimientos más importantes, siguiendo las
recomendaciones de Peter Druker cuando dice que: “los ejecutivos eficaces no toman un
gran número de decisiones. Se concentran en lo que es importante” [DRU67]. Y por otro
lado, “…consideran que la habilidad de trabajar con un gran número de variables es un
síntoma de baja calidad intelectual…” [DRU67]. En consecuencia, la solución que se
construya deberá bajar la complejidad del problema original (bajar la cantidad de variables)
para posibilitar a los decisores poder priorizar rápidamente las iniciativas presentadas.

Instituto Tecnológico de Buenos Aires (ITBA) Página 2 de 4

Magíster en Ingeniería del Software
Tesis de Magíster

4. Usuarios del Proyecto

Como usuarios del proyecto estarán el Technology Head o Jefe de Tecnología de un banco
multinacional con sede en Argentina, los responsables de las Unidades de Desarrollo o
Development Units, los responsables de los equipos funcionales o Business
Representatives, y el responsable de la Oficina de Programación o Program Office.

5. Planificación del proyecto

Tarea Esfuerzo Duración
(horas)
Gestión de Configuración de sistemas 20 2 semanas
PSI Plan de Sistemas de Información N/A N/A
ARS Análisis de Requisitos del Sistema 40 2 semanas
EFS Especificación Funcional de Sistemas 40 2 semanas
DTS Diseño Técnico del Sistema 80 6 semanas
DCS Desarrollo de Componentes del Sistema 100 6 semanas
DPU Desarrollo de Procedimientos de Usuario 20 2 semana
PIA Pruebas, Implementación, y Aceptación del Sistema 40 2 semanas
Escritura de la Tesis de Magíster 80 2 semanas
TOTAL 420 24 semanas

6. Bibliografía
[BOH89] Boehm, Barry; Ross, Rony. “Theory-W Software Project Management:
Principles and Examples”, IEEE Transactions on Software Engineering, July
1989.
[BRO95] Brooks, Frederick P. Jr. The Mythical Man Month – Anniversary Edition,
Addison Wesley, 1995.
[CAM97] Campbel, Andrew; Marcus, Alexander. “Harvard Business Review – What’s
wrong with Strategy”, November-December, 1997, pp 42-51.
[DRU67] Druker, Meter F. “Harvard Business Review – Toma de decisiones”, Desuto,
Buenos Aires, Octubre 2004, pp 1-22.
[FEN96] Fenton, Norman E.; Pfleeger, Shari L. Software Metrics – A rigorous &
Practical Approach, International Thompson Computer Press, 2nd edition, 1996
[JAC99] Jacobson, Ivar; Booch, Grady; Rambough, James. The Unified Software
Development Process, Addison Wesley, 1999
[MCC96] McConnell, Steve. Rapid Development: Taming wild software schedules,
Microsoft Press, 1996.
[PGA99] Perez García, Alfredo. Material del Magíster, Unidad 3 – Planificación de
Sistemas de Información, 1999.
[PRE93] Pressman, Roger. Ingeniería del Software – Un enfoque práctico, Mc Graw
Hill, 3ra edición, 1993.

Instituto Tecnológico de Buenos Aires (ITBA) Página 3 de 4

Magíster en Ingeniería del Software
Tesis de Magíster

[SWE04] Software Engineering Body of Knowledge 2004 Version, IEEE Computer

Society, 2004
[WAT90] Watts, Humphrey. Managing the Software Process, SEI series in software
engineering, Addison Wesley, 1989.

NOTA: La bibliografía enunciada es la que hasta el momento se ha revisado. Durante el

desarrollo de la tesis podrán incluirse otros textos aun no consultados.

Instituto Tecnológico de Buenos Aires (ITBA) Página 4 de 4

Magíster en Ingeniería del Software