ndice

Conceptos sobre Gestin de Proyectos 1

El espectro de la Gestin. Las 4 Ps. 2

Personal
Participantes
Jefes de equipo 3
Equipo de Software 4
Organigramas de equipo genricos
Paradigmas de organizacin 5
Toxicidad de equipo 6
Aspectos sobre la coordinacin y la comunicacin
Tcnicas de coordinacin de proyectos 7

Producto
mbito del software
Descomposicin del problema 8

Proceso
Modelo de Procesos
Maduracin del producto y del proceso 9
Descomposicin del proceso 10

Proyecto 11
El principio de W5HH 12
Prcticas Crticas 13
Gestin de Proyectos de Software es 14






1

Conceptos sobre Gestin de Proyectos

En el prefacio de su libro sobre gestin de proyectos de software, Meiler Page-
Jones dice una frase que pueden corroborar muchos asesores de ingeniera del software:
He visitado docenas de empresas, buenas y malas, y he observado a muchos
administradores de proceso de datos, tambin buenos y malos. Frecuentemente, he visto
con horror cmo estos administradores luchaban intilmente contra proyectos de
pesadilla, sufriendo por fechas lmite 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 sntomas que resultan de una serie de problemas
tcnicos y de gestin. Sin embargo, si se hiciera una autopsia de cada proyecto, es muy
probable que se encontrara un denominador comn constante: una dbil gestin.

En este captulo consideraremos los conceptos clave que llevan a una gestin
efectiva de proyectos de software.


Qu es?
La gestin de proyecto implica la planificacin, supervisin y control del
personal, del proceso y de los eventos que ocurren mientras evoluciona el software
desde la fase preliminar a la implementacin operacional.

Quin lo hace?
Los gestores del proyecto planifican, supervisan y controlan el trabajo de un
equipo de ingenieros de software

Por qu es importante?
La construccin de software de computadoras es una empresa compleja,
particularmente si participa mucha gente, trabajando durante un periodo de tiempo
relativamente largo.

Cules son los pasos?
Comprender las cuatro Ps (personal, producto, proceso y proyecto). El personal
debe estar organizado para desarrollar el trabajo del software con efectividad. Debe
seleccionarse el proceso adecuado para el personal y el producto. El proyecto debe
planificarse estimando el esfuerzo y el tiempo para cumplir las tareas; estableciendo
puntos de control de calidad y estableciendo mecanismos para controlar y supervisar el
trabajo definido en la planificacin.

Cmo puedo estar seguro de que lo he hecho correctamente?
Nunca estas completamente seguro de que el plan de proyecto es correcto hasta
que no has entregado un producto de alta calidad dentro del tiempo y del presupuesto.
Sin embargo, un gestor de proyectos hace lo correcto cuando estimula al personal para
trabajar juntos como un equipo efectivo, centrando su atencin en las necesidades del
cliente y en la calidad del producto.





2

El espectro de la Gestin. Las 4 Ps.

La gestin eficaz de un proyecto de software se centra en las 4 Ps: personal,
producto, proceso y proyecto. Un gestor que no fomenta una minuciosa comunicacin
con el cliente al principio de la evolucin del proyecto se arriesga a construir una
elegante solucin para un problema equivocado. El administrador que presta poca
atencin al proceso corre el arriesgo de arrojar mtodos tcnicos y herramientas eficaces
al vaco. El gestor que emprende un proyecto sin un plan solido arriesga el xito del
producto.

Personal: el factor humano es tan importante que el instituto de ingeniera del
software ha desarrollado un modelo de madurez de la capacidad de gestin del personal.
Este modelo define las siguientes reas clave para el personal que desarrolle software:
reclutamiento, seleccin, gestin de rendimiento, entrenamiento, retribucin, desarrollo
de la carrera, diseo de la organizacin del trabajo, desarrollo cultural y espritu de
equipo.

Producto: antes de poder planificar un proyecto, se deberan establecer los
objetivos y el mbito del producto, se deberan considerar soluciones alternativas a
identificar las dificultades tcnicas y de gestin. Sin esta informacin, es imposible
definir unas estimaciones razonables del coste; una valoracin efectiva del riesgo, una
subdivisin realista de las tareas del proyecto o una planificacin del proyecto que
proporcione una indicacin fiable del progreso.
El desarrollador del software y el cliente deben reunirse para definir los objetivos
del producto y su mbito. Los objetivos identifican las metas generales del proyecto. El
mbito identifica los datos primarios, funciones y comportamientos que caracterizan al
producto. Una vez que se han entendido los objetivos y el mbito del producto, se
consideran soluciones alternativas.

