Gestión de proyectos: definiciones y fundamentos

1.
Definiciones de Gestión de
Proyectos
Gestión de proyectos
Tema 1. Fundamentos
Curso 2020-21
¿Un proyecto…?
1.- PUNTO DE PARTIDA
2.- ACTIVIDADES DEFINIDAS
3.- PUNTO FINAL
Un proyecto es una tarea temporal realizada de forma independiente

de las estructuras de la organización existente
1.1. - 2
Proyectos
• Definición PMBOK: Un proyecto es un esfuerzo temporal
emprendido para crear un producto o servicio único.
• Realización independiente de las estructuras de la

organización existente.
• Un proyecto implica voluntad de realización.
▫ Una planificación detallada que no se ejecuta es un plan,
no un proyecto.
• Los procesos empresariales suponen una ejecución cíclica o
continua.
▫ Los proyectos son instancias únicas y acotadas en el
tiempo, cuyos productos son también únicos.
1.1. - 3
Características de un proyecto
• Temporal, debe estar delimitado entre una fecha de
inicio y otra de finalización.
• Se obtiene un resultado único.
• Existe uno o varios objetivos claros.
• Se pueden identificar una serie de tareas que son
necesarias y que no son habituales.
• Las tareas tienen que realizarse de forma ordenada.
• Es necesaria la intervención de especialistas.
• Se utilizaran recursos de diversos tipos.
• Existen limitaciones en los recursos y el presupuesto.
• Se requiere una planificación.
• El producto final tendrá que cumplir las especificaciones.
• Se busca un determinado nivel de calidad en el producto.
1.1. - 4
Proyecto
5
1.1. - 5
Un proyecto…?
FASES
1 2 3 Producción
ESTUDIOS DESARROLLO PRUEBAS

CONVERSION
PLANES EJECUCION EVALUACION
mirar hacia mirar hacia

adelante producir atrás
PROYECTO
1.1. - 6
Actividades del proyecto
• Estudios y planes. Definición del problema y
planificación de la solución:
▫ Clarificar el problema, el producto o el servicio
▫ Evaluar los costes económicos y los recursos
• Desarrollo y ejecución. Puesta en marcha y fase
productiva:
▫ Organizar el equipo de trabajo y su funcionamiento
▫ Realizar el producto, controlar, informar, coordinar y corregir
• Evaluación y entrega. Pruebas finales, entrega al
cliente y balance y cierre:
▫ Poner a disposición del cliente un producto verificado y
validado
▫ Revisar, documentar y desactivar el equipo de proyecto
1.1. - 7
Etapa de estudios y planes
• Objetivos:
▫ Clarificar el problema a solucionar, el
producto a obtener, o servicio a proporcionar,
▫ Evaluar los costes económicos en que se va a
incurrir, así como los recursos humanos y de
cualquier otro tipo a dedicar.
• Fases:
▫ Definición del problema.
▫ Evaluar Viabilidad.
▫ Planificación del proyecto.
1.1. - 8
Etapa de desarrollo y ejecución
• Objetivos:
▫ Organizar el equipo de trabajo y su
funcionamiento.
▫ Establecer el entorno de trabajo: normas,
estándares, recursos.
▫ Realizar el producto a obtener, controlar,
informar, coordinar y corregir.
• Fases:
▫ Puesta en marcha.
▫ Fase productiva.
1.1. - 9
Etapa de evaluación y entrega
• Objetivos:
▫ Poner a disposición de uso del cliente un
producto verificado y validado .
▫ Revisar y documentar resultados,
productividad, incidencias, etc.
▫ Desactivar el equipo de proyecto.
• Fases:
▫ Pruebas finales.
▫ Entrega al cliente.
▫ Balance y cierre.
1.1. - 10
Tipos de proyectos
• Técnicos y no técnicos.
 Ejp: Cambio en el sistema de gestión de BBDD de una organización / Control y
disminución de costes de explotación.
• Unipersonales y multipersonales.
 Ejp: Desarrollo de una página web sencilla / Implantación de un sistema ERP.
• Monodisciplinares y multidisciplinares.
 Ejp: Reorganización de las BBDD / Desarrollo de un sistema de e-learning
(diseñadores, informáticos, creadores de contenidos)
• Monocontrato y multicontrato.
 Ejp: Mantenimiento del sistema de información actual por el propio personal de
informática / Proyecto de sustitución del sistema de información de una
organización contratando a empresas de desarrollo software, de auditoria, de
implantación de hardware y software de base, etc.
• Resultados tangibles e intangibles.
 Ejp: Desarrollo de una aplicación de gestión automática de almacenes /
Reestructuración de programas o mantenimiento preventivo.
• Rentabilidad económica y rentabilidad social.
 Ejp: Desarrollo y comercialización de un paquete software estándar / DNI
electrónico.
1.1. - 11
¿Qué es un proyecto Informático?
• Un proyecto informático es un proyecto enfocado a
obtener uno o más resultados deseables sobre un sistema
de información (S.I.)
• Actuaciones de un proyecto actúa sobre un S.I. :
 Crear
 Implantar
 Mejorar
 Auditar,…
• Recursos involucrados:
 Recursos Humanos (RRHH)
 Software (SW)
 Hardware (HW)
 Comunicaciones (COM) 1.1. - 12
¿Que es un proyecto Informático?
• Crear una aplicación que automatice el trabajo.
• Implantar una aplicación que automatice el trabajo.
• Auditoria, ...
Diseñador
Analista ¿Como? Programador
¿Que? Hacerlo
Servicio de Aplicación
Usuario 13
1.1. - 13
Proyecto software
• Dentro del ámbito de la ingeniería se dice que algo está
en proyecto mientras no esté finalizado. Por tanto el
proyecto es todo el proceso de construcción de un
objeto hasta su terminación
• En particular un sistema software está en proyecto
mientras no esté finalizado, es decir operativo; y en
consecuencia todo el proceso de desarrollo del SW es
un proyecto SW
• Además de los proyectos de desarrollo, son proyectos
software aquellos cuyo objetivo es el mantenimiento,
control, mejora y eliminación o sustitución de un
producto software.
1.1. - 14
Proyecto software
• Un sistema software está en proyecto mientras no esté
finalizado (operativo)
• Todo el proceso de desarrollo del SW es un proyecto SW.
• Proyectos software realizados sobre un producto software

con objetivos relativos a realizar tareas de:
 Mantenimiento
 Control,
 Mejora
 Eliminación o sustitución
1.1. - 15
Características de Proyectos SW
• El SW es intangible (es un producto lógico no físico)
• Los productos SW pueden aceptarse con modificaciones
• Cada proyecto SW es único (desarrollos a medida,
personalizaciones).
• La estandarización de los
procesos de desarrollo SW no está
generalizada. Se desarrolla, no
se fabrica en el sentido clásico.
• Continua innovación tecnológica.
• Fuerte dependencia de los RRHH

en los proyectos SW. 1.1. - 16
Actividades en Proyectos Sw
• Actividades de Inicio del Proyecto: Estimación del
esfuerzo y Planificación del proyecto. Determinar el
tamaño y las restricciones del software y los recursos y
tiempo necesarios para construirlo.
• Actividades de Seguimiento y Control. Asignación

de las tareas, su aceptación interna por parte del equipo
de proyecto y su control. Incluye la gestión de
incidencias y cambios en los requisitos que puedan
presentarse y afectar a la planificación del proyecto.
• Actividades de Finalización del Proyecto. Cierre

del proyecto y Registro de la documentación de gestión.
Balance final del proyecto: tecnología, metodología,
problemas, soluciones, útil para planificar proyectos
futuros. 1.1. - 17
Organización del trabajo
• Organización espontánea
▫ Se improvisa, se espera a que
sucedan los eventos, no importan ni
los costes económicos ni los plazos de
finalización
• Planificación y gestión de un proyecto

▫ Conocimiento estimativo de costes y
plazos
▫ Cuanto más exacto mejor
1.1. - 18
Necesidad de la gestión de un proyecto
• un proyecto siempre está sujeto a restricciones
de presupuesto y de calendario.
• un proyecto involucra a tareas y RRHH (sujetas
a problemas y cambios)
1.1. - 19
¿Qué es gestionar?
• Definición RAE: hacer diligencias conducentes al logro
de un negocio o de un deseo cualquiera.
• Gestionar implica:
– Planificar. Determinar los resultados requeridos por la
organización y establecer estrategias adecuadas para su
realización.
– Organizar. Especificar cómo lograr los resultados
planificados, asignando las tareas planificadas a los
miembros y equipos de la organización.
– Controlar. Realizar el seguimiento de la consecucion de los
resultados previstos, corrigiendo las desviaciones que se
detecten.
– Dirigir. Liderar y motivar a los miembros de la organización,
para alcanzar los objetivos marcados.
1.1. - 20
Objetivos de la gestión de proyectos
• Finalidad de la gestión de proyectos (GP) :
▫ La planificación, el seguimiento y control de las
actividades y de los RRHH y materiales que intervienen
en el desarrollo del proyecto.
• Si existe una GP es posible:

▫ Conocer en cada momento
qué problemas se producen
▫ Resolverlos o mitigarlos
inmediatamente.
1.1. - 21
Facetas de la gestión de proyectos
• Faceta Ingenieril:
▫ Aplicación de técnicas para obtener datos objetivos
 Ejp. camino crítico, los costes, etc.
• Faceta Sociológica:
▫ Aplicación de soluciones
subjetivas y negociadas
(basada en el comportamiento
humano)
 Ejp. La comunicación entre los
participantes, la motivación,
etc.
1.1. - 22
Participantes en proyectos de software
• En función de cada organización y del tipo de proyecto
• Varios perfiles:
▫ Cada uno de ellos puede corresponder a una o varias personas
 Ejp. En proyectos pequeños una misma persona puede hacer
la función de analista y de programador):
• Perfiles:
▫ Directivo
▫ Responsable del proyecto
▫ Equipo de proyecto
▫ Analista
▫ Programador
▫ Técnico de sistemas
▫ Personal de explotación
▫ Comité de Garantía de Calidad
▫ Usuario
1.1. - 23
• Directivo
▫ Alto nivel en la dirección
▫ Autoridad para validar y aprobar los procesos realizados durante el
proyecto, con conocimientos de los objetivos estratégicos y de
negocio
▫ Comité de Dirección: directivos de diferente nivel y asesores de
cada organización implicada en el proyecto (aprobaciones finales del
proyecto y decisiones importantes de cada fase)
▫ Comité de Dirección formado como mínimo por
un directivo de la organización usuaria (cliente) y
otro de cada una de las organizaciones de
desarrollo participantes (proveedores)
▫ Director del Proyecto: está al frente del Comité

de Dirección, patrocina el proyecto y en
comunicación directa con el Jefe de Proyecto
1.1. - 24
• Responsable del proyecto
▫ Jefe de proyecto.
▫ Experto en la gestión (Ingeniero Informático):
coordinación del equipo del proyecto y gestión del proyecto.
▫ Nombrado por las organizaciones implicadas (directivo de
la organización encargada del desarrollo del sistema)
▫ Delega en responsables
de áreas (calidad,
seguridad,
mantenimiento,..)
1.1. - 25
• Equipo de proyecto
▫ Constituido por las personas (analistas, diseñadores,
programadores, técnicos) que se van a encargar
directamente del desarrollo.
▫ Pertenecerán a la organización contratada para
desarrollar el sistema*
▫ Si el desarrollo es externo (empresa contratista) y la
organización usuaria dispone de Departamento de
Informática  algunas personas del departamento forman
arte del equipo
*Si es un desarrollo interno pertenecerán la propia organización

usuaria
1.1. - 26
• Analista
▫ Ingeniero de software con conocimiento de la metodología
de desarrollo y de las herramientas CASE a utilizar
▫ Intermediario entre el usuario y el equipo del proyecto
(estudio de los requisitos, objetivos y funciones a realizar por
el sistema, documenta todos estos aspectos según la
metodología establecida)
▫ Analiza y diseño del software
▫ Dos categorías:
1. Analista funcional (fase de análisis)
2. Analista orgánico o diseñador (fase de diseño)
1.1. - 27
• Programador
▫ Codificarán, mediante un lenguaje de
programación concreto, los componentes
software establecidos por los diseñadores.
Participarán en las pruebas del sistema y, en
ciertos casos, en la generación de manuales.
▫ Aunque su misión es codificar el software ya
diseñado, en algunos casos, participa también en
el diseño, e, incluso, en el análisis. Si realiza
labores de análisis o diseño se denomina
Analista-programador.
1.1. - 28
• Técnico de sistemas
▫ Experto en SW de base (S.O., comunicaciones,

BBDD,..) y equipos informáticos que ofrece
apoyo técnico en el proyecto.
▫ Miembro del equipo de proyecto o soporte

