Pressman, R., Maxim, B. R. (2021). Conceptos de gestión de proyectos.

En Ingeniería de
software:un enfoque práctico (pp.490-503)(671p.)(9a ed). Ciudad de México : McGraw Hill
Interamericana. (C100526)
CAPÍTULO

24 CONCEPTOS DE GESTIÓN
DE PROYECTOS

En el prefacio de este libro sobre la gestión de proyectos de software, Meiler Page-Jones

[Pag85] comenta sobre los proyectos de software que no van por buen camino, "he obser-
vado con horror mientras ... los gerentes luchaban inútilmente a través de proyectos de
pesadilla, se retorcían por plazos de entrega imposibles o entregaban sistemas que indignaban
a sus usuarios y procedían a devorar enormes periodos de mantenimiento".

CONCEPTOS alcance del software .................... 497 partes interesadas .....................493

coordinación y comunicación ............. 496
descomposición del problema ............ 497
equipo ágil. ...........................495
equipo de software .................... .494
líderes de equipo ......................493
personas ............................. 491
prácticas imprescindibles. . . . . . . . . . . . . . . 502
principio W5HH ........................ 501
producto ............................. 491
proyecto ..............................492

ANÁLISIS BREVE

¿Qué es? Aunque muchos de nosotros (en nuestros
momentos más oscuros) adoptamos la perspectiva
de "gestión" de Dilbert,1 sigue siendo una actividad
muy necesaria cuando se crean sistemas y productos
basados en computadora. La gestión del proyecto im-
plica la planeación, monitoreo y coordinación de per-
sonas, procesos y eventos que ocurren a medida que
el software evoluciona de un concepto preliminar
hasta su despliegue operacional completo.
¿Quién lo hace? Todos "gestionan" en cierta medida,
pero el alcance de las actividades de gestión varía
entre las personas involucradas en un proyecto de
software.
¿Por qué es importante? Crear software de computa-
dora es una iniciativa compleja, en especial si involu-
cra a muchas personas trabajando durante un periodo
relativamente largo. Es por eso que los proyectos de
software necesitan gestionarse.
¿Cuáles son los pasos? Entender las cuatro P: perso-
nas, producto, proceso y proyecto. Las personas de-
ben organizarse para realizar el trabajo de software
de manera efectiva. Hay que entender el alcance del
producto y los requerimientos. Es necesario seleccio-
nar un proceso que sea apropiado para las personas
y el producto. Para planear el proyecto se deben estimar
el esfuerzo y el tiempo de calendario para realizar las
tareas del trabajo. Esto se aplica incluso para la gestión
de proyectos ágiles.
¿Qué es el producto de trabajo? Se crea un plan del
proyecto y evoluciona a medida que comienzan las
actividades del proyecto. El plan es un documento
viviente que define el proceso y las tareas a realizar,
las personas que realizarán el trabajo y los mecanis-
mos para evaluar riesgos, controlar el cambio y eva-
luar la calidad.
¿Cómo me aseguro de que lo hice bien? Nunca
estaremos completamente seguros de que el plan
del proyecto sea adecuado, sino hasta que el equipo
haya entregado un producto de alta calidad a tiempo
y dentro del presupuesto. Sin embargo, un líder de
equipo tiene éxito cuando anima a las personas del
software a trabajar en conjunto como un equipo efec-
tivo, enfocando su atención en las necesidades del
cliente y la calidad del producto.

Pruebe a buscar el término gestión (management) en el sitio web de Dilbert: http://dilbert.com/.

490
 CAPÍTULO 24 CONCEPTOS DE GESTIÓN DE PROYECTOS 491

Lo que Page-Jones describe son síntomas que resultan de una gama de problemas de
gestión y técnicos. Pero si se realizara una autopsia para cada proyecto, es muy probable
que se encuentre un tema consistente: la gestión del proyecto fue débil o inexistente.
En este capítulo y en los capítulos 25 al 27, presentaremos los conceptos clave que
conducen a una gestión efectiva de proyectos de software. Este capítulo considera los con-
ceptos y principios básicos de gestión de proyectos de software. El capítulo 25 analiza las
técnicas que se usan para estimar costos y crear calendarios realistas (pero flexibles). El
capítulo 26 presenta las actividades de gestión que conducen a un monitoreo, mitigación y
gestión efectivos del riesgo. El capítulo 27 considera los aspectos de soporte del producto
y analiza los temas de gestión que nos encontraremos al lidiar con el mantenimiento de
sistemas desplegados. Por último, el capítulo 28 analiza las técnicas para estudiar y mejorar
los procesos de ingeniería de software de su equipo.

24.1 EL ESPECTRO DE LA GESTIÓN

La gestión efectiva de proyectos de software se enfoca en las cuatro P: personas, producto,

proceso y proyecto. El orden no es arbitrario. El gerente que olvida que el trabajo de inge-
niería de software es un esfuerzo intensamente humano nunca tendrá éxito en la gestión de
proyectos. Un gerente que no fomente una comunicación integral con las partes interesadas
al principio de la evolución de un proyecto se arriesga a crear una solución elegante para
el problema equivocado. El gerente que pone poca atención al proceso corre el riesgo de
insertar métodos y herramientas técnicos competentes en un vacío. El gerente que comienza
a trabajar sin un plan sólido pone en peligro el éxito del proyecto. El que no está listo para
revisar el plan cuando surgen cambios está destinado al fracaso.

24.1.1 Las personas