Proceso: proporciona la estructura desde la que se puede establecer un detallado
plan para el desarrollo del software. Un pequeo nmero de actividades estructurales se
puede aplicar a todos los proyectos de software, sin tener en cuenta su tamao o
complejidad. Diferentes conjuntos de tareas permiten a las actividades estructurales
adaptarse a las caractersticas del proyecto de software y a los requisitos del equipo del
proyecto.

Proyecto: Para evitar el fracaso del proyecto, el gestor y los ingenieros de
software que construyeron el producto deben eludir un conjunto de seales de peligro
comunes; comprender los factores del xito crticos que conducen a la gestin correcta
del proyecto y desarrollar un enfoque de sentido comn para planificar, supervisar y
controlar el proyecto.



3

Definicin bien detallada de cada concepto:
PERSONAL

Los participantes.
El proceso del software lo componen participantes que pueden clasificarse en una
de estas cinco categoras:
Gestores superiores, que definen los aspectos de negocios que a menudo tienen
una significativa influencia en el proyecto.
Gestores (tcnicos) del proyecto, que deben planificar, motivar, organizar y
controlar a los profesionales que realizan el trabajo de software.
Profesionales, que proporcionan las capacidades tcnicas necesarias para la
ingeniera de un producto o aplicacin.
Clientes, que especifican los requisitos para la ingeniera del software y otros
elementos que tienen menor influencia en el resultado.
Usuarios finales, que interaccionan con el software una vez que se ha entregado
para la produccin.

Los jefes de equipo.
La gestin de un proyecto es una actividad intensamente humana, y por esta razn,
los profesionales competentes del software a menudo no son buenos jefes de equipo.
Simplemente no tienen la mezcla adecuada de capacidades del personal.

En qu nos fijamos cuando seleccionamos a alguien para conducir un proyecto de
software?
Por una parte se sugiere seguir el modelo MOI.
Motivacin. La habilidad para motivar al personal tcnico para que produzca
conforme a sus mejores capacidades.
Organizacin. La habilidad para amoldar procesos existentes que permita al
concepto inicial transformarse en un producto final.
Ideas o innovacin. La habilidad para motivar al personal para crear y sentirse
creativos incluso cuando deban de trabajar dentro de los lmites establecidos para un
producto o aplicacin de software particular.
El xito de los gestores de proyecto se basa en aplicar un estilo de gestin en la
resolucin de problemas. Es decir, un gestor de proyectos de software debera
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 que la calidad es
importante y que no debe verse comprometida.

Otro punto de vista resalta cuatro puntos clave.
Resolucin del problema. Un gestor eficiente de un proyecto de software puede
diagnosticar los aspectos tcnicos y de organizacin ms relevantes, estructurar una
solucin sistemticamente o motivar apropiadamente a otros profesionales para que
desarrollen la solucin, aplicar las lecciones aprendidas de anteriores proyectos a las
nuevas situaciones, mantenerse lo suficientemente flexible para cambiar la gestin si los
intentos iniciales de resolver el problema no dan resultado.
Dotes de gestin. Un buen gestor de proyectos debe tomar las riendas. Debe tener
confianza para asumir el control cuando sea necesario y la garanta para permitir que los
buenos tcnicos sigan sus instintos.


4

Incentivos por logros. Para optimizar la productividad de un equipo de proyecto,
un gestor debe recompensar la iniciativa y los logros, y demostrar a travs de sus
propias acciones que no se penalizar si se corren riesgos controlados.
Influencia y construccin de espritu de equipo. Un gestor de proyecto eficiente
debe ser capaz de leer a la gente; debe ser capaz de entender seales verbales y no
verbales y reaccionar ante las necesidades de las personas que mandan esas seales. El
gestor debe mantener el control en situaciones de gran estrs.


El equipo de software
Las siguientes opciones pueden aplicarse a los recursos humanos de un proyecto
que requiere n personas trabajando durante k aos:
1- n individuos son asignados a m diferentes tareas funcionales, la coordinacin es
responsabilidad del gestor del software que puede que tenga otros seis proyectos
de los que preocuparse.
2- y individuos son asignados a m diferentes tareas funcionales (m<n) de manera
que se establecen equipos informales; se puede nombrar un lder al efecto; la
coordinacin entre los equipos es responsabilidad de un gestor del software.
3- n individuos se organizan en t equipos; a cada equipo se le asignan una o ms
tareas funcionales; cada equipo tiene una estructura especfica que se define para
todos los equipos que trabajan en el proyecto; la coordinacin es controlada por
el equipo y por el gestor del proyecto de software.