ocasional.
1.1. - 29
• Personal de explotación
▫ Personas del Dpto.Informática o proceso de datos de la
organización usuaria o contratada, con conocimientos sobre
el entorno en el que se explotará el sistema cuando se
instale.
▫ Colaborarán con el equipo de desarrollo, para concretar
determinados aspectos relacionados principalmente con la
definición del entorno tecnológico del sistema (equipos,
software de base,..) y con la construcción de la BBDD que,
con toda seguridad, utilizará el sistema (conviene que exista
un Administrador de tal BBDD, que será una persona del
área de explotación experta en esta labor y que se
responsabilizará de la seguridad, confidencialidad y ajustes
de la BBDD, mediante parámetros externos para asegurar el
óptimo rendimiento, cuando el sistema funcione en
explotación.
1.1. - 30
• Comité de Garantía de Calidad
▫ Personal, con conocimientos y experiencia en metodologías de
desarrollo, del departamento de informática (calidad), si existe,
de la organización usuaria o, en caso contrario, de una
organización externa, independiente de la que desarrolla el
sistema (en el caso de pertenecer a la organización usuaria, el
personal encargado de este control de calidad deberá ser
independiente del equipo de desarrollo del sistema.
▫ Se encarga de controlar la evolución del proyecto a través del
análisis de los productos generados a lo largo de las diferentes
fases de desarrollo.
▫ Existe en proyectos importantes (en otros proyectos sus
funciones las realiza directamente el jefe de proyecto con el
equipo de desarrollo)
1.1. - 31
• Usuario
▫ Persona que utilizará el software a desarrollar y que definirá
sus requisitos.
▫ Normalmente no forman parte del equipo de desarrollo (si el
proyecto tiene cierta envergadura pueden participar en el
proyecto como miembros del equipo)
▫ Son fundamentales en la definición de los requisitos y en las
pruebas de aceptación.
▫ Dos categorías de usuarios:
1. Usuario responsable: Encargado de fijar requisitos
generales y de dar el visto bueno al software final y a los
manuales.
2. Usuario final: En el que delegará el responsable para
definir los requisitos detallados.
1.1. - 32
Necesidad de una Metodología **
PMBOK
 Proyect Management Body Of Knowledge, creado por PMI
(Proyect Management Institute).
 PMBOK surge de la necesidad de poseer un manual de referencia
para los gestores de proyectos.
 Unifica el léxico, conocimientos, habilidades y prácticas.
 Documento usado por PMI para el examen de certificación PMI
(Proyect Management Professional).
 Existen distintas versiones desde 1996. Actualmente está
disponible la 6ta versión publicada en septiembre del 2017.
** Flipped Learning: Realizar la actividad 1 de laboratorio para discutirla. 1.1. - 33

Necesidad de una Metodología
Métrica V3
1.1. - 34
Necesidad de una Metodología
Scrum
• SCRUM es una metodología ágil de gestión de
proyectos cuyo objetivo primordial es elevar
al máximo la productividad de un equipo.
• Reduce al máximo la burocracia y actividades

no orientadas a producir software que
funcione y produce resultados en periodos
muy breves de tiempo (cada 30 días), por
medio de iteraciones o Sprints.
• Ideal para proyectos con un rápido cambio de

requerimientos.
1.1. - 35
1.1. - 36
El flujo de Scrum
1.1. - 37
Viabilidad de proyectos
Tema 1. Fundamentos
Valoración y proceso de valoración
• Valoracion:
“Proceso formal según el cual se asignan unas magnitudes monetarias a
determinados procesos o hechos económicos con objeto de hacerlos calculables
para un determinado fin”.
• Proceso de valoración de la empresa:

▫ Dotar el precio
▫ Criterio propio que se utilice:
▫ - Pagatorio: Basado en pagos y cobros (estudiando el coste real)
▫ - Calculatorio. Basado en la oferta y demanda (estudiando el mercado)
▫ Inversión = desembolso inicial necesario para que un negocio empiece a funcionar
• Siempre que se realiza una inversión esperamos un cierto rendimiento

conocido como rentabilidad en un cierto tiempo.
• Toda inversión en un determinado proyecto viene dado por el trinomio formado por
un desembolso inicial, un rendimiento y una duración.
Viabilidad
• Viabilidad:
€ Económica
 Técnica
 Legal
 Operativa
 De plazos
 De motivación
• Método de análisis económico:
▫ Análisis de costes/beneficios
▫ Cálculo de gastos e ingresos
▫ Análisis de inversiones
Fases del análisis de viabilidad
• Estudiar la solicitud de proyecto y establecer el alcance y los
límites del sistema.
• Estudiar la situación actual e identificar sistemas y personas
involucradas.
• Realización de una definición preliminar de requisitos y
directrices técnicas .
• Estudiar y especificar las diferentes alternativas de solución:
▫ Comprar un producto software comercial.
▫ Desarrollar el producto internamente.
▫ Desarrollarlo de forma externa mediante un contrato.
▫ Automatizar sólo parcialmente el sistema
• Viabilidad de cada una de las alternativas
• Selección y aprobación de la alternativa más apropiada.
Costes y beneficios
• Análisis de costes/beneficios:
▫ Interés inicial del proyecto
▫ Al final de la fase de análisis  estudio más detallado
▫ Costes:
 Personal de proyecto, consultoría, software adicional, hardware,
infraestructura, costes debidos al usuario
▫ Beneficios:
 Nuevas funciones, eliminar o reducir errores, aumento de
velocidad, volumen o de fiabilidad, productividad
Análisis
• Información previa necesaria:
▫ Estimación de costes de operación:
 del sistema actual
 del sistema propuesto
▫ Estimación de costes de fases de desarrollo
▫ Descripción de beneficios intangibles
▫ Base histórica para estimar la evolución de

costes y beneficios en los siguientes años
▫ Identificación de riesgos asociados a

desarrollar o no el proyecto
Costes
• Típicos:
▫ Hardware y software, con mantenimiento e
infraestructura
▫ Viajes y formación
▫ Conversión de sistemas, consultoría, etc.
▫ Esfuerzo (personal): coste dominante en proyectos
 Costes salariales completos: SS, cuotas, etc.
 Costes indirectos: total infraestructura entre número de personas
(habitualmente el doble del coste salarial):
 Oficinas: alquiler, calefacción, iluminación.
 Personal de apoyo: secretaría, contabilidad, etc.
 Redes y comunicaciones
 Infraestructuras: biblioteca, etc.
Beneficios
• Típicamente difíciles de cuantificar:
▫ Tangibles:
 Principalmente ahorros en recursos humanos por reducción
de personal o evitar nuevas contrataciones
 Reducir costes de mala calidad, errores, repetición de
trabajos, etc.
 Reducir o evitar otros recursos
▫ Intangibles o difícilmente cuantificables:
 Mejora de competitividad
 Mayor satisfacción de empleados
 Imagen
Valor Monetario Esperado (VEM)
Sumatorio de la renta que se espera obtener en cada
alternativa multiplicada por la probabilidad de que esa
renta se produzca:
j n
VEN   Pr obabilidad j  rentaesperada j
j 1
Rentabilidad Prevista (PR)

Cociente entre la diferencia del Valor Esperado Monetario menos el
Coste de la Inversión dividido por el Coste de la Inversión
VEM  CI
RP 
CI
Rentabilidad del proyecto
• Conceptos generales:
▫ Capital circulante: el que necesita todo negocio para

afrontar su actividad normal después de realizar la
inversión.
▫ Flujo de tesorería: mide las entrada y salidas de caja.
▫ Periodos a contemplar: Periodos desde la inversión
hasta que el producto deja de ser un bien útil o se decide
liquidarlo.
▫ Tasa de referencia: Interés medio de mercado que se
pagará por disponer de unos fondos de los que se carece.
▫ Valor residual: Valor del negocio cuando se decide
liquidarlo.
Previsión de cuenta de resultados
Concepto Año1 Año2 Año3
(1) Ventas o prestación de servicio
(2) Devoluciones y rappel
Subvenciones a explotación, Ingresos financieros
Otros ingresos de explotación
A. Total Ingresos
(3) Compras
Servicios, Tributos, Gastos de personal, Gastos
financieros
(4) Dotaciones p/amortizaciones
Dotación a provisiones
B. Total Gastos
C. Margen Bruto (1-2)-(3)
D. Resultado antes de impuestos (A-B)
E. Impuesto de sociedades
F. Resultado (D-E)
G. Cash flow (F+4)
Previsión de cuenta de resultados
Concepto Año1 Año2 Año3
(1) Ventas o prestación de servicio
(2) Devoluciones y rappel
Subvenciones a explotación,Ingresos financieros
Otros ingresos de explotación
A. Total Ingresos
(3) Compras
En la vida real hay que
Servicios, Tributos, Gastos de personal, Gastos financieros
(4) Dotaciones p/amortizaciones
usar conceptos
Dotación a provisiones
complicados como éstos
Nosotros trataremos
B. Total Gastos
con datos simplificados
C. Margen Bruto (1-2)-(3)
D. Resultado antes de impuestos (A-B)
E. Impuesto de sociedades
F. Resultado (D-E)
G. Cash flow (F+4)
Cuenta de resultados
• Ingresos:
▫ Ventas o prestación de servicios
▫ Devoluciones y rappel ventas
▫ Subvenciones a la explotación
▫ Ingresos financieros
▫ Otros ingresos de explotación
• Gastos:
▫ Compras: mercaderías, materias primas, variación de existencias
▫ Servicios: I+D, arrendamientos y cánones, reparaciones y
conservación, servicios profesionales
▫ Independientes: transportes, seguros, servicios bancarios, publicidad y
rel.públicas, suministros, otros servicios
▫ Tributos: Impuestos, contribuciones, tasas (exc. Sociedades), ajuste
IVA
▫ Gastos de personal: sueldos y salarios, seg.social a cargo de empresa
▫ Gastos financieros: intereses, descuentos ventas, gastos financieros
▫ Dotaciones amortiz.: gastos de establecimiento, inmovilizado
▫ Dotación provisiones: inmovilizado, insolvencias, existencias
Métodos de evaluación de rentabilidad
• Período de recuperación de inversión y punto de equilibrio
(BET)
• ROI: beneficio acumulado
• Valor actual neto (VAN)

▫ Representa el valor monetario neto en un momento dado. Se calcula como la
diferencia entre los flujos de tesorería actualizada a la tasa de interés prefijado y las
inversiones actualizadas a esa misma fecha.
▫ Un VAN positivo indica que la inversión en el proyecto es rentable o, al menos,
es mejor que la tasa de referencia.
• Tasa interna de retorno (TIR)

▫ Rentabilidad inmediata
▫ Razón beneficio/coste
Punto de equilibrio (break even)
• Momento en el que los ingresos (Cash Flow)
igualan los costes
▫ Beneficio acumulado = Ingresos –Costes = 0
▫ Costes totales = fijos + variables (según ventas)
• Período de recuperación (BET)
▫ BET = Inversión inic. act. fijo / Ingresos anuales
▫ Activos fijos: aportaciones socios, inmovilizado
 Gastos de establecimiento
Éstas son fórmulas de
 Inmaterial - amortización
economía
 Material (- amortización)
Nosotros usaremos
 Financierosmétodos más intuitivos
 Acciones propias
Retorno de inversión (ROI)
• Analizar el beneficio neto acumulado
▫ Beneficios = ingresos – gastos (- inversión inicial)
▫ ROI = beneficio neto acumulado al final del proyecto
▫ Uso: elegir alternativa de ROI más elevado
• Método del payback (Retorno de la inversión)

▫ ((Ing –Gas) – Inv ) / Inv
Índice de Payback: Indicador que calcula el plazo en el cual los flujos de tesorería actualizados
a la tasa de referencia igualan el valor de las inversiones actualizadas a esa misma fecha.
Este valor nos indica la velocidad con que se recupera la inversión de tal suerte que a valor
más bajo, con el resto de las condiciones constantes, mejor será económicamente el proyecto.
BET (I) y ROI
Año 1 Año 2 Año 3 Año 4
FINAL
Gastos 5 3 1 1
Ingresos 2 2 7 8
Beneficio -3 -4 2 9
acumulado
ROI
BET (II)
Beneficio acumulado
10
9
8
6
4
2 2
0
-2 Año 1 Año 2 Año 3 Año 4
-3
-4 -4
-6
BET
BET y ROI (II)
Año Año 2 Año 3 Año 4
1 FINAL
Gastos 5 3 1 1
G. acumulados 5 8 9 10
Ingresos 2 2 7 8
I. acumulados 2 4 11 19
Beneficio -3 -4 2 9
acumulado
ROI
BET (III)
Gastos e Ingresos Gastos
Ingresos
20
19
15
11
10 10
Cifra
8 9
de equilibrio
5 5 4 Punto de
2 equilibrio
0
BET
Año 1 Año 2 Año 3 Año 4
Alternativas mediante Retorno de la
inversión (RP)
Proyecto 1: Comprar un portal de venta electrónica
Proyecto 2: Sistema de ayuda a la distribución de mercancías en el mercado japonés
Proyecto 3: Crear un sistema de gestión de cobros que permita flexibilizar las entregas
Hipótesis baja Hipótesis media Hipótesis alta

Probabilidad Probabilidad Probabilidad
0,2 0,7 0,1 Coste
Portal de ventas 72 80 93 47
Ayuda distribución 45 70 87 35
Gestion de Cobros 57 83 113 52
79,7  47
RP (1)  ((72  0,2  80  0,7  93  01) - 47) / 47   0,69
47
66,7  35
RP (2)  ((45  0,2  70  07  87  0,1) - 35) / 35   0,91
35
80,8  52
RP (3)  ((57  02  83  07  113  01) - 52) / 52   0,55
52
VAN (I)
• El VAN se calcula como el valor actualizado de todos los ingresos
• Es útil para calcular el valor final de una inversión o la recuperación
de un pago
n
Flujot
• VAN: valor actualizado de todos los ingresos VAN  
▫ Flujo de caja: Cash Flow (CF) t 0 (1  K ) t
• Compara todos los ingresos y gastos en un momento del proyecto

▫ Normalmente el momento inicial o cero
• VAN:
▫ Es el valor actualizado de todos los cash flow esperados:
 La diferencia entre el valor actualizado de los cobros y los pagos
VAN (II)
• Inversión y recuperación de un pago:
▫ VF = VA · (1+k)n  VF =VA · Tk,n (T10,3 = 1,331)
 VF = valor futuro; VA = valor actual; k =interés; n = años
• ¿Qué capital final se obtendrá en tres años con una
inversión inicial de 10.000€ si se prevé un interés anual del
10%?
▫ VF =VA ·(1+K)t= VA · (1+0,1)3 =VA · 1,331= 13.310€
Año Capital inicial Intereses (10%) Saldo final

1 10.000 1.000 11.000
2 11.000 1.100 12.100
3 12.100 1.210 13.310
VAN (III)
• ¿Cuánto invertir para lograr 15.000 en 3 años al 10%?
▫ VA = VF/Tk,n  VA = 15.000 / 1,331 = 11.269,72
capital inicial Interés (10%) saldo final

11.269,72 € 1.126,97 € 12.396,69 €
12.396,69 € 1.239,67 € 13.636,36 €
13.636,36 € 1.363,64 € 15.000,00 €
• ¿Qué interés para 15.000 a partir de 10.000 en 3 años?

▫ Tk,n= VF/VA  Tk,3 = 1,5  k = 14,46 (n = 3); n = 4,244 (k = 10)
VAN (IV)
• Inversión y recuperación de un pago (VAN):
▫ VAN = - I + CF1/(1+k1) + CF2/((1+k2)(1+k1)) + ... + CFn/(1+ki)

I = Inversión; kn = interés de año; CFn = beneficios del añon
▫ VAN = - I + CF1/(1+k) + CF2/(1+k)2 + ... + CFn/(1+k)n
 Si k1 = k2 = k3 = ... = kn
• Supone:
▫ Una inversión inicial (momento 0)
▫ Actualización del ROI según valor actual
▫ Elegir VAN más alto: en empate, lo que suponga menor
inversión y gasto
Ejemplo de VAN
Inversión CF1 CF2 CF3 CF4
inicial (año1) (año2) (año3) (año4)
Proyecto A 200 70 70 60 60
Proyecto B 170 60 50 45 55
Proyecto C 120 50 50 50 0
Tasa de descuento k = 10%

VAN (X) = - I + CF1/(1+k) + CF2/(1+k)2 + CF3/(1+k)3 + CF4/(1+k)4
VAN (A) = - 200 + 70/(1+0,1) + 70/(1+0,1)2 + 60/(1+0,1)3 + 60/(1+0,1)4 = 7,4

VAN (B) = - 170+ 60/(1+0,1) + 50/(1+0,1)2 + 45/(1+0,1)3 + 55/(1+0,1)4 = -2,8
VAN (C) = - 120 + 50/(1+0,1) + 50/(1+0,1)2 + 50/(1+0,1)3 + 0/(1+0,1)4 = 4,2
Tasa interna de rendimiento (TIR)
• Tipo de interés (k) que permite hacer cero el VAN
▫ VAN = - I + CF1/(1+k) + CF2/(1+k)2 + ... + CFn/(1+k)n
▫ En general, n = 5 es el máximo. CFi = beneficio del año i
▫ Con VAN = 0 y conociendo los Cfi, se calcula k
• Sólo interesan los proyectos en los que la TIR sea
mayor que el interés del dinero en el mercado de
capitales
▫ También conviene evaluar la rentabilidad financiero-fiscal
• También es conveniente analizar:
▫ Cantidad máxima de capital requerido, endeudamiento requerido,
momento requerido, etc.
Caso de estudio
• Contabilidad manual
• 2 personas de coste 26.000 €/año
• Paquete: 18.000 €, mant. 15% anual
• Adaptación: 44 jornadas a 27 €/hora
• Ordenador: 3.000 €, mant. 10% anual
• Formación: un coste de 1000 €
• Ahorro: 50% tiempo
• Vida de 4 años
• Plenamente operativo: 3 meses
Solución caso
Año 1 2 3 4
Beneficio 19.500 26.000 26.000 26.000
Coste hardware 3.000 300 300 300
Coste software 18.000 2.700 2.700 2.700
Coste personal 9.504 - - -
Coste usuario 1.000 - - -
Total costes 31.504 3.000 3.000 3.000
Beneficio neto -12.004 23.000 23.000 23.000
Beneficio neto -12.004 10.996 36.996 56.996
acumulado
BET => 12.004 = (23.000/12) · t => 6,26 meses

Valor actual = Beneficio neto / (1+t/100)n
Aspectos importantes
• Estimaciones suelen consistir en rangos
probables
• Estimaciones conservadoras, pesimistas
(Murphy)
• Múltiples factores para prospectiva económica:
inflación, tipos de interés, volúmenes de crecimiento,...
• Valorar y prever todos los riesgos
• Dificultad en valorar o cuantificar beneficios:
▫ Principal aportación: información
• Profundo conocimientos del mercado:
▫ Innovaciones
▫ Rendimiento
Viabilidad técnica
• Tecnología práctica y disponible
▫ Inviable cuando no hay algoritmos o no son
eficientes (reconocimiento de lenguaje natural sin
restricciones)
• Ejemplos:
▫ ¿Existe o se puede adquirir la tecnología necesaria?
▫ ¿Equipo propuesto tiene capacidad para soportar los
datos requeridos?
▫ ¿Sistema propuesto ofrecerá salidas apropiadas para
cualquier número y disposición de usuarios?
▫ Si se desarrolla el sistema, ¿puede crecer?
▫ ¿Hay garantías técnicas de exactitud, facilidad de
acceso, etc.?
Viabilidad legal
• Respetar la normativa legal:
▫ Específica de TI
▫ Comercial y general
• Normativa específica:
▫ LOPD: Ley Orgánica de Protección de Datos de carácter
personal (Ley 15/1999 y reglamento de seguridad RD
994/1999)
 Previamente la LORTAD Ley 5/1992 (derogada)
▫ Propiedad intelectual (RDL 1/1996): software, imágenes o
dibujos, contenidos, etc.
▫ Ley de Servicios de la Sociedad de la Información y el
Comercio Electrónico (Ley 34/2002): spam, páginas web,
etc.
▫ Ley General de Telecomunicaciones (Ley 32/2003):
cifrado, intercepción, registro, etc.
Viabilidad operativa
• Sistema apropiado para entorno de trabajo
• Ejemplos:
▫ ¿Existe apoyo suficiente para el proyecto por parte
de la dirección? ¿y de los usuarios?
▫ ¿Los métodos actuales son aceptados por los
usuarios?
▫ ¿Los usuarios han participado en la planificación y
desarrollo del proyecto?
▫ El sistema propuesto ¿causa algún perjuicio? ¿se
perderá el control en algún área? ¿se afecta a la
productividad de usuarios?
Viabilidad de plazos y de motivación
• Plazos: calendario realista y razonable
▫ Técnicamente
▫ Según los requisitos del negocio
 Fechas de conversión de datos a principio de año
• Motivación: aceptación de los usuarios
▫ Colaboración con el desarrollo
▫ Admisión de ruptura de las rutinas de trabajo
▫ Esfuerzo de adaptación y de formación
Factores del éxito del proyecto
• Dependiendo del entorno de la empresa variarán los objetivos y
dependiendo de cómo definamos los objetivos obtendremos éxito o no.
• Los objetivos que queremos obtener nos van a decir la orientación que
deberá darse a la utilización de recursos y el comportamiento del
personal.
• Es de considerar que suele haber un conjunto de objetivos lo que

conlleva una serie de prioridades que nos obligarán al establecimiento
de un plan o programa de cumplimiento de objetivos.
• Posibles objetivos:
▫ Obtener beneficio económico directo;
▫ Abrir un nuevo mercado;
▫ Formar al personal e introducirlo en una nueva tecnología;
▫ Obtener un producto de más calidad que nos haga destacar frente a
los competidores.
Criterios para alcanzar el éxito
• Frente a la dirección:
▫ Es un activo real
▫ Se alcanzaron los objetivos
▫ Se controlaron los costes
▫ Estuvo bien dirigido y controlado
• Frente a los usuarios:
▫ Se comprendieron las necesidades
▫ Permite el crecimiento
▫ Se implementaron cambios vitales
▫ El sistema resulta fácil de controlar
▫ Trabaja como se esperaba
Criterios para alcanzar el éxito (2)
• Frente al equipo del proyecto:
▫ Hubo comunicación con los usuarios
▫ Las especificaciones fueron revisadas y aprobadas
▫ Se evaluaron los cambios
▫ La dirección estuvo continuamente implicada
▫ Aumentó nuestra experiencia y confianza
• Frente a la operación:
▫ Está bien documentado
▫ Es fácil de operar
▫ Fue bien probado y no tiene “sorpresas”
▫ Tiene una excelente capacidad de recuperación y
rearranque
Los activos de la empresa
• El proyecto es satisfactorio si realmente constituye
un activo importante para la empresa,
considerándolo como un elemento de
posicionamiento en el mercado frente a la
competencia.
• Se situará la gestión informática como un activo más

de la empresa.
• La información es un valor para la empresa, es

un activo de primer orden que puede ser utilizado
para crear riqueza, para obtener un mejor
posicionamiento en el mercado, o para poder
utilizarlo como una baza de mejora frente a la
competencia
Los activos de la empresa
• Activos Tangibles: se consideran activos tangibles
todos los bienes de naturaleza material susceptibles
de ser percibidos por los sentidos, tales como:
▫ Materias primas y Stocks
▫ El mobiliario
▫ Las maquinarias
▫ Los terrenos
▫ El dinero .....
• Activos Intangibles: se consideran activos
intangibles aquellos bienes de naturaleza inmaterial
tales como:
▫ El conocimiento del saber hacer (Know How)
▫ Las relaciones con los clientes
▫ Los procesos operativos
▫ La tecnología de la información y bases de datos
▫ Capacidades, habilidades y motivaciones de los
empleados.....
UN PROYECTO HA TENIDO EXITO SI:
Se ha realizado:
▫ Dentro de plazos
▫ Dentro de presupuesto
▫ Un producto de calidad que satisface a
los usuarios
Metodologías de gestión de
proyectos
Tema 1. Fundamentos
Metodologías
• Métrica V3
▫ Metodología de Planificación, Desarrollo y
Mantenimiento de Sistemas de Información patrocinada
por el gobierno de España.
• PMBOK
▫ Estándar en la gestión de proyectos desarrollado por el
Project Management Institute (PMI).
• SCRUM
▫ Es una “metodología ágil” de desarrollo de proyectos que
toma su nombre y principios de los estudios realizados
sobre nuevas prácticas de producción por Hirotaka
Takeuchi e Ikujijo Nonaka a mediados de los 80.
Estructura de Métrica V3
Métrica V3 - Gestión de proyectos
• La Gestión de Proyectos tiene como finalidad principal la
planificación, el seguimiento y control de las actividades y
de los recursos humanos y materiales que intervienen en el
desarrollo de un Sistema de Información.
• Como consecuencia de este control es posible conocer en todo
momento qué problemas se producen y resolverlos o paliarlos de
manera inmediata.
• La Interfaz de Gestión de Proyectos de MÉTRICA Versión 3
contempla proyectos de desarrollo de Sistemas de Información en
sentido amplio. EUROMÉTODO (metodología europea para la
adquisición de sistemas de información y servicios relacionados)
considera proyectos de desarrollo de nuevos Sistemas de
Información y también los proyectos de ampliación y mejora
de los ya existentes.
Métrica V3 – Proceso
• Las actividades de la Interfaz de Gestión de Proyectos se
presentan en el siguiente esquema, en el que se aprecian
las áreas que cubre. Se distinguen tres grupos de
actividades:
▫ Actividades de Inicio del Proyecto (GPI).
▫ Actividades de Seguimiento y Control (GPS).
▫ Actividades de Finalización del Proyecto (GPF).
Métrica V3 – Actividades
• Actividades de Inicio del Proyecto (GPI). Al principio del
proyecto, al concluir el proceso Estudio de Viabilidad del Sistema, se
realizarán las actividades de Estimación de Esfuerzo y Planificación
del proyecto.
• Actividades de Seguimiento y Control (GPS). Comprenden

desde la asignación de las tareas hasta su aceptación por parte del
equipo de proyecto, incluyendo la gestión de incidencias y cambios
en los requisitos. El Seguimiento y Control del proyecto se realizan
durante los procesos de Análisis, Diseño, Construcción,
Implantación y Aceptación, y Mantenimiento del Sistema de
Información, para vigilar el correcto desarrollo de las actividades y
tareas establecidas en la planificación.
• Actividades de Finalización del Proyecto (GPF). Por último,

al concluir el proyecto se realizan las tareas propias de Cierre del
Proyecto y Registro de la Documentación de Gestión.
Métrica V3 - GPI
• Tienen un doble objetivo: estimar el esfuerzo a
realizar para desarrollar el sistema y planificar
las actividades de dicho desarrollo.
• Para ello, toman como punto de partida la
Solución Propuesta en el EVS.
• Se identifican los elementos a desarrollar, se
calcula el esfuerzo a realizar, y se planifican
las actividades.
Métrica V3 – Tareas GPI
• Estimación
Métrica V3 – Tareas GPI
• Planificación
Métrica V3 – GPS
• Objetivo: Vigilar las actividades de desarrollo del
sistema.
• Para ello busca desviaciones (retrasos), para analizar sus
causas y realizar correcciones con el objeto de
recuperar el tiempo perdido.
• Se aplican desde la asignación de las tareas hasta su
aceptación interna.
• Las tareas de Seguimiento y Control se ponen en marcha
a medida que se ejecutan las distintas tareas de los
procesos de Análisis, Diseño, Construcción,
Implantación y Mantenimiento del Sistema.
Métrica V3 – Tareas GPS
• Cuatro funciones:
Cambio en los requisitos
GPS 6 GPS 8
GPS 5 Análisis de GPS 7 Estimación del GPS 9
Petición de la petición Aprobación esfuerzo y Registro del
cambios de de cambio de la solución Planificación cambio de
requisitos de requisitos de la solución requisitos
GPS 1 GPS 2 GPS 3 GPS 10 GPS 11 GPS 12

Asignación Comunicación Seguimiento Finalización Actualización Reuniones de GPS 13
detallada al equipo de tareas de latarea de la seguimiento Aceptación
de tareas del proyecto planificación
GPS 4
Análisis y Control, reacción e informes
Asignación y seguimiento registro de
la incidencia
Incidencias y problemas
• Asignación y seguimiento
▫ Para que una tarea finalice con éxito es importante asignarla a un
técnico capaz de desarrollarla, por lo que se debe estudiar muy
bien cada tarea antes de su asignación y conocer los
conocimientos y capacidades de los componentes del
equipo de proyecto.
▫ Informar al equipo de proyecto de las características del mismo
y comunicar a cada miembro las tareas específicas que va a
desarrollar.
▫ Seguimiento de todas las tareas que están siendo desarrolladas,
revisando con cada uno de los responsables de las tareas la fecha
real de comienzo, el tiempo empleado hasta el momento en su
realización, la apreciación del tiempo que queda para terminarla
y los problemas o incidencias encontradas.
• Asignación y seguimiento
• Cambio en los requisitos
▫ El usuario formula una petición de cambio de los requisitos
iniciales.
▫ Analizar en detalle la petición, contemplando los posibles
cambios en la funcionalidad y el impacto que el cambio pedido
tendría sobre el resto del Sistema de Información. Estudiar las
posibles alternativas de solución, considerando para cada
alternativa los recursos, esfuerzo, tiempo y coste que supone.
▫ Elegir una solución y planificar las nuevas actividades que
genera y replanificar las tareas que se ven afectadas (por
dependencias con las nuevas o por reorganización de los
recursos).
▫ Por su gravedad, es el último recurso al que hay que recurrir
para resolver un problema.
• Cambio en los requisitos (I)
• Cambio en los requisitos (II)
▫ Se prevén cuatro posibilidades:
 El Comité rechaza la petición, archivándose ésta como
rechazada indicándose el porqué.
 El Comité juzga que la petición es necesaria, pero que el
coste o la dilatación son excesivos. El Equipo del Proyecto
lo revisa.
 El Comité de Seguimiento aprueba la petición.
 El Comité de Seguimiento aprueba la petición pero
decide aplazar su desarrollo hasta otro momento.
• Cambio en los requisitos (III)
• Incidencias y problemas
▫ Conocer las tareas a las que afecta la incidencia y evaluar
su impacto en términos de:
 Horas necesarias para resolverla.
 Retrasos previstos.
 Recursos afectados.
▫ Plantear posibles alternativas de solucionar la
incidencia y elegir una, designando a los miembros del
equipo de proyecto encargados de realizarla. De acuerdo
con la solución adoptada habrá que revisar y ajustar la
planificación del proyecto.
▫ Registrar la incidencia para imputar sus costes e prevenir
que vuelva a ocurrir.
• Incidencias y problemas
• Control, reacción e informes
▫ El Jefe de proyecto deberá comprobar las tareas que han
finalizado correctamente y registrar su fecha de
finalización y el esfuerzo real empleado.
▫ Con los datos obtenidos en el seguimiento de tareas, gestión
de incidencias y cambios de requisitos, el Jefe de proyecto
debe:
 Actualizar la planificación detallada del proyecto para
adecuar el estado de cada tarea a la situación real.
 Estimar cual será la evolución futura del proyecto y
decidir en consecuencia (replanificar o corregir si es
necesario).
 Informar al Equipo de proyecto y al Comité de dirección
de lo realizado, las incidencias y desviaciones
detectadas junto con las acciones encaminadas a
corregirlas y las variaciones en los recursos.
• Control, reacción e informes (I)
• Control, reacción e informes (II)
Métrica V3 – GPF
• Su objetivo es dar por concluido el proyecto una vez
aceptado por el usuario.
• Esta actividad consiste en resumir los datos del
proyecto, en cuanto a funcionalidad, tecnología, equipo
técnico, formación recibida, experiencias, logros,
problemas encontrados y, en general, cualquier dato que
el Jefe de proyecto considere de interés.
• Hay que tener en cuenta que esta información tiene la
finalidad de servir de apoyo a proyectos futuros,
aprovechando las experiencias habidas y tratando de
evitar incurrir en los mismos errores.
• Las actividades de finalización son las siguientes:
▫ Realizar el balance final del proyecto.
▫ Registrar toda la información de gestión del proyecto
Métrica V3 – Tareas GPF
• El Histórico de Proyectos es una base de datos la información
importante de todos los proyectos de la organización (métricas de
gestión de proyectos). Por ejemplo, la plataforma tecnológica
donde se ha trabajado, la metodología y el entorno metodológico
(herramientas Case), las incidencias ocurridas, aspectos funcionales
y los organizativos.
• Toda la documentación de gestión del proyecto, tanto en papel
como en soporte magnético, sea ordenada y archivada. Así mismo se
registrará la versión del sistema.
PMBOK - Introducción
 Proyect Management Body Of Knowledge, creado por PMI
(Proyect Management Institute).
 PMBOK surge de la necesidad de poseer un manual de referencia
para los gestores de proyectos.
 Unifica el léxico, conocimientos, habilidades y prácticas.
 Documento usado por PMI para el examen de certificación PMI
(Proyect Management Professional).
 Existen distintas versiones desde 1996. 5ta versión Publicada en 2013
 El 6 de septiembre de 2017 se publicó la versión 6 PMBOK.
 PMBOK refiere a conocimientos y prácticas aplicables a la
mayoría de los proyectos,
 "buena práctica" implica que hay un acuerdo general para la
aplicación de los conocimientos, habilidades, herramientas y
técnicas que recomienda para aumentar el éxito en proyectos.
PMBOK – Definiciones y conceptos
 Proyecto: esfuerzo temporal iniciado para crear un único
producto o servicio.
 Gestión de proyectos: aplicación de conocimientos, habilidades y

técnicas para las actividades de un proyecto con el objeto de
satisfacer las necesidades y expectativas.
 PMBOK establece tres apartados:

 Fases y Ciclo de Vida
 Procesos
 Áreas de conocimiento
PMBOK – Fases y ciclo de vida
 Fases: marcadas por uno o mas entregables.
 Ciclo de vida: determina el comienzo y el final de un proyecto.
 El CV define:
 Trabajos técnicos realizados en cada fase.
 Quién debe estar involucrado en cada fase.
 No confundir CV del proyecto con el CV del producto.
 Metodología de gestión de proyecto: descripción detallada del
CV.
PMBOK – Procesos
 Proceso: serie de acciones que tiene como consecuencia un
resultado.
 Relaciones entre procesos:

 Inputs. Documentos mediante los cuales se actuará.
 Herramientas y técnicas. Mecanismos aplicados a los inputs para crear los
outputs.
 Outputs. Documentos que son el resultado de los procesos.
 PMBOK organiza los procesos en 5 grupos.

PMBOK – Procesos
 Dos categorías:
 Procesos de gestión. Describir y organizar el trabajo del proyecto.
 Procesos orientados al producto. Especificar y crear el producto del
proyecto.
 División en subprocesos de dos tipos:
 Básicos. Son aquellos procesos que tienen claras dependencias y requieren
ser ejecutados de la misma manera en la mayoría de los proyectos.
 De facilitación. Son aquellos procesos que dependen de la naturaleza del
proyecto y no tienen que, obligatoriamente, ejecutarse de manera regular.
PMBOK - Procesos
PMBOK – Procesos de iniciación
• Iniciación: Se reconoce que un proyecto o fase

debe comenzar y se comprometen a ello.
• Tiene un único subproceso: Iniciación.

PMBOK – Proceso de planificación
• El proceso de Planificación desarrolla y
mantiene un esquema revisable de tareas a
desarrollar para completar el proyecto.
• Este esquema se denomina plan del proyecto.

PMBOK – Proceso de planificación
PMBOK – Proceso de ejecución
• Este proceso coordina a las personas y otros
recursos para desarrollar o llevar a cabo el plan
del proyecto anteriormente definido.
PMBOK – Proceso de ejecución
PMBOK – Proceso de control
• Este proceso asegura que los objetivos del
proyectos sean cumplidos a través de la
monitorización y medición del avance y toma de
acciones correctivas cuando sea necesario.
• Ha de llevar a cabo acciones preventivas,

anticipándose a posibles problemas.
PMBOK – Proceso de control
PMBOK – Proceso de cierre
• El proceso de cierre formaliza la aceptación del
proyecto y permite una terminación ordenada.
PMBOK – Proceso de cierre
PMBOK – Relación entre procesos
• Los procesos se relacionan mediante los resultados que
producen, que son a su vez entradas de otros
• No son necesariamente secuenciales y puede haber

feedback
PMBOK – Áreas de conocimiento
• Describen conocimiento y prácticas de la
administración de proyectos utilizadas en los
procesos.
• Se han definido nueve áreas de conocimiento.
• Dependiendo del área de conocimiento se
requerirán unos procesos y otros para su
realización.
• Gestión de integración del proyecto.
Describe los procesos necesarios para asegurar
la coordinación de todos los elementos de
proyecto.
• Subprocesos:
▫ Desarrollo del plan de proyecto (Planificación)
▫ Ejecución del plan de proyecto (Ejecución)
▫ Control de cambios generales (Control)
• Gestión del Alcance. Describe todos los
procesos necesarios para asegurar que el
proyecto incluye todo el trabajo requerido, y sólo
el trabajo requerido para llegar al éxito del
proyecto.
• Subprocesos:
▫ Iniciación
▫ Planificación del alcance y Definición del alcance
(Planificación)
• Gestión del Tiempo. Describe los procesos
requeridos para asegurar los tiempos del
proyecto.
• Subprocesos:
▫ Definición de actividades, Secuenciación de
actividades y Estimación de duración de
actividades (Planificación)
▫ Desarrollo del cronograma (Ejecución)
▫ Control del cronograma (Control)
• Gestión de Costos. Describe los procesos
necesarios para asegurar que el proyecto es
completado sin salirse del presupuesto
aprobado.
• Subprocesos:
▫ Planificación de los recursos, Estimación de costos
y Presupuesto de costo (Planificación)
▫ Control de costos (Control)
• Gestión de Calidad. Describe los procesos
requeridos para asegurar que se satisfacen las
necesidades para las cuales fue concedido el
proyecto.
• Subprocesos:
▫ Planificación de la calidad (Planificación)
▫ Aseguramiento de la calidad (Ejecución)
▫ Control de calidad (Control)
• Gestión de Recursos Humanos. Describe
todos los procesos necesarios para obtener el
uso más eficiente de todas las personas
involucradas en el proyecto.
• Subprocesos:
▫ Planificación organizacional, Adquisición del
personal (Planificación)
▫ Desarrollo de equipo (Ejecución)
• Gestión de Comunicación. Describe los
procesos requeridos para asegurar la
generación, recopilación, difusión,
almacenamiento y disposición de la información
del proyecto de modo puntual.
• Subprocesos:
▫ Planificación de la comunicación (Planificación)
▫ Distribución de la información (Ejecución)
▫ Informes de desenvolvimiento (Control)
▫ Cierre administrativo (Cierre)
• Gestión de Riesgos. Describe los procesos
relevantes a la identificación, análisis y
respuesta de los riesgos que podrían darse en el
proyecto.
• Subprocesos:
▫ Planificación de gestión de riesgos, Identificación
de riesgos, Análisis cualitativo de riesgos, Análisis
cuantitativo del riego y Desarrollo de la respuesta
al riesgo (Planificación)
▫ Monitorización y control de riesgos (Control)
• Gestión de la Compra. Describe los procesos
requeridos para adquirir bienes y servicios de
entidades externas a la organización.
• Subprocesos:
▫ Planificación de adquisición y Planificación de
solicitud (Planificación)
▫ Solicitud, Selección de la fuente y Administración
de contrato (Ejecución)
▫ Cierre del contrato (Cierre)
Gestión ágil de proyectos: Scrum
Introducción
• Scrum es una metodología ágil de desarrollo de

proyectos que toma su nombre y principios de los
estudios realizados sobre nuevas prácticas de
producción por Hirotaka Takeuchi e Ikujijo Nonaka a
mediados de los 80.
• En 1996 se definió por primera vez un patrón para

aplicar esos principios de desarrollo en “campos de
scrum” al software.
• Esta fue la primera definición de un patrón Scrum

aplicado al software, diseñada por Jeff Sutherland y Ken
Schwaber en 1996
Introducción
• SCRUM es una metodología ágil de gestión de
proyectos cuyo objetivo primordial es elevar
al máximo la productividad de un equipo.
• Reduce al máximo la burocracia y actividades

no orientadas a producir software que
funcione y produce resultados en periodos
muy breves de tiempo (cada 30 días), por
medio de iteraciones o Sprints.
• Ideal para proyectos con un rápido cambio de

requerimientos.
CONTEXTO SCRUM
Sólo abarca Delega completamente Sus raíces

prácticas de en el equipo la teóricas están en
gestión sin entrar responsabilidad de las teorías de la
en las prácticas de decidir la mejor manera auto-
desarrollo como de trabajar para ser lo organización.
puede hacer XP. más productivos posibles
y, le da gran
protagonismo a las
reuniones que realicen a
lo largo del proyecto.
La esencia de Scrum
 Al iniciar cada iteración, el equipo revisa el trabajo

pendiente del proyecto y selecciona la parte que
terminará como un incremento de funcionalidad
incorporado al software al terminar la iteración.
 Al final de la iteración el equipo presenta el incremento
de funcionalidad a las partes implicadas en el proyecto.
El equipo revisa los requisitos, considera la tecnología disponible, evalúa sus

conocimientos, y de forma colectiva determina cómo implementar la funcionalidad.
Roles
Scrum tiene una estructura muy simple. Todas las responsabilidades del proyecto se
reparten en 3 roles:
 Propietario del producto (Product Owner)
 Equipo (Scrum Team)
 Gestor de Scrum (Scrum manager o Scrum Master)
Responsable del proceso Scrum.
* Formación y entrenamiento del proceso.
* Incorporación de Scrum en la cultura de la empresa.
* Garantía de cumplimiento de roles y responsabilidad.

Auto - Gestionado
Responsable
de transformar Auto - Organizado
el Backlog de la
iteración en un
incremento de la Multi - Funcional
funcionalidad
del software.
Roles
Propietario del producto

Representa a todos los interesados en el producto final.
Sus áreas de responsabilidad son:
 Financiación del proyecto

 Requisitos del sistema
 Retorno de la inversión del proyecto
 Lanzamiento del proyecto
Equipo
Responsable de transformar la pila del sprint (Sprint Backlog) en un incremento de
la funcionalidad del software
 Auto-gestionado
 Auto-organizado
 Multi-funcional
Scrum Manager
Responsable del proceso Scrum
 Formación y entrenamiento del proceso

 Incorporación de Scrum en la cultura de la empresa
 Garantía de cumplimiento de roles y responsabilidad
Los roles: Product Owner
• Persona conocedora del entorno de negocio del
cliente y de la visión del producto.
• Representa a todos los interesados en el
producto final
• Es el responsable del Product Backlog
Procesos internos:
• Responsable de marketing
• El Product Manager
Procesos externos:
• Responsable del proceso de adquisición del cliente
Los Roles: Scrum Team
• Equipo multidisciplinar que cubre todas las
habilidades necesarias para generar el resultado
• Se auto-gestiona y auto-organiza
• Dispone de atribuciones suficientes para toma

de decisiones sobre cómo realizar su trabajo
Los roles: Scrum Master
• Garantiza el funcionamiento de los procesos y
metodologías que se emplean
• No designa a una persona sino más bien a la
responsabilidad de funcionamiento del modelo
• Es un role flexible:
▫ Dirección de la empresa, con el conocimiento de
gestión y desarrollo ágil y facilitando los recursos
necesarios
▫ Responsables del Departamento
▫ Responsables del área de gestión de proyectos
▫ …
Scrum
Scrum es un método adaptativo de gestión de proyectos que se basa en los principios ágiles:
 Colaboración estrecha con el cliente.
 Predisposición y respuesta al cambio
 Prefiere el conocimiento tácito de las personas al explícito de los procesos
 Desarrollo incremental con entregas funcionales frecuentes
 Comunicación verbal directa entre los implicados en el proyecto
 Motivación y responsabilidad de los equipos por la auto-gestión, auto-organización y
compromiso.
 Simplicidad. Supresión de artefactos innecesarios en la gestión del proyecto.
Scrum diferencia entre estos dos grupos

para garantizar que quienes tienen la
responsabilidad tienen también la autonomía
necesaria para poder lograr el éxito, y que
quienes no tienen la responsabilidad no
producen interferencias innecesarias
IMPLICADOS EN EL PROYECTO
COMPROMETIDOS EN EL PROYECTO Marketing
 Propietario del producto Comercial
 Equipo Etc.
* Equipos de entre 6 y 10 personas revisan los
requisitos, la tecnología disponible y evalúan los
conocimientos para Colectivamente determinar
como incrementar la funcionalidad.
* Reuniones diarias, antes de empezar a trabajar,

con una duración máxima de 4 hrs.
* Se llevan a cabo hasta que el proyecto este listo

para ser puesto en producción o ser lanzado al
mercado.
* En la primera reunión se explica al equipo la forma de
trabajo, especificando que son reuniones cortas para
coordinar trabajo y no para solucionar problemas. Se
establecen los criterios para arreglar los errores por
prioridades (base del éxito del sistema).
* En cada reunión las preguntas claves a contestar son:

• Qué es lo que se hizo desde la última reunión?
• Qué es lo que se va a hacer hasta la siguiente reunión?
• Cómo se va a llevar a cabo?
Componentes de SCRUM
• Las Reuniones
▫ Planificación del Sprint
▫ Seguimiento del Sprint
▫ Revisión del Sprint
• Los elementos
▫ Product Backlog
▫ Sprint Backlog
▫ Incremento
• Los roles o responsabilidades:
▫ Responsables del producto: “Product Owner”
▫ Responsables del desarrollo: “Scrum Team”
▫ Responsables del funcionamiento de Scrum:
“ScrumMaster”
Capacidad
Sprint Planning meeting
del Equipo
Priorización
Product
• Analizar y evaluar el Product Objetivo
Backlog Backlog del Sprint
• Seleccionar el objetivo del
Sprint
Condiciones
del Negocio Planificación
• Decidir como alcanzar el
objetivo del Sprint (diseño)
Producto
• Crear el Sprint Backlog (tareas) Sprint
Actual
en base a los temas del Product Backlog
Backlog (user stories / features)
Tecnología
• Estimar Sprint Backlog en horas
Planificación del Sprint
• El equipo selecciona los temas a partir del Product
Backlog que pueden comprometerse a completar
• Se crea el Sprint Backlog
▫ Se identifican tareas y cada una es estimada (1-16 horas)
▫ Realizado colaborativamente, no solo por el ScrumMaster
• El diseño de Alto Nivel es considerado
COMO planificador Codificar la capa intermedia (8

de vacaciones, YO hs)
QUIERO ver fotos Codificar la interfaz de usuario (4)
de los hoteles. Escribir los test fixtures (4)
Codificar la clase foo (6)
Actualizar test de performance (4)
Daily Scrum
• Parámetros
▫ Diaria
▫ Dura 15 minutos
▫ Parados
• No para la solución de problemas
▫ Todo el mundo está invitado
▫ Sólo los miembros del equipo, ScrumMaster y
Product Owner, pueden hablar
▫ Ayuda a evitar otras reuniones innecesarias
Todos responden 3 preguntas
1
¿Qué hiciste ayer?
2
¿Qué vas a hacer hoy?
3
¿Hay obstáculos en tu camino?
• No es dar un status report al Scrum Master
• Se trata de compromisos delante de pares
Sprint review
• El equipo presenta lo realizado durante el sprint
• Normalmente adopta la forma de una demo de
las nuevas características o la arquitectura
subyacente
• Informal
▫ Regla de 2 hs preparación
▫ No usar diapositivas
• Todo el equipo participa
• Se invita a todo el mundo
Sprint retrospective
• Periódicamente, se echa un vistazo a lo que
funciona y lo que no
• Normalmente 15 a 30 minutos
• Se realiza luego de cada sprint
• Todo el equipo participa
▫ ScrumMaster
▫ Product owner
▫ Equipo
▫ Posiblemente clientes y otros
Start / Stop / Continue
• Todo el equipo se reúne y discute lo que les
gustaría:
Comenzar a hacer
Dejar de hacer
Esto es sólo una
de las muchas
maneras de Continuar haciendo
hacer una
retrospectiva.
El flujo de Scrum
Nueva funcionalidad
Pila del sprint
Selección de la
Pila de producto
Pila de producto
Requisitos priorizados
Visión:
ROI – versiones
hitos
Fuente: Agile Project Management with Scrum
Ken Schwaber
El flujo de Scrum
Sprint
Es el periodo de tiempo durante el que se desarrolla un incremento de funcionalidad.

Constituye el núcleo de Scrum, que divide de esta forma el desarrollo de un proyecto
en un conjunto de pequeñas “carreras”.
 Duración máxima: 30 días.

 Durante el sprint no se puede modificar el trabajo que se ha acordado en el Backlog.
 Sólo es posible cambiar el curso de un sprint, abortándolo, y sólo lo puede hacer el
Scrum Master si decide que no es viable por alguna de las razones siguientes:
 La tecnología acordada no funciona.
 Las circunstancias del negocio han cambiado.
 El equipo ha tenido interferencias.
El objetivo del Sprint
• Una breve declaración de cual será el foco del
trabajo durante el sprint
Ciencias Biológicas
Funciones de apoyo técnico
Aplicación con B.Datos
necesarios para estudios de
genética de poblaciones.
Hacer que la aplicación se
ejecute en SQL Server, además
de Oracle. Servicios Financieros
Soportar más indicadores

técnicos que la empresa ABC en
tiempo real y streaming de
datos.
Artefactos
Pila de producto (Product Backlog)
Listado con los requisitos del sistema

 Es responsabilidad del dueño del producto
 Contenido
 Priorización
 Disponibilidad
 Nunca llega a ser una lista completa y definitiva
 El empleado para planificar el proyecto es sólo una estimación inicial de requisitos
 Es un documento dinámico que incorpora constantemente las necesidades del sistema
 Se mantiene durante todo el ciclo de vida (hasta la retirada del sistema).
Product Backlog• Los requisitos
• Una lista de todos los
trabajos deseados en el
proyecto
• Idealmente cada tema tiene
valor para el usuarios o el
cliente
• Priorizada por el Product
Owner
• Repriorizada al comienzo
Este es el de cada Sprint
product backlog
Producto Backlog
• Crea un listado con los requisitos de los
usuarios o propietarios del sistema para
planificar el proyecto.
• No es una lista completa y definitiva. Es
sólo una estimación inicial de los
requisitos.
• Es un documento dinámico que incorpora
las constantes necesidades del sistema y
se mantiene durante todo el ciclo de vida
(hasta la retirada del Sist.).
Artefactos
Pila de producto
Estimación inicial
Estim. ajustada
Trabajo pendiente
Complejidad
Product Backlog
Sprint
2
1
4
3
ID Elemento
1 Nuevo formulario para peticiones de clientes 2 0.2 2,4 2,4 0 0 0
2 Configuración de respuestas automáticas 3 0.2 3,6 3,6 0 0 0
3 Envío automático de respuestas 1 0.2 1,2 1,2 0 0 0
4 Consulta para los clientes de peticiones enviadas 1 0.2 1,2 1,2 0 0 0
5 Modificación del cliente de sus peticiones enviadas 2 0.2 2,4 2,4 0 0 0
6 Acceso a peticiones sólo para clientes del portal jurídico 5 0.2 6 6 0 6 0
7 Consulta de peticiones por parte del staff 1 0.2 1,2 1,2 0 0 0
SPRINT 1 15 18 18 0 0 0
8 Inserción de comentarios y reasignación a peticiones (staff) 2 0.2 1,2 1,2 1,2 0 0
9 Consultas por clientes, fechas y temas 3 0,2 3,6 3,6 3,6 0 0
10 [Continúa]….
Ejemplo de Product Backlog
Backlog item Estimación
Permitir que un invitado a hacer una reserva. 3
Como invitado, quiero cancelar una reserva. 5
Como invitado, quiero cambiar las fechas de
3
una reserva.
Como un empleado de hotel, puedo ejecutar
informes de los ingresos por habitación 8
disponible
Mejorar el manejo de excepciones 8
... 30
... 50
Artefactos
Pila del sprint (Sprint Backlog)
Trabajo o tareas determinadas por el equipo para realizar en un sprint y lograr al final del mismo
un incremento de la funcionalidad.
Se recomienda que las tareas reflejadas tengan una duración comprendida entre las 4 y las 16
horas de trabajo.
Las de mayor duración deben intentar descomponerse en sub-tareas de ese rango de tiempo.
Especifica la serie de tareas que se van a desarrollar según los

requisitos señalados.
Al final del sprint se busca un incremento en la funcionalidad.

Gestión del Sprint Backlog
• Los individuos eligen las tareas
• El trabajo nunca es asignado
• La estimación del trabajo restante es actualizada
diariamente
• Cualquier miembro del equipo puede añadir, borrar
o cambiar el Sprint Backlog
• El trabajo para el Sprint emerge
• Si el trabajo no está claro, definir un tema del Sprint
Backlog con una mayor cantidad de tiempo y
subdividirla luego.
• Actualizar el trabajo restante a medida de que más
se conoce
Ejemplo de Sprint Backlog
Tareas L M M J V
Codificar UI 8 4 8
Codificar negocio 16 12 10 4
Testear negocio 8 16 16 11 8
Escribir ayuda online 12
Escribir la clase foo 8 8 8 8 8
Agregar error logging 8 4
Comunicación
Reunión diaria
Revisión del sprint
Reunión retrospectiva
La forma más eficiente y efectiva de comunicar información de ida y vuelta dentro de

un equipo de desarrollo es mediante la conversación cara a cara.
Revisión diaria
Iteración
Sprint backlog Nueva
funcionalidad
Producto. Back log Producto. Back log

seleccionado priorizado
Comunicación
Reunión diaria
Reunión del equipo con duración máxima de 15 minutos.

 Todos los días en el mismo sitio y a la misma hora.
 Se recomienda que sea la primera actividad del día.
 Deben acudir todos los miembros del equipo.
 Moderada por el Scrum Manager, que pregunta a todos los asistentes
 ¿Cuál ha sido el trabajo realizado desde la última revisión diaria?
 ¿Cuál es el trabajo previsto para hoy?
 ¿Hay algo que necesitas, o que te impide realizar el trabajo previsto?
 No se permite entrar en divagaciones o salirse del guión.
 Sólo habla la persona que informa de su trabajo, el resto escucha y no hay lugar para
otras conversaciones.
 Cuando un miembro informa de algo de interés para otros, o necesita ayuda de otros,
estos se reúnen al terminar la revisión diaria.
 ¿Qué trabajo has realizado desde la última reunión?

 ¿Qué tienes previsto para hoy?
 ¿Qué necesitas?
Comunicación
Revisión del sprint
Reunión del equipo, Scrum Manager, propietario del producto con todas las personas implicadas
en el proyecto.
 Duración máxima: 4 horas.
 Finalidad: presentar al propietario del producto y a los implicados las nuevas
funcionalidades implementadas.
 Las funcionalidades no implementadas no se presentan.
 En la reunión, los miembros del equipo muestran las nuevas funcionalidades.
 Al final de la reunión se interroga individualmente a todos los asistentes para recabar
impresiones, sugerencias de cambio y mejora, y su relevancia.
 El propietario del producto trata con los asistentes y con el equipo las posibles
modificaciones en la pila de producto.
Comunicación
Reunión retrospectiva
Acuden el equipo y el Scrum Master, y opcionalmente el Propietario del Producto.

 Todos los miembros del equipo responden a dos preguntas:
 ¿Qué cosas fueron bien en el último sprint?
 ¿Qué cosas se podrían mejorar?
 El Scrum Manager anota todas las respuestas
 El equipo prioriza las mejoras posibles
 El Scrum Manager no proporciona respuestas, sino que ayuda al equipo a encontrar la
mejor forma de trabajar con Scrum.
 Las acciones de mejora localizadas que se puedan implementar en el próximo Sprint
deben introducirse en la pila de producto como elementos no funcionales.
Factores claves en Scrum
• Delegación de atribuciones al ScrumTeam: auto-
organización y toma de decisiones
• Respeto entre las personas: confianza en los
conocimientos y capacidades
• Responsabilidad y autodisciplina
• Trabajo centrado en el compromiso de
desarrollo
• Información, transparencia y visibilidad en el
desarrollo del proyecto
 Valor para la organización ante todo, representado en software
funcional
 Es preferible tener el 70% de funcionalidad a tiempo que
tratar de lograr el 100% y fallar .
 Metodología sencilla pero efectiva.
 Visibilidad durante todo el proyecto.
 No existe sorpresas.
 Scrum no dice como desarrollar, el equipo de desarrollo
escoge la metodología
Fases
Tema 2 Planificación del tiempo
Fases de un proyecto
• I. Detección y decisión de realización.
▫ Identificación de la oportunidad, análisis y oferta.
▫ Negociación, asignación y plan de proyecto.
• II. Realización.
▫ Arranque.
▫ Desarrollo.
▫ Puesta en marcha.
• III. Explotación y cierre.
Fases de un proyecto (otro punto
de vista)
• Osadía
Detección y decisión de realización
• Alegría
• Confusión
Realización
• Desilusión
• Búsqueda de los culpables
• Castigo de los inocentes Explotación y cierre
• Condecoración de los que no han
participado
I. Detección y decisión de realización
• Concurso.
▫ Un organismo identifica una necesidad que no puede
satisfacer con sus propios recursos.
▫ La forma de hacer pública esta necesidad es el Concurso.
▫ Un Concurso es útil si:
 Existe un número alto de posibles proveedores.
 Los posibles proveedores son desconocidos.
 El volumen del contrato compensa el esfuerzo de
preparar y convocar un Concurso.
▫ Si no se cumplen las condiciones anteriores se puede
contactar directamente con los posibles proveedores.
• Bases de un Concurso.
▫ El contratante tiene que preparar una petición de
oferta o Pliego de Condiciones.
▫ El contratista debe de evaluar la decisión de
ofertar.
▫ En caso de interesarle ofertar deberá preparar
su oferta.
▫ El contratante tendrá que evaluar las
diferentes ofertas que reciba.
▫ El contratista y el contratante negociarán los
términos de la adjudicación.
• Pliego de Condiciones.
▫ Claridad en la redacción para que el contratista que se
elija no tenga ambigüedades o mal entendidos en cuanto
a calidad, plazos y precio.
▫ Se facilitarán instrucciones de la forma de
presentación de las ofertas buscando una
uniformidad para que podamos deducir las
capacidades de cada contratista.
▫ Se incorporará la lista de requisitos y condiciones.
▫ Se pueden pedir pruebas y cruces de datos para
asegurarnos de la veracidad de la información
aportada por los contratistas.
• Tipos de documentos en un Concurso.
▫ Legal: justificante de existencia de la Sociedad,

justificante de tasas.
▫ Técnico: planificación, garantías de calidad.
▫ Económico: calendario de cobros, presupuesto,
penalizaciones.
▫ Administrativo: declaración de arbitraje en caso
de litigio, declaración de conformidad con
condiciones generales.
• Antes de ofertar.
▫ Estudio del Pliego de Condiciones y los requisitos allí recogidos
haciendo hincapié en los trabajos o servicios a prestar por terceros.
▫ Considerar los beneficios y los riesgos que se asumen si se
adjudica la contratación.
▫ Estudiar la disponibilidad de recursos para poder atender los
compromisos derivados de la oferta o si se pueden aumentar (¡los
recursos son limitados!)
▫ Estudiar si es soportable el esfuerzo financiero a satisfacer.
▫ Estudiar la posibilidad de contratos similares y si se pueden
estandarizar los procedimientos enriqueciendo la experiencia de la
empresa.
▫ Análisis DAFO (debilidades, amenazas, fortalezas y oportunidades)
• Preparar la oferta.
▫ Elegir un responsable de preparar la oferta.
▫ Determinar el grados de libertad frente al cliente, expresado
en el Pliego de Condiciones.
▫ Descomponer el trabajo en hitos, fases y tareas (análisis de la
oferta).
▫ Asignar las fases a las distintas áreas de la empresa para que
estimen el trabajo que deberán realizar y ofrecer datos de
valoración de cada fase.
▫ Integrar las fases considerando los esfuerzos de coordinación.
▫ Obtener el coste del producto y de los plazos de realización,
indicando los puntos mejorados y los puntos no incluidos.
▫ Posibilidad de incluir estudios distintos a los pedidos
indicando claramente las ventajas que tendría el contratante si
siguiera estos procedimientos o recomendaciones.
▫ Someter la oferta al departamento jurídico para que estudie
los modelos de contratos y la redacción.
• Evaluación de las ofertas.
▫ Comprobación de que cada ofertante cumple los requisitos
legales para poder ser contratados.
▫ Análisis de las posibilidades de cada una de las empresas,
estudiando su estructura, su potencia y su organización.
▫ Análisis de la calidad que se estime van a cumplir cada una de
las empresas ofertantes.
▫ Precio del producto o servicio.
▫ Valoración del riesgo que se corre por elegir una empresa u otra.
▫ Establecimiento de una métrica basada en factores y pesos
para clasificar las ofertas según una determinada valoración.
▫ Elaboración de un informe de valoración donde quede muy
claro los criterios tomados y en el que se propone un orden de
adjudicación y una lista de empresas excluidas con su
justificación.
• Negociación de la oferta.
▫ Importancia de nombrar un interlocutor con plenos poderes.
▫ Conocimiento de la importancia estratégica de la empresa en
el contrato a obtener.
▫ Investigación de la situación de los competidores frente al
contrato en curso.
▫ Conocimiento de los criterios de evaluación.
▫ Cualidades de buenos negociadores, conocimientos sobre
requisitos y condicionantes legales y administrativos, etc.
• Resumen Contratante.
• Resumen Ofertante.
II. Realización
• Arranque administrativo del proyecto.
▫ Autorización de la dirección para que empiece el proyecto.
Cada organización tiene sus propias normas internas.
▫ Requisitos mínimos generales para que se autorice el arranque de
un proyecto:
 Compromiso claro, por escrito, del contratante.
 Bien definidos los tres objetivos primarios: que vamos a hacer,
cuanto nos va a costar y cuando lo vamos a terminar.
 Se haya nombrado un director del proyecto.
 Comunicación del arranque a las personas de primer nivel de
dirección involucradas.
 Se haya completado la documentación básica del proyecto (Project
Charter).
II. Realización - Plan de proyecto
• Responsabilidad del jefe de proyecto:
▫ conjunto de acciones
▫ recursos para cumplir requisitos
• Objetivos:
▫ Resumir proyecto para directivos
▫ Facilitar control de progreso de jefe de proyecto y
cliente
▫ Establece criterios de terminación y de éxito
▫ Documento de base aprobado por cliente y
actualizable
• Contenido
▫ Resumen de proyecto y productos que se entregan
▫ Hitos: acontecimientos con responsabilidad
▫ Procedimientos y estándares (referencia)
▫ Comunicación entre cliente y personal de proyecto
▫ Diagrama de descomposición de trabajo (WBS)
▫ Lista de personal y su asignación a WBS
▫ Red de actividades
▫ Presupuestos y calendario para cada actividad
• Introducción • Proceso técnico
• Resumen, productos, • Metodología, técnicas y
referencias y definiciones herramientas
•Organización de proyecto • Documentación
• Modelo de procesos, • Funciones de apoyo
estructura organizativa y •Plan de desarrollo
responsabilidades • Paquetes de trabajo
•Gestión • Dependencias
• Objetivos y prioridades • Recursos asignados
• Supuestos, dependencias y • Presupuesto y distribución
restricciones de recursos
• Gestión de riesgos • Calendario
• Supervisión y control •Anexos
• Personal • Calidad, gestión de
configuración, etc.
II. Realización - Plan del proyecto
• Triángulo de triple compromiso
Calendario
Calidad Coste
II. Realización
• Arranque operativo del proyecto.
▫ 1. Reunión de lanzamiento del proyecto con el cliente.
▫ 2. Reunión de coordinación del proyecto sin el cliente.

II. Realización
• Reunión de lanzamiento del proyecto.
▫ Se establecen las ideas generales respecto a:
 Los objetivos a alcanzar.
 Los requisitos contractuales en configuración, calidad, plazos y
costos.
 La organización existente y los recursos con los que se cuenta.
 Los hitos y puntos de control a realizar.
▫ Todo ello estará soportado por una documentación apropiada.
▫ Se considerarán los posibles protocolos de aceptación:
 Protocolo provisional en el que el proyecto se acepta a falta de
subsanar algunos detalles a satisfacer en un tiempo prudencial.
 Protocolo definitivo que se limita a dejar constancia de que la lista
anterior ha sido finalizada a satisfacción.
II. Realización
• Reunión de coordinación del proyecto.
▫ Motivar a los participantes y alinearlos con los objetivos.
▫ Presentar a las personas y su función.
▫ Revisar prioridades y puntos críticos de la planificación.
▫ Presentar (y discutir) normas, métodos y herramientas.
▫ Conocer el Plan de Proyecto.
▫ Establecer el modelo de futuras reuniones: periodicidad,
siguiente reunión, responsable del acta, responsable de la
dirección y del orden del día, modelo de registro y seguimiento
de decisiones, etc.
II. Realización
• Cuestionario de salud del proyecto.
▫ Plan de Proyecto
▫ Recursos
▫ Dominio
▫ Justificación
▫ Expertos
▫ Claridad
▫ Soporte
II. Realización
• Cuestionario de salud del proyecto. Plan de Proyecto.
▫ Existe un plan detallado : camino crítico, programación, hitos,
recursos, etc.
▫ Existe un plan detallado de costos.
▫ Las responsabilidad del personal clave están especificadas en
el plan del proyecto.
▫ Conocemos qué actividades poseen disponibilidad en tiempo
y qué recursos pueden ser usados para emergencias en otras
áreas.
▫ Existe un plan de contingencia en caso que el proyecto se
desvíe de su programación o presupuesto.
II. Realización
• Cuestionario de salud del proyecto. Recursos.
▫ Se dispone de los suficientes Recursos Humanos para
completar el proyecto.
▫ La tecnología apropiada estará disponible durante toda el
ciclo del proyecto.
▫ La tecnología a ser utilizada durante el proyecto está probada y
posee un completo soporte.
▫ Las tareas específicas del proyecto están dirigidas
apropiadamente.
▫ Los integrantes del grupo del proyecto comprenden los roles
que les han sido asignados.
II. Realización
• Cuestionario de salud del proyecto. Dominio.
▫ Todos los involucrados han tenido la oportunidad de aportar
y opinar acerca del proyecto.
▫ Todos los involucrados aceptan y se sienten responsables de sus
tareas.
▫ Las formas de medir el éxito han sido acordadas.
▫ Se comprenden cabalmente los límites del proyecto.
▫ Conocen los requerimientos propios que han sido incluidos en
el proyecto.
II. Realización
• Cuestionario de salud del proyecto. Justificación.
▫ El proyecto se ha presupuestado en su totalidad y cuenta con el
acuerdo del sponsor.
▫ Se han calculado los beneficios comerciales y financieros
del proyecto.
▫ Se han definido los beneficios colaterales, como aumento el
Know-how de la compañía y de la experiencia de sus recursos,
adquisición de nuevo software o herramientas, etc.
II. Realización
• Cuestionario de salud del proyecto. Expertos.
▫ Todos los miembros del equipo del proyecto poseen el grado
apropiado de pericia (conocimiento, habilidad, actitud,
experiencia).
▫ Todos los miembros del equipo comprenden el proyecto y los
entregables. Los miembros del equipo comprenden cómo
serán evaluados sus resultados.
▫ Las descripciones de pericias de los miembros han sido
descritas, comunicadas y comprendidas.
▫ El entrenamiento necesario ha sido incluido en la
programación del proyecto.
II. Realización
• Cuestionario de salud del proyecto. Claridad.
▫ Los objetivos del proyecto son claros para todos los
involucrados.
▫ Las metas del proyecto están alineadas con la estrategia y los
estándares de la organización.
▫ Las probabilidades de éxito del proyecto son grandes.
▫ Se dispone de documentación de los requerimientos y las
formas de medir su cumplimiento.
▫ Los involucrados han asistido a una presentación en la que se
clarificaron direccionamiento y objetivos del proyecto.
II. Realización
• Cuestionario de salud del proyecto. Soporte.
▫ La Dirección comparte la responsabilidad con el equipo del
proyecto para asegurar su éxito.
▫ La Dirección comprende y asume la importancia del
proyecto.
▫ Se han definido y acordado las posibles cooperaciones con
otros proyectos y organizaciones.
▫ Se han acordado los términos, niveles de autoridad y
responsabilidades.
▫ El sponsor del proyecto está totalmente comprometido con el
éxito del proyecto.
II. Realización
• Desarrollo.
Aplicar los modelos de ciclo de vida del software
Materia de Ingeniería del Software

Procesos en cada área de conocimiento
interrelacionados entre sí
Inicio del Proyecto
La Planificación no es nada sin los procesos de inicio: Se comienza el proyecto con las aproximaciones
de Alcance, Tiempo y Coste. Además de identificar a todos los implicados en el proyecto.
Gestión del Proyecto
II. Realización
• Puesta en marcha.
▫ La entrega o puesta en marcha del proyecto puede ser de
forma:
 Parcial o por fases.
 Total.
 En frío o vacío (sin carga de entrada).
 En carga o en caliente.
▫ Es necesario considerar en la puesta en marcha:
 Comprobar que se han cumplido las especificaciones.
 No influir en la producción en curso.
 Involucrar al personal de explotación y
mantenimiento.
 Importancia de manuales de explotación, usuario y
mantenimiento.
 Posibilidad de grupos o personas de apoyo que den a
conocer e introduzcan el sistema en la organización.
III. Explotación y cierre
• Uso del sistema.
▫ Formación/entrenamiento del personal.
 Entornos de prueba.
 Demos.
 Cursillos de formación.
 En la propia instalación de forma vigilada.
▫ Transferencia de tecnología sobre equipos y software
de base.
▫ Equipo de soporte durante el tiempo de garantía.
▫ Control de objetivos:
 Requisitos mínimos (datos, número de usuarios).
 Fallos.
 Tiempos de operación.
Recursos y calendario
Gestión de Proyectos
Tema 2.0 . Planificación del tiempo
Objetivo
• Partimos de que tenemos un plan preliminar del proyecto
• Identificar:
▫ los entregables, fases y tareas
▫ los recursos a asignar a cada tarea, y
▫ que tareas se asignan a cada persona bajo responsabilidad.
• Crear un calendario de realización, con dos objetivos:
▫ que quede claro lo que se espera y para cuando,
▫ comprobar que es posible, un día 24 h (*con turnos)
Estimación de los recursos
• Con el documento de requisitos y objetivos, así
como con un posible calendario “forzado” el
director podrá estimar, en una primera fase, el
esfuerzo a desarrollar en cada etapa.
• Posteriormente podrá obtener una especificación
de los recursos que serán necesarios para acometer
el proyecto:
▫ El recurso en sí (su descripción)
▫ Disponibilidad en sí
▫ Las distintas fechas en las que se le requiere
▫ La duración a partir de cada fecha de comienzo
Recursos del proyecto
Recursos humanos: Propios y Ajenos
Recursos materiales: Máquinas y herramientas software y Dinero
• Las estimaciones de esfuerzo siempre se suelen hacer en
personas-mes porque las personas que trabajan en un
proyecto son el recurso principal.
• Pero existen también otros recursos a tener en cuenta para
planificar un proyecto software, además de los recursos
humanos. Estos son los recursos HW y los recursos SW.
• Se consideran recursos HW a todo elemento HW a utilizar en
algún momento del desarrollo: la máquina de desarrollo, la
máquina de explotación (si es que no es la misma donde se va
a hacer el desarrollo), impresoras, terminales, scanner....
• Igualmente se consideran recursos SW: editores, gestores de
B.D., compiladores, herramientas CASE ....
Disponibilidad de recursos
• Los recursos son escasos
• Los recursos no siempre están disponibles
• A veces no se puede conseguir un recurso a
cualquier precio
• El tiempo debe de convertirse en un recurso
• El usuario también es un recurso, normalmente
fuera de nuestra autoridad
• Considerar los tiempos perdidos imprevistos
(enfermedad…)
• Considerar planes de contingencia ante la ausencia
repentina de recursos
Disponibilidad de recursos
• Los recursos son escasos
• Los recursos no siempre están disponibles
• A veces no se puede conseguir un recurso a cualquier
precio
Calendario - Ordenar las etapas
• ¿Qué hay que hacer?
▫ Establecer fases
• ¿Quién tiene que hacerlo?
▫ Establecer recursos y asignarlos a las fases
• ¿Cuándo debe de hacerse?
▫ Establecer prerequisitos o vínculos y estudiar el
calendario del proyecto
• ¿Cuánto va a costar hacerlo?
▫ Establecer niveles y cuentas para poder responder de
los costes (budget-real)
• ¿Cómo y a quién se ha de informar?
Pasos en la creación de un
calendario aceptable
1. Creación del calendario y camino crítico.
▫ Ordenación de las tareas,
▫ Creación del calendario,
2. Revisión y ajuste del calendario:
▫ En función del uso de recursos ,
▫ Según las necesidades del usuario,
3. Aceptación generalizada del plan.
Ordenación de las tareas
• Identificar y documentar dependencias.

▫ Restricciones,
▫ Supuestos,
▫ Dependencias obligatorias,
▫ Dependencias discrecionales,
▫ Dependencias externas.
Identificar y documentar
dependencias
• De forma genérica, situandonos en cada tarea,
nos planteamos las siguientes cuestiones:
▫ ¿Qué debe haberse hecho antes de esto?
▫ ¿Qué puede hacerse a la vez?
▫ ¿Que debe seguir a lo que hacemos ahora?
• Añadiremos a cada ficha de tarea la lista de
tareas precedentes.
Restricciones
• Son los factores que limitan las opciones del
equipo de desarrollo.
• Son impuestas por el cliente o la dirección de
la empresa desarrolladora.
▫ Ejemplo:
 Lenguaje de desarrollo,
 Equipo en que deberá funcionar,
 Personal del que se dispondrá.
Supuestos
• Factores que se consideran verdaderos
durante la planificación.
• Tienen un grado de riesgo, es decir, de no
cumplirse durante el desarrollo, por tanto,
están directamente relacionados con la
gestión de riesgos del proyecto.
• Por ejemplo:
▫ Se dispondrá de un ordenador en casa del cliente.
▫ No habrá cortes del servidor o fallos en los equipos.
▫ No habrá movimiento del personal.
Dependencias obligatorias
• Son las inherentes a la naturaleza del trabajo

(aspectos técnicos).
• Se suelen deber a la necesidad de disponer de
un entregable, que es punto de partida en la
tarea.
• Ejemplo:
▫ “Prueba del programa XYZ”, debe ser precedida de
“Codificación del programa XYZ”.
▫ La construcción de la base de datos se hará después
del análisis y del diseño de datos.
Dependencias discrecionales
• Las que define el equipo del proyecto.

• Hay que ser cautelosos, ya que condicionan la
programación y resultado del proyecto.
• Se basan en el conocimiento de las “Mejores
Prácticas” y la experiencia previa.
• Por ejemplo:
▫ Se modifica la secuencia de actividades relacionadas
con las pruebas del sistema porque ya se hizo así,
con éxito, en otros proyectos.
▫ Se prefiere que en la tarea de análisis de datos
participe el administrador de la base de datos actual.
Dependencias externas
• Vienen impuestas desde el exterior.
• Se refieren a la interdependencia:
▫ Con otros proyectos.
▫ Con empresas externas o contratos sobre los que no
podemos ejercer ninguna presión.
• Una actividad no puede comenzar hasta que no
se dispone de un producto ajeno.
• Por ejemplo:
▫ Pruebas de implantación sobre la máquina de
explotación o con un lector de código de barras que no
están disponibles.
▫ Diseño de una interfaz con otra aplicación que se está
modificando.
Métodos de descomposición:
• Por PROCESOS
▫ Diferentes fases conceptuales
 ¿Que?, ¿Como?, Realización, Pruebas ...
• Por PRODUCTOS
▫ Detectamos diferentes productos que
conformaran el sistema que nos piden.
▫ Ej.: Facturación, Control de Stocks, ...
Manera típica de planificar
Proyecto
Juan Manolo Vanessa Sergio Clara

Parte A Parte B y C Parte D Parte E, F y G Parte H
Manera típica de planificar
• Hitos:
▫ Entrega el 27 de junio
• Puntos de control:
▫ Comenzar pruebas el 30 de mayo
▫ Comenzar a escribir documentación el 7 de marzo
Métodos y técnicas de planificación temporal

Revisión y ajuste del calendario.
• La primera planificación suele hacerse con
criterios técnicos, por lo que suele ser
necesario revisarla con dos enfoques:
▫ En función del uso de recursos,
 Equilibrar la disponibilidad de personal,
▫ Según las necesidades del usuario.
 Habitualmente siempre desea que se termine lo
más pronto posible.
 Restricciones de calendario, imponiendo fechas o
cierres empresariales o tiempo limitado de uso de
recursos.
20
La documentación técnica como herramienta de
seguimiento de la planificación
21
Secuenciación de Actividades
Es el orden en que se decide que deben desarrollarse las

actividades necesarias para el proyecto.
Se hace en la fase de desarrollo cuando se realiza la
planificación.
 Existen cuatro tipos de secuencias o precedencias:
• Relación final/comienzo.
• Relación comienzo/comienzo.
• Relación final/final.
• Relación comienzo/final.
Según el método de programación escogido para el
proyecto, estas secuencias permiten demora o retraso
Secuenciación de tareas
Definiciones
• WBS (Work Breakdown Structure) se utiliza para
representar la estructura de descomposición de trabajos.
Unicamente se representan las tareas o trabajos en
estructura de árbol.
• OBS (Object Breakdown Structure): descomposición según
productos, permite descomponer el objetivo del proyecto
así como los sub-objetivos del mismo a nivel de productos.
También se representa en forma de árbol.
• RBS (Resource Breakdown Structure):descomposición de
recursos. Es el formalismo asociado a “QUIÉN HACE QUE”.
Se representa en forma de una tabla y permite asegurar
que para cada elemento terminal hay, al menos, un
responsable de terminación.
• Red Lógica: que se establece con las tareas especificadas
en el WBS, sus relaciones de dependencia puestas en
relieve y las indicaciones de recursos. 24
Representación Gráfica del
WBS
0.0. Proyecto
Contabilidad
1.0. Especificar 2.0. Analizar 3.0. Diseñar 4.0. Codificación 5.0. Pruebas
necesidades Contabilidad Aplicación
1.1. Estudiar 2.1. Estudiar 3.1. Diseño 4.1. Creación 5.1. Prueba
Sistema Actual Procesos B.D Esquema Unidades
1.2. ide. nuevas 2.2. Estudiar 3.2. Diseño 4.2. Codificación 5.2. Prueba del
carácteristica Datos Programas Programas Sistema
Representación en lista del WBS
0.Proyecto Contabilidad. 3.1.Diseño B.D.
1.Especificar necesidades. 3.2.Diseño Programas.
1.1.Estudiar Sistema Actual. 4.Codificación.
1.2.Añadir Nuevas 4.1.Construcción del
Características. esquema.
2.Analizar Contabilidad. 4.2.Codificación de los
2.1.Estudiar Procesos. Programas
2.2.Estudiar Datos. 5.Pruebas
3.Diseñar Aplicación. 5.1.Prueba de Unidades
5.2.Prueba del Sistema
WBS
• La numeración facilita la localización de las
tareas en el WBS.
• Los nodos se leen como:
 es un componente de …
 forma parte de …
• Construcción:
 Nombrar el nodo inicial,
 Poner en torno a 72 en cada nivel.
 Las tareas son las hojas del árbol.
Completamos la Ficha de cada
Tarea.
Especificación de tarea
Número: 3.1.
Nombre: Diseño B.D.
Descripción: Se diseñara la base ...
Esfuerzo Estimado: 2 semanas/hombre
Personas: 1 Diseñador …
Recursos: Sala de reuniones …
Duración: 2 semanas
Entregables: Estructura de implementación de la B.D.
Predecesoras:2.1 (D. obligatoria); 2.2 (D. Externa).
OBS
El WBS se refiere acciones a realizar (Trabajo).
Si lo que se pretende es representar los resultados o productos a
obtener (Objetivos) hay que acudir a otra representación: el OBS
Relación WBS/OBS
Los rectángulos del WBS son acciones. Las elipses del OBS son
productos o estados. Una acción transforma un estado en otro
estado
Ejemplo de un RBS/WBS
INTERVINIENTES
A B C D Cía J Cía k
Def. sistema X
Real. sst. 1 X
Real. sst. 2 X X
Real. sst. 3 X
Int. sst. n-m X X X X
Int sistema X X X X X X
31
RBS con cargas de trabajo
32
RBS con roles
33
Puntos sobre los que actuar para
revisar la planificación
• Sobre la secuencia de las tareas.
▫ Aumentando paralelismo.
• Sobre la duración de las tareas
1. Utilizar mejores técnicas y herramientas.
2. Modificar la productividad de las personas.
3. Modificar la cantidad de personas asignadas a
una tarea.
4. Asignar horas extras
34
Sobre la secuencia de las tareas
• Estudiaremos las tareas del camino critico y

revisaremos la razón por la que se había
creado la secuencia de tareas.
 ¿Es posible sacar unas tareas de la secuencia?
• Aumentando paralelismo entre tareas.
 Es posible que una tarea pueda comenzar cuando
la precedente se ha realizado al 60%.
 Esto es peligroso, puede llevar a rehacer trabajo
que no estaba bien definido.
35
Sobre la duración de las tareas
• Reducir la duración de las tareas del camino
critico y, por tanto, la del proyecto.
• Tener en cuenta que al reducir la duración de

una tarea, puede cambiar el camino critico.
• Cuando el reducir la duración de una tarea

lleva a un coste mayor, deberemos ajustar la
reducción al máximo con coste mínimo
(equilibrio tiempo y coste).
36
1. Utilizar mejores técnicas y
herramientas
• ¿la duración de la tarea se basa en una técnica
o herramienta?
• ¿Existe software que puede dar soporte a una
tarea?
▫ Por precio no fue oportuno considerarlo,
▫ Tener en cuenta la curva de aprendizaje.
• Eliminar las tareas de formación.
▫ ¿Se puede ir a herramientas conocidas?
37
2. Modificar la productividad
• Modificar la productividad y calidad de los

recursos asignados a una tarea.
• En un estudio sobre, la diferencia de

productividad entre programadores se
detectó una gran oscilación.
• Tom DeMarco, como M. Page-Jones, dejan

claro que relaciones de uno a tres son muy
usuales dentro de una misma organización.
38
3. Modificar la cantidad de personas
• Podemos asignar más personas al proyecto,

de modo que en las tareas críticas se puedan
incluir más personas.
• Hay que tener en cuenta:

 Los diferentes tipos de tareas que hay, según la
cantidad de personas que asignemos.
 El añadir más personal a un proyecto en marcha
puede retrasar la finalización del proyecto.
39
3. Asignar horas extra
• Esto en principio puede suponer un coste
adicional o no.
• Se recomienda hacer uso de las horas extra

sólo en casos muy puntuales (crisis de
proyectos).
• Parece poco razonable pensar en este recurso

en la fase de planificación.
40
Revisiones y ajustes a la planificación
Alteraciones
Objetivos Suposiciones Referencia
Desarrollo
ESTIMACIÓN PROGRAMACIÓN Estado Trabajo
EVALUACIÓN
INICIAL PLANIFICACIÓN Informe de
Evaluación
del Proyecto
Estado
Progreso
SEGUIMIENTO
PERIODICO
Proyecciones
SEGUIMIENTO
CONSOLIDADO
41
Aceptación generalizada del
plan.
• Una planificación buena ha • En la probabilidad de éxito
de ser: también influyen la fe y la
▫ aceptada por todos los confianza.
participantes, y
▫ que todo el mundo crea en
ella.
• Para esto ha de ser realista.
42
Métodos de planificación
temporal
Tema 2 . Planificación del tiempo
Objetivos
• Conocer las técnicas y conceptos básicas de
planificación de proyectos:
▫ Diagramas de estructuras (WBS, OBS, RBS)
▫ Gantt
▫ PERT
• Ser capaces de realizar una planificación de
proyecto dada una lista de actividades,
dependencias y tiempos
• Analizar las implicaciones de la planificación:
▫ Holguras, camino crítico, etc.
Planificar
• Proceso de planificación
▫ Estudio: viabilidad, definir requisitos, estimar costes, plan de
desarrollo sencillo
▫ Análisis y diseño: estrategias y métodos de desarrollo (objetivos
de calidad, rendimiento, prototipos), especificaciones externas
(usuario, arquitectura), secuencia de desarrollo (modelo),
estrategias de pruebas y controles (traza de requisitos,
seguimiento de cambios y problemas), calendarios-presupuesto-
plantilla, documentación de plan (WBS, Gantt, PERT,
estándares, etc.)
▫ Implementación: especificaciones de diseño detalladas, codificar
y prueba de unidad, pruebas de integración y funcional, gestión
de configuración, seguir progreso
▫ Mantenimiento: corregir problemas, mejoras funcionales,
mantener diseño, mantener documentación, mantener código
Ejemplo de plan
• Descomposición en cada asignación

• Coordinación de las pruebas finales de funcionalidad y rendimientos
• Inclusión de puntos de control como inspecciones
Calendario
• Hito:
▫ Entrega el 26-6-2016
• Puntos de control:
▫ Planificación completa
▫ Comenzar fase de implementación
▫ Completar primera build
▫ Completar segunda build
▫ Completar tercera build
▫ Completar cuarta build
Tareas de planificación
• Responder a:
▫ ¿Qué?: definición del producto
▫ ¿Cuándo?: hitos y tiempos (calendario y plazos)
▫ ¿Quién?: asignación de tareas y responsabilidades
▫ ¿Cómo?: establecer presupuesto y asignar
recursos
• Pasar de plano de proceso a la realidad de dinero
y tiempo
Actividades para la planificación
• Definición y análisis de objetivos, alcance y restricciones:
▫ RFP (req. for proposals), visión, pliego de concurso,
RFI (req.for information). Estudio de viabilidad
▫ Especificaciones detalladas y criterios de éxito
• Descomposición de actividades:
▫ Adaptación de ciclos de vida y procesos.
▫ Normativa técnica (procesos, métodos, personal, etc.)
• Relación entre actividades:
▫ Tipos: F/F, C/F, F/C, C/C (con demora o no)
▫ Restricciones de tareas: fechas, etc.
• Estimación de costes y plazos
• Reajuste de plazos según restricciones de proyecto
• Asignación de recursos y definición de equipo
• Revisión de calendario y gestión de compromisos
▫ Entregas, métricas, seguimiento
Actividades para la planificación
Objetivo: calendario
Comprensible
Suficientemente detallado
Actividades críticas identificadas
Flexible
Tiempos fiables
Ajustable a recursos disponibles
Compatible con planes de proyectos relacionados
Diagramas de organización
• Descomposición de actividades (WBS):
▫ Actividades agrupadas por paquetes de trabajo
▫ Tareas: unidades pequeñas
 Entradas, salidas y recursos
 Código numérico
• Descomposición según productos (OBS):
▫ Niveles: sistema completo, subsistemas, elementos de
configuración, componentes de software
• Descomposición de recursos (RBS)
▫ Organización humana, estructura de recursos materia
▫ Distintas alternativas de organización (tema
específico)
Aplicación de diagramas
• CONSTRUIR UNA LISTA DE LAS TAREAS A REALIZAR (WBS)
o Tecnología necesaria para el proyecto
o Cumplimiento de los estándares
o Iteraciones (niveles)
• IDENTIFICAR LOS ENTREGABLES (OBS)
o Internos/externos
o Iniciar la gestión de configuración
o Arquitectura del sistema
o Documentación
• IDENTIFICAR Y ORGANIZAR LOS RECURSOS (RBS)
o Tipos: humanos, equipamiento, material, etc.
o Perfiles, cualificación, características
o Posición en la compañía (recurso humano)
o Equipo de proyecto (recurso humano)
Relaciones
PLAN NORMAS ESTANDARES ESTADO
NORMAS PREFIJADAS
ESTRATEGICO NEGOCIO CLIENTE DEL ARTE
DEPENDEN DEL PROYECTO
LARGO PLAZO: WBS PROCESO
WBS (CÓMO HACEMOS

NEGOCIO)
MEDIO PLAZO: OBS

(LO QUE SE PRODUCE/TIPO NEGOCIO)
OBS
LARGO PLAZO: RBS
RBS (CUALES SON LOS

RECURSOS)
KNOWHOW
COMPAÑIA
NECESIDAD FUNCION DISEÑO
ESTRUCTURA
COMPAÑIA
NORMAS PREESTABLECIDAS
NO DEPENDEN DEL PROYECTO

WBS
• Work Breakdown Structure: descomposición de trabajo
- Árbol de actividades: jerarquía
- Sirve de lista de comprobación en planificación
- Herramienta: organización, contable y metodológica (¿Metrica3?)
- No incluye tiempo pero cada ítem con hitos, fechas y plan de tareas
- Cada función: 1 responsable
- Estándares: calidad independiente, etc.
L.Fernández
proyecto X-Files
L.Fernández J.M.Gómez J.Cervera

Subsistema 1 Control SUsbistema 2 Almacenamiento Aseguramiento de calidad
M.Rueda P.Fuente M.Bueno S.Sánchez

Proceso 1.1 datos Proceso 1.2 datos Análisis y diseño Programación y pruebas
WBS
• Work Breakdown Structure (ejemplo DoD)
Sistema de proyectiles dirigidos
1er nivel normal: empresa 20000
2º nivel normal: Rampa de lanzamiento Cohete Sistema de guía y control Entrenamiento

21000 22000 23000 28000
producto/sistema
Motor propulsor Nave de reentrada Proyectil balístico Ingeniería de sistemas

3er nivel 22100 22200 22300 22900
normal:
subsistema
Ojiva Primera fase Segunda fase Interfase Sección del equipo
22310 22320 22330 22340 22350
Montaje de secciones Instrumentación Montaje sist. encendido Documentación

22321 22322 22323 22329
4º nivel normal:
tarea/actividad
OBS
• Object Breakdown Structure: descomposición según productos
- Responsabilidades
o Un producto/sistema: responsabilidad de un cliente (interno o externo)
- Trazabilidad
o Cada nivel: todas las funciones del WBS. Cada objeto esta bajo la
responsabilidad de un único recurso
Proyecto 1er nivel normal: subsistemas
ASI DSI
2ºnivel normal: Análisis de sistema de información Diseño de sistema de información
componentes 1 2
ASI 1.1 ASi 1.2 ASi 1.3

Determinación del alcance del sistema Obtención de requisitos Especificación de casos de uso
Catálogo de requisitos Glosario Catálogo de requisitos Modelo de casos de uso Catálogo de requisitos Modelo de casos de uso
1.1.1 1.1.2 1.2.1 1.2.2 1.3.1 1.3.2
Contexto del sistema Modelo conceptual de datos 3er nivel normal: Especificación de casos
1.1.3 1.1.4 1.3.3
documentos/ficheros
OBS
• Medida del avance del desarrollo
- Evolución de costes y compleción de entregas
• Análisis de costes relacionados con una entrega
- Elaboración de precios internos y precios para clientes
• Análisis de ratios coste/tamaño de componentes
- Por subsistema y por campo de aplicación
Sistema
Subsistema 1 Subsistema 2 ... Subsistema n
Hw Sw
Doc's Programas
Documentación
P1
Elementos Hw.
P2
P3
Elemento Hw. 1
...
Elemento Hw. 2
...
Relación WBS/OBS
Los rectángulos del WBS son acciones. Las elipses del OBS son
productos o estados. Una acción transforma un estado en otro
estado
17
RBS
• Resource Breakdown Structure:
• descomposición de recursos
L.Fernández
proyecto X-Files
L.Fernández J.M.Gómez J.Cervera

Gestión de proyecto Desarrollo Ingeniería de sistemas
L.Fernández P.Fuente M.Bueno S:Sánchez

Gestión de proyecto Gestión de configuración Análisis Programación
Relación RBS/WBS
INTERVINIENTES
A B C D Cía J Cía k
Def. sistema X
S1
X
S2 X X
S3 X
Subintegración
X X X X
Integración X X X X X X
19
Indicaciones en el RBS/WBS
• Cargas de trabajo de cada uno de los componentes
• Roles:
▫ Producción: cuando una carga de trabajo y una intensidad
determina la obtención de un producto final. En terminología de
gestión de proyectos son los recursos.
▫ Responsabilidad: Un participante es responsable de un WBS
cuando determina las condiciones en que pueda ser obtenido el
producto final del elemento de trabajo o tarea. El responsable
determina cuando un trabajo está terminado.
▫ Aprobación: Un participante aprueba un trabajo cuando fija el
resultado del mismo de forma que toda modificación posterior
deberá ser autorizada por él.
▫ Certificación: Validación, al menos parcial, de un elemento de
WBS.
▫ Soporte: Un recurso actúa como soporte de un elemento WBS
cuando debe estar disponible durante la duración del trabajo.
RBS/OBS con cargas de trabajo
21
RBS/WBS con roles
22
Técnicas: diagramas de hitos
• El esquema más simple
Actividad Fecha finalización
Establecer alcance de proyecto 12-1-2004
Recogida de información de 21-2-2004

usuarios
Contrastar requisitos con usuarios 15-3-2004
• Ventajas:
▫ Facilidad de uso y mínimo coste de
preparación
• Desventajas:
▫ No hay interrelaciones ni datos sobre
inicios
Técnica: Diagrama de Gantt
• Es el diagrama más antiguo y quizás el que
más se utiliza para trabajar
• Refleja de forma esquemática las tareas, su
duración y las fechas en que se deberán
realizar. Trabajando sobre este diagrama el
director de proyecto realiza planificaciones y
seguimiento de un proyecto.
• Se representa en un cuadro de doble entrada:
 En el eje horizontal se representa el tiempo,
 En el eje vertical las tareas,
 Cada tarea se representa como un rectángulo
situado a la altura de la tarea y que va desde el
comienzo a la finalización de la tarea.
Técnicas: diagramas de Gantt
• No permiten representar claramente dependencias
• Mejor técnica para ver solapamientos:
▫ Cuando las dependencias sean intuitivas
Metodología Gantt
• I. Representación gráfica de la primera actividad con su
duración estimada.
• II. Representación de símbolos adicionales.
▫ Entradas / Salidas.
▫ Hitos.
• III. Identificación de actividades siguientes y tipos de
relaciones.
▫ Cálculo de fechas más tardías de terminación impuestas por:
 Inputs.
 Duraciones.
 Demoras.
▫ Representación de dichas actividades por su duración, una vez
fijada la fecha más tardía de terminación.
Metodología Gantt (II)
• IV.Representación de forma secuencial de las siguientes actividades,
obteniendo al final la fecha de terminación del proyecto.
▫ Tener en cuenta condicionantes de comienzo y finalización de actividades
(dependencia de finalización de otras).
• V. Identificación y representación del camino crítico.
▫ Identificación y representación de las holguras (libres) para las actividades que no
forman parte del camino crítico.
• VI.Calculada la duración del proyecto (Media, Varianza) estimación del
riesgo de incumplimiento.
• VII.Trazado posterior de las curvas de carga de recursos y optimización de
las mismas.
Representación gráfica del uso
de recursos en un proyecto
• Es muy útil el poder ver tan solo las tareas que
hay asignadas a cada recurso, para:
 comunicar a los participantes el uso de un recurso
compartido,
 verificar que se utilizan de forma equilibrada,
 verificar que ningún recurso se pretende utilizar más
de lo posible.
• Se usa el Gantt y el de Cargas
Ejemplo (I)
Diagrama de Gantt
A 2A
B 1A
C 2A
D 1P
E 1A
F 4P
G 1A
H 2P
I 2P
J 2P
K 1P
1 2 3 4 5 6 7 8 9 10
Ejemplo (II)
• Se desea ver la asignación de programadores
del ejercicio anterior.
D 1P
F 4P
H 2P
I 2P
J 2P
K 1P
1 2 3 4 5 6 7 8 9 10
30
Ejemplo (III) Diagrama de Cargas
• Se desea ver la asignación de programadores
del ejercicio anterior.
Nº de programadores
6
5
4
3
2
1
1 2 3 4 5 6 7 8 9 1 0
31
Ejemplo (IV) Diagrama de Cargas
• Carga del programador Juan que realiza las
tareas D e I a tiempo completo.
Nº de horas diarias
8
7
6
5
4
3
2
1
1 2 3 4 5 6 7 8 9 1 0
32
Técnicas: redes de precedencia
• PERT (1957: Polaris) y CPM (1959:DuPont)
• Utilidad:
▫ Todas las actividades bien definidas
 Proceso repetible, dominado: fabricación, construcción,...
 Difícil para tecnologías y equipos humanos grandes (duraciones
no realistas, tareas y enlaces imprevistos...)
 Corregir con técnicas de planificación avanzada
▫ Posibilidad de comienzo y realización separada
▫ Relación entre actividades
▫ Ordenadas y posibilidad de secuencia
▫ Una vez comenzada tarea, continúa sin interrupción
• Red:
▫ Gráfico de relaciones secuenciales
▫ Camino crítico: secuencia más larga (PERT y CPM)
▫ Diferencia PERT y CPM: determinar tiempos de actividad
Conceptos
• Tiempos en distribución Beta:
En CPM el manejo de tiempos es
determinístico, por tanto se estima
un único tiempo que no esta sujeto
a variaciones, supone que no hay
cambios en la duración establecida.
En PERT, en cambio, se establecen
tres tiempos para determinar tanto
el rango de tiempos dentro del cual
se hallará el valor real como una
estimación de un tiempo más
probable.
El método PERT normalente
Topt (a) Tprob (m) TPERT (Te) Tpes (b) adopta como distribución de
probabilidad la distribución BETA.
Tpes (b)
Para estimar hay que procurar que
los tiempos optimista, pesimista y
Moda = (a+b)/2±1/3(b-a); Media = (a + 4m + b)/6 probable procedan de las personas
2t = (b – a)2 /36 t = (b – a) / 6 que van a realizar las actividades
(más garantías para estimar).
Técnicas: PERT
• Recomendable cuando:
▫ En proyectos industriales, construcción, etc.
▫ Menor en tecnologías:
 Duraciones menos realistas
 Grandes grupos humanos
 Tareas y enlaces no previstos
• Usar:
▫ Mínimo de 20 eventos
▫ Con gran número, necesaria herramienta
▫ Con proyectos críticos, complejos, etc.
 Dependencias complejas o poco claras
Técnicas: PERT
• Representación en red
• Dos tipos de representación:
▫ Nodos = eventos de inicio y fin de actividad
(mejor para uso manual: uso en clase)
Actividad A
1 Duración 2
▫ Nodos = actividades (más usado en

herramientas: Project)
Valor:
Actividad A Actividad B
demora
Técnicas: PERT
Para iniciar la actividad B es
necesario haber finalizado la
RELACIONES DE A B actividad A. El suceso 2 es
1 2 3
PRECEDENCIA suceso final de A y suceso
LINEALES inicio de B.
1 Para iniciar la actividad D es

A
necesario haber finalizado las
RELACIONES DE B D actividades A, B y C.
4 5
PRECEDENCIA 2
CONVERGENTES C
3
Para poder iniciar cualquiera

3 de las actividades B, C, o D, es
B
RELACIONES DE A C
necesario que haya finalizado
PRECEDENCIA 1 2 4 la actividad A.
D
DIVERGENTES
5
Técnicas: PERT
Uso de actividades ficticias:
•Cuando existe más de una actividad entre los mismos sucesos:
•Cuando dos o más actividades tengan algunas precedentes comunes

pero no todas:
Técnicas: PERT
• Construcción:
▫ Tabla de predecesores (o de sucesores)
Actividad Precedente Dur

A - 1
3 E
B A 4 B
6
C A 3 F
A C H
D A 6 1 2 4
E B 7 D 7
G
F C 9
5
G D 2
H E,F 4
Técnicas: PERT
• Asignaciones de tiempos:
▫ Realistas, basadas en experiencias y datos
históricos
▫ Tres tiempos:
 To = tiempo optimista
 Tp = tiempo pesimista
 Tm = tiempo medio
• Duraciones:
▫ Compromisos y acuerdos negociado con
implicados
▫ Difícil duración fija, más habitual hablar de
rangos
▫ Uso de un tiempo determinado para
cálculos simplificados: tiempo PERT
Técnicas: PERT
Definiciones
• Duración: tiempo que calculamos que se tardará en completar la
tarea.
• Inicio temprano: fecha más temprana en que puede comenzar la
tarea, en función de las tareas precedentes.
• Final temprano: fecha más temprana en que puede finalizar la
tarea (inicio más temprano + duración).
• Inicio tardío: fecha más retrasada en la que se puede comenzar
sin que afectar la fecha de terminación del proyecto, en función de
las tareas siguientes.
• Final tardío: fecha más retrasada en la que puede terminar la
tarea sin afectar ala fecha final (inicio más tardío + duración).
• Máximo tiempo disponible: tiempo máximo que puede durar
una tarea en caso de comenzar en su Inicio temprano y concluir en
su Final tardío (final más tardío – inicio más temprano).
• Holgura: tiempo que disponemos para jugar con el inicio de la
tarea, sin afectar al proyecto (máximo tiempo disponible –
duración).
Técnicas: PERT
• Cálculos:
▫ TE = tiempo early: más temprano de ocurrir
▫ TL = tiempo late: más tardío de ocurrir
• Aplicación a red PERT:
▫ Primero sobre TE de eventos de inicio y fin de
actividad:
 Tareas iniciales = 0;
▫ Después sobre TL de eventos de inicio y fin de
actividad:
• Por último:
▫ Tabla de tiempos
▫ Cálculo de holguras
▫ Determinación de camino crítico
Técnicas: PERT
Aplicación sobre TE de eventos
Actividad A B C D E F G H
Duración 8 5 6 5 6 7 9 3
Si confluyen varios caminos: Máximo

Dirección 13
6
3 19
5 E
21
B 3 22
7 6
8 H
0 8 6 14 24
F
1 2 4 7
A C
9
5
D G
13
5
Técnicas: PERT
Aplicación sobre TL de eventos
Actividad A B C D E F G H
Duración 8 5 6 5 6 7 9 3
Si confluyen varios caminos: Mínimo

Dirección
13 15
6 21
3 19
5 E
8 21 21 24
B 3 22
10 6
7
8 H
0 0 8 8 6 14 14 24 24
F
1 2 4 7
A C
9
5
D G
13 15
5
Técnicas: PERT
• Tabla de tiempos y duraciones Evento i Evento j
ACTIVIDAD Tij TEi TLi TEj TLj HL HT
TE TL TE TL
G 5 4 4 10 11 1 2
I 2 0 0 7 7 5 5 HT
C 4 0 0 4 9 0 5
B 6 4 9 15 15 5 5 HL
E 9 7 7 18 18 2 2
HI
F 3 7 7 10 11 0 1
P 7 10 11 18 18 1 1
K 6 10 11 22 22 6 6
• Cálculo de holguras:
• Holgura total, libre, independiente
• Determinación de camino crítico: holgura total = 0
Técnicas: PERT
• Holguras:
▫ De evento (slack): se aplica a TE y TL de eventos
▫ De actividad (Margen: float):
 Total: máximo retraso sin afectar a fecha de final del
proyecto
 HTij = TLj - TEi - Tij
 Libre: máximo retraso sin afectar a las actividades
siguientes y sin retrasar proyecto
 HLij = TEj - TEi - Tij,
 Independiente: máximo retraso sin retrasar proyecto
si actividades anteriores están en TL
 HIij = TEj - TLi - Tij,
Técnicas: PERT
Se deben tener en cada actividad tres tiempos los cuales
son:
•Tiempo óptimo u optimista
•Tiempo mas probable
•Tiempo pésimo o pesimista
Tomado entonces la distribución BETA se calculan el

tiempo medio y la varianza para cada actividad
Técnicas: PERT
•Tiempo medio = (tpésimo + 4tprobable + tóptimo)/6
•Varianza = [(tpésimo - tóptimo)/6]2
•Varianza del proyecto = Suma de las varianzas de las
actividades del camino crítico
•Tiempo medio del proyecto = Suma de los tiempos
medios de las actividades del camino crítico
•Desviación típica o estándar = √Varianza
Técnicas: PERT
• Con la distribución normal se puede calcular la
probabilidad de cumplir en un tiempo especificado
para la terminación del proyecto. Pasos:
1. Z = (Tespecificado – Tmedio)/desviación típica

2. Con ese valor consultar la tabla de distribución
normal
Técnicas: PERT
Técnicas: PERT
Actividad
Activida Actividad
d Preceden
Siguiente
te
A - C,D
B - E,F
C A E,F
D A F
E B,C H
F B,C,D G,J
G F I
H E -
I G,J -
J F I
Técnicas: PERT
3 5 9
E(3) H(2)
B(3) I(2)
8
1 F1(0)
C(7)
A(2) G(8) F2(0)

7
2 4 6
D(8) F(9) J(10)
Camino crítico = A-D-F-J-I

Técnicas: PERT
• Varianza del proyecto = 0,11 + 4 + 4 + 2,77 + 0 = 10,88
• Tiempo medio del proyecto = 2 + 8 + 9 + 10 +2 = 31
• Desviación típica o estándar = √10,88 = 3,3
• Probabilidad de terminar en 35 semanas:
1. Z = (35 – 31)/3,3 = 1,21
2. Consultando la tabla con 1,21 obtenemos 0,8869, luego la probabilidad de
que termine en un plazo de 35 semanas es de un 88,69%
• Probabilidad de terminar en 37 semanas:

1. Z = (37 – 31)/3,3 = 1,81
2. Consultando la tabla con 1,81 obtenemos 0,9649, luego la probabilidad de
que termine en un plazo de 37 semanas es de un 96,49%
Técnicas: PERT
Disminución de tiempos en función del coste
ACTIVIDAD Días
A: Lugar de emplazamiento 1
B: Hoyo cimientos B 4
C: Cimientos hormigón B 3
D: Colocar plinto 2
E: Hoyo cimientos A 2
F: Cimiento hormigón A 1
G: Preparar torre A 1
H: Colocar torre A 1
I: Colocar torre B 1
J: Colocar el arco 1 54
Técnicas: PERT
3 Cimiento hormigón A 10 Compl. base A 11
3 1
4 1
5
1
2
0 12
1
Marcar 12 9
1 2
1
4 1
1
5 10
13
8
6 3
2
10
8
7 Tiempo normal
Técnicas: PERT
Coste
ACTIVIDAD Días
Extra
A: Lugar de emplazamiento 1
B: Hoyo cimientos B 4 2 40
C: Cimientos hormigón B 3 2 20
D: Colocar plinto 2 1 10
E: Hoyo cimientos A 2 1 20
F: Cimiento hormigón A 1
G: Preparar torre A 1
H: Colocar torre A 1 1/2 10
I: Colocar torre B 1 1/2 10
J: Colocar el arco 1 1/2 10
56
Técnicas: PERT
3 1
4 1
5
1/2
1
0 7,5
1
Marcar 12 9
1 2
1
2 1/2
1/2
5 6
8
8
6 2 10
5
1 Tiempo acortado
7 Coste: +120
tiempo: 8 días
Técnicas: PERT
3 1
4 1
5
1/2
2
0 7,5
1
Marcar 9
1 2
1
2 1
1/2
3 6
8
8
6 2
1
10
5
7 Acción mejorada
Tiempo: 8 días
Coste: +90.000
Planificación y estimación de
esfuerzo
Gestión de Proyectos Tema 3

Tema 3 Tema 3: JLCS
Planificación y estimación de
esfuerzo
ESTIMACIÓN DEL TAMAÑO (Líneas de código, Puntos de

función)
ESTIMACIÓN DEL ESFUERZO (Hombres/mes)
ESTIMACIÓN DEL COSTE (€)
Gestión de Proyectos Tema 3: JLCS

Modelos Empíricos de Estimación de Costos
Pesos Una de las partes más críticas de

Modelos
Tamaño y complejidad un proyecto informático es
averiguar lo que costara
desarrollarlo (horas-hombre,
días-hombre, meses-hombre,
Euros, …)
Siempre se quiere muy pronto

(Yourdon)

¿Qué es una métrica?
• La medida valora una característica individual.
• La medición es el acto de valorar dicha característica.
• Las medidas no sirven para comparar, necesitamos métricas
• La métrica permite relacionar y comparar mediciones:

Métricas de software
• MÉTRICAS TÉCNICAS: Mide la estructura del sistema, el cómo esta
hecho, por ejemplo: la complejidad lógica, el grado de modularidad.
• MÉTRICAS DE CALIDAD: Mide cómo se ajusta el software a los
requisitos.
• MÉTRICAS DE PRODUCTIVIDAD. Mide el rendimiento del proceso.
• MÉTRICAS ORIENTADAS A LA PERSONA. Mide la efectividad del
trabajo humano, de las herramientas y métodos.
• MÉTRICAS ORIENTADAS AL TAMAÑO. Son medidas directas del
software: líneas de código, número de errores, número de páginas de
documentación, etc.
• MÉTRICAS ORIENTADAS A LA FUNCIÓN. Son medidas indirectas del
software: se centran en la funcionalidad (listados, transacciones, ficheros).

Categorización de los proyectos según su
dimensión
• La dimensión del proyecto puede determinarse dentro de las

variables de:
Complejidad. Varios tipos: de datos, de métricas, algorítmica o
de operaciones y de la arquitectura en sí.
Riesgo. Probabilidad de impacto en el negocio.
Calidad. Según el resultado en cuanto al buen funcionamiento en
el tiempo del sistema de información creado.
Tamaño. Es posible hablar de proyectos grandes, medianos o
pequeños, en función del número o cantidad de funcionalidades
previstas, del número de líneas de programa fuente a producir,
del tiempo de desarrollo y, en general, de la cantidad de esfuerzo
a invertir en el proyecto.

Estimación
• Término “estimación”:
“Juzgar, creer”
Dificultad para predecir con exactitud
• Predicciones:
Raramente en términos monetarios
• Esfuerzo de desarrollo y mantenimiento
• Duración
• Nivel de plantilla
Valores:
• Probable
• Límite superior
• Límite inferior
La estimación es difícil
• Problema:
El software a construir suele ser algo borroso
• A lo largo del proyecto se perfila el software.
La productividad es muy variable.
• Son habituales productividades de 1 a 5 entre programadores
en la misma empresa. (DeMarco –Lister)
La estimación es un proceso gradual a lo largo del
proyecto.
• No entender la dificultad, lo hace peor.

¿Qué es lo que más nos interesa?
• Medir el tamaño del software,
• Averiguar lo que costara de desarrollar una

aplicación.(meses-persona, euros., …)
• Existen formas distintas...

Puntos de función.
Líneas de código.
...

Estimación común
T.DeMarco:
 Definición más común de estimación:
“ Una estimación es la predicción más optimista con
una probabilidad distinta de cero de ser cierta”
 Aceptarla lleva irrevocablemente al método:
“¿Cuál es el primer momento en el que no se puede
demostrar que no va a ser posible terminar”

Uso de estimaciones
• Estimaciones preliminares
Licitación de contrato y viabilidad de proyecto
Poca exactitud por falta de información
• IBM Federal System Division: 95% éxito
• SEMA: saber si NO quieren hacer oferta
“Adivestimar”
• Planificación de proyecto
Información de requisitos
• Supervisión y control de proyecto

Refinamiento y evolución
10
Definición inicial
Definición
aprobada
ERS E.Diseño
E. de diseño detallado
Producto
1 terminado
E.Diseño
E. de diseño
ERS detallado
Definición
aprobada
Definición inicial
0,1
Problemas de estimación
• Carencia de expertos y experiencia:
Ausencia de práctica seria
• Prejuicios
Predisposición a subestimar
• Cuestiones políticas que ignoran estimaciones
Reemplazadas por metas no realistas (“crear "incentivos“)
• Carencia de datos
Estimar: entender productividad actual y valorar "tamaño"
• Esperar que no cueste. Supone tiempo y
esfuerzo:
Desarrollar y explotar sistemas de recogida de datos
Desarrollar métodos de estimación y estimar a tiempo.
Supuestos habituales
• Coste principal de proyecto:
Esfuerzo de personal de desarrollo
• Medida habitual de esfuerzo:
Salarios mensuales, mes de trabajo (MM: man-month)
Salario horario, horas de trabajo (HH: hora hombre)
• Factor principal para estimación:
“Tamaño” del producto futuro
• Líneas de código (LOC: Lines Of Code)
• Puntos de Función (FP: Function Points)
• Productividad
LOC/HH, LOC/MM, FP/HH, FP/MM
Un Principio Básico a tener en cuenta
Presupuesto
Presupuesto
Área constante
Plazos Defectos: Calidad
Área constante
Plazos Defectos:Calidad

Factores clave de estimación
Tecnología
Calidad de
software y
Personal productividad Procesos
Entorno

Categorías de información
• Información en gestión de proyectos:
Tamaño:
• Páginas Estimación de tamaño
• Puntos Función
Datos de atributos:
• Habilidades
• Entorno Valoración
• Herramientas Planificación
• Métodos y estimación Medición
Datos crudos:
• Plantilla
• Calendario
• Esfuerzo Seguimiento
• Costes
• Defectos
Datos normalizados:
• Productividad
• Calidad
Estimación y control de proyecto
• El modelo del proyecto es un prerrequisito
para estimar:
Fases/actividades/tareas
Hitos (comienzo y fin de fase)
Producto relacionados con los hitos
• Supervisión cuantitativa del proyecto
Establecer objetivos cuantitativos para todos los
atributos/métricas
Rango de valores aceptable
Comprobar valores reales frente a objetivos
Responder a la desviación de objetivo
Práctica normal en la industria
Entorno de la estimación
Evaluar Estimación Medir Medición

Estimación provisional
proyecto original proyecto post-implem.
Prueba e
Planes Requisitos Diseño Código Mantenim.
implantación
Evaluación Análisis de Análisis de Análisis de Evaluación Defectos

de proyecto: defectos defectos defectos de medición postimplem.
factores
Estimación Estimación Contar LOC Análisis de Medición de
defectos mantenim.
Tamaño PF Tamaño PF Tamaño PF Análisis de

complejidad
Contabilidad de coste y esfuerzo del proyecto
Gestión de configuración (productos de entrega)

Técnicas de estimación
• Tipos generales de estimación:
Juicio de expertos
Analogía
Descomposición de actividades
Modelos estadísticos
Price to win
Parkinson
• Métodos algorítmicos
Puntos de función
COCOMO
SLIM
Estimar lo que costara
• Experiencia Individual
• Experiencia de Empresa

Métodos utilizados para la estimación de proyectos.
• Basados en la experiencia.
• Basado exclusivamente en los recursos.
• Método basado exclusivamente en el mercado.
• Basado en los componentes del producto o en
el proceso de desarrollo.
• Métodos algorítmicos

Juicio experto: Puro
• Un experto estudia las

especificaciones y haces su
estimación.
• Se basa fundamentalmente
en los conocimientos del
experto.
• Si desaparece el experto, la
empresa deja de estimar

Juicio experto: Wideband Delphi
• Un grupo de personas son informadas y

tratan de adivinar lo que costara el
desarrollo tanto en esfuerzo, como su
duración.
• Las estimaciones
en grupo suelen
ser mejores que
las individuales.
Juicio de expertos
Técnica Delphi:
1. Coordinador proporciona a cada experto:
– Especificación del proyecto e impreso anónimo para opinar
2. Expertos rellenan impreso de forma anónima
– Pueden preguntar al coordinador sobre el proyecto
– No intercambian opiniones entre ellos
3. Coordinador ofrece media de opiniones para
comparar
– Pide una nueva estimación anónima e indicar razonamiento
4. Se repite el proceso de recoger opiniones hasta
consenso
– No se realizan reuniones en grupo durante todo el proceso

Delphi banda ancha
• Presentado en Boehm, 1981
Proceso:
1. Coordinador presenta a cada experto:
• Especificación de proyecto y otras informaciones estándar
2. Coordinador convoca reunión de grupo:
• Los expertos discuten cuestiones de estimación.
3. Expertos: cuestionarios anónimos de estimación de esfuerzo
• Valor probable y límites inferior y superior: E = (li + 4p + ls) / 6
4. Coordinador prepara y circula un resumen:
• Estimación de grupo (media ponderada) y las individuales
• Varianzas individuales ( = (ls - li)/6) y de grupo (media)
5. Coordinador reúne a expertos para discutir estimación
6. Repetir puntos 2-6 hasta consenso.

Delphi banda ancha
Examinar requisitos
Discutir en el grupo
Estimar anónimamente
Calcular la media y
comparar
Discutir diferencias
Repetir hasta convergencia

No
Sí
Información para Delphi
• Especificación de proyecto homogénea
Información sobre nuevo producto/proyecto:
Estandarizada: siempre la misma información
Considerar los siguientes factores:
• Extensión y alcance del proyecto (influir en límites mayores y
menores de la estimación)
• Rigor de requisitos de rendimiento, de fiabilidad, de seguridad
• Experiencia en la máquina requerida y configuración objetivo
• Información cuantitativa disponible
• Extensión de la capacidad de reutilización
• Experiencia en los métodos y herramientas propuestos
• Disponibilidad de clientes y usuarios
Analogía
• Consiste en comparar las

especificaciones de un
proyecto, con las de otros
proyectos.

Analogía
• Identificar un proyecto similar
 Identificar las características de un proyecto anterior
• Esfuerzo y plazos de un proyecto anterior
 Estimaciones iniciales para el proyecto nuevo
 Ajuste de diferencias y reutilización
• Análisis
 Tamaño: ¿mayor o menor?
 Complejidad: ¿Más complejo de lo usual?
 Usuarios: Si hay más usuarios habrá más complicaciones.
 Otros factores:
 Sistema Operativo, entornos (la primera vez más).
 Hardware, ¿Es la primera vez que se va a utilizar?
 Personal del proyecto, ¿nuevos en la organización?
Descomposición
• Descomponer proyecto en tareas sencillas

Establecer jerarquía de descomposición
Nombrar responsables o expertos
Solicitar compromisos o estimaciones
Calcular el coste global
• Apoyo de diagramas de descomposición

funcional (OBS,WBS,etc.)
Descomposición por fase
ACTIVIDAD PF/mes HORAS/PF Nºmedio PF/pers
REQUISITOS 175 0,75 250
PROTOTIPADO 150 0,88 350
ARQUITECTURA 300 0,44 2000
PLAN DE PROYECTO 500 0,26 1000
DISEÑO INICIAL 175 0,75 250
DISEÑO DETALLADO 150 0,88 250
CODIFICACIÓN 50 2,64 150
ADQUISICIÓN DE PAQUETES 400 0,33 5000
V Y V DE CÓDIGO 150 0,88 150
DOCUMENTACIÓN DE USUARIO 70 1,89 750
PRUEBA UNITARIA 150 0,88 150
PRUEBA DE SISTEMA 175 0,66 2500
ASEGURAMIENTO DE CALIDAD 200 0,88 2000
INSTALACIÓN Y FORMACIÓN 350 0,38 5000
GESTIÓN DE PROYECTO 100 1,32 750
GESTIÓN DE CONFIGURACIÓN 1750 0,08 1000
Otros “métodos”
Dos esquemas de restricciones
Price to win
• Ofrecer estimación de coste, plazo o esfuerzo necesaria
para llevarse el contrato
• Reacción:
 Limitar calidad de proceso y producto
 Limitar funcionalidad de aplicación
Ley de Parkinson
• “El trabajo tiende a consumir todo el tiempo o los
recursos disponibles”
• Objetivo de plazos de tiempo no realista. Creencias
erróneas :
 A los programadores les gustan los "desafíos“
 Los programadores no trabajan duro si no están
presionados
Métodos algorítmicos
• Se basan en la utilización de fórmulas que

aplicadas sobre modelos producen una
estimación de coste del proyecto
u
v
f(x)
x
Aplicación a Coste
desarrollar y
...
z

Puntos de Función
• Mide dos tipos de características:
– Los elementos de función
(entradas, salidas, ficheros, etc.)
Permiten calcular los Puntos de Función sin ajustar “PFSA”
– Los factores de Complejidad.
• Elementos de Función: Analiza los siguientes factores:

– Entradas
– Salidas
– Consultas
– Ficheros Lógicos Internos
– Ficheros de Interfaz
Entradas externas
Paso Acción Reglas de cuenta
1 Identificar EI Reglas de identificación:

- Aplicar definición
2 Determinar la complejidad las EI y su Reglas de complejidad:
contribución a la cuenta de PF no ajustados. - Referencias a tipos de ficheros
(File Type References: FTRs)
- Tipos elementales de datos
(Data element types: DETs)

Puntos de Función (Entradas)
Entradas:
• Son todos aquellos procesos que hacen llegar
datos a la aplicación desde el exterior, desde un
usuario u otra aplicación.
• El flujo de datos deberá tener una sola

dirección, del exterior al interior.
• Como consecuencia de una entrada, siempre

deberá actualizarse un fichero lógico interno.
Puntos de Función (Entradas)
Entradas:
Ejemplos:
• Pantallas de entrada de datos.
• Lector de códigos de barras.
• Lector de tarjetas magnéticas y electrónicas.
• Captura de imágenes, voz, etc.

Puntos de Función(Entradas)
Clasificación de las entradas:
DIFICULTAD Número de Campos o Atributos de la Entrada
ENTRADAS
1-4 Atributos 5-15 Atributos 16 + Atributos
0 ó 1 ficheros
BAJA BAJA MEDIA
accedidos
2 ficheros
BAJA MEDIA ALTA
accedidos
3 + ficheros
MEDIA ALTA ALTA
accedidos

Reglas de complejidad: EI (I)
• Tipo de fichero referido (file type referenced: FTR):

 Un ILF leído o mantenido por un tipo de función.
 Un EIF leído por un tipo de función.
• Reglas de FTRs:
 Contar un FTR por cada ILF mantenido.
 Contar un FTR por cada ILF o EIF leído durante el proceso
de la EI.
 Contar un FTR por cada ILF mantenido y leído por un
entrada externa.

Reglas de complejidad: EI (II)
• Reglas de DET:
 Contar un DET por cada campo no recursivo y reconocible por el usuario mantenido en un ILF
por una entrada externa.
Ejemplo: nombre de trabajo y nivel de paga son dos campos que el usuario puede reconocer
como parte de un trabajo.
 Contar un DET por cada campo no introducido por el usuario pero que, a través de una entrada
externa, se mantiene en un ILF.
Ejemplo:un código de empleado generado por el sistema en el ILF de trabajo.
 Contar un DET por cada una de las siguiente técnicas de implementación para un grupo entero
de campos: un campo lógico almacenado físicamente como muchos campos. Ejemplo: fecha.
 Contar como un único DET las siguientes técnicas de implementación para todo el conjunto de
campos:
• Campos que aparecen más de una vez debido a las técnicas de implementación.
Ejemplo: clave en el registro de empleado y clave ajena en el registro de familiares.
 Campos que indican que ha ocurrido un error durante el proceso o que confirman que el
proceso se ha completado.
Ejemplo: si un usuario intenta añadir un empleado existente, el sistema genera varios
mensajes de error y el campo incorrecto se resalta. Contar un DET para todas las respuestas
de error del sistema.
 Contar un solo DET para especificar la acción a tomar por la entrada externa.
Ejemplo: líneas de ordenes o teclas de función/acción que disparan la acción de la entrada
externa (contar un DET por el conjunto de teclas, es decir, una extra por cada EI).
Proceso completo: EI
1 Identificar los datos o la información de control que entra del exterior.
2 Usar las reglas de cuenta de EI para determinar si se cuenta dicha información
como EI: aplicar definición.
3 Aplicar las reglas de cuenta de FTR y DET
4 Clasificar la complejidad de cada EI según la siguiente tabla basada en las
cantidades de DET y RET:
Complejidad 1 to 4 DET 5 to 15 DET  16 DET
0-1 FTR Baja Baja Media

2 FTR Baja Media Alta
 3 FTR Media Alta Alta
5 Buscar los pesos aplicables a cada EI en función de su complejidad y calcular

aportación para el cálculo de PF no ajustados
Complejidad Baja Media Alta
EI ___  3 ___  4 ___  6

Salidas externas
1 Identificar EO Reglas de identificación:

2 Determinar la complejidad las EO y su Reglas de complejidad:
contribución a la cuenta de PF no ajustados. - Referencias a tipos de ficheros
(File Type References: FTRs)

Puntos de Función (Salidas)
Salidas:
• Son todos aquellos procesos que hacen llegar
datos desde la aplicación hacia el exterior, a un
usuario o a otra aplicación.
• El flujo de datos deberá tener una sola

dirección, del interior al exterior.

Salidas:
Ejemplos:
• Pantallas de salida de datos.
• Listados.
• Grabación de bandas magnéticas.
• Transferencia de datos a otras aplicaciones,
ya sea mediante ficheros o transmisión de
datos.

Clasificación de las salidas:
DIFICULTAD Número de Campos o Atributos de la Salida
SALIDAS
1-5 Atributos 6-19 Atributos 20 + Atributos
0 ó 1 ficheros
BAJA BAJA MEDIA
accedidos
2 ó 3 ficheros
BAJA MEDIA ALTA
accedidos
4 + ficheros
MEDIA ALTA ALTA
accedidos

Reglas de cuenta: EO
• Reglas para contar datos:

• El proceso manda datos o información de
control al exterior de los límites de la
aplicación.
• Los datos o la información de control se
mandan mediante un proceso elemental.
• Para el proceso, se debe cumplir una de
estas condiciones:
 La lógica de proceso es distinta de otras
salidas externas
 Los elementos de datos identificados son
diferentes de otras salidas externas de la
aplicación.

Reglas de complejidad: EO (I)
• Tipo de fichero referido (file type referenced: FTR):

 Un EIF leído cuando se procesa la salida externa
• Reglas de FTRs:
 Contar un FTR por cada ILF o EIF leído durante el procesamiento de la
salida externa

Reglas de complejidad: EO (II)
• Reglas de DET:
 Contar un DET por cada campo no recursivo y reconocible que aparece en una salida
externa.
Ejemplo: cada campo de total de la salida.
 No contar literales como DET.
Ejemplo:título de informe.
 No contar como DET las variables de paginación o las marcas generadas por el sistema.
Ejemplo: número de página.
 Contar las siguientes técnicas de implementación física como un único DET:
• Un campo lógico almacenado físicamente como múltiples campos cuando se requiere por el
usuario como un solo campo.
Ejemplo: número de cuenta.
• Cada tipo de etiqueta y tipo de equivalente numérico en una salida gráfica.
Ejemplo: gráfico de tarta podría tener dos DET, uno para la categoría y uno para el
porcentaje.
• Información textual como una única palabra o frase.
Ejemplo: un mensaje incluido en un informe para la razón de no completar una transacción.
Proceso completo: EO
1 Identificar un proceso que envía datos al exterior
2 Usar las reglas de cuenta de EO para determinar si se cuenta como EO: aplicar
definición.
3 Aplicar las reglas de cuenta de FTR y DET
4 Clasificar la complejidad de cada EO según la siguiente tabla basada en las
cantidades de DET y RET:
0-1 FTR Baja Baja Media

2-3 FTR Baja Media Alta
 4 FTR Media Alta Alta
5 Buscar los pesos aplicables a cada EO en función de su complejidad y calcular

aportación para el cálculo de PF no ajustados
EI ___  4 ___  5 ___  7

Puntos de Función (Consultas)
Consultas:
• Son todos aquellos procesos que están formados por
una combinación de entradas y salidas, produciendo
una consulta a los datos.
• El flujo de datos deberá tener dos direcciones.
• Como consecuencia de una consulta no se modifican
los datos del sistema.
• La complejidad de la consulta viene dada por la
mayor entre la entrada y la salida.

Consultas externas
Datos derivados:
• Datos que requieren procesamiento distinto a una recuperación directa o edición de
información de ILF/EIF. Ejemplos: calcular salario mensual a partir de horas
trabajadas almacenadas en un ILF o totalizar el número de empleados en una sede.
1 Identificar EO Reglas de identificación:

2 Determinar la complejidad las EO y su Reglas de complejidad:
contribución a la cuenta de PF no ajustados. - Determinar complejidad de la
parte de entrada de la EQ.
- Determinar la complejidad de la
parte de salida de la EQ.
- Determinar la contribución los
PF no ajustados usando la mayor
de las dos complejidades

Reglas de complejidad: EQ (I)
• Utilizar la complejidad mayor de las dos siguiente: parte de entrada y
parte de salida.
• Entrada: en cada parte de entrada de EQ, un FTR por cada ILF/ELF
leído durante el proceso.
 Contar un DET por cada campo no recursivo y reconocible por el usuario
usado en la entrada de EQ. Ejemplo:ID y clave al entrar al sistema.
 Contar un DET por cada campo que indica criterio de selección de datos.
Ejemplo: nombre para buscar lista de empleados.
 Contar un DET por cada una de las siguiente técnicas de implementación
para un grupo entero de campos:
• Campos que indican que ha ocurrido un error al procesar los DET de entrada o confirmar
que el proceso ha terminado.
• Campos que proporcionan la capacidad de especificar una petición externa que se debe
procesar. Ejemplo: Ok para indicar que el usuario está lista para recuperar datos y verlos.

Reglas de complejidad: EQ (II)
• Salida: cada parte de salida de EQ, un FTR por cada ILF/ELF leído
durante el proceso.
 Contar un DET por cada campo no recursivo y reconocible que aparece en una
salida externa. Ejemplo: cada campo de total de la salida. por Ejemplo:
número de seguridad social
 No contar literales como DET. Ejemplo:título de informe.
 No contar como DET las variables de paginación o las marcas generadas por el
sistema. Ejemplo: número de página, fecha, “filas 23 a 51 de 145”, etc.
 Contar las siguientes técnicas de implementación física como un único DET:
• Un campo lógico almacenado físicamente como múltiples campos cuando se
requiere por el usuario como un solo campo. Ejemplo: número de cuenta.
• Campos que, por implementación, aparecen más de una vez en un ILF.
Ejemplo: clave y clave ajena.

Proceso completo: EQ
1 Identificar un proceso que envía datos al exterior
2 Usar las reglas de cuenta de EQ para determinar si se cuenta como EQ:
aplicar definición.
3 Aplicar las reglas de cuenta de FTR y DET en la parte de entrada y en la
de salida
4 Clasificar la complejidad de la entrada según la tabla de EI y la de salida
según la tabla de EO.
5 Buscar los pesos aplicables a cada EQ en función de la mayor de sus
complejidades (de entrada o de salida) y calcular aportación para el
cálculo de PF no ajustados
EI ___  3 ___  4 ___  6

Identificar límites de aplicación
•Basada en visión de usuario, no de técnicos

Dominio de usuario •Entre aplicaciones relacionadas, basada en
Entrada Consulta
funcionalidad de negocio
Salida
externa
externa externa •Límites iniciales no influidos por el tipo de
cálculo de PF: mejora, desarrollo, etc.
Entrada
externa
Salida
externa
Internal External
Logical Interface
File File
Consulta
externa

Funciones de datos
• Tipos de funciones de datos:
 Funcionalidad proporcionada al usuario para requisitos de datos internos y externos
 Internos (Internal Logical Files): ILFs.
 Externos (External Interface Files): EIFs.
• Fichero (file): diferente de sentido tradicional
 Grupo de datos relacionados lógicamente (no su implementación física).
• Ficheros lógicos internos:
 Grupo de información (datos o control) relacionados lógicamente, identificable por el
usuario y mantenida dentro de los límites de la aplicación
• Ficheros externos de interfaz:
 Grupo de información (datos o control) relacionados lógicamente que son referenciados
por la aplicación
 Identificable por el usuario pero mantenida dentro de los límites de OTRA aplicación

Proceso de cuenta: ILF/EIF
1 Identificar ILFs y EIFs. Reglas de identificación:

2 Determinar la complejidad de ILF o EIF y su Reglas de complejidad:
contribución a la cuenta de PF no ajustados. - Tipos elementales de registro
(Record element types: RETs)

Puntos de Función (ILF)
Ficheros Lógicos Internos:

• Es un grupo de datos relacionados, tal como
los percibe el usuario y que son mantenidos por
la aplicación.
• Los ficheros se cuentan una sola vez,

independientemente del número de procesos
que los acceden.

Ficheros Lógicos Internos:

Ejemplos:
• Clientes.
• Socios.
• Artículos.
• Proveedores.

Clasificación de las ficheros lógicos internos:
DIFICULTAD Número de Campos o Atributos
FICHEROS
LÓGICOS 1-19 Atributos 20-50Atributos 51 + Atributos
1 Registro
BAJA BAJA MEDIA
Lógico
2 a 5 Registros
BAJA MEDIA ALTA
Lógicos
6 o más
MEDIA ALTA ALTA
Registros Lógic.

Puntos de Función (EIF)
Ficheros de Interfaz Externos:

• Es un grupo de datos relacionados, tal como los
percibe el usuario, referenciados por la aplicación
y que son mantenidos por otra aplicación.
• Son ficheros internos de otra aplicación.

Puntos de Función (EIF)
Clasificación de las ficheros de interfaz:
DIFICULTAD Núm ero de Cam pos o Atributos
FICHEROS
DE INTERFAZ 1-19 Atributos 20-50Atributos 51 + Atributos
1 Entidad o
BAJA BAJA MEDIA
Registro Lógico
2 a 5 Registros
BAJA MEDIA ALTA
Lógico
6 o m ás
MEDIA ALTA ALTA
Registros Lógic.

Reglas de complejidad: ILF/EIF
• Tipo de dato elemental (DET):

 Un único campo no recursivo del ILF o EIF que es reconocible por el usuario
• Reglas para DET:
 Contar un DET por cada campo único y reconocible por el usuario de un ILF o
EIF
• Ejemplo: un número o un dato físicamente almacenado en múltiples campos se cuenta como
un solo DET.
 Contar un DET por cada unidad de dato en un ILF o EIF que existe porque el
usuario requiere que se mantenga una relación con otro ILF.
• Ejemplo: en una aplicación de RRHH, se mantiene información de empleados en una ILF.
Se cuenta un DET por la denominación del puesto del empleado que sirve para relacionarlo
con la lista de puesto de la empresa (clave ajena: foreign key).
 Contar como un único DET las siguientes técnicas de implementación para todo
el conjunto de campos:
• Campos que aparecen más de una vez debido a las técnicas de implementación. Ejemplo:
clave en el registro de empleado y clave ajena en el registro de familiares.
• Campos repetititivos idénticos en formato para múltiples ejemplares de valores (no hay
1ªFN). Ejemplo: 12 campos para cantidades mensuales y un total anual, cuenta como 2 DET.
Reglas de complejidad: ILF/EIF
• Tipo de registro elemental (RET):

 Un subgrupo de elementos de datos en un ILF o EIF que es reconocible por el usuario
 Dos tipos:
• Opcional: el usuario tiene opción de usar uno o ninguno durante el proceso elemental de crear o añadir
• Obligatorio (mandatory): el usuario debe usar al menos uno
 Ejemplo: en aplicación de RRHH, aparte de la información general del empleado,
la información debe indicar si es asalariado o autónomo (cada uno con distintos
campos) y puede tener información sobre familiares.
• Información general (obligatoria)
• Asalariado (opcional)
• Autónomo (opcional)
• Familiares (opcional)
• Reglas para RET:
 Contar un RET por cada subgrupo opcional u obligatorio de un ILF o EIF.
 Si no hay subgrupos, contar el ILF o EIF como un RET.

Proceso completo: ILF/EIF
1 Identificar grupos lógicos de datos e información de control.
2 Usar las reglas de cuenta de ILF o EIF para determinar si cada grupo se cuenta
como ILF o EIF: aplicar definición.
3 Aplicar las reglas de cuenta de DET y RET
4 Clasificar la complejidad de cada ILF/EIF según la siguiente tabla basada en
las cantidades de DET y RET:
1 RET Baja Baja Media

2-5 RET Baja Media Alta
 6 RET Media Alta Alta
5 Buscar los pesos aplicables a cada ILF o EIF en función de su complejidad y

calcular aportación para el cálculo de PF no ajustados
ILF ___  7 ___  10 ___  15
EIF ___  5 ___  7 ___  10

Guía rápida
• En modelos de datos:
ILF/EIF  Entidad (cuidado con grupos de varios RET)
DET: atributos/campos
RET: subentidades/entidades débiles/subtipos
FTR: entidades accedidas/usadas
• Una misma pantalla o caso de uso puede implicar
varias funciones: consultas, entradas, etc.

Puntos de Función
Puntos de Función Sin Ajustar (PFSA):
Simple Media Compleja Total

Cantidad * Peso Cantidad * Peso Cantidad * Peso
Entradas *3 *4 *6
Salidas *4 *5 *7
Consultas *3 *4 *6
Fic. Lógicos *7 * 10 * 15
Fic. Interfaz *5 *7 * 10
Total puntos de función sin ajustar (PFSA)

Puntos de Función: Factores de Complejidad
Factores de complejidad (significado):
Valor Significado del valor
0 Sin influencia, factor no presente
1 Influencia insignificante, muy baja
2 Influencia moderada o baja
3 Influencia media, normal
4 Influencia alta, significativa
5 Influencia muy alta, esencial

Puntos de Función
FC1) Comunicación de Datos.
Los datos usados en el sistema se envían o reciben
por líneas de comunicaciones.
Sistema aislado
Varios protocolos de comunicación

Puntos de Función
FC1) Comunicación de Datos (Valores):
0: Sistema aislado del exterior
1: Batch, usa periféricos E o S remotos
2: Batch, usa periféricos E y S remotos
3: Captura de datos en línea o teleproceso que pasa
los datos o sistema de consulta
4: Varios teleprocesos con mismo protocolo
5: Varios protocolos. Sistema Abierto y con
interfaces de todo tipo al exterior.

Puntos de Función
FC2) Proceso Distribuido.
Existen procesos o datos distribuidos y el control
de éstos forma parte del sistema.
Centralizado
Varios servidores en distintos equipos