Desde la década de 1960 se ha discutido acerca de cultivar personas de software motivadas
y altamente calificadas. De hecho, el "factor persona" es tan importante que el Instituto de
Ingeniería de Software desarrolló un Modelo de madurez de capacidades del personal ( CMM
de personas), como reconocimiento de que "toda organización debe mejorar de manera
continua su habilidad de atraer, desarrollar, motivar, organizar y conservar la fuerza laboral
necesaria para lograr sus objetivos de negocios estratégicos" [Cur09].
El modelo de madurez de capacidades del personal define las siguientes áreas de práctica
clave para las personas de software: dotación de personal, comunicación y coordinación,
ambiente laboral, gestión del rendimiento, capacitación, compensación, análisis y desarrollo
de competencias, desarrollo profesional, desarrollo de grupos de trabajo y de equipo/cultural,
y otros. Las organizaciones que obtienen altos niveles de madurez en el CMM del personal
tienen una mayor probabilidad de implementar prácticas efectivas de gestión de proyectos
de software.

24 .1. 2 El producto
Antes de poder planear un proyecto, se deben establecer los objetivos y el alcance del pro-
ducto, considerar soluciones alternativas e identificar las limitaciones técnicas y de gestión.
Sin esta información es imposible definir estimaciones razonables (y precisas) del costo de
una evaluación del riesgo efectiva, un desglose realista de tareas del proyecto o un calendario
del gestionable que proporcione una indicación significativa del progreso.
492 PARTE C UATRO G E STI ÓN D E PROYECTOS DE SO FT WARE

Como desarrollador de software, usted y otras partes interesadas deben reunirse para
definir los objetivos y el alcance del producto. En muchos casos, esta actividad comienza
como parte de la ingeniería del sistema o la ingeniería del proceso de negocios y continúa como
el primer paso en la ingeniería de requerimientos de software (capítulo 7). Los objetivos
identifican las metas en general para el producto (desde los puntos de vista de las partes
interesadas) sin considerar cómo se lograrán estas metas. A menudo estas adoptan la forma
de historias de usuario y casos de uso formales. El alcance identifica los datos principales,
las funciones y comportamientos que caracterizan el producto y, lo que es más importante,
los intentos de vincular estas características de una manera cuantitativa.
Una vez que se entienden los objetivos y el alcance del producto, se consideran solu-
ciones alternativas. Aunque se analizan muy pocos detalles, las alternativas permiten que
los gerentes y profesionales especializados seleccionen el "mejor" enfoque, dadas las res-
tricciones impuestas por los plazos de entrega, las restricciones en el presupuesto, la dispo-
nibilidad del personal, las interfaces técnicas y muchos otros factores.

24.1.3 El proceso
Un proceso de software (capítulos 2 al 4) provee el marco de trabajo a partir del cual puede
establecerse un plan detallado para el desarrollo de software. Hay un pequeño número de
actividades estructurales que se aplican a todos los proyectos de software, sin importar su
tamaño o complejidad. Incluso hasta los desarrolladores ágiles siguen un proceso adecuado
para el cambio (capítulo 3) para imponer cierta disciplina en su trabajo de ingeniería de
software. Varios conjuntos de tareas (tareas, hitos, productos de trabajo y puntos de asegu-
ramiento de calidad) permiten adaptar las actividades estructurales a las características del
proyecto de software y los requerimientos del equipo del proyecto. Por último, las actividades
sombrilla (como el aseguramiento de calidad del software, la administración de configuración
del software y la medición) se superponen al modelo del proceso. Las actividades sombrilla
son independientes de cualquier actividad estructural y ocurren durante el proceso.

24.1.4 El proyecto
Llevamos a cabo proyectos de software planeados y controlados por una razón principal: es
la única forma conocida de gestionar la complejidad. Y, aun así, los equipos de software
siguen batallando. En un estudio de 250 proyectos de software grandes entre 1998 y 2004,
Capers Janes [Jon04] encontró que "alrededor de 25 se consideraron exitosos en cuanto a
que lograron sus objetivos de calendario, costo y calidad. Aproximadamente 50 tu-
vieron retrasos o sobrecostos por debajo del 35, mientras que alrededor de 175 experimentaron
retrasos y sobrecostos considerables, o se dieron por terminados sin completarse". Aunque
la tasa de éxito para los proyectos de software actuales tal vez haya mejorado un poco, nuestra
tasa de fracasos de proyectos sigue siendo mucho más alta de lo que debería ser. 2
Para evitar el fracaso del proyecto, un gerente de proyectos de software y los ingenieros
de software que crean el producto deben evitar un conjunto de señales de advertencia co-
munes, entender los factores de éxito críticos que conducen a una buena gestión del proyecto
y desarrollar un enfoque coherente para planear, monitorear y controlar el proyecto [Gha 14].
En la sección 24.5 y en los siguientes capítulos analizaremos cada uno de estos temas.

2 Dadas las estadísticas, es razonable preguntar cómo sigue creciendo en forma exponencial el impacto de
las computadoras. Creemos que parte de Ja respuesta es que una cantidad considerable de estos proyec-
tos "fallidos" se concibieron mal en primer lugar. Los clientes pierden el interés con rapidez (porque lo
que solicitaron no era en realidad tan importante como pensaban) y se cancelan Jos proyectos.
 CAPÍTULO 24 CONCEPTOS DE GESTIÓN DE PROYECTOS 493

24.2 PERSONAS
Las personas crean software de computadora y los proyectos tienen éxito debido a que la
gente bien capacitada y motivada hace las cosas. Todos nosotros, desde los vicepresidentes
ejecutivos de ingeniería hasta el profesional especializado de nivel más bajo, comúnmente
damos por hecho a las personas. Los gerentes argumentan que las personas son primordiales,
pero algunas veces sus acciones contradicen sus palabras. En esta sección examinaremos
las partes interesadas que participan en el proceso del software y la forma en que se orga-
nizan para realizar una ingeniería de software efectiva.

24. 2.1 Las partes interesadas