Cmo debera estar organizado un equipo de software?
Mantei sugiere tres organigramas de equipo genricos:
Descentralizado democrtico (DD). Este equipo de ingeniera del software no
tiene un jefe permanente. Ms bien, (se nombran coordinadores de tareas a corto plazo y
se sustituyen por otros para diferentes tareas) las decisiones sobre problemas y los
enfoques se hacen por consenso del grupo. La comunicacin entre los miembros del
equipo es horizontal.
Descentralizado controlado (DC). Este equipo de ingeniera del software tiene un
jefe definido que coordina tareas especficas y jefes secundarios que tienen
responsabilidades sobre subtareas. La resolucin de problemas sigue siendo una
actividad del grupo, pero la implementacin de soluciones se reparte entre subgrupos
por el jefe de equipo. La comunicacin entre subgrupos e individuos es horizontal.
Tambin hay comunicacin vertical a lo largo de la jerarqua de control.
Centralizado controlado (CC). El jefe del equipo se encarga de la resolucin de
problemas a alto nivel y la coordinacin interna del equipo. La comunicacin entre el
jefe y los miembros del equipo es vertical.

Qu factores deberamos considerar cuando estructuramos un equipo de
software?
Mantei describe siete factores de un proyecto que deberan considerarse cuando
se planifica el organigrama de equipos:
1- la dificultad del problema que hay que resolver
2- el tamao del programa resultante en lneas de cdigo o puntos de funcin.
3- el tiempo que el equipo estar junto.
4- el grado en que el problema puede ser modularizado.
5- la calidad requerida y fiabilidad del sistema que se va a construir.
6- la rigidez de la fecha de entrega.


5

7- el grado de sociabilidad requerido para el proyecto.

Debido a que una estructura centralizada realiza las tareas ms rpidamente, es
la ms adecuada para manejar problemas sencillos. Los equipos descentralizados
generan ms y mejores soluciones que los individuales. Por tanto, estos equipos tienen
ms probabilidades de xito en la resolucin de problemas complejos. Puesto que el
equipo DC es centralizado para la resolucin de problemas, tanto el organigrama de
equipo DC como el de CC pueden aplicarse con xito para problemas sencillos. La
estructura DD es la mejor para problemas difciles.
Como el rendimiento de un equipo es inversamente proporcional a la cantidad de
comunicacin que se debe entablar, los proyectos muy grandes son mejor dirigidos por
equipos con estructura CC o DC, donde se pueden formar fcilmente subgrupos.
El tiempo que los miembros del equipo vayan a vivir juntos afecta a la moral
del equipo. Se ha descubierto que los organigramas de equipo tipo DD producen una
moral ms alta y ms satisfaccin por el trabajo y son, por tanto, buenos para equipos
que permanecern juntos durante mucho tiempo.
El organigrama de equipo DD se aplica mejor a problemas con modularidad
relativamente baja, debido a la gran cantidad de comunicacin que se necesita. Los
organigramas CC o DC funcionan bien cuando es posible una modularidad alta (y la
gente puede hacer cada uno lo suyo).
Los equipos CC y DC producen menos defectos que los equipos DD, pero estos
datos tienen mucho que ver con las actividades especficas de garanta de calidad que
aplica el equipo. Los equipos descentralizados requieren generalmente ms tiempo
para completar un proyecto que un organigrama centralizado y al mismo tiempo son
mejores cuando se precisa una gran cantidad de comunicacin.


Constantine sugiere cuatro paradigmas de organizacin para equipos de
ingeniera del software:
1- Un paradigma cerrado estructura a un equipo con una jerarqua tradicional de
autoridad. Estos equipos trabajan bien cuando producen software similar a otros
anteriores.
2- El paradigma aleatorio estructura al equipo libremente y depende de la iniciativa
individual de los miembros del equipo. Cuando se requiere innovacin o avances
tecnolgicos, los equipos de paradigma aleatorio son excelentes.
3- El paradigma abierto el trabajo se desarrolla en colaboracin, con mucha
comunicacin y toma de decisiones consensuadas. Estos equipos son adecuados
para la resolucin de problemas complejos, pero pueden no tener un rendimiento
tan eficiente como otros equipos.
4- El paradigma sincronizado se basa en la compartimentacin natural de un
problema y organiza los miembros del equipo para trabajar en partes del problema
con poca comunicacin activa entre ellos.