Puntos de Función
FC2) Proceso distribuido (Valores):

0: Sistema totalmente centralizado
1: Sistema realiza procesos en un equipo, salidas
usadas vía Sw por otros equipos
2: Sistema captura, los trata en otro
3: Proceso distribuido, trans. una sola direc.
4: idem, transferencia en ambas direcciones.
5: procesos cooperantes ejecutándose en distintos
equipos.
Puntos de Función
FC3) Objetivos de Rendimiento.
Si el rendimiento es un requisito del sistema, es decir,
es crítico algún factor como tiempo de respuesta o
cantidad de operaciones por hora. Se tendrá que hacer
consideraciones especiales durante el diseño,
codificación y mantenimiento.
Rendimiento normal
Necesidad de uso de herramientas especiales para

analizar el rendimiento (muy crítico)
Puntos de Función
FC3) Objetivo de Rendimiento (Valores):
0: Rendimiento normal ( no se da énfasis ).
1: Se indican requisitos, no medida especial.
2: Crítico en algunos momentos. Procesos
acabados antes de próxima sesión de trabajo.
3: Tiempo de respuesta es crítico.
4: ... en diseño hacer análisis de rendimiento en
tiempo respuesta o cantidad operaciones/hora.
5: .. uso herramientas para alcanzar el rendimiento
demandado por el usuario.
Puntos de Función
FC4) Integración de la Aplicación.
El sistema tendrá que ejecutarse en
un equipo en el que coexistirá con
otros, compitiendo por los recursos,
teniendo que tenerse en cuenta en
las fase de diseño.
No coexistencia
Restricciones especiales de uso de