El proceso de software (y todo proyecto de software) está compuesto de partes interesadas
que pueden clasificarse en una de cinco circunscripciones:
l. Gerentes ejecutivos (dueños del producto) que definen los aspectos de negocios que por
lo general tienen una influencia considerable en el proyecto.
2. Gerentes de proyecto (técnicos) (maestros scrum o líderes de equipo) que deben planear,
motivar, organizar y coordinar a los profesionales especializados que realizan el trabajo
de software.
3. Profesionales especializados que brindan las habilidades técnicas necesarias para idear
un producto o aplicación.
4. Clientes que especifican los requerimientos para el software que se va a idear y otras
partes interesadas que tienen un interés secundario en el resultado.
5. Usuarios finales que interactúan con el software una vez que se libera para usarse en
producción.
Todo proyecto de software está compuesto por personas que están dentro de esta taxonomía. 3
Para ser efectivo, el equipo del proyecto debe organizarse de una forma que maximice las
capacidades y competencias de cada persona. Y ese es el trabajo del líder del equipo.

24. 2. 2 Líderes de equipo

La gestión del proyecto es una actividad que requiere de tratar mucho con las personas y,
por esta razón, es común que los profesionales especializados competentes no sean buenos
líderes de equipo. Simplemente no tienen la mezcla correcta de habilidades interpersonales.
Y, aun así, como dice Edgemon: "por desgracia y con demasiada frecuencia, parece que los
individuos solo caen en un rol de gerente de proyectos y se vuelven gerentes de proyectos
por accidente" [Edg9 5]. A menudo el liderazgo compartido ayuda a los equipos a tener un
mejor desempeño, pero por lo general los líderes de equipo monopolizan la autoridad de
la toma de decisiones y no proveen a los miembros del equipo los niveles de autonomía que
necesitan para completar sus tareas [Hoel6].
Durante muchos años, James Kouzes ha estado escribiendo sobre el liderazgo efectivo
en varias áreas técnicas. Él enumera cinco prácticas que se encuentran en líderes de tecno-
logía ejemplares [Koul4]:
Modelar el camino. Los líderes deben practicar lo que predican. Demuestran com-
promiso con el equipo y el proyecto mediante el sacrificio compartido (por ejemplo,
ser el último en irse a casa cada noche o tomarse el tiempo para convertirse en un
experto en la aplicación de software).

3 Cuando se desarrollan WebApps, MobileApps o videojuegos, puede haber otras personas no técnicas
involucradas en la creación de contenido.
494 PARTE C UATRO G E STIÓ N DE PROYECTOS D E SO F TWARE

Inspirar y visión compartida. Los líderes reconocen que no pueden dirigir sin segui-
dores. Es importante motivar a los miembros del equipo para enlazar sus aspiraciones
personales con las metas del equipo. Esto implica involucrar a las partes interesadas
al principio del proceso de establecimiento de metas.
Desafiar el proceso. Los líderes deben tomar la iniciativa de buscar formas innova-
doras para mejorar su propio trabajo y el de sus equipos. Anime a los miembros del
equipo a experimentar y asumir riesgos, al ayudarles a generar pequeños éxitos fre-
cuentes mientras aprenden de sus fallas.
Permitir que otros actúen. Fomentar las habilidades colaborativas del equipo al
generar confianza y facilitar relaciones. Incrementar el sentido de competencia del
equipo por medio de compartir la toma de decisiones y el establecimiento de metas.
Alentar el corazón. Celebrar los logros de los individuos. Generar espíritu comuni-
tario (de equipo) al celebrar las metas y victorias compartidas, tanto dentro como
fuera del equipo.
Otra forma de ver a los líderes de proyectos exitosos podría ser sugerir que adopten un estilo
de gestión de solución de problemas. Un gerente de proyectos de software debería concen-
trarse en entender el problema a resolver, coordinar el flujo de ideas de las partes interesadas
y dejar que todos en el equipo sepan (mediante palabras y, lo que es mucho más importante,
mediante acciones) que la calidad comienza con cada uno de ellos y que se valoran sus
aportaciones y contribuciones.

24.2.3 El equipo de software

Hay casi tantas estructuras organizacionales para el desarrollo de software como organiza-
ciones que lo desarrollan. Para bien o para mal, la estructura organizacional no puede
modificarse con facilidad. Las preocupaciones por las consecuencias prácticas y políticas
del cambio organizacional no están dentro del alcance de la responsabilidad del gerente de
proyectos de software. Sin embargo, la organización de las personas directamente involu-
cradas en un nuevo proyecto de software está dentro del ámbito del gerente de proyectos.
La "mejor" estructura de equipo depende del estilo gerencial de su organización, el
número de personas que conformarán el equipo y sus niveles de habilidad, y la dificultad
del problema en general. Mantei [Man81] describe siete factores de proyectos que deben
considerarse a la hora de planear la estructura de los equipos de ingeniería de software:
(1) dificultad del problema a resolver, (2) "tamaño" del o de los programas resultantes en
líneas de código o puntos de función, (3) tiempo que el equipo permanecerá unido (tiempo
de vida del equipo), ( 4) grado en que el problema puede modularizarse, ( 5) calidad y con-
fiabilidad del sistema a crear, (6) rigidez de la fecha de entrega y (7) grado de sociabilidad
(comunicación) requerido para el proyecto.
Sin importar la organización del equipo, el objetivo de todo gerente de proyectos es
ayudar a crear un equipo que muestre cohesión. En su libro Peopleware, DeMarco y Lister
[DeM98] buscan equipos que se "consoliden"; y por ello escriben:
Un equipo consolidado es un grupo de personas tan estrechamente unidas que el todo
es mayor que la suma de sus partes ...
Una vez que un equipo comienza a consolidarse, la probabilidad de éxito aumenta
de manera considerable. El equipo puede volverse imparable, un gigante del éxito ... No
es necesario administrarlos de la forma tradicional y, ciertamente, no necesitan motiva-
ción. Tienen impulso.

DeMarco y Lister afirman que los miembros de equipos consolidados son mucho más
productivos y motivados que el promedio. Comparten una meta común, una cultura común
y, en muchos casos, un "sentido de élite" que los hace únicos.
CAPÍTULO 24 CONCEPTOS DE GESTIÓN DE PROYECTOS 495

