ADMINISTRACION

DE PROYECTOS DE
SOFTWARE

MATUTE CALDERON, RICHARD

PALACIOS CASTILLO, EDUARDO
SAGASTEGUI RUIZ, DIANA
ZEVALLOS DIAZ, YUZLIN

ADMINISTRACION
Objeto
Estudio

ORGANIZACIONES

Tcnicas

Planificacin
Organizacin
Direccin
Control

RECURSOS

Obtener EFICIENCIA o mximo beneficio posible

PROYECTO
LIMITES
Actividades
PLANIFICADAS

COORIDNADAS

INTERRELACIONADAS

Alcanza
r
METAS

Presupuesto
Calidades establecidas
Lapso de tiempo

ADMINISTRACION DE PROYECTOS DE SOFTWARE

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.
Planificaci
n

Personal
Procesos
Acciones

Administraci
n del
proyecto
Contro
l

Monitore
o

LU
O
EV
CONCEPTO

N
O
I
C

Desplieg
ue
Operativ
o

CULES SON LOS PASOS?

LAS 4P

PERSONAL

PROYECTO

PRODUCTO

PROCESO

OBEJETIVO DE
LAS 4P

EL PERSONAL

Los Participantes
Gerentes
Ejecutivo
s

Gerentes
de
proyecto

Usuarios
finales

Participant
es

Clientes

Profesional
es tcnicos

Lideres de equipo
motivaci
n

Liderazgo

organizaci
n
Ideas o
innovacin
Resolucin de
problemas

Gerente de proyecto

Identidad
administradora
Logro
Influencia y
construccin de
equipo

Equipo de software
Paradigma Cerrado
Paradigmas
organizaciona
les

Paradigma aleatorio
Paradigma abierto
Paradigma sncrono

Equipos giles

Conflictos de coordinacin
y comunicacin

PRODUCTO

PRODUCTO: QU?
Lo que se desea
obtenerse al final del
proyecto
Para
empezar
un
proyecto
se
necesita

Estimaciones cuantitativas y un plan

organizado.
Informacin solida del producto a
construir.
Un anlisis de requerimientos sera lo
deseable.
Dada la problemtica se opta por
establecer y acotar el mbito del
producto.

MBITO DEL SOFTWARE

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

CONTEXTO

En esta parte
se trata de ver
datos visibles
para el cliente
que se
producen tanto
en la salida
como entrada
OBJETIVOS
del software
DE
INFORMACI
N

En donde se ve
las funciones
que realiza el
software para
transformar los
datos de
entrada en
salida
FUNCIN Y
DESEMPEO

CARACTERSTICAS:
No debe ser ambiguo ni
incomprensible a niveles de
gestin y tcnico .
Los enunciados deben
acotarse.
Contener las restricciones o
limitaciones.
Se describen los factores para
reducir riesgos.

DESCOMPOSICIN DEL
PROBLEMA
La funcionalidad y el

Se aplica en dos
contenido que deben
reas
entregarse
principales:
El procesos que se usara
para entregarlo

Para entender el
problema se aplica la
descomposicin del
mismo.
Antes de comenzar la
estimacin se evala y
refina la redaccin del
mbito.

PROCESO

El problema es seleccionar el modelo de proceso

que sea adecuado para el software que el equipo
del proyecto someter a ingeniera
Clientes y
Personal.

El modelo de
procesos
debe
adecuarse a:

Caracters
ticas del
producto.
Entorno
del
proyecto

Una vez definido el marco de

trabajo se deber aplicar a cada
una de las funciones establecidas
para el producto
Una vez seleccionado el proceso se
define el plan preliminar del proyecto
con base en las actividades del marco
de trabajo

Cules son las seales de que

un proyecto de software est en
peligro?

Los
gerentes
evitan
mejores
prcticas

El personal
no
entiende
las
necesidad
es del
cliente

mbito del
producto
pobrement
e definido

Personal
de equipo
de
proyecto
carece de
habilidade
s.

Cambios
gestionado
s
pobrement
e

Prdida de
patrocinio

Cambia la
tecnologa
elegida

Los
usuarios
son
resistentes
Las fechas
limites son
irreales

Las
necesidad
es
empresaria
les
cambian

Cmo acta un gerente para evitar

los problemas mencionados?

COMENZAR CON EL PIE DERECHO

OBJETIVOS

MANTENER LA CANTIDAD DE MOVIMIENTO

Mantener la rotacin de personal

en un mnimo absoluto.

El equipo debe enfatizar la calidad

en cada tarea que se realice.

SIGA LA PISTA AL PROGRESO

El progreso se rastrea:
conforme los productos operativos
(por ejemplo, modelos, cdigo fuente,
conjuntos de casos de prueba) se
producen y

aprueban (usando revisiones

tcnicas) como parte de una
actividad que asegure la calidad.

TOME DECISIONES INTELIGENTES

DECIDA
usar software comercial de anaquel, o
componentes o patrones de software
existentes
EVITAR
interfaces a la medida cuando estn
disponibles enfoques estndar;
DECIDA
tambin identificar y luego evitar los
riesgos obvios, y asignar ms tiempo del
que se considere necesario para tareas
complejas y riesgosas (necesitar cada
minuto).

REALICE UN ANLISIS POSTMORTEN

Establezca
un mecanismo consistente para
extraer lecciones aprendidas por cada
proyecto.
Evale
los calendarios planeado y real
Recopile y analice
Consiga
retroalimentacin de los
miembros del equipo y de los
clientes,

mtricas de proyecto de
software.

Registre
los hallazgos en forma escrita.

EL PRINCIPIO W5HH

Por qu (why) se desarrollar el sistema?

Todos los participantes deben valorar
la validez de las razones
empresariales para el trabajo de
software.
El propsito de la empresa justifica
el gasto de personal, tiempo y
dinero?

Qu (what) se
har?

Defina el conjunto de tareas

requeridas para el proyecto.

Cundo (when) se har?

El equipo establece un calendario de
proyecto al identificar cundo se realizarn
las tareas del proyecto y cundo se
alcanzarn los hitos.
Quin (who) es responsable de
cada funcin?
Defina el papel y la responsabilidad
de cada
miembro del equipo de software.
Dnde (where) se ubicarn
en la organizacin?
No todos los roles y responsabilidades
residen dentro de los profesionales del
software. Clientes, usuarios y otros
participantes tambin tienen
responsabilidades.

Cmo (how) se har el trabajo,

tcnica y organizativamente?
Una vez establecido el mbito
del producto, debe definirse una
estrategia tcnica para el proyecto.
Cunto (how much) se necesita
de cada recurso?

La respuesta a esta pregunta se

deriva al
desarrollar estimaciones con base en
las respuestas a las preguntas
anteriores.
El principio W5HH de Boehm es aplicable sin importar el tamao o
complejidad de un proyecto de software.