aplicaciones en los procesadores
Puntos de Función
FC4) Integración de la aplicación (Valores):
0: No se indican restricciones
1: Existen las restricciones usuales
2: Características de seguridad o tiempos.
3: Restricciones en algún procesador
4: El Sw deberá funcionar con restricciones de uso
en algún procesador.
5: Restricciones especiales para aplicación en los
componentes distribuidos del sistema
Puntos de Función
FC5) Tasa de Transacciones.
La tasa de transacciones será elevada. Se
tendrá que hacer consideraciones especiales
durante el diseño, codificación e instalación.
No hay picos ni tasa elevada
Tasa de transacciones tan elevada que necesita

de herramientas especiales de análisis y
control
Puntos de Función
FC5) Tasa de transacciones (Valores):

0: No se prevén picos.
1: Se prevén picos poco frecuentes (mensual).
2: Se prevén picos semanales.
3: Se prevén horas punta, diarias.
4: Tasa de trans. tan elevada que en diseño se hace
análisis de rendimiento.
5: Análisis de rendimiento en diseño,
implementación e instalación.
Puntos de Función
FC6) Entrada de Datos On-line.
La entrada de datos será directa
desde el usuario a la aplicación,
de forma interactiva.
Batch
Interacción más del 30%

Puntos de Función
FC6) Entrada de datos on-line (Valores):