Para conseguir un equipo de alto rendimiento.
Los miembros del equipo deben confiar unos en otros.
La distribucin de habilidades debe adecuarse al problema.
Para mantener la unin del equipo, los inconformistas tienen que ser excluidos del
mismo.



6

Cualquiera que sea la organizacin del equipo, el objetivo para todos los gestores de
proyecto es colaborar a crear un equipo que presente cohesin.

Tendemos a usar la palabra equipo demasiado libremente en el mundo de los
negocios, denominando equipo a cualquier grupo de gente asignado para trabajar
junta. Pero muchos de estos grupos no parecen equipos. No tienen una definicin
comn de xito o un espritu de equipo identificable. Lo que falta es un fenmeno que
denominamos cuajar.

Un equipo cuajado es un grupo de gente tejido fuertemente. Una vez que el equipo
empieza a cuajar, la probabilidad de xito empieza a subir. El equipo puede convertirse
en imparable, no necesitan ser dirigidos de una manera tradicional y no necesitan que
se les motive. Estn en su gran momento.
Los miembros de equipos cuajados son significativamente ms productivos y estn ms
motivados que la media. Comparten una meta comn, una cultura comn.

Por otra parte muchos equipos sufren lo que se llama toxicidad de equipo se
definen cinco factores que fomentan un entorno de equipo txico potencial:
1- una atmsfera de trabajo frentica en la que los miembros del equipo gastan
energa y se descentran de los objetivos del trabajo a desarrollar.
2- alta frustracin causada por factores tecnolgicos, del negocio, o personales
que provocan friccin entre los miembros del equipo.
3- procedimientos coordinados pobremente o fragmentados, o una definicin pobre
o impropiamente elegida del modelo de procesos que se convierte en un
obstculo a saltar.
4- definicin confusa de los papeles a desempear produciendo una falta de
responsabilidad y la acusacin correspondiente.
5- continua y repetida exposicin al fallo que conduce a una prdida de confianza y
a una cada de la moral.

Existen varios antitxicos que tratan los problemas comunes destacados
anteriormente.
Para evitar un entorno de trabajo frentico, el gestor de proyectos debera estar
seguro de que el equipo tiene acceso a toda la informacin requerida para hacer el
trabajo y que los objetivos y metas principales, no deberan modificarse a menos que
fuese absolutamente necesario. Adems, las malas noticias no deberan guardarse en
secreto, sino entregarse al equipo tan pronto como fuese posible.
Aunque la frustracin tiene muchas causas, los desarrolladores de software a
menudo la sienten cuando pierden la autoridad para controlar la situacin. Un equipo de
software puede evitar la frustracin si recibe tanta responsabilidad para la toma de
decisiones como sea posible. Cuanto ms control se le d al equipo para tomar
decisiones tcnicas y del proceso, menos frustracin sentirn los miembros del equipo.
Una eleccin inapropiada del proceso del software puede ser evitada de dos
formas: (1) Estando seguros de que las caractersticas del software a construir se ajustan
al rigor del proceso elegido, y (2) permitiendo al equipo seleccionar el proceso.
El gestor de proyectos de software debera refinar claramente los roles y las
responsabilidades antes del comienzo del proyecto.
El gestor de proyectos de software debera refinar los roles y las
responsabilidades antes del comienzo del proyecto. El equipo debera establecer su


7

propio mecanismo para la responsabilidad y definir una serie de enfoques correctivos
cuando un miembro del equipo falla en el desarrollo.
Todo equipo de software experimenta pequeos fallos. La clave para eliminar una
atmsfera de fallos ser establecer tcnicas basadas en el equipo para retroalimentar y
solucionar el problema. Adems, cualquier fallo de un miembro del equipo debe ser
considerado como un fallo del equipo.

Aspectos sobre la coordinacin y la comunicacin
El equipo de ingeniera del software debe establecer mtodos efectivos para
coordinar a la gente que realiza el trabajo.
Para lograr esto se deben establecer mecanismos de comunicacin formal e
informal entre los miembros del equipo y entre mltiples equipos. La comunicacin
formal se lleva a cabo por escrito, con reuniones organizadas y otros canales de
comunicacin relativamente no interactivos e impersonales. La comunicacin informal
es ms personal.

