PARTE

II
GESTION DE PROYECTOS
DE SOFTWARE

: U n enfoque Práctico, estudiamos

nificar; organizar, supervisar
vienen a conti-

ema durante un
;Provecto de software?
1 r r

* ¿Queson1 oftware y cómo pueden emplearse para gestio-

nar un proyecto e y el proceso del software?
¿Cómo genera e software estimaciones fiables del esfuerzo,
costes y duración del proyecto?

35
 CAPÍTULO

3 CONCEPTOS SOBRE GESTION

DE PROYECTOS

E N el prefacio de su libro sobre gestión de proyectos de software, Meiler Page-Jones

[PAG85] dice una frase que pueden corroborar muchos asesores de ingeniería del soft-
ware:
He visitado docenas de empresas, buenas y malas, y he observado a muchos administradores de proce-
so de datos, también buenos y malos. Frecuentemente, he visto con horror cómo estos administradores lucha-
ban inútilmente contra proyectos de pesadilla, sufriendo por fechas límite imposibles de cumplir, o que
entregaban sistemas que decepcionaban a sus usuarios y que devoraban ingentes cantidades de horas de
mantenimiento.
Lo que describe Page-Jones son síntomas que resultan de una serie de problemas técnicos y
de gestión. Sin embargo, si se hiciera una autopsia de cada proyecto, es muy probable que se
encontrara un denominador común constante: una débil gestión.
En este capítulo y en los seis que siguen consideraremos los conceptos clave que llevan a
una gestión efectiva de proyectos de software. Este capítulo trata conceptos y principios bási-
cos sobre gestión de proyectos de software. El Capítulo 4 presenta las métricas del proyecto y
del proceso, la base para una toma de decisiones de gestión efectivas. Las técnicas que se emple-
an para estimar los costes y requisitos de recursos y poder establecer un plan efectivo del pro-
yecto se estudian en el Capítulo 5. Las actividades de gestión que llevan a una correcta
supervisión, reducción y gestión del riesgo se presentan en el Capítulo 6. El Capítulo 7 estudia
las actividades necesarias para definir las tareas de un proyecto y establecer una programación
del proyecto realista. Finalmente, los Capítulos 8 y 9 consideran técnicas para asegurar la cali-
dad a medida que se dirige un proyecto y el control de los cambios a lo largo de la vida de una
aplicación.

tomamos la visión de
=gestión*, falta una software de com
necesaria cuando se

plan define el proceso y las tareas a

y control del perso realizar el personal que realizcná el tra-
d e los eventos que bajo y los mecanismos para evaluar los

&Cómopuedo d a r seguro de que

lo he hecho correctamente?Nun-
estás completamente seguro d e que

nierode software gestiona s u activi- el alcance del producto y los requisi- alta calidad dentro del tiempo y del
dades de1 d h a dial Planificahdo, tos. Debe seleccionarse el proceso presupuesto. Sin embargo, un gestor
SuPWisandQ Y controlando las tareas adecuado para el personal, y el pro- d e proyectos hace lo correcto cuando
técnicas. Los gestores d to Pla- ducto. El proyecto debe planificarse estimula a l personal para trabajar jun-
nifkan, supemisan Y c eltra- estimando el esfuerzo y el tiempo tos como un equipo efectivo, centran-
bajo de un equipo d e ingenieros de para cumplir l a s tareas; definiendo do su atención en las necesidades del
software. LOS gestores e x P e ~ O S C ~ r d i - los productos del trabajo, estable- cliente y en la calidad del producto.

37
INGENlERfA DEL SOFTWARE. U N ENFOQUE PRÁCTICO

La gestión eficaz de un proyecto de software se cen- 3.1.2. Producto

tra en las cuatro P’s: personal, producto, proceso y Antes de poder planificar un proyecto, se deberían esta-
proyecto. El orden no es arbitrario. El gestor que se blecer los objetivos y el ámbito del producto‘, se debe-
olvida de que el trabajo de ingeniería del software es rían considerar soluciones alternativas e identificar las
un esfuerzo humano intenso nunca tendrá éxito en la dificultades técnicas y de gestión. Sin esta información,
gestión de proyectos. Un gestor que no fomenta una es imposible definir unas estimaciones razonables (y
minuciosa comunicación con el cliente al principio exactas) del coste; una valoración efectiva del riesgo,
de la evolución del proyecto se arriesga a construir una subdivisión realista de las tareas del proyecto o una
una elegante solución para un problema equivocado. planificación del proyecto asequible que proporcione
El administrador que presta poca atención al proce- una indicación fiable del progreso.
so corre el riesgo de arrojar métodos técnicos y herra-
mientas eficaces al vacío. El gestor que emprende un
proyecto sin un plan sólido arriesga el éxito del pro-
ducto. En d Capitulo 1 se tmto una taxonomía de las &reas
de aplicociiin que producen los aproductosx de software.
3.1.1. Personal
La necesidad de contar con personal para el desarrollo
del software altamente preparado y motivado se viene El desarrollador de software y el cliente deben reunir-
discutiendo desde los años 60 (por ejemplo, [COUSO, se para definir los objetivos del producto y su ámbito. En
WíT94, DEM981). De hecho, el «factor humano» es tan muchos casos, esta actividad empieza como parte del pro-
importante que el Instituto de Ingeniería del Software ceso de ingeniería del sistema o del negocio (Capítulo 10)
ha desarrollado un Modelo de madurez de la capacidad y continúa como el primer paso en el análisis de los requi-
de gestión de personal (MMCGP) «para aumentar la sitos del software (Capítulo 11). Los objetivos identifican
preparación de organizaciones del software para llevar las metas generales del proyecto sin considerar cómo se
a cabo las cada vez más complicadas aplicaciones ayu- conseguirán (desde el punto de vista del cliente).
dando a atraer, aumentar, motivar, desplegar y retener El ámbito identifica los datos primarios, funciones y
el talento necesario para mejorar su capacidad de desa- comportamientos que caracterizan al producto, y, más
rrollo de software» [CUR94]. importante, intenta abordar estas características de una
manera cuantitativa.
Una vez que se han entendido los objetivos y el ámbi-
to del producto, se consideran soluciones alternativas.

3.1.3. Proceso
Un proceso de software (Capítulo 2) proporciona la
estructura desde la que se puede establecer un detalla-
do plan para el desarrollo del software. Un pequeño
El modelo de madurez de gestión de personal defi- número de actividades estructurales se puede aplicar a
ne las siguientes áreas clave prácticas para el personal todos los proyectos de software, sin tener en cuenta su
que desarrolla software: reclutamiento, selección, ges- tamaño o complejidad. Diferentes conjuntos de tareas
tión de rendimiento, entrenamiento, retribución, desa- -tareas, hitos, productos del trabajo y puntos de garan-
rrollo de la carrera, diseño de la organización y del tía de calidad-permiten a las actividades estructura-
trabajo y desarrollo cultural y de espíritu de equipo. les adaptarse a las características del proyecto de
El MMCGP es compañero del modelo de madurez software y a los requisitos del equipo del proyecto. Final-
de la capacidad software (Capítulo 2), que guía a las mente, las actividades protectoras -tales como garan-
organizaciones en la creación de un proceso de software tía de calidad del software, gestión de la configuración
maduro. Más adelante en este capítulo se consideran del software y medición-cubren el modelo de proce-
aspectos asociados a la gestión de personal y estructu- so. Las actividades protectoras son independientes de
ras para proyectos de software. las estructurales y tienen lugar a lo largo del proceso.

es usado para abarcar cual-

I En este contexto, el termino ([producto))
quier software que será construido a petición de otros. Esto incluye
no sólo productos de software, sino también sistemas basados en
computadora, software empotrado y software de resolución de pro-
blemas (por ejemplo, programas para la resolución de problemas
científicos/de ingeniería).

38
 CAPfTULO 3 CONCEPTOS SOBRE GESTI6N DE PROYECTOS

por 100 experimentaron un desbordamiento en la pla-

".%
c VE
las actividades estructurales se componen de tareas, hitos,
nificación y en el coste [REE99].Aunque la proporción
de éxito para los proyectos de software ha mejorado un
poco, nuestra proporción de fracaso de proyecto per-
productos de trabaio y puntos de garantío de calidad. manece más alto del que debería ser2.
Para evitar el fracaso del proyecto, un gestor de pro-
yectos de software y los ingenieros de software que
3.1.4. Proyecto construyeron el producto deben eludir un conjunto de
Dirigimos los proyectos de software planificados y con- señales de peligro comunes; comprender los factores
trolados por una razón principal -es la Única manera del éxito críticos que conducen a la gestión correcta del
conocida de gestionar la complejidad-. Y todavía proyecto y desarrollar un enfoque de sentido común
seguimos esforzándonos. En 1998, los datos de la indus- para planificar, supervisar y controlar el proyecto. Cada
tria del software indicaron que el 26 por 100 de pro- uno de estos aspectos se trata en la Sección 3.5 y en los
yectos de software fallaron completamente y que el 46 capítulos siguientes.

En un estudio publicado por el IEEE [CURSS] se les del software, damos este aspecto por descontado. Los
preguntó a los vicepresidentes ingenieros de tres gran- gestores argumentan (como el grupo anterior) que el
des compañías tecnológicas sobre el factor más impor- personal es algo primario, pero los hechos desmienten
tante que contribuye al éxito de un proyecto de software. a veces sus palabras.
Respondieron de la siguiente manera: En esta sección examinamos los participantes que cola-
VP 1: Supongo que si tuviera que elegir lo más importante boran en el proceso del software y la manera en que se
de nuestro entorno de trabajo, diría que no son las organizan para realizar una ingeniería del Software eficaz.
herramientas que empleamos, es la gente.
VP 2: El ingrediente más importante que contribuyó al éxi- 3.2.1. Los participantes
to de este proyecto fue tener gente lista ...pocas cosas
más importan en mi opinión ... Lo más importante El proceso del software (y todos los proyectos de soft-
que se puede hacer por un proyecto es seleccionar el ware) lo componen participantes que pueden clasificarse
personal ... El éxito de la organización de desarrollo en una de estas cinco categorías:
del software está muy, muy asociado con la habili-
1. Gestores superiores, que definen los aspectos de
dad de reclutar buenos profesionales.
negocios que a menudo tienen una significativa
VP 3: La única regla que tengo en cuanto a la gestión influencia en el proyecto.
es asegurarme de que tengo buenos profesionales
-gente realmente buena-, de que preparo bue- 2. Gestores (técnicos) del proyecto, que deben planifi-
na gente y de que proporciono el entorno en el car, motivar, organizar y controlar a los profesiona-
que los buenos profesionales puedan producir. les que realizan el trabajo de software.
3. Profesionales, que proporcionan las capacidades téc-
nicas necesarias para la ingeniería de un producto o
aplicación.
4. Clientes, que especifican los requisitos para la inge-
niería del software y otros elementos que tienen
menor influencia en el resultado.
5. Usuarios finales, que interaccionan con el software
Ciertamente, éste es un testimonio convincente sobre una vez que se ha entregado para la producción.
la importancia del personal en el proceso de ingeniería Para ser eficaz, el equipo del proyecto debe organizarse
del software. Y, sin embargo, todos nosotros, desde los de manera que maximice las habiiidades y capacidades
veteranos vicepresidentes al más modesto profesional de cada persona. Y este es el trabajo del jefe del equipo.

Dadas estas estadísticas, es razonable preguntarse cómo el impacto

de las computadorascontinúa creciendo exponencialmente y la indus-
tria del software continúa anunciando el crecimiento de ventas al doble.
Parte de la respuesta, pienso, es que un importante número de estos
proyectos .fallidos))están mal concebidos desde el primer momento.
Los clientes pierden el interés rápidamente (puesto que lo que ellos
pidieron realmente no era tan importante como ellos habían pensado),
y los proyectos son cancelados.