0: Todo es Batch.
1: 1%<entradas interactivas <7%.
5: Entradas interactivas >30%.

Puntos de Función
FC7) Eficiencia para el Usuario Final.
Se demanda eficiencia para el trabajo del usuario, es
decir, se tiene que diseñar e implementar la
aplicación con interfaces fáciles de usar y con
ayudas integradas.
Ninguna necesidad de eficiencia (teclas de función,

ayuda on-line)
Necesidad de herramientas para medir la usabilidad

y accesibilidad, que es total
Puntos de Función
Tipos de elementos asociados a la eficiencia del
usuario.
• Menús.
• Uso de ratón.
• Ayudas "en_línea".
• Movimiento automático del cursor.
• Efectos de Scroll (papiro).
• Teclas de función predefinidas.
• Lanzamiento de procesos Batch desde las
transacciones "en_línea“.
Puntos de Función
… continuación:
• Selección mediante cursor de datos de la pantalla;
• Pantallas con muchos colores y efectos;
• Posibilidad de "hard-copy".
• Ventanas de "pop-up";
• Aplicación bilingüe (cuenta por cuatro).
• Aplicación Multilingüe (mas de dos, cuenta por seis).

Puntos de Función
FC7) Eficiencia para el Usuario Final (Valores):

0: No se da énfasis al tema
1: 1 a 3 de los factores
2: 4 a 5 de los factores
3: 6 o más factores, sin requerir eficiencia
4: ... con requerimientos que implican estudio de
los factores humanos en el diseño
5: … se demandan prototipos y herramientas para
verificar que se alcanzaran los objetivos
Puntos de Función
FC8) Actualizaciones On-line.