Pero no todos los equipos se consolidan. De hecho, muchos sufren de lo que Jackman
[Jac98] denomina "toxicidad de equipo". Ella define cinco factores que "fomentan un
ambiente en equipo potencialmente tóxico": ( 1) una atmósfera de trabajo frenética, (2) gran
frustración que provoca fricción entre los miembros del equipo, (3) un proceso de software
"fragmentado o mal coordinado", ( 4) una definición imprecisa de los roles en el equipo de
software y (5) una "exposición continua y repetida al fracaso".
Para evitar un ambiente de trabajo frenético, el gerente del proyecto debe asegurarse
de que el equipo tenga acceso a toda la información requerida para hacer el trabajo y que
las principales metas y objetivos, una vez que se definan, no deberán modificarse a menos
que sea absolutamente necesario. Un equipo de software puede evitar la frustración si recibe
tanta responsabilidad por la toma de decisiones como sea posible. Para evitar un proceso
inapropiado (por ejemplo, tareas de trabajo innecesarias o pesadas, o productos de trabajo
mal elegidos) es necesario entender el producto que se va a crear y las personas que reali-
zarán el trabajo, además de permitir que el equipo seleccione el modelo del proceso. El
equipo mismo debe establecer sus propios mecanismos de rendición de cuentas (las revi-
siones técnicas 4 son una excelente forma para lograr esto) y definir una serie de enfoques
correctivos cuando un miembro del equipo deja de cumplir. Y, finalmente, la clave para
evitar una atmósfera de fracaso es establecer técnicas basadas en equipo para la retroali-
mentación y solución de problemas.
Muchas organizaciones de software defienden el desarrollo ágil de software (capítulo
3) como un antídoto para muchos de los problemas que han asolado el trabajo de los pro-
yectos de software. Para la revisión, la filosofía ágil fomenta la satisfacción del cliente y la
entrega incremental anticipada del software; equipos de proyecto pequeños y muy motivados;
métodos informales; productos de trabajo de ingeniería de software mínimos y una simpleza
en el desarrollo en general.
El equipo de proyecto pequeño y muy motivado, también conocido como equipo ágil,
adopta muchas de las características de los equipos de proyectos de software exitosos que
analizamos en la sección anterior y evita muchas de las toxinas que crean problemas [Hoel6].
Sin embargo, la filosofía ágil hace hincapié en la competencia individual (miembro del
equipo) junto con la colaboración grupal como factores de éxito críticos para el equipo.
Cockburn y Highsmith [Coco 1a] señalan esto al escribir:
Si las personas en el proyecto son lo bastante buenas, pueden usar casi cualquier proceso
y lograr su asignación. Si no son lo bastante buenas, ningún proceso reparará su incom-
petencia: "personal mata proceso" es una forma de decir esto. Sin embargo, la falta de
apoyo de los usuarios y ejecutivos puede terminar con un proyecto: "política mata perso-
nal". Un apoyo inadecuado puede evitar que incluso buenas personas logren el trabajo ...

Para hacer un uso efectivo de las competencias de cada miembro del equipo y fomentar una
colaboración efectiva durante un proyecto de software, los equipos ágiles son autoorganizados.
Muchos modelos de proceso ágiles (como Scrum) dan al equipo ágil una autonomía
considerable para tomar las decisiones gerenciales y técnicas del proyecto que se requieren
para hacer el trabajo. La planeación se mantiene al mínimo y se permite al equipo seleccionar
su propio enfoque (proceso, métodos, herramientas), lo que se limita solo mediante los
requerimientos del negocio y los estándares organizacionales. A medida que el proyecto
avanza, el equipo se autoorganiza para enfocar la competencia individual de una forma que
sea más benéfica para el proyecto en un punto determinado en el tiempo.
Para lograr esto, un equipo ágil podría realizar reuniones diarias para coordinar y
sincronizar el trabajo que deba realizarse para ese día. Con base en la información obtenida
durante estas reuniones, el equipo adapta su enfoque de una forma que logre un incremento

4 En el capítulo 16 analizamos las revisiones técnicas con detalle.

496 PART E C UATRO G E STIÓ N D E PROYECTOS D E SO FTWAR E

de trabajo. A medida que transcurre cada día, la autoorganización y colaboración continuas

hacen que el equipo obtenga un incremento de software terminado.

24.2.4 Temas de coordinación y comunicación

Hay muchas razones por las que los proyectos de software se meten en problemas. La escala
de muchos esfuerzos de desarrollo es grande, conduce a la complejidad, confusión y difi-
cultades considerables para coordinar los miembros del equipo. La incertidumbre es común,
lo que resulta en un flujo continuo de cambios que ajustan al equipo del proyecto. La inter-
operabilidad se ha vuelto una característica clave de muchos sistemas. El nuevo software
debe comunicarse con el software existente y ajustarse a las restricciones predefinidas im-
puestas por el sistema o producto.
Estas características del software moderno (escala, incertidumbre e interoperabilidad)
son hechos de la vida. Para lidiar con ellas de manera efectiva, es necesario establecer
métodos efectivos para coordinar a las personas que realizan el trabajo. Para lograr esto, se
deben establecer mecanismos para la comunicación formal e informal entre los miembros del
equipo y entre varios equipos. La comunicación formal se logra a través de "la comunicación
escrita, reuniones estructuradas y otros canales de comunicación relativamente no interac-
tivos e impersonales" [Kra95]. La comunicación informal es más personal. Los miembros
de un equipo de software comparten ideas sobre la marcha, piden ayuda a medida que
surgen los problemas e interactúan entre sí a diario.

CASASEGl 1RA

~ Estructura del equipo