Tcnicas de coordinacin de proyectos que se categorizan de la siguiente manera:
Formal, enfoque impersonal. Incluyen documentos de ingeniera del software y
entregas, memorandos tcnicos, hitos del proyecto, planificaciones del programa y
herramientas de control del proyecto, peticiones de cambios y documentacin relativa,
informes de seguimiento de errores e informacin almacenada.
Formal, procedimientos interpersonales. Se centra en las actividades de garanta
de calidad aplicada a productos de ingeniera del software. Estos incluyen reuniones de
revisin de estado e inspecciones de diseo y de cdigo.
Informal, procedimientos interpersonales. Incluyen reuniones de grupo para la
divulgacin de informacin y resolucin de problemas as como definicin de
requisitos y del personal de desarrollo.
Comunicacin electrnica. Comprende correo electrnico, boletines de noticias
electrnicos y sistemas de videoconferencia.
Red interpersonal. Discusiones informales con los miembros del equipo y con
personas que no estn en el proyecto pero que pueden tener experiencia o una profunda
visin que puede ayudar a los miembros del equipo.

Es interesante resaltar que las redes interpersonales fueron catalogadas como las
tcnicas de mayor valor de coordinacin y de comunicacin.



8

PRODUCTO
Debemos examinar el producto y el problema a resolver justo al inicio del
proyecto. Por lo menos se debe establecer el mbito del producto y delimitarlo.

mbito del software
La primera actividad de gestin de un proyecto de software es determinar el
mbito del software. El mbito se define respondiendo a las siguientes cuestiones:
Contexto. Cmo encaja el software a construir en un sistema, producto o
contexto de negocios mayor y qu limitaciones se imponen como resulta do del
contexto?
Objetivos de informacin. Qu objetos de datos visibles al cliente se obtienen del
software? Qu objetos de datos son requeridos de entrada?
Funcin y rendimiento. Qu funcin realiza el software para transformar la
informacin de entrada en una salida? Hay caractersticas de rendimiento especiales
que abordar?
El mbito de un proyecto de software debe ser unvoco y entendible a niveles de
gestin y tcnico. Los enunciados del mbito del software deben estar delimitados.
Es decir, los datos cuantitativos (por ejemplo: nmero de usuarios simultneos,
tamao de la lista de correo, mximo tiempo de respuesta permitido) se establecen
explcitamente; se anotan las limitaciones (por ejemplo: el coste del producto limita el
tamao de la memoria) y se describen los factores de reduccin de riesgos.

Si no puede delimitar una caracterstica del software que se intenta construir considere
la caracterstica como un riesgo principal del proyecto.

Descomposicin del problema
La descomposicin del problema es una actividad que se asienta en el ncleo del
anlisis de requisitos del software. Durante la actividad de exposicin del mbito no se
intenta descomponer el problema totalmente. Ms bien, la descomposicin se aplica en
dos reas principales: (1) la funcionalidad que debe entregarse y (2) el proceso que se
emplear para entregarlo.

Los seres humanos tienden a aplicar la estrategia de divide y vencers cuando se
enfrentan a problemas complejos. Dicho de manera sencilla, un problema complejo se
parte en problemas ms pequeos que resultan ms manejables. sta es la estrategia que
se aplica al inicio de la planificacin del proyecto.

Para desarrollar un plan de proyecto razonable, tiene que descomponer funcionalmente
el problema a resolver

Las funciones del software, descritas en la exposicin del mbito, se evalan y
refinan para proporcionar ms detalle antes del comienzo de la estimacin. Puesto que
ambos, el coste y las estimaciones de la planificacin temporal, estn orientados
funcionalmente, un pequeo grado de descomposicin suele ser til.

A medida que evoluciona la exposicin del mbito, un primer nivel de particin ocurre
de forma natural.



9

PROCESO

Modelo de proceso
Las fases genricas que caracterizan el proceso de software definicin, desarrollo
y soporte son aplicables a todo software. El problema es seleccionar el modelo de
proceso apropiado para la ingeniera del software que debe aplicar el equipo del
proyecto. Existe gran gama de paradigmas de ingeniera del software:
- El modelo secuencia1 lineal
- el modelo de prototipo
- el modelo DRA
- el modelo incremental
- el modelo en espiral
- el modelo en espiral WINWIN
- el modelo de desarrollo basado
(ensamblaje) en componentes
- el modelo de desarrollo
concurrente
- el modelo de mtodos formales
- el modelo de tcnicas de cuarta
generacin
Uno vez elegido el modelo de proceso, acompelo con el mnimo conjunto de toreos de
trabajo y productos que desembocaron en un producto de alta calidad evite la
capacidad de destruccin del proceso.

El gestor del proyecto debe decidir qu modelo de proceso es el ms adecuado
para (1) los clientes que han solicitado el producto y la gente que realizar el trabajo; (2)
las caractersticas del producto en s, y (3) el entorno del proyecto en el que trabaja el
equipo de software. Cuando se selecciona un modelo de proceso, el equipo define
entonces un plan de proyecto preliminar basado en un conjunto de actividades
estructurales. Una vez establecido el plan preliminar, empieza la descomposicin del
proceso. Es decir, se debe crear un plan completo reflejando las tareas requeridas a las
personas para cubrir las actividades estructurales.