Los ficheros maestros y/o las Bases de
Datos son modificados de forma
interactiva.
Solo batch
Gran cantidad de actualizaciones interactivas;

sistema de recuperación muy automatizados
Puntos de Función
FC8) Actualizaciones On-line (Valores):
0: No hay.
1: De 1 a 3 ficheros con información de control;
cantidad baja y ficheros recuperables.
2: ... pero con 4 o más ficheros de control
3: Actualización de ficheros importantes
4: ... esencial la protección ante pérdidas
5: Gran cantidad de actualizaciones interactivas;
sistemas de recuperación muy automatizados.
Puntos de Función
FC9) Lógica de Proceso Interno Compleja.
La complejidad interna en un proceso esta en función de
las siguientes características:
• Especificados algoritmos matemáticos complejos.
• Proceso con lógica compleja.
• Especificado muchas excepciones, consecuencia de
transacciones incompletas, que deberán tratarse.
• Manejar múltiples dispositivos de entrada / salida.
• Se incorporarán sistemas de seguridad y control.
Ninguna de las características anteriores
Todas
Puntos de Función
FC9) Lógica de Proceso Interno Compleja (Valores):

0: Ninguna de las características.
1: 1 Característica.
2: 2 Características.
...
5: Las 5 características.

Puntos de Función
FC10) Reusabilidad del Código.
Es necesario hacer consideraciones especiales durante
el diseño, codificación y mantenimiento para que el
código se reutilice en otras aplicaciones.
No se prevé
Reutilización mediante búsquedas automáticas con

