ADMINISTRACI

N DE
PROYECTOS DE
SOFTWARE

La administracin es una actividad muy

necesaria cuando se construyen sistemas y
productos basados en computadora.

La administracin del proyecto involucra

planificacin, monitoreo y control del
personal, procesos y acciones que
ocurren conforme el software evoluciona
desde un concepto preliminar hasta su
despliegue operativo completo.

QUIN LO HACE?

GERENTES
DEL
INGENIERO
PROYECTO
DE
SOFTWARE

Un ingeniero del software

administra sus actividades
cotidianas, planifica,
monitorea y controla las
tareas tcnicas.
Los gerentes de proyecto
planifican, monitorean y
controlan el trabajo de un
equipo de ingenieros de
software.
Los gerentes ejecutivos
coordinan la interfaz entre la
empresa y los profesionales
del software.

CULES SON LOS PASOS?

PERSONAL

PROYECTO

PRODUCTO

PROCESO

Cmo me aseguro de que lo hice bien?

Nunca se est completamente
seguro de que el plan del proyecto
es correcto, hasta que se entrega
un producto de alta calidad a
tiempo y dentro del presupuesto.

Sin embargo, un gerente de

proyecto lo hace bien cuando
alienta al personal del software a
trabajar en conjunto, como un
equipo efectivo, y cuando enfoca
su atencin en las necesidades
del cliente y en la calidad del

PERSONAL

Desde la dcada de 1960 se estudia la formacin

de personal de software motivado y enormemente
calificado.

De hecho, el factor humano es tan importante

que el Software Engineering Institute desarroll un
Modelo de madurez de capacidades del personal
(People-CMM).

Las organizaciones que conforme a este modelo

logran altos niveles de madurez de capacidades de
personal tienen una probabilidad muy elevada de
alcanzar
la
implementacin
de
prcticas
administrativas efectivas en los proyectos de
software.

PRODUCTO

Como desarrolladores de software, todos los

participantes deben reunirse para definir los
objetivos y el mbito del producto.

Los objetivos identifican las metas globales para el

producto.
El mbito identifica los datos, funciones y
comportamientos principales que caracterizan al
producto.
Una vez comprendidos los objetivos y el mbito del
producto, se consideran soluciones alternativas.

PROCESO

Un proceso de software proporciona el marco

conceptual desde el cual puede establecerse un
plan completo para el desarrollo de software.

Un pequeo nmero de actividades de marco

conceptual se aplica a todos los proyectos de
software, sin importar su tamao o complejidad.

Las actividades sombrilla (como el aseguramiento

de la calidad del software, la administracin de
configuracin del software y las mediciones)
recubren el modelo de proceso.

PROYECTO

Los proyectos de software se planean y

controlan debido a una razn principal: es la
nica forma conocida para manejar la
complejidad. Incluso as, los equipos de
software todava batallan.

Para evitar el fracaso del proyecto, un gerente

de proyecto de software y los ingenieros de
software que construyan el producto deben
evitar un conjunto de seales de advertencia
comunes.

EL PERSONAL
Para la mayora de las personas, desde los vicepresidentes
ejecutivos de ingeniera hasta el profesional en el nivel ms
bajo, con frecuencia dan por hecho al personal como el
elemento ms importante en una organizacin.

 En esta seccin se examina a las personas que participan en el

proceso de software y la forma en la que se organizan para
realizar ingeniera de software efectiva.

Los
participante
s

Lderes de
equipo

El equipo de
software

Equipos
giles

Conflictos de
coordinacin

Los participantes
El proceso de software (y todo proyecto de software) est
poblado de participantes, quienes
pueden organizarse en alguna de las siguientes reas:

Gerentes ejecutivos
Gerentes de proyecto
Profesionales
Clientes que especifican los requerimientos
Usuarios finales

Lderes de equipo
La administracin del proyecto es una actividad que implica
mucho trato con la gente; por estarazn, los profesionales
competentes tienen con frecuencia pobre desempeo como lderes
de equipo. Simplemente, no tienen la mezcla justa de habilidades
personales.
En un excelente libro acerca del liderazgo tcnico, Jerry Weinberg
sugiere un modelo MOI de liderazgo:

Motivacin
Organizacin
Ideas o
innovacin

El equipo de software
Existen casi tantas estructuras organizativas humanas para el
desarrollo del software como organizaciones que lo desarrollan.
Para bien o para mal, la estructura organizativa no puede
modificarse fcilmente.
La mejor estructura de equipo depende del estilo
administrativo de la organizacin, del nmero de personas que
formarn el equipo y de sus niveles de habilidad, as como de la
dificultad global del problema.

 Mantei describe siete factores de proyecto que deben