Maduracin del producto y del proceso
La planificacin de un proyecto empieza con la maduracin del producto y del
proceso. Todas las funciones que se deben tratar dentro de un proceso de ingeniera por
el equipo de software deben pasar por el conjunto de actividades estructurales que se
han definido para una organizacin de software.

Asuma que la organizacin ha adoptado el siguiente conjunto de actividades
estructurales:
Comunicacin con el cliente, tareas requeridas para establecer la obtencin de requisitos
eficiente entre el desarrollador y el cliente.
Planificacin, tareas requeridas para definir los recursos, la planificacin temporal del
proyecto y cualquier informacin relativa a l.
Anlisis del riesgo, tareas requeridas para valorar los riesgos tcnicos y de gestin.
Ingeniera, tareas requeridas para construir una o ms representaciones de la aplicacin.
Construccin y entrega- tareas requeridas para construir, probar, instalar y proporcionar
asistencia al usuario (por ejemplo: documentacin y formacin).
Evaluacin del cliente, tareas requeridas para obtener informacin de la opinin del
cliente basadas en la evaluacin de las representaciones de software creadas durante la
fase de ingeniera e implementadas durante la fase de instalacin.



10

Recuerde.... las actividades estructurales se aplican en todos los proyectos, no hoy
excepciones.

Los miembros del equipo que trabajan en cada funcin aplicarn todas las actividades
estructurales.
El trabajo del gestor del proyecto (y de otros miembros del equipo) es estimar los
requisitos de recursos, poner fechas de inicio y finalizacin para las tareas y los
productos a fabricar.

La descomposicin del producto y del proceso se produce simultneamente con la
evolucin del plan de proyecto.

Descomposicin del proceso
Un equipo de software debera tener un grado significativo de flexibilidad en la
eleccin del paradigma de ingeniera del software que resulte mejor para el proyecto y
de las tareas de ingeniera del software que conforman el modelo de proceso una vez
elegido.
Un proyecto relativamente pequeo similar a otros que se hayan hecho
anteriormente se debera realizar con el enfoque secuencia1 lineal. Si hay lmites de
tiempo muy severos y el problema se puede compartimentar mucho, el modelo
apropiado es el DRA (en ingls RAD). Si la fecha lmite est tan prxima que no va a
ser posible entregar toda la funcionalidad, una estrategia incremental puede ser lo mejor.
Similarmente, proyectos con otras caractersticas (p. ej.: requisitos inciertos, nuevas
tecnologas, clientes difciles, potencialidad de reutilizacin) llevarn a la seleccin de
otros modelos de proceso.

Una vez que se ha elegido el modelo de proceso, la estructura comn de proceso
(ECP) se adapta a l. En todos los casos, el ECP puede adaptarse al paradigma.
Funcionar para modelos lineales, para modelos iterativos e incrementales, para
modelos de evolucin e .incluso para modelos concurrentes o de ensamblaje de
componentes. El ECP es invariable y sirve como base para todo el trabajo de software
realizado por una organizacin. Pero las tareas de trabajo reales s varan.
La descomposicin del proceso comienza cuando el gestor del proyecto pregunta:
Cmo vamos a realizar esta actividad ECP? Por ejemplo, un pequeo proyecto,
relativamente simple, requiere las siguientes tareas para la actividad de comunicacin
con el cliente:
1. Desarrollar una lista de aspectos que se han de clarificar.
2. Reunirse con el cliente para resolver los aspectos que se han de clarificar.
3. Desarrollar conjuntamente una exposicin del mbito del proyecto.
4. Revisar el alcance del proyecto con todos los implicados.
5. Modificar el alcance del proyecto cuando se requiera.
Estos acontecimientos pueden ocurrir en un periodo de menos de 48 horas.
Representan una descomposicin del problema apropiado para proyectos pequeos
relativamente sencillos.

Ahora, consideremos un proyecto ms complejo que tenga un mbito ms amplio y un
mayor impacto comercial.
Un proyecto como se podra requerir las siguientes tareas para la actividad de
comunicacin con el cliente:
1. Revisar la peticin del cliente.


11