39
INGENIERiA DEL SOFTWARE. UN ENFOQUE PRACTICO

3.2.2. Los jefes de equipo Incentivos por logros. Para optimizar la productividad de
un equipo de proyecto, un gestor debe recompensar la inicia-
La gestión de un proyecto es una actividad intensamente tiva y los logros, y demostrar a través de sus propias acciones
humana, y por esta razón, los profesionales competen- que no se penalizará si se corren riesgos controlados.
tes del software a menudo no son buenos jefes de equi- Influencia y construcción de espíritu de equipo. Un ges-
po. Simplemente no tienen la mezcla adecuada de tor de proyecto eficiente debe ser capaz de «leer» a la gente;
capacidades del personal. Y sin embargo, como dice debe ser capaz de entender señales verbales y no verbales y
Edgemon: «Desafortunadamente y con demasiada fre- reaccionar ante las necesidades de las personas que mandan
cuencia, hay individuos que terminan en la gestión de esas señales. El gestor debe mantener el control en situaciones
proyectos y se convierten en gestores de proyecto acci- de gran estrés.
dentales» [EDG95].

¿En qué nos fijamos cuando

seleccionamos a alguien para Un experto de sohore puede no tener temperomento o
deseo de ser jefe de equipo. No fuerce oí experto poro ser
conducir un proyecto de software?
uno de ellos.

En un excelente libro sobre gestión técnica, Jerry

Weinberg [WEI86] sugiere el modelo de gestión MOI: 3.2.3. El equipo de software
Motivación.La habilidad para motivar (con un «tira y aflo- Existen casi tantas estructuras de organización de perso-
ja») al personal técnico para que produzca conforme a sus mejo-
res capacidades.
nal para el desarrollo de software como organizaciones
que se dedican a ello. Para bien o para mal, el organi-
Organización. La habilidad para amoldar procesos exis- grama no puede cambiarse fácilmente. Las consecuen-
tentes (oinventar unos nuevos) que permita al concepto inicial
transformarse en un producto hal.
cias prácticas y políticas de un cambio de organización
no están dentro del alcance de las responsabilidades del
Ideas o innovación. La habilidad para motivar al personal gestor de un proyecto de software. Sin embargo, la orga-
para crear y sentirse creativos incluso cuando deban de traba-
jar dentro de los límites establecidos para un producto o apli- nización del personal directamente involucrado en un
cación de software particular. nuevo proyecto de software está dentro del ámbito del
gestor del proyecto.
Las siguientes opciones pueden aplicarse a los recur-
sos humanos de un proyecto que requiere n personas
trabajando durante k años:
1. n individuos son asignados a m diferentes tareas fun-
cionales, tiene lugar relativamente poco trabajo con-
junto; la coordinación es responsabilidad del gestor
del software que puede que tenga otros seis proyec-
Weinberg sugiere que el éxito de los gestores de pro- tos de los que preocuparse.
yecto se basa en aplicar un estilo de gestión en la reso-
lución de problemas. Es decir, un gestor de proyectos de
software debería concentrarse en entender el problema
que hay que resolver, gestionando el flujo de ideas y, al
mismo tiempo, haciendo saber a todos los miembros del
equipo (mediante palabras y, mucho más importante,
con hechos) que la calidad es importante y que no debe
verse comprometida.
Otro punto de vista [EDG95] de las características
2. individuos son asignados a m diferentes tareas fun-
y1
que definen a un gestor de proyectos eficiente resalta
cionales (m<n)de manera que se establecen «equi-
cuatro apartados clave:
pos~ informales; se puede nombrar un líder al efecto;
Resolución del problema. Un gestor eficiente de un pro- la coordinación entre los equipos es responsabilidad
yecto de software puede diagnosticar los aspectos técnicos y
de organización más relevantes, estructurar una solución siste-
de un gestor del software.
máticamente o motivar apropiadamente a otros profesionales 3. n individuos se organizan en t equipos; a cada equipo
para que desarrollen la solución, aplicar las lecciones aprendi- se le asignan una o más tareas funcionales; cada
das de anteriores proyectos a las nuevas situaciones, mante- equipo tiene una estructura específica que se define
nerse lo suficientementeflexible para cambiar la gestión si los para todos los equipos que trabajan en el proyecto;
intentos iniciales de resolver el problema no dan resultado.
la coordinación es controlada por el equipo y por el
Dotes de gestión. Un buen gestor de proyectos debe tomar gestor del proyecto de software.
las riendas. Debe tener confianza para asumir el control cuan-
do sea necesario y la garantía para permitir que los buenos téc- Aunque es posible encontrar argumentos en pro y en
nicos sigan sus instintos. contra para cada uno de los enfoques anteriores, existe
40
 CAPfTULO 3 CONCEPTOS SOBRE GESTI6N DE PROYECTOS