~ El escenario: Oficina de Doug Miller,
antes de la instalación del proyecto de
software CasaSegura.
Los participantes: Doug Miller, gerente del equipo de
ingeniería de software de CasaSegura; Vinod Raman,
Jamie Lazar y otros miembros del equipo de ingenie-
ría de software del producto.
La conversación:
Doug: ¿Tuvieron oportunidad de ver la información
preliminar sobre CasaSegura que marketing preparó?
Vinod (asintiendo y viendo a sus compañeros): Sí.
Pero tenemos varias preguntas.
Doug: Hagamos eso a un lado por un momento. Me
gustaría hablar sobre cómo estructuraremos el equi-
po, quién será responsable de qué ...
Jamie: En verdad me gusta la filosofía ágil, Doug.
Creo que deberíamos ser un equipo autoorganizado.
Vinod: Estoy de acuerdo. Dados el estrecho plazo de
entrega y la incertidumbre, y puesto que todos somos
realmente competentes (risas], esa parece la opción
correcta.
Doug: Me parece bien, pero ya saben el procedimiento.
Jamie (sonriendo y hablando como si fuera a recitar
algo): Tomamos decisiones tácticas, acerca de quién
hace qué y cuándo, pero es nuestra responsabilidad
sacar el producto a tiempo.
Vinod: Y con calidad.
Doug: Exacto. Pero recuerden que hay limitaciones.
Marketing define los incrementos de software que se
van a producir; deben consultarlo con nosotros, por
supuesto.
Jamie: ¿Y?
Doug: Y vamos a usar UML como nuestro enfoque de
modelado.
Vinod: Pero tenemos que mantener la documentación
extraña al mínimo.
Doug: ¿Quién será mi enlace?
Jamie: Decidimos que Vinod sea el líder de tecnología;
es el más experimentado, así que Vinod será tu enlace,
pero puedes hablar con cualquiera de nosotros.
Doug (riendo): No se preocupen. Lo haré.
 CAPÍTULO 24 CONCEPTOS DE GESTIÓN DE PROYECTOS 497

24.3 PRODUCTO
Un gerente de proyectos de software se enfrenta con un dilema desde el principio de un
proyecto de software. Se requieren las estimaciones cuantitativas y un plan organizado, pero
no hay información sólida disponible. Un análisis detallado de los requerimientos de software
proporcionaría la información necesaria para las estimaciones, pero el análisis por lo general
tarda semanas o incluso meses en completarse. Peor aún, los requerimientos tal vez sean
fluidos y cambien con regularidad a medida que el proyecto avanza. De todas formas, ¡se
necesita un plan ahora!
Nos guste o no, debemos examinar el producto y el problema que pretende resolver al
principio del proyecto. Como mínimo se debe establecer y vincular el alcance del producto.

24. 3 .1 Alcance del software

La primera actividad de gestión de proyectos de software es la determinación del alcance
del software. Para definir el alcance es necesario responder las siguientes preguntas:

Contexto. ¿Cómo es que el software a crear se adapta a un contexto de sistema,

producto o negocio más grande y qué restricciones se imponen como resultado del
contexto?

Objetivos de información. ¿Qué objetos de datos visibles por el cliente se producen

como resultados del software? ¿Qué objetos de datos se requieren como entrada?

Función y rendimiento. ¿Qué función realiza el software para transformar los datos
de entrada en salida? ¿Hay que lidiar con características de rendimiento especiales?

El alcance de un proyecto de software debe ser claro y comprensible en los niveles de gestión
y técnico. Se debe vincular una declaración del alcance del software. Esto significa que se
deben indicar los datos cuantitativos (como el número de usuarios simultáneos, el tamaño
de la lista de correo, el tiempo de respuesta máximo permitido) de manera explícita, señalar
las restricciones y/o limitaciones (por ejemplo, el costo del producto restringe el tamaño de
la memoria) y describir los factores mitigantes (por ejemplo, los algoritmos deseados se
entienden bien y están disponibles en Java). Incluso en las situaciones más fluidas, es nece-
sario tener en cuenta el número de prototipos y establecer el alcance del primer prototipo.

24.3.2 Descomposición del problema

La descomposición del problema, conocida algunas veces como particionamiento o elabo-
ración del problema, es una actividad fundamental del análisis de los requerimientos de
software (capítulos 7 y 8). Durante la actividad de definición del alcance, no se intenta
descomponer el problema en su totalidad. Más bien, la descomposición se aplica en dos
áreas principales: (1) la funcionalidad y el contenido (información) que deben entregarse
y (2) el proceso que se usará para entregar estos elementos. Esto puede lograrse mediante
el uso de una lista de funciones, mediante casos de uso o, para el trabajo ágil, con historias
de usuario.
Los seres humanos tendemos a aplicar una estrategia de "divide y vencerás" cuando
nos enfrentamos a un problema complejo. En resumen, un problema complejo se divide en
problemas más pequeños que sean más gestionables. Esta es la estrategia que se aplica al
comenzar la planeación del proyecto. Las funciones de software, que se describen en la
declaración del alcance, se evalúan y refinan para proveer un mayor detalle antes de comenzar
la estimación (capítulo 25). Puesto que tanto las estimaciones de costo como del calendario
498 PARTE CUATRO G E STIÓN DE PROYECTOS DE SOFTWARE

están orientadas a la funcionalidad, por lo general es conveniente cierto grado de descom-

posición. De manera similar, el contenido principal o los objetos de datos se descomponen
en las partes que los constituyen, lo que proporciona un entendimiento razonable de la
información que producirá el software.