2. Planificar y programar una reunin formal con el cliente.
3. Realizar una investigacin para definir soluciones propuestas y enfoques existentes.
4. Preparar un documento de trabajo y una agenda para la reunin formal.
5. Realizar la reunin.
6. Desarrollar conjuntamente mini especificaciones que reflejen la informacin, funcin
y caractersticas de comportamiento del software.
7. Revisar todas las mini especificaciones para comprobar su correccin, su
consistencia, la ausencia de ambigedades.
8. Ensamblar las mini especificaciones en un documento de alcance del proyecto.
9. Revisar ese documento general con todo lo que pueda afectar.
10. Modificar el documento de alcance del proyecto cuando se requiera.

Ambos proyectos realizan la actividad estructural que denominamos comunicacin con
el cliente, pero el equipo del primer proyecto lleva a cabo la mitad de tareas de
ingeniera del software que el segundo.

Aplique siempre la FCf (Estructura Comn de Proceso), sin tener en cuenta el tamao,
criticidad o tipo del proyecto. Las tareas pueden variar pero la ECf no.


PROYECTO
Para gestionar un proyecto de software con xito, debemos comprender qu puede
ir mal (para evitar esos problemas) y cmo hacerlo bien, John Reel define diez seales
que indican que un proyecto de sistemas de informacin est en peligro:

1. La gente del software no comprende las necesidades del cliente.
2. El mbito del producto est definido pobremente.
3. Los cambios estn mal realizados.
4. La tecnologa elegida cambia.
5. Las necesidades del negocio cambian o estn mal definidas.
6. Las fechas de entrega no son realistas.
7. Los usuarios se resisten.
8. Se pierden los patrocinadores o nunca se obtuvieron adecuadamente.
9. El equipo del proyecto carece del personal con las habilidades apropiadas.
10. Los gestores y los desarrolladores evitan buenas prcticas y sabias lecciones.

Los profesionales veteranos de la industria hacen referencia frecuentemente a la regla
90-90 cuando estudian proyectos de software particularmente difciles: el primer 90%
de un sistema absorbe el 90% del tiempo y del esfuerzo asignado. El ltimo 10% se
lleva el otro 90% del esfuerzo y del tiempo asignado. Los factores que conducen a la
regla 90-90 estn contenidos en las diez seales destacadas en la lista anterior.

Cmo acta un gestor para evitar los problemas sealados anteriormente?
Reel sugiere una aproximacin de sentido comn a los proyectos de software dividida
en cinco partes:
Empezar con el pie derecho. Esto se realiza trabajando duro para comprender el
problema a solucionar y estableciendo entonces objetivos y expectativas realistas para
cualquiera que vaya a estar involucrado en el proyecto.


12

Mantenerse. Muchos proyectos no realizan un buen comienzo y entonces se desintegran
lentamente. Para mantenerse, el gestor del proyecto debe proporcionar incentivos para
conseguir una rotacin del personal mnimo, el equipo debera destacar la calidad en
todas las tareas que desarrolle y los gestores veteranos deberan hacer todo lo posible
por permanecer fuera de la forma de trabajo del equipo.
Seguimiento del Progreso. Para un proyecto de software, el progreso se sigue mientras
se realizan los productos del trabajo y se aprueban como parte de una actividad de
garanta de calidad.
Tomar Decisiones Inteligentes. En esencia, las decisiones del gestor del proyecto y del
equipo de software deberan seguir siendo sencillas. Siempre que sea posible, utilice
software del mismo comercial o componentes de software existentes; evite personalizar
interfaces cuando estn disponibles aproximaciones estndar; identifique y elimine
entonces riesgos obvios; asigne ms tiempo del que pensaba necesitar para tareas
arriesgadas o complejas.

Realizar un Anlisis Postmortem (despus de finalizar el proyecto). Establecer un
mecanismo consistente para extraer sabias lecciones de cada proyecto.
Evaluar la planificacin real y la prevista, reunir y analizar mtricas del proyecto de
software y realimentar con datos de los miembros del equipo y de los clientes, y
guardar los datos obtenidos en formato escrito.