metadatos asociados a los elementos de software
Puntos de Función
FC10) Reusabilidad del Código (Valores):
0: No se prevé.
1: Reutilizar código en la misma aplicación.
2: Menos de un 10% de la aplicación tiene en cuenta
las necesidades de + de 1 usuario.
3: El 10 % o más ...
4: Aplicación preparada para ser reutilizable a nivel
de código.
5: Aplicación preparada para ser reutilizable por
medio de parámetros.

Puntos de Función
FC11) Contempla la conversión e instalación.

Se proveerán facilidades de conversión e instalación
en el sistema, se tendrá que hacer consideraciones
especiales durante el diseño, codificación y pruebas
para que la conversión del sistema antiguo sean
fáciles de realizar durante la puesta en marcha del
sistema nuevo.
Antiguo Nuevo

Puntos de Función
FC11) Contempla la conversión e instalación (Valores).

0: No se requiere conversión.
1: Se solicita facilidad de instalación.
2: Se solicitan procesos de conversión e
instalación, no importantes para el proyecto.
3: ... si son importantes.
4: 2 y herramientas conversión e instalación.
5: 3 y herramientas conversión e instalación;
sistema crítico para la empresa.
Puntos de Función
FC12) Facilidad de Operación.
Facilitar la explotación real de la aplicación, dedicando especial
atención durante el diseño, codificación y pruebas del sistema. Se
pueden tener en cuenta las siguientes posibilidades de automatización:
• Procesos de arranque, back-up y recuperación pero con o sin

intervención del operador.
•Manejo de cintas u otros dispositivos manual o automático.
Ninguna operación
Operación compleja totalmente automatizada

Puntos de Función
FC12) Facilidad de Operación (Valores):

0: No se especifica nada.
1 a 4: Sumar la cantidad de items de la lista
anterior.
5: Sistema automático sin intervención humana.

Puntos de Función
FC13) Instalaciones Múltiples.
El sistema ha de incluir los requerimientos de
diversas empresas o departamentos en donde se
ejecutara (incluso plataformas).
Un solo entorno
Múltiples entornos con requerimientos funcionales

distintos (monedas, leyes, idiomas) y hardware y
sistemas de soporte (gestores b.d, sistemas
operativos) distintos
Puntos de Función
FC13) Instalaciones Múltiples (Valores):

0: 1 solo lugar.
1: Múltiples lugares, mismo Hw y Sw.
2: En diseño se tiene en cuenta el caso (1).
3: En diseño se tiene en cuenta múltiples entornos
Hw y Sw.
4: Se documenta y planea para (1) y (2).
5: Idem, para (3).

Puntos de Función
FC14) Facilidad de Cambios.
Se tendrá que hacer consideraciones especiales
para que en el sistema sea fácil de introducir
cambios y fácil de adaptar al usuario.
Ninguna facilidad
Necesidad de consultas flexibles con

condiciones lógicas complejas y
parametrización (customización del sistema)
compleja
Puntos de Función
FC14) Facilidad de Cambios.
Items a tener en cuenta:
•Consultas flexibles del usuario:
- Simples con condiciones. lógicas And/Or que implican
un único fichero lógico
- Medias con cond. lógicas sobre más de 1 F.L. (por 2).
- Complejas con condiciones lógicas complejas que
afectan a varios F.L. (por 3).
•Parámetros de la aplic. con tablas ajenas al código:
- El cambio se hace efectivo al arrancar el sistema.
- El cambio es interactivo (por 2).

Puntos de Función
FC14) Facilidad de Cambios (Valores):

0: No se especifica nada
1: Un ítem de valor 1
2: Items por valor 2
3: ...
5: Items por valor 5

Puntos de Función: Factores de Complejidad
Tabla para el cálculo de los Factores de Complejidad
# Factor de Complejidad Valor
(0..5)
1 Comunicación de Datos.
2 Proceso Distribuido.
3 Rendimiento
4 Configuración Operacional compartida
5 Ratio de Transacciones
6 Entrada de Datos EN-LÍNEA
7 Eficiencia con el Usuario Final
8 Actualizaciones EN-LÍNEA
9 Complejidad del Proceso Interno
10 Reusabilidad del Código
11 Contempla la Conversión e Instalación
12 Facilidad de Operación (back up, etc.)
13 Instalaciones Múltiples
14 Facilidad de Cambios
Factor de Complejidad Total (FCT) ? Valori

Puntos de Función Ajustado
Cálculo de los PFA:

PFSA: Punto de Función Sin Ajustar FC: Factor de Complejidad
PFA = PFSA * (0,65 + (0.01 * FC))
Esfuerzo = PFA * Promedio_Organización( Lenguaje)

Puntos de Función
Estimación del Esfuerzo Requerido (Datos históricos)
Nombre Puntos de Lenguaje Esfuerzo en Horas/PF

Proyecto Función horas
Sénia 200 COBOL 5.017 25
Paláncia 150 PASCAL 2.569 17
Turia 375 4GL 3.011 8
Albufera 500 PASCAL 9.479 19
Magro 425 4GL 3.342 8
Cabriel 800 PASCAL 13.349 17
Júcar 180 PASCAL 2.800 16
Serpis 325 4GL 2.541 8
Montnegre 225 PASCAL 4.528 20
Segura 470 COBOL 13.218 28

Resumen del Proceso de Conteo
Puntos de Función
• Proceso de Conteo:
Teniendo la descripción del sistema y sus componentes, iniciamos el proceso