24.4 PROCESO
Las actividades estructurales (capítulo 1) que caracterizan el proceso del software se aplican
a todos los proyectos. El problema es seleccionar el modelo del proceso que sea apropiado
para el software que el equipo de su proyecto ideará. El modelo del proceso recomendado
en el capítulo 4 puede ser un buen punto de partida para que lo consideren muchos equipos
de proyectos.
Su equipo debe decidir qué modelo del proceso es más apropiado para ( 1) los clientes
que solicitaron el producto y las personas que realizarán el trabajo, (2) las características
del producto en sí y (3) el ambiente del proyecto en el que trabaja el equipo de software.
Cuando se selecciona un modelo del proceso, el equipo define a continuación un plan
preliminar del proyecto con base en el conjunto de actividades estructurales del proceso.
Una vez que se establece el plan preliminar, comienza la descomposición del proceso. Es
decir, se debe crear un plan completo que refleje las tareas de trabajo requeridas para con-
formar las actividades estructurales. En las siguientes secciones exploraremos con brevedad
estas actividades y en el capítulo 25 presentaremos una perspectiva más detallada.

24.4.1 Unión del producto y el proceso

La planeación del proyecto comienza con la unión del producto y el proceso. Cada función
que su equipo ideará debe pasar por el conjunto de actividades estructurales que se hayan
definido para su organización de software. El marco de trabajo del proceso establece un
esqueleto para la planeación del proyecto. Se adapta mediante la asignación de un conjunto
de tareas que sea apropiado. Suponga que la organización adoptó las actividades estructu-
rales genéricas (comunicación, planeación, modelado, construcción y despliegue) que ana-
lizamos en el capítulo 1.
Los miembros del equipo que trabajen en una función del producto aplicarán cada una
de las actividades estructurales a este. En esencia, se crea una matriz similar a la que se
muestra en la figura 24.1. Cada función principal del producto (la figura enumera las fun-
ciones para el software de la aplicación de ejercicio que analizamos en el capítulo 2) o historia
de usuario se enumera en la columna izquierda. Las actividades estructurales se enumeran en
la fila superior. Las tareas de ingeniería de software (para cada actividad estructural) se intro-
ducen en la siguiente fila. 5 El trabajo del gerente del proyecto (y de otros miembros del equipo)
es estimar los requerimientos de recursos para cada celda de la matriz, las fechas inicial y final
para las tareas asociadas con cada celda y los productos de trabajo que se generarán como
consecuencia de cada tarea. En el capítulo 25 consideraremos estas actividades.

24.4.2 Descomposición del proceso

Un equipo de software debe tener un grado considerable de flexibilidad para elegir el modelo
del proceso de software que sea el más adecuado para el proyecto, y las tareas de ingeniería

5 Cabe señalar que se deben adaptar las tareas de trabajo a las necesidades específicas del proyecto, con
base en varios criterios de adaptación.
 CAPÍTULO 24 CONCEPTOS DE GESTIÓN DE PROYECTOS 499

• i'4'M·*& $. Unión del problema y el proceso

ACTIVIDADES ESTRUCTURALES
COMUNES DEL PROCESO

Tareas de ingeniería de software

/¡'/ 1¡ ·~
~
;, ,f
tr
!if
cr;
~
'As'
f / .cJl '/J11
;::¡
~

Q
~
·IR
~

\
Función del producto
Sincronizar teléfono con dispositivo
Mostrar datos en IU de teléfono
',
Establecer metas personales •
Almacenar datos en nube 1

,
Permitir que el usuario modifique IU del teléfono
Integrar medios sociales
Establecer metas con amigos
~
\
\
t\

de software que conformen el modelo del proceso una vez que se seleccione. Un proyecto
relativamente pequeño que sea similar a esfuerzos anteriores podría realizarse mejor me-
diante un enfoque de un solo sprint. Si el plazo de entrega es tan ajustado que no pueda
entregarse de manera razonable la funcionalidad completa, podría ser mejor usar una es-
trategia incremental. De manera similar, los proyectos con otras características (como:
requerimientos inciertos, tecnología de vanguardia, clientes difíciles o el potencial de reu-
tilización de componentes) conducirán a la selección de otros modelos del proceso. 6
Una vez elegido el modelo del proceso, se adapta a este el marco de trabajo del proceso.
En cada caso puede usarse el marco de trabajo del proceso genérico que vimos antes. Fun-
ciona para los modelos lineales, los modelos iterativos e incrementales, para los modelos
evolutivos e incluso para los de ensamble de componentes o concurrentes. El marco de
trabajo del proceso es invariable y sirve como base para todo el trabajo que realiza una
organización de software.
Pero las tareas de trabajo actuales varían. La descomposición del proceso comienza
cuando el gerente del proyecto pregunta: "¿cómo realizamos esta actividad estructural?".
Por ejemplo, un proyecto pequeño y relativamente simple podría requerir las siguientes
tareas de trabajo para la actividad de comunicación:

l. Desarrollar una lista de temas de aclaración.

2. Reunirse con las partes interesadas para lidiar con los temas de aclaración.

3. Desarrollar en forma conjunta una declaración del alcance mediante la enumeración

de las historias de usuario.

4. Revisar la declaración del alcance con todos los involucrados y determinar la impor-
tancia de cada historia de usuario para las partes interesadas.

5. Modificar la declaración del alcance según se requiera.

6 Recuerde que las características del proyecto tienen una fuerte influencia sobre la estructura del equipo
de software (sección 24.2.3).
500 PARTE C UATRO G E STIÓN D E PROYECTOS D E SO FTWAR E

Estos eventos podrían ocurrir durante un periodo de menos de 48 horas. Representan una
descomposición del proceso adecuada para el proyecto pequeño y relativamente simple.
Ahora consideremos un proyecto más complejo, con un alcance más amplio y un im-
pacto de negocios considerable. Dicho proyecto podría requerir las siguientes tareas de
trabajo para la comunicación:

l. Revisar la solicitud del cliente.