considerarse cuando se planee la estructura de los equipos de
ingeniera de software:
Dificultad del problema que se va a resolver.
Tamao del programa resultante en lneas de cdigo o
puntos de funcin
Tiempo que el equipo permanecer unido (vida del equipo)
Grado en el que puede dividirse en mdulos el problema.
Calidad y confiabilidad requeridas por el sistema que se va a
construir.
Rigidez de la fecha de entrega.
Grado de sociabilidad

 Constantine sugiere cuatro paradigmas organizacionales para

los equipos de ingeniera de software:
Un paradigma
Un paradigma
aleatorio estructura
cerrado estructura
un equipo de manera
un equipo conforme
holgada y depende
a una jerarqua de
de la iniciativa
autoridad tradicional
individual de los
miembros del equipo
Un paradigma
Un paradigma
abierto intenta
sncrono se apoya en
estructurar un
la
equipo de manera
compartimentalizaci
que logre algunos de
n natural de un
los controles
problema y organiza
asociados con el
a los miembros del
paradigma cerrado
equipo

DeMarco y Lister sostienen que los miembros de los

equipos cuajados son significativamente ms
productivos y ms motivados que el promedio.
Comparten una meta comn, una cultura comn y
en muchos casos un sentido de lite que los hace
nicos.
Pero no todos los equipos cuajan. De hecho, muchos equipos sufren
de lo que Jackman llama toxicidad de equipo. Ella define cinco
factores que fomentan un ambiente de equipo potencialmente
txico:

alta frustracin que

causa friccin entre los
miembros del equipo

un proceso de
software
fragmentado o
pobremente
coordinado

una definicin
poco clara de
los roles en el
equipo de
software y

continua y
repetida
exposicin al
fracaso.

 Un equipo de software puede evitar la frustracin si se le da tanta

responsabilidad para la toma de decisiones como sea posible. Un proceso
inadecuado puede evitarse al entender el producto que se va a construir
y a las personas que hacen el trabajo, as como al permitir al equipo
seleccionar el modelo de proceso. El equipo mismo debe establecer sus
propios mecanismos de responsabilidad y definir una serie de enfoques
correctos cuando un miembro del equipo tiene fallos en el desempeo.

Finalmente, la clave para evitar una

atmsfera de fracaso radica en
establecer tcnicas basadas en equipo
para retroalimentarse y resolver
problemas

Equipos giles
Durante las dcadas pasadas, el desarrollo de software gil se ha sugerido como
antdoto a muchos de los problemas que plagan el trabajo en un proyecto de
software.

La filosofa gil alienta la satisfaccin del cliente y la entrega incremental

temprana del software, as como pequeos equipos de proyecto enormemente
motivados, mtodos informales, mnimos productos operativos de ingeniera de
software y simplicidad de desarrollo global.

El pequeo equipo de trabajo enormemente motivado, tambin llamado equipo

gil, adopta la mayora de las caractersticas de los equipos de proyecto de
software exitosos y evita muchas de las toxinas que crean problemas.

No obstante, la filosofa gil subraya la competencia individual, acoplada con la

colaboracin grupal como factores de xito vitales para el equipo.

 Cockburn y Highsmith observan esto cuando escriben:

Si el personal del proyecto es suficientemente bueno, puede usar
casi cualquier proceso y lograr esta asignacin. Si no lo es,
ningn proceso reparar su inadecuacin: personal mata
proceso.
Sin embargo, la falta de apoyo de usuarios y ejecutivos puede
matar al proyecto: poltica mata personal. El apoyo inadecuado
puede impedir que incluso el personal bueno logre esta tarea.

Para hacer uso efectivo de las competencias de cada miembro del equipo y
fomentar la colaboracin efectiva a travs de un proyecto de software, los
equipos giles son:

autoorganizad
os

Un equipo autoorganizado no necesariamente mantiene una sola

estructura de equipo, sino que usa elementos de los paradigmas aleatorio,
abierto y sncrono de Constantine.

Muchos modelos de proceso gil, dan al equipo gil significativa autonoma

para tomar las decisiones administrativas y tcnicas del proyecto
necesarias para hacer que el trabajo se cumpla.

Conforme avanza el proyecto, el equipo se autoorganiza para enfocarse en

la competencia individual, de manera que sta sea ms benfica para el
proyecto en un momento determinado. Para lograr esto, un equipo gil
puede realizar reuniones grupales diarias para coordinar y sincronizar el
trabajo que debe realizarse en ese da.
Con base en la informacin obtenida durante dichas reuniones, el equipo
adapta su enfoque para lograr un incremento de trabajo. Conforme
transcurre cada da, la autoorganizacin y la colaboracin continuas
mueven al equipo hacia un incremento de software completo.