de conteo de la siguiente forma:
1. Identificar las funciones (archivos lógicos internos, archivos lógicos

externos, entradas externas, salidas externas, consultas externas).
2. Clasificar las funciones (determinar el grado de complejidad para cada
función.
3. Calcular Puntos de Función No Ajustados. (PFSA)
4. Calcular el Factor de Ajuste “Complejidad”- ”FC” (basado en las 14
características generales).
5. Calcular los Puntos de Función Ajustados. PFA (El resultado es el tamaño
del sistema expresado en Puntos de Función).
6. Estimación del Esfuerzo Requerido (basado en los datos históricos
promedios de la organización).
Ver Ejemplo Práctico en el Aula Virtual (Carpeta de Ejercicios)

Resumen: Cálculo de puntos de función
Medir
funciones de
datos
Cálculo PF no
ajustados
Medir
Identificar
funciones de
alcance de transacciones
medición y Cálculo de
límites de PF ajustados
aplicación
Calcular valor
de factor de
ajuste

COCOMO
COnstructive COst MOdel
(Modelo Constructivo de Costes)
•Desarrollado en 1981 por Barry Boehm
(Universidad de California Sur).
•Es el modelo de estimación de costes más utilizado.
•En 1995 se publicó la versión COCOMO II y actualmente

derivó a COCOMO 2000.
El equipo liderado por B. Boehm (Center for Software
Engineering) pretende mejorar, ampliar y adaptar el modelo
anterior a las nuevas formas en que se desarrolla el software.
COCOMO
PERMITE ESTIMAR EL ESFUERZO, COSTO Y DURACION DE
CUALQUIER PROYECTO INFORMATICO
• Ámbito: fase de diseño hasta prueba (Fase de Diseño:Análisis-Diseño)
• Excluye: planificación, conversión, implantación
• El esfuerzo se mide en mes - hombre: 1 mm = 19 persona-días =
152 persona-horas.
• Es un modelo algorítmico, es decir, se basa en una serie de fórmulas
matemáticas que producen una estimación en función de un conjunto
de variables : f(x1,x2,….xn):
- Líneas de código fuente.
- Capacidad de analistas y programadores.
- Complejidad del producto.
- Restricciones de tiempo de ejecución, memoria, equipos de trabajo
…
- Fiabilidad de la aplicación, etc.
COCOMO
PARTE DE QUE:
• El modelo del proyecto está bien dirigido tanto por el desarrollador del
mismo como por el cliente, existiendo por ello muy pocos tiempos
perdidos en el análisis de requerimientos del producto.
• Considera que la especificación de requerimientos no tiene cambios

sustanciales después de la fase de planificación y requerimientos del
producto.
• El modelo avanzado considera que la influencia de los factores

conductores de coste del software dependen de cada fase. Los otros
modelos sólo hacen diferencias entre la etapa de desarrollo y la etapa de
mantenimiento.
• El coste de cada fase incluye todos los costes incurridos durante la fase.
Los costes de actualización del plan de integración y prueba y la
aceptación completa de los planes de prueba están incluidos en la fase
de diseño detallado.
COCOMO
Consideraciones básicas:
• La estimación se realiza de acuerdo con la información
disponible en el momento que se lleva a cabo.
• La variable principal para la estimación son las líneas de código
fuente esperadas, expresadas en miles (KDSI).
DSI (Delivered Sources Instructions o Instrucciones Fuentes Deliberadas). No se consideran las
líneas de comentarios, test, documentación, etc., a no ser que se escriban con un fin expreso.
• La estimación cubre únicamente un conjunto definido de fases

(por ejemplo, no incluye la fase de formación a los usuarios).
• Incluye todas las labores directas del proyecto, pero no las
labores indirectas.
• El esfuerzo se mide en hombre-mes (mm: Man-Mes)
1 mm = 19 persona-días = 152 persona-horas
Cuando se habla de hombres-mes se refiere a 152 horas de tiempo de trabajo
al mes. Este factor se ha calculado teniendo en cuenta la experiencia en los
distintos proyectos desarrollados y considerando el tiempo de vacaciones
COCOMO
En el ciclo de vida del desarrollo de software se resaltan las siguientes características:
1. Una cuidada definición y validación de la especificación de los requerimientos software por

un grupo de personas relativamente pequeño con anterioridad a la entrada en la fase de
diseño.
2. Una cuidada definición y validación del diseño del sistema software por un grupo de
personas algo más grande, aunque todavía relativamente pequeño, anterior a la entrada en
la fase de diseño detallado y codificación.
3. Un Diseño detallado, codificación y prueba de unidades desarrollados por un grupo grande
de programadores trabajando en paralelo, y siguiendo una línea base firmemente
establecida de estructuras de diseño del sistema, a menudo un desarrollo incremental de la
planificación.
4. La integración y prueba de cada incremento en el sistema está basada en una gran cantidad
de planificación de pruebas tempranas y en la eliminación de casi todas las unidades
defectuosas por medio de cuidadosos y completos recorridos de las unidades desarrolladas.
5. Gran cantidad del esfuerzo de documentación (por ejemplo los borradores de los manuales
de usuario) se desarrollan pronto para proporcionar a los usuarios (y desarrolladores)
algunas ideas de la naturaleza operacional del producto.
A raíz de lo expuesto, se puede deducir que la cantidad de personal requerido para el

desarrollo de un proyecto no es constante.
Por ello, Boehm considera que la curva de distribución de Rayleigh es un estimador

razonablemente exacto de los requisitos de personal para el ciclo de vida de desarrollo,
desde el diseño arquitectónico hasta las pruebas del sistema, siempre y cuando se use la
porción de la curva entre 0.3td y 1.7td.
COCOMO: la función de Rayleight
como estimador
• Boehm considera que la función de

distribución de Rayleight es un estimador
exacto para los requisitos de personal para
el ciclo de vida del desarrollo ;
Desde el diseño arquitectónico hasta las

pruebas del sistema siempre que usemos la
porción de curva entre 0,3td y 1,7td

Curva de Rayleigh del esfuerzo frente al tiempo
(K: esfuerzo total desarrollado” area bajo la curva; td: valor máximo de esfuerzo)
Esfuerzo
td tiempo
Figura 5.5 Curva de Rayleigh del esfuerzo frente a tiempo
t2
K  e
Esfuerzo  2 te 2 td
td
MODELOS COCOMO
Boehm, clasifica el modelo COCOMO jerárquicamente y en base a la complejidad
y cantidad de información utilizada en la estimación en:
• BASICO: Modelo estático evaluado que calcula el

esfuerzo y el coste de desarrollo en función del DSI (Líneas
de Código Fuente Estimadas)
• INTERMEDIO: Esfuerzo en función del tamaño del
programa y de un conjunto de guías de coste. que incluyen
una evaluación subjetiva del producto, del hardware, del
personal y de los atributos del proyecto.
• AVANZADO: Como el intermedio pero estudiando las
guías en cada fase concreta (análisis, diseño, etc)

MODOS DE DESARROLLO
COCOMO
Asímismo, Boehm distingue tres tipos de modos de desarrollo en base a las
características del producto software, para cada uno de los modelos anteriormente
definidos:
• ORGANICO: Proyectos pequeños que trabajan con pocos

requerimientos, en los que pequeños equipos de trabajo con
buena experiencia en la aplicación trabajan en un conjunto poco
rígido de requerimientos y en un entorno familiar.
(inferiores a 50KDSI).
• SEMIACOPLADO: intermedios en tamaño y complejidad en
el que equipos de trabajo con una mezcla promedio de gente
experimentada e inexperimentada deben satisfacer
requerimientos poco y medio rígidos (inferiores a 300KDSI).
• EMPOTRADOS: Opera dentro de una serie de restricciones
que elevan la complejidad del producto.
Características de los diferentes modos de
desarrollo de sofware
MODOS COCOMO
CARACTERÍSTICAS
Orgánico Semiacoplado Empotrado
Experiencia en trabajar con EXTENSO CONSIDERABLE MODERADO

Sistemas Software relacionados
Entendimiento organizacional de COMPLETO CONSIDERABLE GENERAL
los objetivos del producto
Necesidad de conformidad del BASICO CONSIDERABLE TOTAL
software con los requerimientos
preestablecidos
Necesidad de conformidad del BASICO CONSIDERABLE TOTAL
software con las especificaciones
del interfase externo
Desarrollo concurrente de nuevo ALGUNO MODERADO EXTENSO
hardware asociado y
procedimientos operacionales
Necesidad de innovación de MINIMA ALGUNA CONSIDERABLE
arquitecturas de proceso de datos
y algoritmos
Premio por una finalización BAJO MEDIO ALTO
temprana
Rango de medidas de producto < 50 KDSI < 300 KDSI CUALQUIERA
Ejemplos Sistemas operativos Muchos sistemas de Grandes sistemas de
Modelos científicos procesamiento de procesamiento de
transacciones transacciones
complejas
Modelos gestión Control de producción Sistemas operativos
de inventarios grandes grandes
Intercambios simples Sistemas operativos y Mandatos de control
bases de datos nuevas complejos
COCOMO
Clasificación de Proyectos según el Factor tamaño
Dentro de cada modelo y modo de desarrollo de un producto software, Boehm realiza una
clasificación de los proyectos en función del tamaño del producto software a desarrollar:
• Pequeños: < 2000 DSI
• Intermedios: entre 2000 y 8000 DSI
• Medios: entre 8000 y 32.000 DSI
• Grandes: entre 32.000 y 128.000 DSI
• Muy grandes: entre 128.000 y 512.000 DSI
Para estos cinco tipos de proyectos se han tabulado las cantidades o porcentajes del esfuerzo y
calendario para cada una de las fases del ciclo de vida consideradas por Boehm dentro del modelo
COCOMO.
Cuando el tamaño del producto en consideración se encuentre dentro de cualquiera de los intervalos
de los tamaños estándares de proyectos que considera el modelo, el cálculo del esfuerzo de desarrollo
para cada una de las fases que lo componen se efectúa por medio de la interpolación.

Modelo COCOMO básico
Las ecuaciones básicas del esfuerzo para un proyecto software en los distintos
modos de desarrollo vienen representadas en la siguiente tabla .
En dicha tabla también se muestran las ecuaciones básicas para el cálculo del
calendario de desarrollo del proyecto software para los diferentes modos y
donde:
KDSI Es el número de miles de instrucciones fuentes deliberadas en el producto software.
MM Es el número de hombres-mes estimados para el desarrollo del software, que incluye las fases del ciclo de vida consideradas
en las definiciones y presunciones que Boehm efectúa para el desarrollo del modelo.
TDEV Es el número de meses estimados para el desarrollo del software, usando las mismas definiciones y presunciones que para
el cálculo del esfuerzo.
MODO ESFUERZO CALENDARIO
Orgánico MM= 2.4 (KDSI)1,05 TDEV= 2,5(MM)0.38
Semi-acoplado MM= 3.0 (KDSI)1.12 TDEV= 2,5 (MM) 0.35
Empotrado MM= 3.6 (KDSI)1,20 TDEV= 2,5 (MM)0,32

COCOMO
• Una vez estimado el esfuerzo y calendario de desarrollo de un producto desde
el punto de vista del modelo básico, pueden obtenerse otros datos sobre el
proyecto como son: la productividad y el número de personal medio que
trabaja a tiempo completo, al cual Boehm ha denominado FSP (Full-time-
equivalent Sofware Personal).
Productividad (PR) = KDSI / MM
Número Medio de Personas: (FSP): MM/ TDEV
Si se representa el esfuerzo estimado frente a la medida del producto , y el calendario estimado

frente al esfuerzo de desarrollo, pueden hacerse las siguientes observaciones:
1. Para productos software de la misma medida, el esfuerzo estimado es considerablemente

mayor y la productividad estimada es considerablemente menor para el modo empotrado.
2. Para productos grandes, la disminución en la productividad es mayor en el modo empotrado.
3. El calendario, estimado como una función de la medida del producto, es parecido o el mismo
para los tres modos de desarrollo.
4. Para proyectos software que requieren la misma cantidad de tiempo de desarrollo, los proyectos
en modo empotrado necesitarán mayor esfuerzo que el resto de los modos de desarrollo.
Los valores pertenecientes a estos datos se muestran en la Tabla siguiente, en la que aparecen los
tres modos de desarrollo del COCOM0 básico para las distintas medidas estándares de
productos.
Estimaciones de COCOMO básico para
medidas estándares de productos (Tabla 1)
(Pequeño) (Intermed) (Medio) (Grande) (Muy
MODO 2 KDSI 8 KDSI 32 KDSI 128 KDSI grande)
512
KDSI
ESFUERZO (MM)
Orgánico 5.0 21.3 91.0 392.0 N.C.

Semiacoplado 6.5 31.0 146.0 687.0 3250.0
Empotrado 8.3 44.0 230 1216.0 6420.0
PRODUCTIVIDAD (DSI/MM)
Orgánico 400 376 352 327 N.C.

Semiacoplado 308 258 219 186 158
Empotrado 241 182 139 105 80
CALENDARIO (TDEV)
Orgánico 4,6 8.0 14,0 24,0 N.C.

Semiacoplado 4,8 8.3 14,0 24,0 42,0
Empotrado 4,9 8.4 14,0 24,0 41,0
PERSONAL
MEDIO
(FSP)
Orgánico 1.1 2,7 6,5 16,0 N.C.

Semiacoplado 1.4 3,7 10,0 29,0 77,0
Empotrado 1.7 5,2 16,0 51,0 157,0
COCOMO - Cálculos
EJEMPLO:
Sea el tamaño del proyecto alrededor de 32000 Líneas de
código (KDSI)
LUEGO ENTONCES APLICAR LAS ECUACIONES

ASOCIADAS AL MODO ORGANICO:
Aplicando las formulas del Cocomo Básico:

• MM = 2,4 (32)1.05 = 91 hombre-mes (Esfuerzo Estimado)
• TDEV= 2,5 (91)0,38 = 14 meses (Tiempo de Desarrollo)
• PR= 32,000 / 91 = 352 líneas / hombre-mes (Productividad)
• FSP = 91 / 14 = 6,5 hombres (Número medio de personas)
Distribución por actividades
• La distribución del tiempo por actividades es

función del tamaño del proyecto y del modo.
• Los porcentajes de los esfuerzos de planificación
son independientes del tamaño del producto.
• Los tiempos de diseño y pruebas aumentan
proporcionalmente con el tamaño.
• Los tiempos de programación disminuyen con una
proporción inversa al tamaño del producto y a su
modo.

Distribución por actividades (Tabla 2)
Ejemplo
Ejemplo. Se calculará la distribución de actividades para la fase de
diseño del producto de un proyecto, cuyo tamaño es muy grande :
(512 KDSI) en modo empotrado.
1. Lo primero que se debe hacer es calcular su esfuerzo y calendario total

para el desarrollo del proyecto.
Para ello, se consulta la Tabla 1, observándose que el esfuerzo de
desarrollo para un proyecto de 512 KDSI en modo empotrado es de
6420 MM y el calendario es de 41 mes.
2. A continuación, se consulta la Tabla 2, en la que se distribuye este
esfuerzo en fases observándose que la fase de diseño del producto
consume un 18% del esfuerzo total y un 38% del calendario total,
pudiendo así calcularse el esfuerzo y el calendario necesario para el
desarrollo de dicha fase de diseño, obteniéndose los valores de:
• MM = 6420 hombres-mes * 0.18 = 1156 hombres-mes
• TDEV = 41 meses * 0.38 = 15.6 meses
3. Estos valores conducen a una medida de FSP =MM/TDEV= 74

personas trabajando durante la fase de diseño del producto.
Esfuerzo de mantenimiento
“Tasa Anual de Cambios” (Annual Change Traffic, ACT) que se define como
“la fracción de instrucciones fuente de un producto software que se cambia
durante un año, bien por adición o por modificación”.
MT = número de líneas en la versión actual.

Fc = número de líneas en la versión actual que han cambiado.
Fa = número de líneas en la versión actual que se han añadido.
Fd = número de líneas en la versión anterior que se han borrado en la versión
actual.
ACT = (Fa + Fc + Fd ) / MT
El esfuerzo de mantenimiento anual se calcula aplicando un coeficiente

próximo a la unidad obtenido en base a la experiencia en la relación de
esfuerzo de mantenimiento y de desarrollo
MMmantenimiento = K x ACT x MMdesarrollo

Limitaciones del modelo COCOMO básico
• No se acomoda de forma secuencial al desarrollo

incremental del proyecto.
• Existen discontinuidades en los niveles de personal
en los límites de cada fase.
• No incorpora los efectos modificadores del coste
del software como pueden ser: restricciones del
hardware, efectos medioambientales o
consideraciones del personal.
Modelo COCOMO intermedio
• El modelo COCOMO básico descrito anteriormente, estima el esfuerzo requerido para
desarrollar un producto software usando solamente una variable simple de predicción
(número de instrucciones fuente deliberadas) y tres modos de desarrollo del
software. Este nivel del modelo es bastante bueno para explicar muchas de las
variaciones en el coste de los proyectos software. Sin embargo, su precisión es sólo
aceptable para realizar estimaciones aproximadas del coste en las primeras etapas
de la definición del producto.
• El modelo COCOMO intermedio, una extensión del COCOMO básico posee mayor
precisión y niveles de detalle que lo hace más susceptible para la estimación de
costes en las etapas de definición de productos software.
• El modelo COCOMO intermedio incorpora unas 15 variables de predicción

adicionales que explican muchas de las variaciones del coste de un proyecto software
inexplicables por el COCOMO básico y ajustándose más, por ello, a los datos de los
proyectos contenidos en la base de datos COCOMO.
• El esfuerzo se mide en función del tamaño del programa y a un conjunto de “guías” de

coste.
• Es un sistema bastante mas “fino” que el anterior pero su complejidad puede hacer que no sea
necesario emplearlo si no se necesita una estimación mas fiable

COCOMO Intermedio
• Los 15 factores o atributos modificadores del coste

que son los usados en el modelo COCOMO
intermedio se agrupan dentro de cuatro categorías,
las cuales define Boehm como :
(1) Atributos del producto software
(2) Atributos del ordenador,
(3) Atributos del personal y
(4) Atributos del proyecto.

Ecuaciones de estimación en un
modelo COCOMO intermedio
MODO ESFUERZO CALENDARIO
Orgánico MM= 3.2 (KDSI)1,05 TDEV= 2,5(MM)0.38
Semi-acoplado MM= 3.0 (KDSI)1.12 TDEV= 2,5 (MM) 0.35
Empotrado MM= 2.8 (KDSI)1,20 TDEV= 2,5 (MM)0,32

Multiplicadores de esfuerzo en el
modelo COCOMO intermedio
MODIFICADORES DEL COSTE DE Muy Bajo Nomin Alto Muy Extra
DESARROLLO bajo al alto alto
ATRIBUTOS DEL PRODUCTO
RELY Confiabilidad requerida del software 0.75 0.88 1.00 1.15 1.40
DATA Tamaño de la Base de Datos 0.94 1.00 1.08 1.16
CPLX Complejidad del producto 0.70 0.85 1.00 1,15 1,30 1.65
ATRIBUTOS DEL ORDENADOR
TIME Restricciones del tiempo de ejecución 1.00 1.11 1.30 1.66
STOR Restric. en almacenamiento principal 1.00 1.06 1.21 1.56
VIRT Volatilidad de la máquina virtual 0.87 1.00 1.15 1.30
TURN Tiempo de respuesta del ordenador 0,87 1.00 1.07 1.15
ATRIBUTOS DEL PERSONAL
ACAP Capacidad de los analistas 1.46 1.19 1.00 0.86 0.71
AEXP Experiencia en la aplicación 1.29 1.13 1.00 0.91 0.82
PCAP Capacidad de los programadores 1.42 1.17 1.00 0.86 0.70
VEXP Experiencia en uso de memoria virtual 1.21 1.10 1.00 0.90
LEXP Experiencia en leng. de programación 1.14 1.07 1.00 0.95
ATRIBUTOS DEL PROYECTO
MODP Uso de prácticas modernas de pro. 1.24 1.10 1.00 0,91 0.82
TOOL Uso de herramientas software 1.24 1.10 1.00 0,91 0.83
SCED Calendario requerido para el desarrollo 1.23 1.08 1.00 1.04 1.10

Manejo de las tablas
• Consideraremos un software a estimar de 32KDSI en
modo semiacoplado con una serie de requisitos de
confiabilidad
• Acudimos a la tabla y observamos que:
MM=3,0(32)1,12= 146 meses-hombre
TDEV=2,5 (146)0,35=14,30 meses
• Se acude a las distintas tablas para estudiar los
coeficientes modificadores de esfuerzo en donde:
Esfuerzo Total (Eo) = MM * Fi ;
donde Fi se corresponde con los quince factores descritos
anteriormente
Ejemplos
• Dependiendo de la influencia del nivel de confiabilidad requerido (RELY) de los distintos tipos de
proyectos que se deseen desarrollar, se tiene:
1. Se desarrolla un prototipo o modelo de demostración de viabilidad de un lenguaje natural o

sistema de entrada de voz. Este tipo de sistemas requieren de un nivel bajo de confiabilidad, ya
que no es un sistema orientado a la producción. Observando la Tabla la estimación del esfuerzo
ajustado para un producto de esta naturaleza es:
(146MM)(0.75) = 110 hombres-mes
2. Se desarrolla un modelo de planificación a gran escala o un modelo de planificación

climatológica. Estos tipos de productos requieren una confiabilidad relativamente baja, porque su
impacto operacional es a gran escala y muchos de sus fallos se pueden producir a bajo nivel, siendo
las pérdidas fácilmente recuperables para los usuarios. La estimación del esfuerzo se obtendrá de la
forma: (146MM)(0.88) = 128 hombres-mes
3. Se desarrolla un sistema de manejo de información o un sistema de control de inventario.

Estos sistemas son representativos de la clase de software con requerimientos de confiabilidad
nominal, en ellos el efecto de un fallo no es trivial, pero generalmente es recuperable sin una
extrema complicación. Por ello, el ajuste se considera nominal y el esfuerzo estimado ser:
(146MM)(1.00) = 146 hombres-mes

Ejemplos ….
4. Se desarrolla un sistema del tipo de autorización de créditos en el campo de la banca o
sistema de distribución eléctrico. Estos sistemas requieren una alta confiabilidad, pues un fallo
en tales sistemas puede producir pérdidas financieras o inconvenientes humanos masivos, siendo el
esfuerzo ajustado: (146MM)(1.15) = 168 hombres-mes
5. El último caso en la escala a considerar, sería el desarrollo un sistema del tipo de control y
mando militar o un sistema de control de un reactor nuclear que exige un requerimiento muy
alto de confiabilidad del software, pues un fallo en el sistema podría ocasionar la pérdida de vidas
humanas, por ello el esfuerzo ajustado vendrá dado por:
(146MM)(1.40) = 204 hombres-mes
Las razones por las cuales se necesitan más hombres-mes para desarrollar un producto software con
altos requerimientos de confiabilidad o fiabilidad son analizados en profundidad en el modelo
detallado o avanzado.

Esfuerzo de mantenimiento
• Utiliza esencialmente el mismo conjunto de factores
conductores de esfuerzo que el desarrollo
• No se tienen en cuenta el factor Sced
• El factor Rely (Fiabilidad) tiene un efecto inverso (si un
producto fue desarrollado con baja fiabilidad, será más
costoso corregir los defectos):
Fiabilidad (RELY)
Slight Low Moderate High $ Loss of life
loss
Ratios Very Low Low Nom High Very High

1.24 1.12 1.00 0.86 0.72

Modelo COCOMO avanzado
El modelo COCOMO intermedio representa un modelo altamente efectivo para muchos de los
propósitos de las estimaciones de costes del software; pero tiene principalmente dos limitaciones,en
las estimaciones detalladas de los costes para proyectos software grandes:
• Las estimaciones de la distribución del esfuerzo por fases es inexacta.
• Es un modelo que resulta incomodo para usarlo en un producto con muchos componentes.
El modelo COCOMO detallado o avanzado permite eliminar las limitaciones del modelo intermedio
por dos vías principalmente:
1. En el modelo intermedio el esfuerzo de distribución por fases es determinado sólo por la medida
del producto software a desarrollar. En la práctica, factores tales como la confiabilidad requerida
del software, experiencia en aplicaciones del personal, etc., afectan a unas fases más que a otras. El
modelo detallado proporciona una medida de la sensibilidad en cada una de las fases de los factores
multiplicadores para cada uno de los atributos modificadores de coste, usando dichos
multiplicadores para determinar la cantidad de esfuerzo requerido para completar cada fase.
2. En el modelo COCOMO intermedio se efectúa una separación de la clasificación de los
modificadores de coste que pudieran ser provistos para los diferentes componentes del producto. Este
proceso puede ser muy tedioso e innecesariamente repetitivo.
El modelo detallado resuelve este problema proporcionando tres jerarquías de niveles del
producto, siendo éstas:
(a) Nivel modular, se consideran los efectos que tienden a variar con la profundización en el nivel
modular.
(b) Nivel de subsistema, se consideran los efectos que varían menos frecuentemente; es decir, varían
de la misma manera para todos los módulos que componen un subsistema.
(c) Nivel de sistema, se consideran efectos tales como la medida total del producto, que afectan a
todo el sistema globalmente.
• Permite introducir modificadores a nivel subsistema, sistema y módulo.
• Se consideran nuevas tablas donde los modificadores de los esfuerzos se detallan para cada fase
COCOMO II
Objetivos:
• El desarrollo de un modelo de estimación de costes y
planificación que pudiera ser usado en el ciclo de vida de
la década de los 90 y posterior al 2000.
• Desarrollar una BD indicativa del coste de software y un

soporte de herramientas con la capacidad suficiente para el
continuo progreso y perfeccionamiento del modelo.
• Proporcionar un cuantioso y analítico marco de trabajo, y

un conjunto de herramientas y técnicas para la evaluación
de los efectos que la tecnología software tiene sobre el
coste de los ciclos de vida software.

COCOMO II
Se consideran tres modelos que cubren desde el
comienzo del análisis de requerimientos hasta el final de
las pruebas e integración del sistema:
• Modelo ACM (Mod. de Composición de Aplicaciones)

• Modelo EDM (Mod. de Diseño Inicial)
• Modelo PAM (Mod. de Post-Arquitectura)

COCOMO II
Modelo ACM (Mod. de Composición de Aplicaciones)
• Usado principalmente para aplicaciones de prototipaje

o aplicaciones basadas en generadores de pantallas,
informes, base de datos, etc…
• Basado en Puntos Objeto (PO) (número y complejidad
de pantallas, listados, componentes de lenguajes) y
Factores de Reusabilidad y Productividad.
• Se procede como en puntos de función: se estiman los
componentes (pantallas, listados…), se estima la
complejidad de cada uno y se les da un peso.

COCOMO II
Proceso del Modelo ACM (Mod. de Composición de
Aplicaciones)
1. Similar a puntos de función: se estiman los componentes
(pantallas, listados…), se estima la complejidad de cada uno y
se les da un peso y se calcula un total (PO).
2. Se calcula el ratio de la productividad (PROD) según la
siguiente tabla:
3. El esfuerzo viene dado: PM = PO / PROD

COCOMO II
Modelo EDM (Mod. de Diseño Inicial)
• Usado en las etapas iniciales cuando se conoce poco
sobre el tamaño del producto, la plataforma, el
personal.
• Basado en Puntos de Función No Ajustados (PFNA).
• Una vez calculados, se convierten a líneas de código.
• Se utiliza el método COCOMO tradicional con 7
modificadores de esfuerzo seleccionados (según el
modelo COCOMO Intermedio).
Gestión de proyectos Tema 3: JLCS

COCOMO II
Modelo PAM (Mod. de Post-Arquitectura)
• Se aplica cuando se considera que el proyecto dispone

ya de requerimientos estables.
• Mismo proceso que EDM con diecisiete factores
específicos diferentes
• Además, tiene en cuenta indicadores de la reutilización
de software, software de desecho y ajuste por uso de
reingeniería.

COCOMO II- Modelo PAM

























Putnam
• Asume una distribución específica del esfuerzo a lo largo del
ciclo de vida de un proyecto
• Relaciona cantidad de personas-mes y la duración del proyecto.
L  Ck  K  t d 
1/ 3 4/3
donde Ck es una constante de
estado de la tecnología, K es el
16
esfuerzo total del desarrollo en 14
Esfuerzo
Asignado
personas-año, td es el tiempo de 12
desarrollo en años y L el número de 10
miles de líneas fuente del proyecto. 8
6
4
2
0
10
12
14
16
18
20
22
24
0
2
4
6
8
Meses de Desarrollo
• Algunos valores típicos de Ck pueden ser Ck =2000 en entornos
de desarrollo típicos o Ck = 8000 en un buen entorno de
desarrollo con buena metodología y herramientas.
Herramientas Automáticas
• Todas requieren:
estimación cuantitativa del tamaño del proyecto
(puede ser en LC)
características cualitativas del proyecto
(complejidad, fiabilidad, grado crítico)
descripción del personal de desarrollo o
entorno de desarrollo

Herramientas automáticas de Estimación
• ESTIMACS: Es un modelo de macro estimación que utiliza el
método de los puntos-función.
• COSTAR: Aplica el método COCOMO fácilmente. Descargar el
Software de la pagina:
http://www.softstarsystems.com/demo.htm(Softstars Systems)
SLIM: Aplica el método de Putnam y facilita la programación
lineal, la simulación estadística y las técnicas PERT en un solo
paquete.
• COSMOS ( Muy práctico y sencillo de Manejar, Aplica el método
de Puntos de Función y Cocomo muy fácilmente)
Es la que usaremos en el laboratorio .. Disponible en aula virtual

COSTAR
COSTAR
Formas de estimación de costes
• Jones, 1998:
Manuales:
• A nivel de proyecto “a ojo de buen cubero”
• A nivel de fase usando ratios y porcentajes
• A nivel de actividad usando WBS
Con soporte automatizado:
• Macroestimación a nivel de proyecto
• Macroestimación a nivel de fase
• Microestimación a nivel de actividad

Manual: descripción general (I)
• Proyecto “a ojo”:
Más antigua, muy usada y menor precisión
• “Media de aplicación COBOL :
 500 LOC por mes de persona”
 “Coste medio COBOL: 10$ por LOC”, etc.
Muy fácil de aplicar
Precisión no tan mala cuando:
• Hay sistematización
• Acumulación de experiencia
• Combinación con Delphi y analogía

Manual: descripción general (II)
• Fases con ratios y porcentajes:

Asignar estimación de proyecto a fases
• 10.000 LOC COBOL  20 mp (mes de persona)
• Requisitos (10%), análisis y diseño (20%), codificación
(30%), pruebas (35%) e instalación (5%)
• Req: 2 mp, AyD: 4 mp, Cod: 6 mp, Pru: 7 mp, Ins: 1 mp
Problemas:
• Porcentajes reales varían mucho (según tamaño de
proyecto, etc.)
• Trabajo expandido en muchas fases o todo el proyecto
• Actividades que no son fases pueden omitirse
 P.ej., aseguramiento de calidad, documentación, etc.

Fases según tamaño de proyecto
Tamaño PF Tamaño LOC Gestión, soporte, Codificación Papel (análisis, Eliminar defectos
etc. diseño,…)
5 500 11% 68% 5% 16%
10 1000 11% 65% 7% 17%
40 4000 11% 58% 12% 19%
80 8000 11% 54% 15% 20%
320 32000 12% 40% 22% 26%
1200 120000 14% 30% 26% 30%
5000 500000 15% 21% 30% 34%
10000 1000000 16% 18% 31% 35%
Actividades como el aseguramiento de la calidad, integración, documentación técnica

pueden totalizar el 25% del esfuerzo total del proyecto

Manual: descripción general (III)
• Uso de la WBS:
El más preciso de los manuales
Complicado manualmente para muchas actividades
(p. Ej., 50) y tareas (p. ej., 250)
Ayuda con herramientas (p. ej., MS-Project)
Crear un plan inicial realista del proyecto
Gestionar el plan
Seguimiento del progreso Ajustar el plan Comunicar el progreso

Manual: descripción general (IV)
Dos maneras de plantear descomposición:
Propuesta directa de coste:
• Por actividad
• Por elemento o función
Estimación de LOC o PF:
• Para cada elemento del software
Cuidado en controlar influencia de factores
¿Cómo combinar para el coste global?
• Relaciones complejas: MS-Project

Gestión de estimaciones
• Diferentes métodos en diferentes etapas del
ciclo de vida
Opinión de expertos y analogías para estimaciones
preliminares
• Cuando no hay suficiente conocimiento para obtener precisión
• Estimaciones manuales “a ojo”
Modelos de costes después de la especificación de
requisitos: buena información de proyecto
• Realimentación basada en valores reales:
Mejorar la experiencia del personal
Mejorar los modelos/métodos de estimación.

Estimaciones tempranas
Primeras estimaciones apoyadas en los expertos
"Adivinar" el esfuerzo directamente, no las LOC
• Estudios demuestran que no hay ventajas
Obtener estimaciones en grupo
• Grupo estable
Proporcionar retroalimentación:
• Evolucionar hacia analogías
• Mejorar la experiencia

Estimación preliminar manual
• Útil:
Estimación temprana sin conocer requisitos a fondo
Proyectos pequeños con uno o dos programadores
Proyectos poco valiosos sin impacto crítico
• Arriesgado:
Propósito contractual
Proyectos mayores de 100 PF o 10.000 LOC
Proyectos con impacto significativo
• Estudio de 50 casos:
Error > 35%, >75% de casos (máximo error > 50%)

Estimaciones pos-especificación
• Preferible construcción de modelos específicos
para el entorno
• Usar entradas medibles, adaptables a cada fase
No desechar opinión de expertos o analogías
• Proyectos poco habituales
• Propuesta independiente
Ecuaciones diferentes para cada fase
• No hay modelos comerciales idóneos
Mejor modelo propio que adaptar uno general
• Igual o menor esfuerzo
No hay solución mágica

Desarrollar un modelo propio
Etapas típicas:
1. Descomposición de elementos de coste
2. Formulación de una teoría de coste
3. Recogida de datos
4. Analizar datos - construir modelo
5. Comprobar el modelo
Soporte de base de datos de proyectos

Descomponer elementos de coste
Definir un "modelo de proyecto“

Determinar qué actividades del modelo se van a
predecir:
• Especificación, diseño, pruebas, etc.
Mayor madurez de proceso, mayor capacidad
de predicción

Formular teoría de costes
Plantear:
¿Qué métricas son apropiadas?
• Tamaño: principal parámetro
• Popular pero ¿válida?
¿Cuándo están disponibles?
¿Qué actividades predicen?
¿Formular la teoría como una ecuación?
• Sistema de predicción
• Ecuación simplemente lineal para modelos locales
 Menor variabilidad
Evitar correlación ciega

Recogida de datos
• Recogida de datos del proyecto para
"comprobar" la teoría
La cantidad depende del número de variables
• Controlar la validez estadística y experimental
• N+2 proyectos (n = variables): práctica de 7-10 para 1 variable
Adecuada recogida de datos •Proyectos en desarrollo o
completados: 18 meses previos
• Definición de procedimientos •Más de 6 meses·hombre
• Formación y difusión •Proyectos representativos:
plataformas y mezcla de
• Base de datos
tecnologías y lenguajes
• Empezar con modelos simples
Refinar cuando haya más datos disponibles
• Supone tener teorías de coste más sofisticadas
Analizar los datos
Usar análisis estadístico

Regresión simple para una ecuación lineal
Logaritmos para la exponencial
Proporcionar:
Valoración de la precisión
Límite de confianza del 95%

Comprobar el modelo
Significado estadístico:
No es suficiente para una buena predicción
Coeficiente de regresión múltiple  0.85
Criterios
Error relativo = (estimación - valor real) / valor real
Media absoluta error relativo  0.25
Por lo menos 75% de las estimaciones dentro del 25%
del valor real
• No es demasiado buen nivel

Retroalimentación
• Aproximación basada en la
retroalimentación de los valores reales
Mejora de la capacidad individual de juicio
Desarrollo de modelos locales
• Valorar la eficacia del proceso de
estimación
Factor de Calidad de Estimación de DeMarco

Gestión de proyectos: definiciones y fundamentos

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Gestión de proyectos: definiciones y fundamentos

Cargado por

Copyright:

Formatos disponibles

1.

Un proyecto es una tarea temporal realizada de forma independiente

• Realización independiente de las estructuras de la

ESTUDIOS DESARROLLO PRUEBAS

mirar hacia mirar hacia

• Todo el proceso de desarrollo del SW es un proyecto SW.

• Proyectos software realizados sobre un producto software

• Continua innovación tecnológica.

• Fuerte dependencia de los RRHH

• Actividades de Seguimiento y Control. Asignación

• Actividades de Finalización del Proyecto. Cierre

• Planificación y gestión de un proyecto

• Si existe una GP es posible:

▫ Director del Proyecto: está al frente del Comité

*Si es un desarrollo interno pertenecerán la propia organización

▫ Experto en SW de base (S.O., comunicaciones,

▫ Miembro del equipo de proyecto o soporte

** Flipped Learning: Realizar la actividad 1 de laboratorio para discutirla. 1.1. - 33

• Reduce al máximo la burocracia y actividades

• Ideal para proyectos con un rápido cambio de

• Proceso de valoración de la empresa:

• Siempre que se realiza una inversión esperamos un cierto rendimiento

▫ Estimación de costes de fases de desarrollo

▫ Descripción de beneficios intangibles

▫ Base histórica para estimar la evolución de

▫ Identificación de riesgos asociados a

Rentabilidad Prevista (PR)

▫ Capital circulante: el que necesita todo negocio para

• ROI: beneficio acumulado

• Valor actual neto (VAN)

• Tasa interna de retorno (TIR)

• Método del payback (Retorno de la inversión)

Hipótesis baja Hipótesis media Hipótesis alta

• Compara todos los ingresos y gastos en un momento del proyecto

▫ VF =VA ·(1+K)t= VA · (1+0,1)3 =VA · 1,331= 13.310€

Año Capital inicial Intereses (10%) Saldo final

capital inicial Interés (10%) saldo final

• ¿Qué interés para 15.000 a partir de 10.000 en 3 años?

▫ VAN = - I + CF1/(1+k1) + CF2/((1+k2)(1+k1)) + ... + CFn/(1+ki)

Tasa de descuento k = 10%

VAN (A) = - 200 + 70/(1+0,1) + 70/(1+0,1)2 + 60/(1+0,1)3 + 60/(1+0,1)4 = 7,4

BET => 12.004 = (23.000/12) · t => 6,26 meses

• Es de considerar que suele haber un conjunto de objetivos lo que

• Se situará la gestión informática como un activo más

• La información es un valor para la empresa, es

• Actividades de Seguimiento y Control (GPS). Comprenden

• Actividades de Finalización del Proyecto (GPF). Por último,

GPS 1 GPS 2 GPS 3 GPS 10 GPS 11 GPS 12

 Gestión de proyectos: aplicación de conocimientos, habilidades y

 PMBOK establece tres apartados:

 Relaciones entre procesos:

 PMBOK organiza los procesos en 5 grupos.

• Iniciación: Se reconoce que un proyecto o fase

• Tiene un único subproceso: Iniciación.

• Este esquema se denomina plan del proyecto.

• Ha de llevar a cabo acciones preventivas,

• No son necesariamente secuenciales y puede haber

• Scrum es una metodología ágil de desarrollo de

• En 1996 se definió por primera vez un patrón para

• Esta fue la primera definición de un patrón Scrum

• Reduce al máximo la burocracia y actividades

• Ideal para proyectos con un rápido cambio de