2. Planear y programar una reunión formal con todas las partes interesadas.
3. Realizar una investigación para especificar la solución propuesta y los enfoques existentes.
4. Preparar un "documento de trabajo" y una agenda para la reunión formal.
5. Realizar la reunión.
6. Desarrollar en forma conjunta miniespecificaciones que reflejen las características de los
datos, funciones y comportamiento del software. Para hacer esto, por lo general se desa-
rrollan casos de uso que describan el software desde el punto de vista del usuario.
7. Revisar cada miniespecificación o caso de uso para asegurar que sea correcta, consis-
tente y carezca de ambigüedades.
8. Ensamblar las miniespecificaciones en un documento de alcance.
9. Revisar la colección de casos de uso con todos los involucrados y determinar su im-
portancia relativa para todas las partes interesadas.
10. Modificar el documento de alcance o los casos de uso, según se requiera.

Ambos proyectos realizan la actividad estructural que conocemos como comunicación, pero
el equipo del primer proyecto realiza la mitad de las tareas de trabajo de ingeniería de software
que realiza el segundo.

24.5 PROYECTO
Para gestionar un proyecto de software exitoso, debemos entender lo que puede salir mal para
poder evitar los problemas. En un excelente artículo sobre proyectos de software, John Reel
[Ree99] define las señales que indican que un proyecto de sistemas de información está en
peligro. En algunos casos, las personas del software no entienden las necesidades de sus clientes.
Esto conduce a un proyecto con un alcance mal definido. En otros proyectos, los cambios
se gestionan de manera deficiente. Algunas veces la tecnología elegida o las necesidades de
negocios cambian y se pierde el patrocinio de la gerencia. Esta puede fijar plazos de entrega
poco realistas o tal vez los usuarios finales se resistan al nuevo sistema. Existen casos en
los que el equipo del proyecto simplemente no tiene las habilidades requeridas. Y, por último,
hay desarrolladores que parecen nunca aprender de sus errores.
Los profesionales de la industria hastiados se refieren con frecuencia a la "regla 90-90"
cuando discuten sobre proyectos de software especialmente difíciles: el primer 90% de un
sistema absorbe el 90% del esfuerzo y tiempo asignados. El último 10% requiere otro 90%
del esfuerzo y tiempo asignados [Zah94]. Las semillas que conducen a la regla del 90-90 están
contenidas en las señales que se indican en el párrafo anterior.
¡Pero basta de negatividad! ¿Cuáles son las características de los proyectos de software
exitosos? Ghazi [Gha 14] y sus colegas señalan varias características presentes en los pro-
yectos de software exitosos y que también se encuentran en los modelos de procesos bien
diseñados.
 CAPÍTULO 24 CONCEPTOS DE GESTIÓN DE PROYECTOS 501

l. Requerimientos claros y bien entendidos, aceptados por todas las partes interesadas.
2. Participación activa y continua de los usuarios durante el proceso de desarrollo.

3. Un gerente del proyecto con las habilidades de liderazgo requeridas, que sea capaz de
compartir la visión del proyecto con el equipo.

4. Un plan y calendario del proyecto desarrollados con la participación de las partes in-
teresadas, para lograr las metas del usuario.
5. Miembros del equipo experimentados y comprometidos.
6. Miembros del equipo de desarrollo con personalidades compatibles, que disfruten
trabajar en un ambiente colaborativo.
7. Estimaciones realistas de calendario y presupuesto, que se vigilen y mantengan.

8. Necesidades del cliente que se entiendan y cumplan.

9. Miembros del equipo que experimenten un alto grado de satisfacción laboral.

10. Un producto funcional que refleje el alcance y la calidad deseados.

24.6 EL PRINCIPIO W5 HH
En un excelente artículo sobre el proceso y los proyectos de software, Barry Boehm [Boe96]
señala: "se requiere un principio de organización que se enfoque en proveer planes [de
proyectos] simples para proyectos simples". Boehm sugiere un enfoque que aborde los ob-
jetivos del proyecto, hitos y calendarios, responsabilidades, enfoques gerencial y técnico, y
recursos requeridos. Lo llama el Principio W 5HH, después de una serie de preguntas que
condujeron a una definición de características clave de un proyecto y el plan del proyecto
resultante:

¿Por qué (Why) se desarrollará el sistema? Todas las partes interesadas deben evaluar
la validez de los motivos de negocios para el trabajo de software. ¿Justifica el propósito de
negocios la inversión de personas, tiempo y dinero?

¿Qué (What) se va a hacer? Se define el conjunto de tareas requeridas para el proyecto.

¿Cuándo (When) se hará? El equipo establece un calendario del proyecto, para lo cual
identifica cuándo se van a realizar las tareas del proyecto y cuándo deben alcanzarse los hitos.

¿Quién (Who) es responsable de cada función? Se definen el rol y la responsabilidad

de cada miembro del equipo de software.

¿En dónde (Where) se localizan en la organización? No todos los roles y responsabi-

lidades residen con los profesionales especializados de software. El cliente, los usuarios y
otras partes interesadas también tienen responsabilidades.

¿Cómo (How) se realizará el trabajo en los sentidos técnico y gerencial? Una vez que
se establece el alcance del producto, es necesario definir las estrategias gerencial y técnica
para el proyecto.

¿Cuánto (How much) se necesita de cada recurso? La respuesta a esta pregunta se

deriva mediante el desarrollo de estimaciones (capítulo 25) basadas en las respuestas a las
preguntas anteriores.
502 PARTE C UATRO G ESTIÓN D E PROYECTOS D E SO FTWARE

El principio W 5HH de Boehm se aplica sin importar el tamaño o la complejidad de un

proyecto de software. Las preguntas señaladas le proporcionan a usted y su equipo un es-
quema de planeación excelente.

24. 7 PRÁCTICAS IMPRESCINDIBLES

