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?

Un ingeniero del software

administra sus actividades
cotidianas, planifica,
monitorea y controla las
GERENTES tareas tcnicas.

DEL
INGENIERO
Los gerentes de proyecto
planifican, monitorean y
PROYECTO
DE
controlan el trabajo de un
equipo de ingenieros de
SOFTWARE software.
Los gerentes ejecutivos
coordinan la interfaz entre la
empresa y los profesionales
del software.
CULES SON LOS PASOS?

PERSONAL PRODUCTO

PROYECTO
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
Lderes de El equipo de Equipos Conflictos de
participante
equipo software giles coordinacin
s
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:

un proceso de una definicin

continua y
alta frustracin que software poco clara de
repetida
causa friccin entre los fragmentado o los roles en el
exposicin al
miembros del equipo pobremente equipo de
fracaso.
coordinado software y
 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 Un equipo autoorganizado no necesariamente mantiene una sola
os 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
La interoperabilidad
se ha convertido en
Existen muchas La escala de muchos una caracterstica
razones por las esfuerzos de clave de muchos
La incertidumbre es
que los desarrollo es grande, sistemas. El software
comn, lo que da
proyectos de lo que conduce a nuevo debe
como resultado un
software tienen complejidad, comunicarse con el
torrente continuo de
problemas. confusin y software existente y
cambios que
dificultades ajustarse a las
detienen al equipo de
significativas en la restricciones
proyecto.
coordinacin de los predefinidas
miembros del equipo. 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 La comunicacin
formal informal
Se consigue Es ms personal, los
mediante miembros de un
comunicacin equipo de software
escrita, reuniones comparten ideas
estructuradas y otros sobre una base ad
canales de hoc, piden ayuda
comunicacin cuando surgen
relativamente no problemas e
interactivos e interactan unos con
impersonales. 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 Clientes (Que solicitan el producto) y Personal( que har

el trabajo)
o Caractersticas del producto
o 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 ESFUERZO

90 90
10 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 WHY WHEN

WHO WHERE

HOW
PRACTICAS CRUCIALES METRICA

El Airlie Council desarroll una

lista de prcticas de software ESTIMACION
cruciales para administracin EMPIRICA DEL
COSTO Y
basada en desempeo. Dichas CALENDARIO
prcticas las usan
consistentemente, y las
RASTREO DEL
consideran cruciales, proyectos y VALOR GANADO
organizaciones enormemente
exitosas cuya lnea base para el
desempeo es consistentemente RASTREO DE
mucho mejor que el promedio DEFECTO CONTRA
META DE CALIDAD
industrial

ADMINISTRACION
CONCIENTE DEL
PERSONAL