El principio de W5HH
Se necesita un principio de organizacin que haga una simplificacin con el fin de
proporcionar planes sencillos para proyectos pequeos.
Boehm sugiere un enfoque que trate los objetivos, hitos y planificacin,
responsabilidades, enfoque tcnico y de gestin, y los recursos requeridos del proyecto.
Boehm lo llama el principio WWWWWHH, despus de una serie de preguntas que
conducen a la definicin de las caractersticas clave del proyecto y el plan del proyecto
resultante:
Por qu se desarrolla el sistema? Esto permite a todas las partes evaluar la validez de
las razones del negocio para el trabajo del software.
Dicho de otra forma, Justifica el propsito del negocio el gasto en personal, tiempo, y
dinero?
Qu se realizar y cundo? Ayuda al equipo a establecer la planificacin del proyecto
identificando las tareas clave del proyecto y los hitos requeridos por el cliente.
Quin es el responsable de una funcin? Anteriormente sealamos que el papel y la
responsabilidad de cada miembro del equipo de software deben estar definida.
Dnde estn situados organizacionalmente? No todos los roles y responsabilidades
residen en el equipo de software. El cliente, los usuarios, y otros directivos tambin
tienen responsabilidades.
Cmo estar realizado el trabajo desde el punto de vista tcnico y de gestin? Una
vez establecido el mbito del producto, se debe definir una estrategia tcnica y de
gestin para el proyecto.
Qu cantidad de cada recurso se necesita? Esto se deriva de las estimaciones
realizadas basadas en respuestas a las preguntas anteriores.

El principio W5HH de Boehm es aplicable sin tener en cuenta el tamao o la
complejidad del proyecto de software. Las preguntas sealadas proporcionan un perfil
de planificacin al gestor del proyecto y al equipo de software.



13

Prcticas Crticas
El Concilio Airlie ha desarrollado una lista de prcticas crticas de software
para la gestin basada en el rendimiento. Estas prcticas son utilizadas de un modo
consistente por, y consideradas crticas por, organizaciones y proyectos de software de
mucho xito cuyo rendimiento final es ms consistente que los promedios de la
industria. En un esfuerzo por permitir a una organizacin de software determinar si un
proyecto especfico ha implementado prcticas crticas, el Concilio Airlie ha
desarrollado un conjunto de preguntas para un proyecto:

Gestin formal del riesgo. Cules son los diez riesgos principales para este proyecto?
Para cada uno de los riesgos cul es la oportunidad de que el riesgo se convierta en un
problema y cul es el impacto si lo hace?
Coste emprico y estimacin de la planificacin. Cul es el tamao actual estimado de
la aplicacin de software que ser entregada en la operacin? Cmo se obtuvo?
Gestin de proyectos basada en mtricas. Dispone de un programa de mtricas para
dar una primera indicacin de los problemas del desarrollo? Si es as, cul es la
volatilidad de los requisitos actualmente?
Seguimiento del valor ganado. Informa mensualmente de las mtricas del valor
ganado? Si es as, estn calculadas estas mtricas desde una red de actividades de
tareas para el esfuerzo total a la prxima entrega?
Seguimiento de defectos frente a objetivos de calidad. Realiza el seguimiento e
informa peridicamente del nmero de defectos encontrados en cada prueba de
inspeccin y ejecucin desde el principio del programa y del nmero de defectos que se
corrigen y se producen en la actualidad?
Gestin del programa del personal. Cul es la media de rotacin de la plantilla en los
tres ltimos meses por cada uno de los distribuidores/desarrolladores involucrados en el
desarrollo del software para este sistema?

Si un equipo de proyectos de software no puede responder a estas preguntas, o las
responde inadecuadamente, se debe realizar una revisin completa de las prcticas del
proyecto.



14

Entonces la Gestin de Proyectos de Software

Es una actividad protectora dentro de la ingeniera del software. Empieza antes
de iniciar cualquier actividad tcnica y contina a lo largo de la definicin, del
desarrollo y del mantenimiento del software.
Hay cuatro << Ps >> que tienen una influencia sustancial en la gestin de
proyectos de software -personal, producto, proceso y proyecto-. El personal debe
organizarse en equipos eficaces, motivados para hacer un software de alta calidad y
coordinados para alcanzar una comunicacin efectiva. Los requisitos del producto
deben comunicarse desde el cliente al desarrollador, dividirse (descomponerse) en las
partes que lo constituyen y distribuirse para que trabaje el equipo de software.
El proceso debe adaptarse al personal y al problema. Se selecciona una
estructura comn de proceso, se aplica un paradigma apropiado de ingeniera del
software y se elige un conjunto de tareas para completar el trabajo. Finalmente, el
proyecto debe organizarse de una manera que permita al equipo de software tener
xito.
El elemento fundamental en todos los proyectos de software es el personal.
Los ingenieros del software pueden organizarse en diferentes organigramas de
equipo que van desde las jerarquas de control tradicionales a los equipos de
paradigma abierto. Se pueden aplicar varias tcnicas de coordinacin y
comunicacin para apoyar el trabajo del equipo. En general, las revisiones formales y
las comunicaciones informales persona a persona son las ms valiosas para los
profesionales.