El Concilio Airlie 7 desarrolló una lista de "prácticas de software imprescindibles para la
gestión basada en el rendimiento". Estas prácticas "se utilizan y consideran imprescindibles
en proyectos y organizaciones de software altamente exitosos, cuyo rendimiento 'final' sea
sistemáticamente mucho mejor que los promedios en la industria" [Air99]. Estas prácticas
aún se aplican para la gestión basada en el rendimiento de todos los proyectos de software
[All14 ].
Las prácticas imprescindibles 8 son: gestión de proyectos basada en métricas (capítulo
23), estimación empírica de costo y calendario (capítulo 25), seguimiento del valor obtenido
(capítulo 25), seguimiento de defectos contra objetivos de calidad (capítulos 19 al 21) y
gestión orientada en las personas (capítulo 24 ). Cada una de estas prácticas imprescindibles
se aborda en la cuarta parte de este libro.

24.8 RESUMEN
La gestión de proyectos de software es una actividad sombrilla dentro de la ingeniería de
software. Comienza antes de iniciar cualquier actividad técnica y continúa durante el mo-
delado, la construcción y el despliegue del software de computadora.
Hay cuatro P que tienen una influencia considerable en la gestión de proyectos de
software: personas, producto, proceso y proyecto. Las personas deben organizarse en equipos
efectivos, motivados para realizar trabajo de software de alta calidad y coordinarse para
lograr una comunicación efectiva. Es importante comunicar los requerimientos del producto
del cliente al desarrollador, particionarlos (descomponerlos) en las partes que los constituyen
y posicionarlos para el trabajo del equipo de software. Es necesario adaptar el proceso a las
personas y el problema. Se selecciona un marco de trabajo de proceso común, se aplica
un paradigma de ingeniería de software apropiado y se elige un conjunto de tareas de trabajo
para lograr el objetivo. Por último, se debe organizar el proyecto de una forma que permita
que el equipo de software tenga éxito.
El elemento fundamental en todos los proyectos de software lo componen las personas.
Los ingenieros de software pueden organizarse en varias estructuras de equipo diferentes,
que varían desde las jerarquías de control tradicionales hasta los equipos de "paradigma
abierto". Puede aplicarse una variedad de técnicas de coordinación y comunicación para
apoyar el trabajo del equipo. En general, las revisiones técnicas y la comunicación informal
de persona a persona tienen el mayor valor para los profesionales especializados.
La actividad de gestión de proyectos incorpora medición y métricas, estimación y
programación de calendarios, análisis de riesgos, seguimiento y control. En los siguientes
capítulos consideraremos cada uno de estos temas.

7 El Concilio Airlie estaba compuesto de un equipo de expertos de ingeniería de software contratados

por el Departamento de Defensa de Estados Unidos para ayudar a desarrollar los lineamientos para
las prácticas recomendadas en la gestión de proyectos de software e ingeniería de software.
s Aquí solo se señalan las prácticas imprescindibles asociadas con la "integridad del proyecto".
CAPÍTULO 24 CONCEPTOS DE GESTIÓN DE PROYECTOS 503

PROBLEMAS Y PUNTOS A PONDERAR

24.1. Con base en la información contenida en este capítulo y su propia experiencia, desarrolle "10
mandamientos" para facultar a los ingenieros de software. Es decir, haga una lista de 10 lineamientos
que produzcan personas de software que trabajen a todo su potencial.

24.2. El Modelo de madurez de capacidades del personal (CMM de personas) del Instituto de Inge-
niería de Software adopta una perspectiva organizada de las "áreas de práctica clave" (KPA, por sus
siglas en inglés) que cultivan buenas personas de software. Su instructor le asignará un KPA para su
análisis y resumen.

24.3. Describa tres situaciones reales en donde el cliente y el usuario final sean la misma persona.
Describa tres situaciones en las que sean diferentes.

24.4. Las decisiones que tome la gerencia ejecutiva pueden tener un impacto considerable sobre la
efectividad de un equipo de ingeniería de software. Proporcione cinco ejemplos para ilustrar que esto
es cierto.

24.5. Lo acaban de nombrar gerente de proyectos dentro de una organización de sistemas de

información. Su trabajo es crear una aplicación bastante similar a otras que su equipo ha creado,
aunque esta es más grande y compleja. El cliente documentó de manera minuciosa los requerimientos.
¿Qué estructura de equipo elegiría y por qué? ¿Qué modelo o modelos del proceso de software
elegiría y por qué?

24.6. Lo acaban de nombrar gerente de proyectos para una pequeña empresa de productos de
software. Su trabajo es crear un producto de vanguardia que combine el hardware de realidad virtual
con software de vanguardia. Debido a que la competencia para el mercado de entretenimiento en el
hogar es intensa, hay una presión considerable para terminar el trabajo. ¿Qué estructura de equipo
elegiría y por qué? ¿Qué modelo o modelos del proceso de software elegiría y por qué?

24. 7. Lo acaban de nombrar gerente de proyectos para una empresa importante de productos
de software. Su trabajo es gestionar el desarrollo de la versión de próxima generación de su aplica-
ción de ejercicio móvil, que es muy popular. Puesto que la competencia es intensa, se han establecido
y anunciado plazos de entrega ajustados. ¿Qué estructura de equipo elegiría y por qué? ¿Qué modelo
o modelos del proceso de software elegiría y por qué?

24.8. Lo acaban de nombrar gerente de proyectos para una empresa que da servicio al mundo de la
ingeniería genética. Su trabajo es gestionar el desarrollo de un nuevo producto de software que acelerará
el ritmo de la tipificación de genes. El trabajo está orientado a investigación y desarrollo (l+D), pero
la meta es generar un producto dentro del próximo año. ¿Qué estructura de equipo elegiría y por qué?
¿Qué modelo o modelos del proceso de software elegiría y por qué?

24.9. Le pidieron que desarrollara una aplicación pequeña que analice cada curso ofrecido por una
universidad y reporte la calificación promedio obtenida en el curso (para un periodo dado). Escriba
informando el alcance que vincule este problema.

24.10. ¿Cuál, en su opinión, es el aspecto más importante de la gestión de personas para un proyecto
de software?

Elemento de diseño: lupa del icono Vista rápida: © Roger Pressman