una gran evidencia que indica que una organización de jar problemas sencillos. Los equipos descentralizados
equipo formal (opción 3) es la más productiva. generan más y mejores soluciones que los individua-
La «mejor» estructura de equipo depende del esti- les. Por tanto, estos equipos tienen más probabilidades
lo de gestión de una organización, el número de per- de éxito en la resolución de problemas complejos. Pues-
sonas que compondrá el equipo, sus niveles de to que el equipo DC es centralizado para la resolución
preparación y la dificultad general del problema. Man- de problemas, tanto el organigrama de equipo DC como
tei [MAN81] sugiere tres organigramas de equipo el de CC pueden aplicarse con éxito para problemas
genéricos: sencillos. La estructura DD es la mejor para problemas
Descentralizado democrático (DD). Este equipo de difíciles.
ingeniería del software no tiene un jefe permanente. Más Como el rendimiento de un equipo es inversamente
bien, «se nombran coordinadores de tareas a corto plazo y proporcional a la cantidad de comunicación que se debe
se sustituyen por otros para diferentes tareas». Las deci- entablar, los proyectos muy grandes son mejor dirigi-
siopes sobre problemas y los enfoques se hacen por con- dos por equipos con estructura CC o DC, donde se pue-
senso del grupo. La comunicación entre los miembros del
equipo es horizontal. den formar fácilmente subgrupos.
El tiempo que los miembros del equipo vayan a
«vivir juntos» afecta a la moral del equipo. Se ha des-
¿Cómo debería estar cubierto que los organigramas de equipo tipo DD pro-
organizado un equipo ducen una moral más alta y más satisfacción por el
de software? trabajo y son, por tanto, buenos para equipos que per-
manecerán juntos durante mucho tiempo.
Descentralizado controlado (DC). Este equipo de inge- El organigrama de equipo DD se aplica mejor a pro-
niería del software tiene un jefe definido que coordina tare- blemas con modularidad relativamente baja, debido a
as específicas y jefes secundarios que tienen responsabilidades
sobre subtareas. La resolución de problemas sigue siendo la gran cantidad de comunicación que se necesita. Los
una actividad del grupo, pero la implementación de solu- organigramas CC o DC funcionan bien cuando es posi-
ciones se reparte entre subgrupos por el jefe de equipo. La ble una modularidad alta (y la gente puede hacer cada
comunicación entre subgrupos e individuos es horizontal. uno lo suyo).
También hay comunicación vertical a lo largo de la jerarquía
de control.
Centralizado controlado (CC). El jefe del equipo se
encarga de la resolución de problemas a alto nivel y la coor-
dinación interna del equipo. La comunicación entre el jefe y Frecuentementees mejor tener pocos equipos pequeños,
los miembros del equipo es vertical. bien centrados que un gran equipo solamente.
Mantei [MAN8 11 describe siete factores de un pro-
yecto que deberían considerarse cuando se planifica el Los equipos CC y DC producen menos defectos que
organigrama de equipos de ingeniería del software: los equipos DD, pero estos datos tienen mucho que ver
la dificultad del problema que hay que resolver con las actividades específicas de garantía de calidad
el tamaño del programa(s) resultante(s) én líneas de que aplica el equipo. Los equipos descentralizados
código o puntos de función (Capítulo 4) requieren generalmente más tiempo para completar un
proyecto que un organigrama centralizado y al mismo
el tiempo que el equipo estará junto (tiempo de vida
tiempo son mejores cuando se precisa una gran canti-
del equipo)
dad de comunicación.
el grado en que el problema puede ser modulari- Constantine [CON931 sugiere cuatro «paradigmas
zado de organización» para equipos de ingeniería del soft-
ware:
¿Qué factores 1. Un paradigma cerrado estructura a un equipo con
deberíamos considerar una jerarquía tradicional de autoridad (similar al
cuando estructuramos equipo CC). Estos equipos trabajan bien cuando pro-
un equipo de software? ducen software similar a otros anteriores, pero pro-
bablemente sean menos innovadores cuando trabajen
dentro de un paradigma cerrado.
la calidad requerida y fiabilidad del sistema que se
va a construir 2. El paradigma aleatorio estructura al equipo libre-
mente y depende de la iniciativa individual de los
la rigidez de la fecha de entrega
miembros del equipo. Cuando se requiere innova-
el grado de sociabilidad (comunicación) requerido ción o avances tecnológicos, los equipos de para-
para el proyecto digma aleatorio son excelentes. Pero estos equipos
Debido a que una estructura centralizada realiza las pueden chocar cuando se requiere un «rendimiento
tareas más rápidamente, es la más adecuada para mane- ordenado».
41
INGENIERfA DEL SOFTWARE. U N ENFOQUE PRÁCTICO

3. El paradigma abierto intenta estructurar a un equipo nen una definición común de éxito o un espíritu de equi-
de manera que consiga algunos de los controles aso- po identificable. Lo que falta es un fenómeno que deno-
minamos cuajar.
ciados con el paradigma cerrado, pero también
mucha de la innovación que tiene lugar cuando se Un equipo cuajado es un grupo de gente tejido tan fuer-
utiliza el paradigma aleatorio. El trabajo se desa- temente que el todo es mayor que la suma de las partes ...
rrolla en colaboración, con mucha comunicación y Una vez que el equipo empieza a cuajar, la probabilidad
toma de decisiones consensuadas y con el sello de de éxito empieza a subir. El equipo puede convertirse en
imparable, un monstruo de éxito ... No necesitan ser dirigi-
los equipos de paradigma abierto. Los organigra- dos de una manera tradicional y no necesitan que se les moti-
mas de equipo de paradigma abierto son adecuados ve. Están en su gran momento.
para la resolución de problemas complejos, pero
pueden no tener un rendimiento tan eficiente como DeMarco y Lister mantienen que los miembros de
otros equipos. equipos cuajados son significativamente más pro-
ductivos y están más motivados que la media. Com-
parten una meta común, una cultura común y, en
muchos casos, un «sentimiento elitista» que les hace
únicos.
Pero no todos los equipos cuajan. De hecho, muchos
equipos sufren lo que Jackman llama «toxicidad de equi-
po» [JAC98] define cinco factores que «fomentan un
entorno de equipo tóxico potencial»:
4. El paradigma sincronizado se basa en la comparti-
mentación natural de un problema y organiza los
miembros del equipo para trabajar en partes del pro-
blema con poca comunicación activa entre ellos.
Constantine [CON931 propone una variación en el
equipo descentralizado democrático defendiendo a los
equipos con independencia creativa cuyo enfoque de
trabajo podría ser mejor llamado «anarquía innova-
dora». Aunque se haya apelado al enfoque de libre 1. una atmósfera de trabajo frenética en la que los
espíritu para el desarrollo del software, el objetivo miembros del equipo gastan energía y se descentran
principal de una organización de Ingeniería del Soft- de los objetivos del trabajo a desarrollar;
ware debe ser «convertir el caos en un equipo de alto
2. alta frustración causada por factores tecnológicos,
rendimiento» [HYM93]. Para conseguir un equipo de
del negocio, o personales que provocan fricción entre
alto rendimiento.
los miembros del equipo;
Los miembros del equipo deben confiar unos en
otros. 3. «procedimientos coordinados pobremente o frag-
mentados» o una definición pobre o impropiamente
La distribución de habilidades debe adecuarse al pro- elegida del modelo de procesos que se convierte en
blema. un obstáculo a saltar;
Para mantener la unión del equipo, los inconformis- 4. definición confusa de los papeles a desempeñar pro-
tas tienen que ser excluidos del mismo duciendo una falta de responsabilidad y la acusación
Cualquiera que sea la organización del equipo, el correspondiente, y
objetivo para todos los gestores de proyecto es colabo- 5. «continua y repetida exposición al fallo» que con-
rar a crear un equipo que presente cohesión. En su libro, duce a una pérdida de confianza y a una caída de la
Peopfeware,DeMarco y Lister [DEM98] estudian este moral.
aspecto: Jackman sugiere varios antitóxicos que tratan los
problemas comunes destacados anteriormente.
Para evitar un entorno de trabajo frenético, el
gestor de proyectos debería estar seguro de que el
Elpapel del biMiotecario existe sin tener en cuento
lo estructura del equipo. Poro más detalles véase
equipo tiene acceso a toda la información requerida
el íopíiuio 9. para hacer el trabajo y que los objetivos y metas prin-
cipales, una vez definidos, no deberían modificarse a
menos que fuese absolutamente necesario. Además,
las malas noticias no deberían guardarse en secreto,
Tendemos a usar la palabra equipo demasiado libre-
mente en el mundo de los negocios, denominando «equi- sino entregarse al equipo tan pronto como fuese posi-
po» a cualquier grupo de gente asignado para trabajar junta. ble (mientras haya tiempo para reaccionar de un modo
Pero muchos de estos grupos no parecen equipos. No tie- racional y controlado).
42
 CAPfTULO 3 CONCEPTOS SOBRE G E S T I 6 N DE PROYECTOS

presenta un argumento lógico, de un modo ordenado.

Otros son intuitivos, pudiendo tomar una decisión basán-
los equipos formodos son lo ideol, pero no es fócil dose en sus «sensaciones».Algunos desarrolladores pre-
conseguirlos. Como mínimo, esté seguro de evitor fieren una planificación detallada compuesta por tareas
un tentorno tóxico)). organizadas que les permita lograr el cierre para algún
elemento de un proyecto. Otros prefieren un entorno
Aunque la frustración tiene muchas causas, los desa- más espontáneo donde aspectos abiertos son correctos.
rrolladores de software a menudo la sienten cuando pier- Algunos trabajan duro para tener las cosas hechas mucho
den la autoridad para controlar la situación. Un equipo antes de la fecha de un hito, de ese modo eliminan la
de software puede evitar la frustración si recibe tanta presión cuando se aproximan a las fechas, mientras que
responsabilidad para la toma de decisiones como sea otros están apurados por las prisas para hacer la entre-
posible. Cuanto más control se le de al equipo para tomar ga en el Último minuto. Un estudio detallado de la psi-
decisiones técnicas y del proceso, menos frustración cología de estos rasgos y de las formas en las que un
sentiran los miembros del equipo. jefe de equipo cualificado puede ayudar a la gente con
Una elección inapropiada del proceso del software rasgos opuestos para trabajar juntos está fuera del ámbi-
(p.ej., tareas innecesarias o pesadas, pobre elección de to de éste libro4. Sin embargo, es importante destacar
los productos del trabajo) puede ser evitada de dos for- que el reconocimiento de las diferencias humanas es el
mas: (1) estando seguros de que las características del primer paso hacia la creación de equipos que cuajan.
software a construir se ajustan al rigor del proceso ele-
gido, y (2) permitiendo al equipo seleccionar el proce- 3.2.4. Aspectos sobre la coordinación
so (con el reconocimiento completo de que, una vez y la comunicación
elegido, el equipo tiene la responsabilidad de entregar
un producto de alta calidad). Hay muchos motivos por los que los proyectos de soft-
El gestor de proyectos de software, trabajando ware pueden tener problemas. La escala (tamaño) de
junto con el equipo, debería refinar claramente los roles muchos esfuerzos de desarrollo es grande, conduciendo
y las responsabilidades antes del comienzo del proyec- a complejidades, confusión y dificultades significativas
to. El equipo debería establecer su propios mecanismos para coordinar a los miembros del equipo. La incerti-
para la responsabilidad (las revisiones técnicas forma- dumbre es corriente, dando como resultado un continuo
les3son una forma para realizar esto) y definir una serie flujo de cambios que impactan al equipo del proyecto.
de enfoques correctivos cuando un miembro del equi- La interoperatividad se ha convertido en una caracterís-
po falla en el desarrollo. tica clave de muchos sistemas. El software nuevo debe
Todo equipo de software experimenta pequeños fallos. comunicarse con el anterior y ajustarse a restricciones
La clave para eliminar una atmósfera de fallos será esta- predefinidas impuestas por el sistema o el producto.
blecer técnicas basadas en el equipo para retroalimentar
y solucionar el problema. Además, cualquier fallo de un
miembro del equipo debe ser considerado como un fallo
del equipo. Esto lleva a un acercamiento del equipo a la
acción correctiva, en lugar de culpar y desconfiar, que
ocurre con rapidez en equipos tóxicos.
Estas características del software moderno e s c a -
¿Cómo debemos evitar la, incertidumbre e interoperatividad-son aspectos de
«toxinas» que con frecuencia la vida. Para enfrentarse a ellos eficazmente, un equi-
infectan un equipo de software? po de ingeniería del software debe establecer métodos
efectivos para coordinar a la gente que realiza el tra-
Además de las cinco toxinas descritas por Jackman, bajo. Para lograr esto se deben establecer mecanismos
un equipo de software a menudo se enfrenta con los ras- de comunicación formales e informales entre los miem-
gos humanos diferentes de sus miembros. Algunos bros del equipo y entre múltiples equipos. La comuni-
miembros del equipo son extrovertidos, otros son intro- cación formal se lleva a cabo «por escrito, con reuniones
vertidos. Algunas personas recogen información intui- organizadas y otros canales de comunicación relativa-
tivamente, separando amplios conceptos de hechos mente no interactivos e impersonales» [KRA95]. La
dispares. Otros procesan la información linealmente, comunicación informal es más personal. Los miembros
reuniendo y organizando detalles minuciosos de los de un equipo de software comparten ideas de por sí,
datos proporcionados. Algunos miembros del equipo piden ayuda a medida que surgen los problemas e inter-
toman las decisiones apropiadas solamente cuando se actúan los unos con los otros diariamente.

Las revisiones técnicas formales se tratan con detalle en el Capi- Se puede encontrar una excelente introducción a estos temas rela-
tulo 8. cionados con los equipos de proyectos de software en [FER98]

43
I N G E N I E R ~ ADEL S O FTWARE . UN ENFOQUE PRÁCTICO

a productos de ingeniería del software. Estos incluyen reu-

discusión entre personasa niones de revisión de estado e inspecciones de diseño y de
/ código.

revisiones de diseiio. / mdocumentos

hitos del proyecto
iinformes de seguimiento
de errores
¿Cómo coordinar
las acciones de los miembros
correo electrónico del equipo?
0 inspecciones de código

o boletines del proyecto Informal, procedimientos interpersonales.Incluyen reu-

niones de grupo para la divulgación de información y resolu-
ción de problemas así como «definición de requisitos y del
personal de desarrollo».
Comunicación electrónica. Comprende correo electróni-
I herramientas de control del proyecto co, boletines de noticias electrónicos y, por extensión, sistemas
de videoconferencia.
Red interpersonal.Discusiones informales con los miem-
I I I I bros del equipo y con personas que no están en el proyecto pero
3 4 5 6 que pueden tener experiencia o una profunda visión que pue-
empleo de la técnica de coordinación de ayudar a los miembros del equipo.
Enfoque impersonal, formal Para valorar la eficacia de estas técnicas para la coor-
0 Procedimiento interpersonal, formal
o Procedimiento interpersonal, informal
dinación de proyectos, Kraul y Streeter estudiaron 65
o Comunicación electrónica proyectos de software con cientos de personas implica-
A Red interpersonal das. La Figura 3.1 (adaptada de [KRA95]) expresa el
valor y empleo de las técnicas de coordinación apunta-
das anteriormente. En la figura, el valor percibido (cla-
FIGURA 3.1. Valor y empleo de técnicas de coordinación sificado en una escala de siete puntos) de varias técnicas
y comunicación. de comunicación y coordinación es contrastado con su
frecuencia de empleo en un proyecto. Las técnicas situa-
Kraul y Streeter [KRA95] examinan una colección
das por encima de la línea de regresión fueron «juzga-
de técnicas de coordinación de proyectos que se cate- das como relativamente valiosas, dado la cantidad de
gorizan de la siguiente manera: veces que se emplearon» [KRA95]. Las técnicas situa-
Formal, enfoque impersonal. Incluyen documentos de das por debajo de la línea se consideraron de menor valor.
ingeniería del software y entregas (incluyendo el código fuen- Es interesante resaltar que las redes interpersonales fue-
te), memorandos técnicos, hitos del proyecto, planificacio-
nes del programa y herramientas de control del proyecto ron catalogadas como las técnicas de mayor valor de
(Capítulo 7), peticiones de cambios y documentación relati- coordinación y de comunicación. Es también importan-
va (Capítulo 9), informes de seguimiento de errores e infor- te hacer notar que los primeros mecanismos de garantía
mación almacenada (Capítulo 3 1). de calidad del software (requisitos y revisiones de dise-
Formal, procedimientos interpersonales. Se centra en ño) parecieron tener más valor que evaluaciones poste-
las actividades de garantía de calidad (Capítulo 8) aplicada riores de código fuente (inspecciones de código).

3 , 5 C T O
El gestor de un proyecto de software se enfrenta a un dile- 3.3.1. Ámbito del software
ma al inicio de un proyecto de ingeniería del software. La primera actividad de gestión de un proyecto de soft-
Se requieren estimaciones cuantitativas y un plan orga- ware es determinar el ámbito del software. El ámbito se
nizado, pero no se dispone de información sólida. Un define respondiendo a las siguientes 'cuestiones:
análisis detallado de los requisitos del software pro-
porcionaría la información necesaria para las estima-
ciones, pero el análisis a menudo lleva semanas o meses.
Aún peor, los requisitos pueden ser fluidos, cambiando Si no puede delimitur uno corocterísrico de/ sohure
regularmente a medida que progresa el proyecto. Y, aún que intento construib considere /o característica como
un riesgo principo/ de/ proyecto.
así, se necesita un plan «¡ya!».
Por tanto, debemos examinar el producto y el pro- Contexto. ¿Cómo encaja el software a construir
blema a resolver justo al inicio del proyecto. Por lo en un sistema, producto o contexto de negocios
menos se debe establecer el ámbito del producto y mayor y qué limitaciones se imponen como resulta-
delimitarlo. do del contexto?
44
 C A P ~ T U L O3 CONCEPTOS SOBRE G E S T I 6 N DE PROYECTOS

Objetivos de información. ¿Qué objetos de datos Las funciones del software, descritas en la exposi-
visibles al cliente (Capítulo 11) se obtienen del softwa- ción del ámbito, se evalúan y refinan para proporcionar
re? ¿Qué objetos de datos son requeridos de entrada? más detalle antes del comienzo de la estimación (Capí-
Función y rendimiento. ¿Qué función realiza el tulo 5). Puesto que ambos, el coste y las estimaciones
software para transformar la información de entra- de la planificación temporal, están orientados funcio-
da en una salida? ¿Hay características de rendimiento nalmente, un pequeño grado de descomposición suele
especiales que abordar? ser útil.
El ámbito de un proyecto de software debe ser uní- Por ejemplo, considere un proyecto que construirá
VOCO y entendible a niveles de gestión y técnico. Los
un nuevo procesador de textos. Entre las características
enunciados del ámbito del software deben estar deli- peculiares del producto están: la introducción de infor-
mitados. mación a través de la voz así como del teclado; carac-
Es decir, los datos cuantitativos (por ejemplo: núme- terísticas extremadamente sofisticadas de «edición
ro de usuarios simultáneos, tamaño de la lista de correo, automática de copia»; capacidad de diseño de página;
máximo tiempo de respuesta permitido) se establecen indexación automática y tabla de contenido, y otras. El
explícitamente; se anotan las limitaciones (por ejemplo: gestor del proyecto debe establecer primero la exposi-
el coste del producto limita el tamaño de la memoria) y ción del ámbito que delimita estas características (así
se describgn los factores de reducción de riesgos (por como otras funciones más normales, como edición,
ejemplo: los algoritmos deseados se entienden muy bien administración de archivos, generación de documen-
si están disponibles en C++). tos). Por ejemplo, ¿requerirá la introducción de infor-
mación mediante voz «entrenamiento» por parte del
usuario? ¿Qué capacidades específicas proporcionará
3.3.2. Descomposición del problema la característica de editar copias? ¿Exactamente cómo
La descomposición del problema, denominado a veces será de sofisticado la capacidad de diseño de página?
particionado o elaboración del problema, es una activi-
dad que se asienta en el núcleo del análisis de requisitos
del software (Capítulo 11). Durante la actividad de expo- En el Capmilo 12 se presento u110 téuika útil paro
sición del ámbito no se intenta descomponer el proble- descomponer el problema, llomada <anáhsgramoticol>.
ma totalmente. Más bien, la descomposición se aplica en
dos áreas principales: (1) la funcionalidad que debe entre-
garse y (2) el proceso que se empleará para entregarlo. A medida que evoluciona la exposición del ámbito,
un primer nivel de partición ocurre de forma natural. El
equipo del proyecto sabe que el departamento de mar-
keting ha hablado con clientes potenciales y ha averi-
guado que las siguientes funciones deberían ser parte
de la edición automática de copia: (1) comprobación
Para desarrollar un plan de proyecto razonable, tiene ortográfica; (2) comprobación gramatical; ( 3 ) compro-
que descomponer funcionalmente el problema a resolver bación de referencias para documentos grandes (p. ej.:
¿se puede encontrar una referencia a una entrada biblio-
Los seres humanos tienden a aplicar la estrategia de gráfica en la lista de entradas de la bibliografía?), y (4)
divide y vencerás cuando se enfrentan a problemas com- validación de referencias de sección y capítulo para
plejos. Dicho de manera sencilla, un problema complejo documentos grandes. Cada una de estas características
se parte en problemas más pequeños que resultan más representa una subfunción para implernentar en soft-
manejables. Ésta es la estrategia que se aplica al inicio ware. Cada una puede ser aún más refinada si la des-
de la planificación del proyecto. composición hace más fácil la planificación.

Las fases genéricas que caracterizan el proceso de soft- el modelo incremental

ware definición, desarrollo y soporte-son aplicables
a todo software. El problema es seleccionar el modelo de
proceso apropiado para la ingeniería del software que debe
. el modelo en espiral
el modelo en espiral WINWIN
aplicar el equipo del proyecto. En el Capítulo 2 se estudió el modelo de desarrollo basado (ensamblaje) en com-
ponentes
una gran gama de paradigmas de ingeniería del software:
el modelo secuencia1 lineal . el modelo de desarrollo concurrente
* el modelo de prototipo el modelo de métodos formales
el modelo DRA . el modelo de técnicas de cuarta generación
45
INGENIERiA DEL SOFTWARE. UN ENFOQUE PRACTICO

Comunicación con el cliente-tareas requeridas para

@O"*"OS
establecer la obtención de requisitos eficiente entre
Uno vez eleyido el modelo de proceso, ocompóñelo con el desarrollador y el cliente.
el mínimo conjunto de toreos de trubojo y productos que Planificación- tareas requeridas para definir los
desembocaron en un producto de oltu colidud - e v i t e la recursos, la planificación temporal del proyecto y
cupocidod de destrucción del procese.
cualquier información relativa a él.

El gestor del proyecto debe decidir qué modelo de

proceso es el más adecuado para (1) los clientes que han
solicitado el producto y la gente que realizará el traba- Recuerde.... las ocrividaáes estructurales se u p h n
jo; ( 2 )las características del producto en sí, y ( 3 ) el entor- en todos los proyectos- no hoy excepciones.
no del proyecto en el que trabaja el equipo de software.
Cuando se selecciona un modelo de proceso, el equipo Análisis del riesgo-tareas requeridas para valorar
define entonces un plan de proyecto preliminar basado los riesgos técnicos y de gestión.
en un conjunto de actividades estructurales. Una vez Zngenieriu- tareas requeridas para construir una o
establecido el plan preliminar, empieza la descomposi- más representaciones de la aplicación.
ción del proceso. Es decir, se debe crear un plan com- Construccióny entrega-tareas requeridas para cons-
pleto reflejando las tareas requeridas a las personas para truir, probar, instalar y proporcionar asistencia al usua-
cubrir las actividades estructurales. Exploramos estas rio (por ejemplo: documentación y formación).
actividades brevemente en las secciones que siguen y Evaluación del cliente-tareas requeridas para obte-
presentamos una visión más detallada en el Capítulo 7.
ner información de la opinión del cliente basadas en
la evaluación de las representaciones de software
3.4.1. Maduración del producto y del proceso creadas durante la fase de ingeniería e implementa-
La planificación de un proyecto empieza con la madu- das durante la fase de instalación.
ración del producto y del proceso. Todas las funciones Los miembros del equipo que trabajan en cada función
que se deben tratar dentro de un proceso de ingeniería aplicarán todas las actividades estructurales. En esencia,
por el equipo de software deben pasar por el conjunto se crea una matriz similar a la que se muestra en la Figu-
de actividades estructurales que se han definido para ra 3.2. Cada función principal del problema (la figura con-
una organización de software. Asuma que la organiza- tiene las funciones para el software procesador de textos
ción ha adoptado el siguiente conjunto de actividades comentado anteriormente) se lista en la columna de la
estructurales (Capítulo 2): izquierda. Las actividades estructurales se listan en la fila

FIGURA 3.2.Maduración del problema y del proceso.

46
 CAPITULO 3 CONCEPTOS SOBRE GESTI6N DE PROYECTOS

de arriba. Las tareas de trabajo de ingeniería del software ECP?». Por ejemplo, un pequeño proyecto, relativamen-
(para cada actividad estructural) se introducirían en la fila te simple, requiere las siguientes tareas para la actividad
siguiente5. El trabajo del gestor del proyecto (y de otros de comunicación con el cliente:
miembros del equipo) es estimar los requisitos de recur- 1. Desarrollar una lista de aspectos que se han de cla-
sos para cada celda de la matriz, poner fechas de inicio y rificar.
finalización para las tareas asociadas con cada celda y los 2. Reunirse con el cliente para resolver los aspectos
productos a fabricar como consecuencia de cada celda. que se han de clarificar.
Estas actividades se consideran en los Capítulos 5 y 7. 3 . Desarrollar conjuntamente una exposición del
ámbito del proyecto.
4. Revisar el alcance del proyecto con todos los impli-
CLAVE cados.
l o descomposición del producto y del proceso se produce
5. Modificar el alcance del proyecto cuando se requiera.
simultóneamente con la evolución del plan de proyecto. Estos acontecimientospueden ocurrir en un periodo de
menos de 48 horas. Representan una descomposición del
problema apropiado para proyectos pequeños relativa-
3.4.2. Descomposición del proceso mente sencillos.
Un equipo de software debería tener un grado significa- Ahora, consideremos un proyecto más complejo que
tivo de flexibilidad en la elección del paradigma de inge- tenga un ámbito más amplio y un mayor impacto comer-
niería del software que resulte mejor para el proyecto y cial. Un proyecto como ése podría requerir las siguientes
de las tareas de ingeniería del software que conforman el tareas para la actividad de comunicación con el cliente:
modelo de proceso una vez elegido. Un proyecto relati-
vamente pequeño similar a otros que se hayan hecho ante- 1. Revisar la petición del cliente.
riormente se debería realizar con el enfoque secuencia1 2. Planificar y programar una reunión formal con el
lineal. Si hay límites de tiempo muy severos y el proble- cliente.
ma se puede compartimentarmucho, el modelo apropia- 3. Realizar una investigación para definir soluciones pro-
do es el DRA (en inglés RAD). Si la fecha límite está tan puestas y enfoques existentes.
próxima que no va a ser posible entregar toda la funcio- 4. Preparar un «documentode trabajo» y una agenda para
nalidad, una estrategia incremental puede ser lo mejor. la reunión formal.
Similarmente,proyectos con otras características (p. ej.: 5. Realizar la reunión.
requisitos inciertos, nuevas tecnologías, clientes difíci- 6. Desarrollar conjuntamente mini-especificaciones que
les, potencialidad de reutilización) llevarán a la selección reflejen la información, función y características de
de otros modelos de proceso6. comportamiento del software.

Aplique siempre la FCf (Estructura Común de Proceso),

sin tener en cuenta el tamaño, criticidad o tipo del
proyecto. las tareas pueden variar pero la ECf no.
Modelo de proceso adaptable.
Una vez que se ha elegido el modelo de proceso, la
estructura común de proceso (ECP) se adapta a él. En todos 7. Revisar todas las mini-especificaciones para compro-
los casos, el ECP estudiado anteriormente en este capítu- bar su corrección, su consistencia,la ausencia de ambi-
lo -comunicación con el cliente, planificación, análisis güedades.
de riesgo, ingeniería, construcción, entrega y evaluación 8. Ensamblar las mini-especificacionesen un documento
del cliente-puede adaptarse al paradigma. Funcionará de alcance del proyecto.
para modelos lineales, para modelos iterativos e incre- 9. Revisar ese documento general con todo lo que pueda
mentales, para modelos de evolución e .incluso para mode- afectar.
los concurrentes o de ensamblaje de componentes.El ECP 10. Modificar el documento de alcance del proyecto
es invariable y sirve como base para todo el trabajo de cuando se requiera.
software realizado por una organización. Ambos proyectos realizan la actividad estructural que
Pero las tareas de trabajo reales sí vm'an. La descom- denominamos comunicacióncon el cliente, pero el equipo
posición del proceso comienza cuando el gestor del pro- del primer proyecto lleva a cabo la mitad de tareas de
yecto pregunta: «¿Cómo vamos a realizar esta actividad ingeniería del software que el segundo.
Se hace notar que las tareas se deben adaptar a las necesidades Recuerde que las características del proyecto tienen también una
específicas de un proyecto. Las actividades estructurales siempre per- fuerte influencia en la estructura del equipo que va a realizar el tra-
manecen igual, pero las tareas se seleccionarán basándose en unos bajo. Vea la Sección 3.2.3.
criterios de adaptación. Este tema e s discutido más adelante en el
Capitulo 7 y en la página Web SEPA 5/e.

47
INGENIERfA DEL SOFTWARE. UN ENFOQUE PRACTICO

3.5 P R m O
Para gestionar un proyecto de software con éxito, vaya a estar involucrado en el proyecto. Se refuer-
debemos comprender qué puede ir mal (para evitar za construyendo el equipo adecuado (Sección 3.2.3)
esos problemas) y cómo hacerlo bien. En un excelente y dando al equipo la autonomía, autoridad y tecno-
documento sobre proyectos de software, John Reel logía necesaria para realizar el trabajo.
[REE99] define diez señales que indican que un pro- Mantenerse. Muchos proyectos no realizan un
yecto de sistemas de información está en peligro: buen comienzo y entonces se desintegran lentamente.
Para mantenerse, el gestor del proyecto debe pro-
porcionar incentivos para conseguir una rotación del
personal mínima, el equipo debería destacar la cali-
dad en todas las tareas que desarrolle y los gestores
veteranos deberían hacer todo lo posible por per-
manecer fuera de la forma de trabajo del equipo7.
Seguimiento del Progreso. Para un proyecto de
software, el progreso se sigue mientras se realizan los
productos del trabajo (por ejemplo, especificaciones,
1. La gente del software no comprende las necesi- código fuente, conjuntos de casos de prueba) y se
dades de los clientes. aprueban (utilizando revisiones técnicas formales)
como parte de una actividad de garantía de calidad.
2. El ámbito del producto está definido pobremente. Además, el proceso del software y las medidas del
3 . Los cambios están mal realizados. proyecto (capítulo 4) pueden ser reunidas y utilizadas
4. La tecnología elegida cambia. para evaluar el progreso frente a promedios desarro-
llados por la organización de desarrollo de software.
5. Las necesidades del negocio cambian [o están mal
definidas]. Tomar Decisiones Inteligentes. En esencia, las
decisiones del gestor del proyecto y del equipo de
6. Las fechas de entrega no son realistas. software deberían «seguir siendo sencillas>>.Siem-
7. Los usuarios se resisten. pre que sea posible, utilice software del mismo
8. Se pierden los patrocinadores [o nunca se obtu- comercial o componentes de software existentes;
vieron adecuadamente]. evite personalizar interfaces cuando estén dispo-
nibles aproximaciones estándar; identifique y eli-
9. El equipo del proyecto carece del personal con las mine entonces riesgos obvios; asigne más tiempo
habilidades apropiadas. del que pensaba necesitar para tareas arriesgadas
10.Los gestores [y los desarrolladores] evitan buenas o complejas (necesitará cada minuto).
prácticas y sabias lecciones.
Los profesionales veteranos de la industria hacen
referencia frecuentemente a la regla 90-90 cuando
estudian proyectos de software particularmente difí-
ciles: el primer 90 por 100 de un sistema absorbe el
90 por 100 del tiempo y del esfuerzo asignado. El últi-
3
Referencia We6
Se puede enconkar un gran conjunto de recursos
que pueden ayudar tanto a gestores de proyecto
mo 10 por 100 se lleva el otro 90 por 100 del esfuer-
experimentodos como a principiantes en:
zo y del tiempo asignado [ZAH94]. Los factores que
www.pmi.org, www.4pm.com y
conducen a la regla 90-90 están contenidos en las diez www.projectmanagement.com
señales destacadas en la lista anterior.
¡Suficientenegatividad! ¿Cómo actúa un gestor para
evitar los problemas señalados anteriormente? Reel Realizar un Análisis «Postmortem»(despuésdefina-
[REE99] sugiere una aproximación de sentido común lizar el proyecto}. Establecer un mecanismo consis-
a los proyectos de software dividida en cinco partes: tente para extraer sabias lecciones de cada proyecto.
Empezar con el pie derecho. Esto se realiza tra- Evaluar la planificación real y la prevista, reunir y ana-
bajando duro (muy duro) para comprender el pro- lizar métricas del proyecto de software y realimentar
blema a solucionar y estableciendo entonces con datos de los miembros del equipo y de los clien-
objetivos y expectativas realistas para cualquiera que tes, y guardar los datos obtenidos en formato escrito.

Esta frase implica la reducción al mínimo de la burocracia, y la eli-

minación tanto de reuniones extrañas como de la adherencia dog-
mática a las reglas del proceso y del proyecto. El equipo debena estar
capacitado para realizar esto.

48
 CAPfTULO 3 CONCEPTOS SOBRE GESTI6N DE PROYECTOS

En un excelente documento sobre proyectos y proce- ponsabilidad de cada miembro del equipo de soft-
so del software, Bany Boehm [BOE96] afirma: «... se ware debe estar definida. La respuesta a la pre-
necesita un principio de organización que haga una gunta ayuda a cumplir esto.
simplificación con el fin de proporcionar planes [de 2 Dónde están situados organizacionalmente?
proyectos] sencillos para proyectos pequeños». Boehm No todos los roles y responsabilidades residen en
sugiere un enfoque que trate los objetivos, hitos y pla- el equipo de software. El cliente, los usuarios, y
nificación, responsabilidades, enfoque técnico y de otros directivos también tienen responsabilidades.
gestión, y los recursos requeridos del proyecto. Bohem
lo llama el principio «WWWWWHH», después de
una serie de preguntas (7 cuestiones) que conducen a
la definición de las características clave del proyecto
y el plan del proyecto resultante:
¿Por qué se desarrolla el sistema? La respuesta a
esta pregunta permite a todas las partes evaluar la vali-
dez de las razones del negocio para el trabajo del soft- Plan de Proyecto de Software
ware. Dicho de otra forma, Ljustifica el propósito del
negocio el gasto en personal, tiempo, y dinero? ¿Cómo estará realizado el trabajo desde elpun-
¿Qué se realizará y cuándo? La respuesta a estas to de vista técnico y de gestión? Una vez estable-
preguntas ayuda al equipo a establecer la planifi- cido el ámbito del producto, se debe definir una
cación del proyecto identificando las tareas clave estrategia técnica y de gestión para el proyecto.
del proyecto y los hitos requeridos por el cliente. ¿Qué cantidad de cada recurso se necesita? La
respuesta a esta pregunta se deriva de las estima-
ciones realizadas (Capítulo 5 ) basadas en res-
¿Qué preguntas necesitan puestas a las preguntas anteriores.
ser respondidas para
desarrollar un Plan de Proyecto? El principio W5HH de Boehm es aplicable sin tener
en cuenta el tamaño o la complejidad del proyecto de
software. Las preguntas señaladas proporcionan un
¿Quién es el responsable de una función? Antes perfil de planificación al gestor del proyecto y al equi-
en este capítulo, señalamos que el papel y la res- po de software.

El Concilio8 Airlie ha desarrollado una lista de uno de los riesgos ¿cuál es la oportunidad de que
«prácticas críticas de software para la gestión basada el riesgo se convierta en un problema y cuál es el
en el rendimiento». Estas prácticas son «utilizadas de impacto si lo hace?
un modo consistente por, y consideradas críticas por, Coste empírico y estimación de la planificación.
organizaciones y proyectos de software de mucho éxi- ¿Cuál es el tamaño actual estimado de la aplicación
to cuyo rendimiento “final” es más consistente que de software (sin incluir el software del sistema) que
los promedios de la industria» [AIR99]. En un esfuer- será entregada en la operación? ¿Cómo se obtuvo?
zo por permitir a una organización de software deter-
minar si un proyecto específico ha implementado
prácticas críticas, el Concilio Airlie ha desarrollado
un conjunto de preguntas de «Visión Rápida» [AIR99]
para un proyecto’:
Gestión formal del riesgo. ¿Cuáles son los diez
riesgos principales para este proyecto? Para cada Visi6n rápida del Proyecto Airlie

8EI Concilio Airlie es un equipo de expertos en ingeniería del soRware 9 Solo se destacan aquí aquellas practicas críticas relacionadas con
promocionado por el Departamento de Defensa U.S.ayudando en el la ((integridaddel proyecto)).Otras practicas mejores se trataran en
desarrollo de directrices para prácticas importantes en la gestión de capítulos posteriores.
proyectos de software y en la ingeniería del Software.

49
INGENIERiA DEL SOFTWARE. UN ENFOQUE P R Á C T I C O

Gestión de proyectos basada en métricas. ¿Dis- de el principio del programa y del número de defectos
pone de un programa de métricas para dar una prime- que se corrigen y se producen en la actualidad?
ra indicación de los problemas del desarrollo? Si es así, Gestión del programa del personal. ¿Cuál es
¿cuál es la volatilidad de los requisitos actualmente? la media de rotación de la plantilla en los tres Últi-
Seguimiento del valor ganado. ¿Informa men- mos meses por cada uno de los distribuidores/desa-
sualmente de las métricas del valor ganado ...? Si rrolladores involucrados en el desarrollo del
es así, ¿están calculadas estas métricas desde una software para este sistema?
red de actividades de tareas para el esfuerzo total Si un equipo de proyectos de software no puede
a la próxima entrega? responder a estas preguntas, o las responde inade-
Seguimientode defectos frente a objetivos de cali- cuadamente, se debe realizar una revisión completa
dad. ¿Realiza el seguimiento e informa periódicamente de las prácticas del proyecto. Cada una de las prácti-
del número de defectos encontrados en cada prueba de cas críticas señaladas anteriormente se tratan con deta-
inspección [revisión técnica formal] y ejecución des- lle a lo largo de la Parte 11 de este libro.

La gestión de proyectos de software es una actividad pletar el trabajo. Finalmente, el proyecto debe organi-
protectora dentro de la ingeniería del software. Empie- zarse de una manera que permita al equipo de software
za antes de iniciar cualquier actividad técnica y con- tener éxito.
tinúa a lo largo de la definición, del desarrollo y del El elemento fundamental en todos los proyectos de
mantenimiento del software. software es el personal. Los ingenieros del software
Hay cuatro << P’s >> que tienen una influencia sustan- pueden organizarse en diferentes organigramas de equi-
cial en la gestión de proyectos de software -personal, po que van desde las jerarquías de control tradiciona-
producto, proceso y proyecto-. El personal debe orga- les a los equipos de «paradigma abierto». Se pueden
nizarse en equipos eficaces, motivados para hacer un aplicar varias técnicas de coordinación y comunica-
software de alta calidad y coordinados para alcanzar una ción para apoyar el trabajo del equipo. En general, las
comunicación efectiva. Los requisitos del producto revisiones formales y las comunicaciones informales
deben comunicarse desde el cliente al desarrollador, persona a persona son las más valiosas para los pro-
dividirse (descomponerse) en las partes que lo consti- fesionales.
tuyen y distribuirse para que trabaje el equipo de soft- La actividad de gestión del proyecto comprende
ware. El proceso debe adaptarse al personal y al medición y métricas, estimación, análisis de riesgos,
problema. Se selecciona una estructura común de pro- planificación del programa, seguimiento y control.
ceso, se aplica un paradigma apropiado de ingeniería Cada uno de estos aspectos se trata en los siguientes
del software y se elige un conjunto de tareas para com- capítulos.

[AIR99] Airlie Council, «Performanced Based Management: ware Engineering, vol. 3 1, n.8 1 1, Noviembre de 1988,
The Program Manager’s Guide Based on the 16-Point pp. 1268-1287.
Plan and Related Metricw, Draft Report, 8 de Marzo,
1999. [CUR94] Curtis, B., et al., PeopIe Management Capahi-
lity Maturity Model, Software Engineering Institute,
[BAK72] Baker, F.T., «Chief Programmer Team Manage- Pittsburgh, PA, 1994.
ment of Production Programming», IBM Systems Jour-
nal, vol. 11, n.” 1, 1972, pp. 56-73. [DEM98] DeMarco, T., y T. Lister, Peopleware, 2.- edi-
ción, Dorset House, 1998.
[BOE96] Boehm, B., «Anchoring the Software Process»,
IEEE Sofhvare, vol. 13, n.Q4, Julio de 1996, pp. 73-82. [EDG95] Edgemon, J., «Right Stuff How to Recognize
[CON931 Constantine, L., «Work Organization: Paradigms It When Selecting a Project Manager», Application
for Project Management and Organization», CACM, vol. Development Trends, vol. 2, n.8 5, Mayo de 1995, pp.
36, n.” 10, Octubre de 1993, pp. 34-43. 37-42.
[COUSO] Cougar, J., y R. Zawacky, Managing and Moti- [FER98] Ferdinandi, P. L., «Facilating Communication»,
vating Computer Personnel, Wiley, 1980. IEEE Software, Septiembre de 1998, pp. 92-96.
[CURSS] Curtis, B., et al, «A Field Study of the Software [JAC98] Jackman, M., «Homeopathic Remedies for Team
Design Process for Large Systemw, IEEE Trans. Soft- Toxicity», IEEE Software, Julio de 1998, pp. 43-45.
50
 CAPfTULO 3 CONCEPTOS SOBRE G E S T l 6 N DE PROYECTOS

[KRA95] Kraul, R., y L. Streeter, «Coordination in Software [REE99] Reel, J.S., «Critica1 S u c a x j Factors in Software
Development»,CACM, vol. 38, n." 3, Marzo de 1995, pp. Projects», IEEE Software, Mayo de 1999, pp. 18-23.
69-8 1. [WEI86] Weinberg, G., On Becoming a Terhnical Leader,
[MAN81] Mantei, M., «The Effect of Programming Team Dorset House, 1986.
Structures on Programming Tasks», CACM, vol. 24, n." 3, [WIT94] Whitaker, K., Managing Software Maniacs, Wiley,
Marzo de 1981, pp. 106-113. 1994.
[PAG85] Page-Jones, M., Practica1 Project Management, [ZAH94] Zahniser, R., «Timeboxing for Top Team Perfor-
Dorset House, 1985, p. VII. mance», SoJnYare Development, Marzo de 1994, pp. 35-38.

3.1. Basándose en la información contenida en este capítu- por el mercado de entretenimiento casero es intensa, hay cier-
lo y en su propia experiencia, desarrolle «diez mandamien- ta presión para terminar el trabajo rápidamente. ¿Qué estruc-
tos» para potenciar a los ingenieros del software. Es decir, tura de equipo elegiría y por qué? ¿,Quémodelo(s) de proceso
haga una lista con las diez líneas maestras que lleven al per- de software elegiría y por qué?
sonal que construye software a su máximo potencial. 3.8. Se le ha nombrado gestor de proyecto de una gran com-
3.2. El Modelo de Madurez de Capacidad de Gestión de Per- pañía de productos software. Su trabajo consiste en dirigir la
sonal (MMCGP) del Instituto de Ingeniería del Software hace versión de la siguiente generación de su famoso procesador
un estudio organizado de las «áreas clave prácticas (ACP)» de textos. Como la competencia es intensa, se han estableci-
que cultivan los buenos profesionales del software. Su profe- do y anunciado fechas límite rígidas. ¿Qué estructura de equi-
sor le asignará una ACP para analizar y resumir. po elegiría y por qué? ¿Qué modelo(s) de proceso de software
3.3. Describa tres situaciones de la vida real en las que el elegiría y por qué?
cliente y el usuario final son el mismo. Describa tres situa- 3.9. Se le ha nombrado gestor de proyecto de software de una
ciones en que son diferentes. compañía que trabaja en el mundo de la ingeniería genética.
Su trabajo es dirigir el desarrollo de un nuevo producto de soft-
3.4. Las decisiones tomadas por una gestión experimentada ware que acelere el ritmo de impresión de genes. El trabajo es
pueden tener un impacto significativo en la eficacia de un equi-
orientado a I+D, pero la meta es fabricar el producto dentro del
po de ingeniería del software. Proporcione cinco ejemplos para
siguiente año. ¿Qué estructura de equipo elegiría y por qué?
ilustrar que es cierto.
¿Qué modelo(s) de proceso de software elegiría y por qué?
3.5. Repase el libro de Weinberg [WEI86] y escriba un resu- 3.10. Como muestra la Figura 3.1, basándose en los resulta-
men de dos o tres páginas de los aspectos que deberían tener- dos de dicho estudio, los documentos parecen tener más uso
se en cuenta al aplicar el modelo MOI. que valor. ¿Por qué cree que pasó esto y qué se puede hacer
3.6. Se le ha nombrado gestor de proyecto dentro de una para mover el punto documentos por encima de la línea de
organización de sistemas de información. Su trabajo es cons- regresión en el gráfico? Es decir, ¿qué se puede hacer para
tniir una aplicación que es bastante similar a otras que ha cons- mejorar el valor percibido de los documentos?
truido su equipo, aunque ésta es mayor y más compleja. Los 3.11. Se le ha pedido que desarrolle una pequeña aplicación
requisitos han sido detalladamente documentados por el clien- que analice todos los cursos ofrecidos por la universidad e
te. ¿Qué estructura de equipo elegiría y por qué? ¿Qué mode- informe de las notas medias obtenidas en los cursos (para un
lo(~)de proceso de software elegiría y por qué? periodo determinado). Escriba una exposición del alcance que
3.7. Se le ha nombrado gestor de proyecto de una pequeña abarca este problema.
compañía de productos software. Su trabajo consiste en cons- 3.12. Haga una descomposición funcional de primer nivel
truir un producto innovador que combine hardware de reali- de la función diseño de página tratado brevemente en la
dad virtml con software innovador. Puesto que la competencia Sección 3.3.2.

Una excelente serie de cuatro volúmenes escrito por Wein- proporcionar una nueva visión profunda de los aspectos del
berg (Quality Software Management, Dorset House, 1992, proyecto de software y de su gestión. Purba y Shah (How to
1993,1994,1996)introduce los conceptos básicos sobre sis- Manage a Successful Software Project, Wiley, 1995) presen-
temas y conceptos de gestión, explica cómo usar medicio- tan un número de estudios de casos de proyectos que indican
nes eficazmente y menciona la «acción congruente», la por qué unos fracasaron y otros fueron un éxito. Bennatan
habilidad de «encajar» las necesidades del gestor, del per- (Software Pi-oject Management in a ClientlServer Environ-
sonal técnico y las del negocio. Proporciona información ment, Wiley, 1995) estudia aspectos específicos de gestión
Útil tanto a los gestores noveles como a los experimentados. asociados con el desarrollo de sistemas cliente/servidor.
Brooks (The Mythical Man-Month, Aniversary Edition, Se puede argumentar que el aspecto más importante de la
Addison-Wesley, 1995) ha actualizado su clásico libro para gestión del proyecto de software es la gestión de personal. El

51
INGENIERfA DEL SOFTWARE. UN ENFOQUE PRÁCTICO

libro definitivo sobre este tema lo escribieron DeMarco y Lis- jo más eficazmente. House (The Human Side of Project
ter [DEM98], pero se han publicado en los Últimos años los Management, Addison-Wesley, 1988) y Crossby (Running
siguientes libros donde se examina su importancia: Things: The art of Making Things Happen, McGraw-Hill,
Beaudouin-Lafon, M., Computer Supported Coopera- 1989) proporcionan directrices prácticas para gestores que
tive Work, Wiley-Liss, 1999. deban tratar con problemas humanos y técnicos.
Carmel, E., Global Software Teams: Collaborating Aunque no están relacionados específicamente con el
Across Borders and Time Zones, Prentice Hall, 1999. mundo del software, y algunas veces sufren demasiadas
Humphrey, W. S., Managing Technical People: Inno- simplificaciones y amplias generalizaciones, los libros de
vation, Teamwork, and the Software Process, Addison-Wes- gran éxito de Drucker (Management Challengesfor the 2ist
ley 1997. Century, Harperbusines, 1999), Buckingham y Coffman
Humphrey, W. S., Introduction to the Team of Software (First, Break Al1 the Rules: What the World’s Greatest
Process, Addison-Wesley, 1999. Managers Do DifSerently, Simon & Schuster, 1999) y Chris-
Jones, P. H., Handbook of Team Design: A Practitio- tensen (The Innovator’s Dilemma, Harvard Business School
ner’s Guide to Team Systems Development, McGraw-Hill, Press, 1997) enfatizan «nuevas reglas» definidas por una
1997. economía que cambia con rapidez. Viejos títulos como The
Karolak, D. S., Global Software Development: Mana- One Minute Manager e In Search of Excellence continúan
ging Virtual Teams and Environments, IEEE Computer proporcionando enfoques valiosos que pueden ayudarle a
Society, 1998. gestionar los temas relacionados con el personal de un modo
Mayer, M., The Virtual Edge: Embracing Technology más eficiente.
for Distributed Project Team Success, Project Management En Internet están disponibles una gran variedad de fuen-
Institute Publications, 1999. tes de información relacionadas con temas de gestión de pro-
Otro excelente libro de Weinberg [WEI86] es lectura yectos de software. Se puede encontrar una lista actualizada
obligada para todo gestor de proyecto y jefe de equipo. Le con referencias a sitios (páginas) web que son relevantes para
dará una visión interna y directrices para realizar su traba- los proyectos de software en http://www.pressmanS.cotn.

52