Conflictos de coordinacin y
comunicacin
Existen muchas
razones por las
que los
proyectos de
software tienen
problemas.

La escala de muchos
esfuerzos de
desarrollo es grande,
lo que conduce a
complejidad,
confusin y
dificultades
significativas en la
coordinacin de los
miembros del equipo.

La incertidumbre es
comn, lo que da
como resultado un
torrente continuo de
cambios que
detienen al equipo de
proyecto.

La interoperabilidad
se ha convertido en
una caracterstica
clave de muchos
sistemas. El software
nuevo debe
comunicarse con el
software existente y
ajustarse a las
restricciones
predefinidas
impuestas por el
sistema o por el
producto.

 Para lidiar con ellos de manera efectiva, deben implantarse mtodos

efectivos a fin de coordinar al personal que hace el trabajo. Esto se
logra estableciendo mecanismos para la comunicacin formal e
informal entre los miembros del equipo y entre los distintos equipos.

La comunicacin
formal
Se consigue
mediante
comunicacin
escrita, reuniones
estructuradas y otros
canales de
comunicacin
relativamente no
interactivos e
impersonales.

La comunicacin
informal
Es ms personal, los
miembros de un
equipo de software
comparten ideas
sobre una base ad
hoc, piden ayuda
cuando surgen
problemas e
interactan unos con
otros diariamente.

EL PRODUCTO

Un gerente de proyecto de software se

enfrenta con un dilema en el comienzo mismo
de un proyecto, requiere estimaciones
cuantitativas y un plan organizado.

Un anlisis detallado de los requerimiento del

software
proporcionara
la
informacin
necesaria para las estimaciones, pero este
mismo tarda entre semana a meses, y aun
ms los requerimientos van cambiando segn
avanza el proyecto

mbito de software:

Es la primera actividad en la administracin del proyecto de

software. En esta parte se responde a las siguientes preguntas

Contexto
Como encaja un software en un sistema, y que restricciones hay

Objetivos de informacin
En esta parte se trata de ver que datos visibles para el cliente se
producen tanto en la salida como entrada del software

Funcin y desempeo
En donde se ve las funciones que realiza el software para
transformar los datos de entrada en salida

Descomposicin del problema

Se aplica en dos reas principales:
La funcionalidad y el contenido que deben
entregarse
El procesos que se usara para entregarlo
Un problema complejo se divide en problemas ms
pequeos que son ms manejables, esta estrategia
se aplica conforme comienza la planeacin del
proyecto, puesto que tanto las estimaciones de
costo como las de calendario se orientan
funcionalmente, es til cierto grado de
descomposicin en sus partes constituyentes,

EL PROCESO

El problema es seleccionar el modelo de proceso que sea

adecuado para el software que el equipo del proyecto
someter a ingeniera

El modelo de procesos debe adecuarse a:

o
el
o
o

Clientes (Que solicitan el producto) y Personal( que har

trabajo)
Caractersticas del producto
Entorno del proyecto donde trabaja el equipo de software

EL PROYECTO

Seales que indican que un proyecto de sistemas de

informacin est en peligro:
1. El personal del software no entiende las necesidades del cliente.
2. El mbito del producto est pobremente definido.
3. Los cambios se gestionan pobremente.
4. Cambia la tecnologa elegida.
5. Las necesidades empresariales cambian [o estn mal
definidas].
6. Las fechas lmite son irreales.
7. Los usuarios son resistentes.
8. Prdida de patrocinio [o nunca obtenido adecuadamente].
9. El equipo del proyecto carece de personal con habilidades
adecuadas.
10. Los gerentes [y profesionales] evitan mejores prcticas y lecciones
aprendidas.

REGLA DEL 90-90

SISTEMA

90
10

ESFUERZO

90
90

el sugiere un enfoque de sentido comn de cinco partes en los proyecto

e:
1.Comenzar con el pie
derecho.
2.Mantener la cantidad de
movimiento
3.Siga la pista al progreso

EL PRINCIPIO W HH

WHAT
WHO

WHY

WHEN

WHERE
HOW

PRACTICAS CRUCIALES
El Airlie Council desarroll una
lista de prcticas de software
cruciales para administracin
basada en desempeo. Dichas
prcticas las usan
consistentemente, y las
consideran cruciales, proyectos y
organizaciones enormemente
exitosas cuya lnea base para el
desempeo es consistentemente
mucho mejor que el promedio
industrial

METRICA

ESTIMACION
EMPIRICA DEL
COSTO Y
CALENDARIO
RASTREO DEL
VALOR GANADO

RASTREO DE
DEFECTO CONTRA
META DE CALIDAD
ADMINISTRACION
CONCIENTE DEL
PERSONAL