Gestin y Planificacin de

Proyectos
Gestin de Proyectos

Material bibliogrfico

Desarrollo y gestin de proyectos informticos. Steve McConnell. McGraw-Hill.

Contiene bibliografa comentada al final de cada tema (e.g., Estimacin, Motivacin, Equipos
de trabajo y Aumento de productividad).

Ingeniera del software. Un enfoque prctico. Roger S. Pressman. 7 edicin.

McGraw-Hill.
Software engineering. Ian Sommerville. 9 edicin. Addison-Wesley.
Ingeniera del software. Aspectos de gestin. Tomo 1: Conceptos bsicos, teora,
ejercicios y herramientas. Romn Lpez-Cortijo y Garca y Antonio de Amescua Seco.
Instituto Ibrico de la Industria del Software (www.iiis.es).
La calidad del software y su medida. Jess M Minguet Melin y Juan F. Hernndez
Ballesteros. Editorial Centro de Estudios Ramn Areces.
Calidad de sistemas informticos. Mario G. Piattini Velthius, Flix O. Garca Rubio e
Ismael Caballero Muoz-Reja. Ra-Ma.
Project management prctico. Tcnicas, herramientas y documentos. J. Eduardo
Caamao. Ed. Crculo rojo-Docencia. (www.pmpractico.com)
Interfaces, tcnicas y prcticas. MTRICA versin 3. Ministerio de las
Administraciones Pblicas: http://www.csi.map.es/csi/metrica3/.
International Function Point Users Group (IFPUG): http://www.ifpug.org.

ndice

Introduccin.

Ciclo de vida de la gestin de proyectos.

Dimensiones de un proyecto software.

Pilares fundamentales.

Introduccin

Introduccin (I)

Factor de calidad en el mbito del software:

Requisito fundamental de ISO 9000 (i.e. de sus guas de aplicacin al

desarrollo software).
La planificacin y seguimiento de proyectos son dos reas de proceso del
nivel 2 de CMMI, en donde se busca slo la repetitividad.

Problema:

Resulta duro aprender sobre temas de calidad trabajando todo el da para

sacar adelante los proyectos.

Crculo vicioso: Parar para planificar, no parar para acabar.

Solucin:

Controlar los proyectos (planificacin) y

Controlar las planificaciones (seguimiento).

Introduccin (II)

Crisis del software:

Problemas originados:

Durante aos el desarrollo de software se ha considerado un arte.

El director (o jefe de proyecto) lo diriga ms bajo consideraciones
tcnicas que de gestin.

Desviaciones en costes y tiempos inaceptables.

Calidad baja o muy baja en sistemas vitales.
Incremento en la complejidad de los sistemas.

Conclusiones:

La ingeniera del software slo no es la solucin si no se considera

la gestin, planificacin y seguimiento de proyectos.
Necesidad de una metodologa para organizar, planificar y
controlar los proyectos software.

Introduccin (III)

Dirigir un proyecto software requiere, fundamentalmente y

entre otras cosas:

Procesos de ingeniera del software y de gestin bien definidos y

aplicados.
Metodologas, tcnicas y herramientas adecuadas y conjuntadas.
Buena especificacin de requisitos por parte del usuario.
Planificacin adecuada con calendarios realistas.
Presupuestos correctos, ajustados y proporcionados.
Personal formado, motivado y adecuado organizado en buenos y
equilibrados equipos.
Control/coordinacin.
Buena comunicacin/informacin.
Gestin de riesgos.

Introduccin (IV)

Si no hay procesos repetibles, que emplee toda la organizacin, no

existe una base para la mejora continua, tanto de la calidad como de
la productividad.

Organizacin inmadura:

No hay un proceso definido y riguroso.

No hay estimaciones realistas, por lo que la planificacin no se cumple.
Si se impone un calendario, la calidad y la funcionalidad se resienten para
lograrlo.

Organizacin madura:

Hay habilidad generalizada para gestionar los procesos de desarrollo

software.
El proceso es conocido y todo se desarrolla de acuerdo con lo planificado.
Los procesos son consistentes (responden a lo esperado).
Las responsabilidades y papeles estn claramente definidos.
La planificacin est basada en datos histricos y es realista.

Ciclo de vida de la gestin de

proyectos

Definiciones

Proyecto:

Accin iniciada por la empresa,

en la que recursos humanos, financieros y materiales se organizan
de una nueva forma
para acometer un trabajo nico,
en el que dadas unas especificaciones y dentro de unas
limitaciones presupuestarias,
se intenta conseguir un cambio beneficioso definido por unos
objetivos cualitativos y/o cuantitativos.

Gestin de proyectos:

Sistema de procedimientos, prcticas, tecnologas y conocimientos

que
facilitan la organizacin, gestin, direccin, planificacin y control
necesarios para que el proyecto termine con xito.

Ciclo de vida (I)

La forma en que se aplican los procesos de gestin cambia

conforme el proyecto avanza.

Existen diferentes modelos de ciclo de vida con variacin

en el nmero de estados propuestos.

Ejemplo:
ETAPA

NOMBRE

OBJETIVO DE GESTIN

Germinacin

Propuesta e iniciacin

- Definicin del proyecto

- Alcance y objetivos
- Diseo funcional
- Viabilidad
- Estimacin inicial
- Decisin de continuar o no

Ciclo de vida (II)

ETAPA

NOMBRE

OBJETIVO DE GESTIN

Crecimiento

Diseo y validacin

- Diseo del sistema

- Producto base
- Estimacin
- Planes y recursos
- Validacin del diseo

Madurez

Ejecucin y control

- Formacin y comunicacin
- Planificacin detallada y diseo
- Control estimacin
- Asignacin de trabajo
- Seguimiento del progreso
- Terminacin de las previsiones
- Control y recuperacin

Muerte

Finalizacin y cierre

- Terminacin del trabajo

- Uso del producto
- Consecucin de beneficios
- Disolucin/recompensa del equipo
- Auditora y revisin
- Registro histrico de los datos

Definicin del proyecto

El contenido del informe de definicin de un proyecto debera considerar

los siguientes apartados principales:

Definicin: Qu se pretende en trminos de resultados finales.

Justificacin: Si el esfuerzo de desarrollo justifica la inversin.
Objetivos y metas: Servirn para determinar si el proyecto concluye con xito.
Factores crticos de xito: Aquellos que harn que el proyecto concluya con
xito o fracase.
Riesgos: Identificar las posibles fuentes de problemas.
Alcance del proyecto: Fija las fronteras del proyecto.
Estructura del proyecto: Se subdividir si la complejidad lo exige.

Cada subproyecto debe incluir ttulo, objetivo, alcance, producto final, hitos,
riesgos/dependencias y responsables.
Fecha prevista de finalizacin.
Fases, actividades, tareas e hitos.
Organizacin: Estructura organizativa y responsabilidades.
Sistema de control: Forma de revisar el trabajo en el proyecto.
Supuestos, dependencias y restricciones: Supuestos sobre el entorno de
desarrollo, dependencias con otros proyectos, etc.
Presupuesto y gestin del presupuesto: Presupuesto disponible, forma de
gestionarlo y responsable.

Finalizacin del proyecto

Hay que asegurarse de que el trabajo se ha completado a tiempo y de forma

eficiente. Para ello se debe finalizar formalmente el proyecto:

Finalizacin del trabajo:

Transferencia del producto a los usuarios:

Establecer una medida de referencia.

Calcular variaciones entre lo medido y lo establecido.
Tomar acciones correctoras para eliminar las variaciones.

Disolucin del equipo:

Planificar la transicin.
Aceptacin del producto por los usuarios.
Formar a los usuarios.
Garantizar el mantenimiento del producto y niveles de servicio.

Obtencin de beneficios:

Planificar y controlar los trabajos: Listas de trabajos a realizar y realizados.

Establecer reuniones de control.
Disolver el equipo y cerrar contratos con terceros.

Planificar la disolucin del equipo y despus devolver los recursos a su origen.

Mantener una reunin de final de proyecto.
Repartir premios, castigos, evaluaciones y otras consideraciones.

Revisiones post-finalizacin:

Configuracin final.
Comparar costes y beneficios finales para retroalimentar el proceso (histricos).
Registrar lo logros tcnicos del proyecto para realimentar el proceso de desarrollo.
Revisar xitos y fracasos del proyecto para el futuro.

Dimensiones de un proyecto
software

4 dimensiones
PERSONAS (Peopleware)

PROCESO

TECNOLOGA

PRODUCTO

Si se potencian estas cuatro dimensiones:

Se maximiza la velocidad de desarrollo.

Se aumenta la calidad.
Adems, la planificacin ser ms completa, creativa, efectiva y satisfar
mejor a todos.

A continuacin se considerarn brevemente

Personas

Todos los aspectos relacionados con las personas tienen un gran impacto
en la productividad del software y en su calidad.
La tecnologa exclusivamente no es la respuesta:

Los mtodos ms efectivos son aquellos que sacan partido al potencial humano
de los desarrolladores.

La mejora en la productividad conlleva ocuparse de temas relacionados con

el personal:
Motivacin.
Equipo de trabajo.
Seleccin de personal.
Formacin.
Gestin de personal.

Barry Boehm en su libro Software engineering economics (1981) propone:

Mximo talento: Usar poco y buen personal.

Trabajo adecuado: Explotar habilidades y motivar a la gente.
Progresin profesional: Actualizacin vs. encajonamiento y monotonicidad.
Equilibrado del equipo: Seleccionar a gente que se complemente y armonice con
los dems.
Eliminar inadaptacin: Reemplazar a los miembros problemticos del equipo lo
antes posible.

Proceso

Para la mejora de esta dimensin se debe considerar la aplicacin de:

Metodologas de desarrollo:

Gestin y planificacin de proyectos.

Myers en 1992 y Gibbs en 1994 ponen como ejemplos de mejora en el

proceso de desarrollo a:

Metodologas.
Estndares.
Procedimientos.
Tcnicas.
Herramientas CASE.

Hughes Aircraft.
Lockheed.
Motorola.
Nasa.
Xerox.

Dichas empresas:

Han reducido sus plazos de salida al mercado a la mitad.

Han reducido costes y errores (y por ende mantenimiento) en un factor de
3 a 10.

Producto

Ocuparse del tamao y caractersticas del producto software da

oportunidades de reducir la planificacin:

Intentar aplicar las reglas siguientes (sin tomarlas al pie de la letra):

Productos grandes: Ms tiempo; Productos pequeos: Menos tiempo.

Ms prestaciones: Ms anlisis, diseo, ms tiempo y costes.
80/20: Desarrollar el 80% del producto empleando el 20% del tiempo.
3x3: Desarrollar el producto en 3 meses trabajando 3 personas.

El
esfuerzo
para
construir
software
se
incrementa
desproporcionadamente ms rpido que el tamao del software.

La reduccin del tamao

desproporcionadamente:

mejorar

la

velocidad

del

desarrollo

Reducir a la mitad el tamao de un programa intermedio normalmente supone

una reduccin de al menos dos tercios del esfuerzo.

Objetivos ambiciosos de rendimiento, robustez y fiabilidad suponen

ms tiempo y ms costes. Esto lleva a:

Desarrollar slo las prestaciones esenciales.

Desarrollar el producto por etapas, incrementalmente.
Emplear lenguajes de alto nivel.
Emplear herramientas CASE, tcnicas y metodologas adecuadas.

Tecnologa

Se deben emplear herramientas efectivas en cada fase del proceso

software:

Herramientas CASE de anlisis y diseo.

Herramientas de pruebas.
L4G.
Etc.

Esto es, por ejemplo:

Requisite Pro vs. documentos (en el mejor de los casos).

Erwin, Bpwin vs. scripts o programar.
Reutilizacin vs. repeticin.
Delphi vs. ensamblador.
Etc.

Pilares fundamentales

Datos reales

Lederer y Prasad (en 1992) Gibbs (en 1994) y Standish Group (en
1994) identificaron que:

Capers Jones (en 1994) indic que:

Alrededor de dos tercios de todos los proyectos superan ampliamente sus

estimaciones.

Los grandes proyectos se retrasan en su fecha de entrega entre un 25% y

un 50% de su duracin.
El retraso medio se incrementa con el tamao del proyecto.

Symons (en 1991) y McConnell (en 1996) propusieron:

Desarrollo rpido (vs. desarrollo lento y tpico con largas planificaciones).

En definitiva, proyectos pequeos.

En un proyecto se debe evitar

Jefe:

Quiero desarrollar un producto preparado para el cambio. Deseo tener

en cuenta la calidad y futuras prestaciones, controlar su planificacin y
tener una fecha de entrega predecible.

Mente del tcnico:

La prioridad real es poner el producto a la venta lo antes posible.

Pero

Qu producto?: Da igual, ya vamos retrasados.

Usabilidad?: No hay tiempo.
Rendimiento?: Puede esperar.
Facilidad del mantenimiento?: Para la prxima.
Verificacin?: El producto es para ayer; hay que acabar como sea.

En definitiva, un proyecto debe comenzar (y hacerlo formalmente)

cuando se sepa lo que se quiere abordar a travs de ese proyecto
(i.e., lo que hay que hacer).

No cumplir esto suele ser origen de proyectos bola de nieve: productos

inicialmente muy sencillos (i.e., proyectos pequeos) cuya
funcionalidad se modific y ampli sin control, igual que su planificacin.

El camino a seguir es

Gestin y planificacin de proyectos.

Es un camino poco transitado, pero el ms concurrido es el que actualmente
redunda en:

Los beneficios, contrastados, que principalmente aporta son:

Controlar tiempos y costes del proyecto.

Proyectos de alta calidad.
Incrementar productividad al conocer capacidades y sobrecargas.
Reducir sensacin de incompetencia.
Mejora la imagen externa y seriedad en el trabajo.

Es un remedio a muchos males (no a todos) pero requiere:

Costes y retrasos masivos, incluso con proyectos cancelados.

Baja calidad.
Muchos cambios de personal y fricciones entre personas.
Etc.

Tiempo (de 3 a 4 aos).

Esfuerzo (de la direccin y de los trabajadores).
Formacin.
Herramientas de soporte.

Pero no hay otra solucin. Como dijo McConnell en 1996:

Las soluciones simples tienden a funcionar slo con problemas sencillos, y el desarrollo
de software no lo es.

Pilares fundamentales (I)

Se puede obtener un desarrollo rpido, econmico y de calidad

basndose en los cuatro pilares que McConnell propone en su libro
Desarrollo y gestin de proyectos informticos:

Pilares fundamentales (II)

Pero cuidado, porque ni los mtodos orientados a la planificacin ms

avanzados son capaces de soportar por ellos solos el mejor plan
posible:

Cometer errores clsicos, no actuar segn los buenos principios de

desarrollo o no gestionar los riesgos provocar retrasos y costes
asociados.

Estos tres pilares son la mayor parte de lo necesario para obtener el mejor
plan posible. La planificacin sola no sirve para nada.

Necesidad de los 3 primeros pilares

Pilar 1 Evitar errores clsicos:

El error clsico en desarrollo de software de descuidar la calidad del

proyecto en sus fases iniciales supone desperdiciar tiempo y dinero ms
adelante corrigiendo defectos, justo lo ms caro:

Pilar 2 Bases del desarrollo:

Si no se analiza, disea y codifica por ese orden y de forma adecuada, el

sistema fallar cuando cambie la concepcin del producto durante el
desarrollo:

Retraso en tiempo y aumento en costes.

Pilar 3 Gestin de riesgos:

Si no se controlan los riesgos se puede descubrir muy tarde que un

subcontratista , por ejemplo, se ha retrasado:

Retraso en tiempo y aumento en costes.

Retraso en tiempo y aumento en costes.

A continuacin se abordan estos pilares

Pilar 1: Evitar errores clsicos (I)

Todo influye en el desarrollo de software y un error puede dar al traste

con todo:

Pilar 1: Evitar errores clsicos (II)

Errores clsicos relacionados con las personas:

Motivacin dbil: Recompensas inadecuadas, no reconocimiento, horas

extras, ...
Personal mediocre: Contrataciones inadecuadas, personal problemtico,
Hitos: Slo fijarse en que se cumplan los hitos y no cmo va el proyecto da
a da.

Esto al final se percibe como un plan muy largo y malo.

Falta de participacin de los implicados.

Falta de participacin del usuario: Cuando no se implica al usuario desde el
principio, no se entienden ni se consideran sus requisitos.

Hay personas que se rigen exclusivamente por hitos: CUIDADO !!

Aadir ms personal a un proyecto retrasado.

Oficinas repletas y ruidosas: Se requiere silencio y privacidad.
Fricciones entre clientes/usuarios y desarrolladores.
Expectativas poco realistas: Los directivos suelen planificar de forma muy
optimista.

Esto originar retrasos y decepciones en el equipo de desarrollo.

Ilusiones y confianza en la bondad de destino: Se cree que el destino

deparar algo mejor de lo que se piensa.

Generalmente es justo lo contrario.

Pilar 1: Evitar errores clsicos (III)

Errores clsicos relacionados con el proceso:

Inicio difuso.
Escatimar en las actividades iniciales: Anlisis y diseo principalmente.
Control insuficiente de la direccin.
Programacin a destajo, sin mtodos tcnicas o estndares.
Omitir tareas necesarias en la estimacin.
Fallos en las subcontrataciones:

Optimista s, pero los retos suelen no cumplirse. Se acaba minando la moral y la

productividad.

Planificacin insuficiente.
Gestin de riesgos insuficiente.
Abandono de la planificacin bajo las presiones:

Los subcontratistas suelen entregar el trabajo tarde, deficiente y sin cumplir con las
especificaciones (as lo estudi Boehm en 1989).

Planificacin excesivamente optimista:

El fallo no es abandonar el plan. Es no crear un plan alternativo.

Hacer una gestin de requisitos poco cuidadosa:

Los problemas derivados de la comunicacin al establecer los requisitos son uno

de los mayores problemas como se puede ver irnicamente a continuacin:

Pilar 1: Evitar errores clsicos (IV)

Problemas de comunicacin entre usuarios y desarrolladores:

Lo que se quiere:

Lo que se disea:

Lo que se desarrolla:

Pilar 1: Evitar errores clsicos (V)

Problemas de comunicacin entre miembros del equipo de desarrollo:

1. Lo que el director desea.

2. Como lo define el director de

proyecto.

3. Como se disea el Sistema.

4. Como lo desarrolla el
programador.

5. Como se ha realizado la
instalacin.

6. Lo que el usuario quera.

Pilar 1: Evitar errores clsicos (VI)

Cada requisito una interpretacin:

Pilar 1: Evitar errores clsicos (VII)

Errores clsicos relacionados con el producto:

Desarrolladores meticulosos y fascinados por la tecnologa.

Desarrollo orientado a la investigacin:

No intentar sobrepasar los lmites de la ingeniera en ms de dos reas a la vez.

El riesgo de fallo es demasiado alto.

Cambios en las prestaciones:

Segn Capers Jones en 1994, como media hay un 20% de cambios en los
requisitos a lo largo del ciclo de vida de un proyecto.
Este porcentaje conlleva un 25% de aumento en el plan.

Exceso de requisitos: Slo los absolutamente necesarios:

Pilar 1: Evitar errores clsicos (VIII)

Errores clsicos relacionados con la tecnologa:

Sndrome de la panacea ante una tecnologa.

Sobreestimacin de las ventajas del empleo
herramientas o mtodos:

de

nuevas

Hay curvas de aprendizaje, las mejoras sern lentas,

Cambiar de herramientas o filosofa de desarrollo a mitad del

proyecto.

El ejemplo es claro si, por ejemplo, se pretende aplicar OO cuando el

anlisis se ha efectuado segn el paradigma estructurado.

Pilar 2: Bases del desarrollo (I)

Se puede planificar bien, pero no considerar los conceptos bsicos del

desarrollo de software supondr no alcanzar las metas planificadas.

Se ha observado (Burlton, 1992: Managing a RAD project: Critical

factors for success) que implantar la disciplina de la ingeniera del
software antes que la de gestin de proyectos es un fracaso:

Los mtodos fundamentales de ingeniera del software deben emplearse

porque reducen el coste y el tiempo de comercializacin.

Por eso a continuacin se aborda primeramente la gestin de proyectos y

luego el desarrollo de software propiamente dicho.

Con respecto a la gestin, sta controla la planificacin, el coste y el

producto y sus fundamentos consisten en:

Determinar el tamao del producto.

Asignar los recursos apropiados a un producto de ese tamao.
Crear un plan para poner en operacin esos recursos.
Controlar el plan dirigiendo los recursos para impedir desvos.

Pilar 2: Bases del desarrollo (II)

Los proyectos bien ejecutados pasan por tres etapas bsicas para
crear una planificacin software:

Estimacin y planificacin son las bases del desarrollo.

Una mala estimacin reduce eficiencia en el desarrollo.

Estimacin del tamao del producto.

Estimacin del esfuerzo necesario para un producto de ese tamao.
Realizacin de una planificacin, basndose en la estimacin del esfuerzo.

Una estimacin correcta es necesaria para una planificacin efectiva y un

desarrollo eficiente.

Para ello hay:

COCOMO.
Puntos (de) funcin o Function Points.
Etc.

Pilar 2: Bases del desarrollo (III)

Hetzel, en 1993, revis un grupo de los mejores proyectos seleccionados por las
propias empresas:

El 75% necesitan mejorar la supervisin y el seguimiento del proyecto.

Baumert, en 1995:

El control del proceso software es tan malo que muchos desastres software no se
conocen hasta el mismo da del despliegue esperado.

El SEI y Kitson y Masters, en 1993:

Debe hacerse un seguimiento del proyecto para comprobar que se est cumpliendo lo
previsto en objetivos de planificacin, coste y calidad.

En los mejores proyectos, Hetzel descubri que se haba hecho una estricta
medicin y seguimiento del estado del proyecto.
Capers Jones, en 1995:

Se encontr que los mejores se caracterizaban por una fuerte planificacin anticipada
para definir las tareas y programaciones.

Pero la planificacin no basta:

En las evaluaciones de las empresas, los principales problemas aparecen en las reas
de planificacin, seguimiento y supervisin del proyecto.

Se necesita el seguimiento:

Reuniones peridicas.
Informes peridicos sobre el estado del proyecto.
Revisiones de hitos.
Informes de presupuestos.

Pilar 2: Bases del desarrollo (IV)

Medidas o mtricas e histricos:

Una forma de progresar, a largo plazo, es recoger datos mtricos

para analizar la calidad y productividad del software.
Se deben recoger datos de:

Tamao de los programas (lneas de cdigo: LOC).

Planificacin.
Tiempo.
Costes.

Recoger ms datos puede suponer mucho tiempo.

Con los anteriores se tienen las bases para la planificacin de
proyectos futuros, que siempre es mejor que el instinto para
responder a preguntas del estilo:

Se puede desarrollar este producto en 3 meses?

Nunca hemos desarrollado un producto de ese tamao en menos de 11

meses y el tiempo medio es de 13 meses.

Pilar 2: Bases del desarrollo (V)

Con respecto al desarrollo software propiamente dicho:

La peor decisin es ahorrar tiempo reduciendo el poco tiempo que

ya se le dedica al anlisis, al diseo, a las revisiones de cdigo, a la
planificacin y a las pruebas.
Todo funcionar mejor si no se cometen los errores en el primer
paso.
Si un software tiene demasiados errores, se emplea ms tiempo
corrigindolo que escribindolo.

Gartner Group estim que en 1995 el 95% de los costes fueron a

mantenimiento.

Capers Jones:

IBM fue la primera compaa en descubrir que la calidad y la

planificacin del software estaban relacionadas.
Tambin descubrieron que los productos con el menor nmero de
defectos eran los que tenan una mejor planificacin.
El nmero de defectos (baja calidad) que se dan cuando los
programadores lanzan productos bajo una excesiva presin en la
planificacin es hasta 4 veces mayor.

Pilar 2: Bases del desarrollo (VI)

Conclusin: Seguir las instrucciones de uso, como en cualquier otro

mbito.

Por ejemplo:

Objetivo: Pintar la caseta del perro.

Pasos: Lectura de las instrucciones de la lata de pintura:

Si hay prisa, no se siguen las instrucciones y se va al paso 3 directamente

y sin dejar secar.

Preparar superficie.
Con superficie seca, aplicar capa fina a una temperatura entre 15 y 30C. Dejar
secar 2 horas.
Aplicar 2 capa fina y dejar 24 horas antes de utilizarla.

Si la caseta es de madera, no est muy sucia y el tiempo es bueno, puede que

todo vaya bien. Despus de unos pocos meses la pintura se agrietar y habr
que volver a pintar: ms costes y ms tiempo.

Qu pasara si fuese un boeing 747 y no se siguiesen las instrucciones?

Seguridad deficiente y eficiencia nula.

Adems, una capa de pintura de un 747 son de 200 a 400 kilos.
No preparar la superficie bien hara que el viento, a la velocidad de crucero, y la
lluvia atacasen la pintura.

Pilar 3: Gestin de riesgos (I)

Los proyectos de software incluyen un amplio rango de riesgos:

Probabilidades en el mundo real:

Cambios en los requisitos de usuario.

Falta de experiencia en la gestin.
Mala estimacin de la planificacin.
Personal contratado poco fiable y efectivo.
Problemas con la tecnologa, con el desarrollo y/o con los proveedores.
Etc.
De finalizar un proyecto complejo en el tiempo estimado: Tiende a 0.
De cancelar un proyecto complejo: Tiende a 0.5.

Peat Marwick, en 1988:

De 600 empresas, el 35% ha tenido al menos un proyecto que se le fue de

las manos.
Ejemplo:

Allstate comenz a automatizar en 1982 sus actividades administrativas.

Planificaron 5 aos y 8 millones.
6 aos ms tarde y 15 millones despus Allstate estableci una nueva fecha
lmite y estim 100 millones de dlares.

Tom Gilb: Si no controlas los riesgos, ellos te controlarn a ti.

Pilar 3: Gestin de riesgos (II)

La funcin de la gestin de riesgos es:

Identificar, estudiar y eliminar las fuentes de riesgo antes de que empiecen

a amenazar la finalizacin satisfactoria de un proyecto.

Segn Pressman, se pueden controlar los riesgos a varios niveles (si

se est en los niveles 1, 2 o 3 se ha perdido la batalla de la
planificacin):

Nivel 1: Control de crisis.

Planificar con antelacin el tiempo que se necesitara para cubrir riesgos en el

caso de que ocurran, pero no intentar eliminarlos inicialmente.

Nivel 4: Prevencin.

Detectar y reaccionar rpidamente ante cualquier riesgo, pero slo despus de

haberse producido.

Nivel 3: Mitigacin de riesgos.

Controlar los riesgos slo cuando se han convertido ya en problemas: Actuar de

bombero apagando el fuego.

Nivel 2: Arreglar cada error.

Crear y llevar a cabo un plan como parte del proyecto software para identificar
riesgos y evitar que se conviertan en problemas.

Nivel 5: Eliminacin de las causas principales.

Identificar y eliminar los factores que puedan hacer posible la presencia de algn
tipo de riesgo.

Pilar 3: Gestin de riesgos (III)

Segn Boehm, la gestin de riesgos se compone de:

Estimacin de riesgos:

Control de riesgos:

Identificacin de riesgos: Genera una lista de riesgos capaces de

romper la planificacin del proyecto.
Anlisis de riesgos: Mide la probabilidad y el impacto de cada riesgo, y
los niveles de riesgo de los mtodos alternativos.
Priorizacin de riesgos: Genera una lista de riesgos ordenados por su
impacto.
Planificacin de la gestin de riesgos: Genera un plan para tratar cada
riesgo significativo. Tambin asegura que los planes para la gestin de
riesgos de cada uno de ellos son consistentes entre s y con el plan del
proyecto.
Resolucin de riesgos: Es la ejecucin del plan para resolver cada uno
de los riesgos significativos.
Monitorizacin de riesgos: Es la actividad del progreso de la
monitorizacin dirigido a la resolucin de cada elemento del riesgo.

A continuacin se vern brevemente estas fases

Pilar 3: Gestin de riesgos (IV)

Identificacin de riesgos:

Los riesgos se parecen mucho a los errores clsicos ya

mencionados.
La diferencia es:

Los errores clsicos se cometen con mayor frecuencia que

los riesgos.
Los riesgos son menos comunes o pueden ser nicos para
un proyecto determinado.

Steve McConnell recopila en su libro Desarrollo y

gestin de proyectos informticos los riesgos ms
habituales en planificacin y los riesgos potenciales de
la planificacin.

Pilar 3: Gestin de riesgos (V)

Anlisis de riesgos:

Una vez identificados, el paso siguiente es analizar

cada riesgo para determinar su impacto.
Para cada riesgo, determinar su exposicin al riesgo:

ER = probabilidad de prdida no esperada x magnitud de

prdida, donde riesgo = prdida no esperada.

Las probabilidades y las magnitudes de prdida hay que

estimarlas, sin pretender ser exactos.
Si slo se quieren los riesgos de planificacin, las
prdidas se expresan en unidades de tiempo.
Si se suman todas las ER, se obtiene el retraso total del
proyecto y se podra emplear para ajustar la planificacin
con un margen de retraso.

Steve McConnell presenta ejemplos de estimacin de

riesgos en su libro ya mencionado.

Pilar 3: Gestin de riesgos (VI)

Priorizacin de riesgos:

Los proyectos suelen gastar el 80% de su presupuesto

en arreglar el 20% de sus problemas.
Conclusin:

Centrase, fundamentalmente, en ese 20%.

Se pueden ordenar los riesgos por su ER y as saber

cules controlar para compensar esfuerzo y reduccin
en tiempo de los riesgos.
Steve McConnell presenta ejemplos de priorizacin de
riesgos en su libro ya mencionado donde se aprecia:

Mayor utilidad al controlar unos riesgos que otros.

Necesidad de controlar riesgos especialmente dolorosos.

Pilar 3: Gestin de riesgos (VII)

Planificacin de la gestin de riesgos:

El plan de gestin de riesgos puede ser tan sencillo

como un prrafo para cada riesgo describiendo:

Quin.
Qu.
Cundo.
Cmo.

Pilar 3: Gestin de riesgos (VIII)

Resolucin de riesgos:

Depende del riesgo especfico que se est tratando.

Algunas posibles acciones son:

Evitar el riesgo: No realizar actividades arriesgadas.

Trasladar el riesgo de una parte del sistema a otra:
Expertos en una materia supervisan a los noveles y que el
riesgo no est en el camino crtico de la planificacin.
Informarse del riesgo: Conocerlo mejor y ver si es o no
posible.
Asumir el riesgo: Si las consecuencias son pequeas y el
esfuerzo grande.
Comunicar: Comunicar el posible impacto de un riesgo en
caso de ocurrir.
Controlar el riesgo: Planificar acciones en caso de ocurrir.
Recordar el riesgo: Para proyectos futuros.

Pilar 3: Gestin de riesgos (IX)

Monitorizacin de riesgos:

Los riesgos aparecen y desaparecen en el desarrollo

del proyecto.
Por ello se necesita una monitorizacin de riesgos que
permita:

Comprobar cmo progresa el control de un riesgo.

Identificar cmo aparecen los nuevos riesgos.

Pilar 4: Mtodos orientados a la

planificacin

Uno de los aspectos ms importantes (si no el ms) para llevar a cabo

una buena planificacin es la estimacin.

Ms adelante se vern mtodos orientados a realizar la planificacin de un

proyecto, pero ahora se abordar la estimacin.

Debe existir una valoracin de la viabilidad tcnica y la inversin detallada,

con el coste y los plazos manejados.

Es decir, es necesaria la estimacin del nuevo proyecto.

Sin embargo, la credibilidad de la estimacin en los proyectos suele
ser baja. En un estudio de Capers Jones de 1994:

Es el primer paso para poder efectuar un plan de proyecto.

Cualquier proyecto debe justificarse, bien por ahorro en costes de

operacin, expansin del negocio, etc.

5% cumplen presupuesto.
10% lo exceden en un 10%.
20% lo exceden en un 25%.
30% lo exceden en un 50%.
35% lo exceden en un 100% o ms.

Una buena regla sera que los beneficios esperados superasen en al

menos 5 veces los costes previstos.

Estimacin (I)

Estimacin es la actividad que permite obtener respuesta a:

Cunto costar?
Cunto tiempo llevar hacerlo?

Las dificultades de una estimacin son, entre otras:

No hay un modelo de cmo hacerla en todas las organizaciones.

Se necesitan diferentes estimaciones para las diferentes personas que hay
en un proyecto (alta direccin, direccin del proyecto y cada recurso).
La utilidad de una estimacin depende de la etapa de desarrollo en que se
est:

Se precisa de diferente grado de exactitud a medida que avanza el proyecto.

Se suele hacer muy superficialmente y bajo presin.

Hay muchos cambios y la informacin de partida es muy vaga a veces.
Los rpidos cambios en las tecnologas de informacin son problemas para
la estabilidad de un proceso de estimacin.
Escasez de histricos y experiencia en estimar proyectos.
Tendencia a subestimar, ignorando aspectos no lineales como
coordinacin y gestin.

Es considerada por muchos la actividad ms difcil en gestin de

proyectos, porque

Estimacin (II)

Como indica Steve McConnell, es muy difcil saber si es posible

construir el producto que el cliente desea en el tiempo esperado hasta
que se comprenda perfectamente lo que quiere:

Estimacin (III)

Ciertamente es una tarea muy difcil.

Pero es una tarea imprescindible en planificacin.

El proceso para planificar un desarrollo consta de tres

pasos bsicos fundamentales:

Estimar el tamao del producto:

Es el paso ms difcil con diferencia.

Estimar el esfuerzo asociado a un producto de dicho tamao:

Se puede hacer, por ejemplo, a travs del nmero de lneas de

cdigo (LOC) o por puntos funcin.

Si hay una buena estimacin del tamao y un histrico de la

organizacin en proyectos similares, es relativamente fcil.

Estimar la planificacin:

Estimados tamao y esfuerzo, esta estimacin es fcil.

Estimacin (IV)

Estimacin del tamao:

Se puede estimar el tamao de un proyecto de

varias formas:

Utilizar un enfoque algortmico (e.g., puntos de

funcin) para estimar el tamao del programa a partir
de sus prestaciones.
Utilizar un software de estimacin, a partir de la
descripcin de las prestaciones del programa
(pantallas, informes, archivos, consultas, tablas de la
BD, ...).
Emplear experiencias en proyectos similares.

Estimacin (V)

Estimacin del esfuerzo:

Obtenida la estimacin del tamao se puede derivar

la estimacin del esfuerzo.
Esta estimacin ayudar a:

Saber cuntas personas hay que incorporar al

proyecto.
Estimar la planificacin.

Para convertir la estimacin del tamao en la del

esfuerzo existen varias posibilidades:

Emplear software de estimacin.

Emplear tablas de conversin tamao-esfuerzo.
Emplear histricos.
Emplear mtodos algortmicos de aproximacin como
el COCOMO de Boehm.

Estimacin (VI)

Estimacin de la planificacin:

Una regla muy usada y con pocas variantes para

calcular la estimacin de la planificacin a partir de
la estimacin del esfuerzo es:

Planificacin (meses) = 3*personas-mes estimadas1/3

Ejemplo:

Si se ha estimado que seran necesarias 65

personas-mes para un proyecto, la ecuacin
establece que la planificacin ptima es de 12 meses
(=3*651/3). Esto implica un tamao ptimo del equipo
de 65 personas-mes/12 meses: un equipo con 5 o 6
miembros.

Estimacin (VII)

Relacin entre tamao y esfuerzo:

Un aspecto a tener en cuenta a lo largo del ciclo de vida y de las sucesivas

estimaciones es la relacin existente entre el tamao del software y el
esfuerzo (y la duracin).
Debido al incremento de esfuerzo de intercomunicacin entre las personas
que componen el equipo de desarrollo a medida que ste crece, no existe
una relacin lineal entre tamao y esfuerzo, ni entre tamao y duracin y
tampoco entre esfuerzo y duracin.
El ejemplo claro se puede ver al hilo de la frmula anterior o al manejar el
modelo COCOMO.

Estimacin (VIII)

Estimacin dentro del desarrollo:

Se escalona a lo largo de varios puntos (referencias) dentro

del ciclo de vida:

Referencia 0: Cuando se realiza la oferta.

Referencia 1: Al principio de la fase de especificacin.

Se elabora una nueva estimacin, que constituye el presupuesto de

desarrollo (versin inicial), considerando la informacin aportada por
el cliente y las tcnicas elegidas en la oferta para desarrollar el
producto.

Referencia 2: Al concluir la fase de especificacin.

Se procede a una primera estimacin para dar un presupuesto

inicial.

Se afina el presupuesto previo con las precisiones aportadas por el

contenido funcional y operacional del producto y la naturaleza
organizativa del proyecto. Es el presupuesto de desarrollo (versin
final).

Referencia 3: Al concluir la fase de diseo de arquitectura.

Constituye el presupuesto final. Tras definir la arquitectura se tiene

mucho ms conocimiento para hacer ya una estimacin definitiva.

Juicio de expertos

Es una tcnica de estimacin que se suele emplear bastante.

Segn Barbara Kitchenham, su nombre es un eufemismo de
adivinacin basada en la experiencia personal.
Existen tcnicas especficas que intentan sistematizar y mejorar la
opinin de las distintas personas involucradas (expertos).
Se suele manejar la opinin de ms de un experto para una mayor
fiabilidad.

Ejemplo: Calcular la media de las estimaciones dadas por los expertos.

Riesgo: La estimacin as obtenida puede resentirse de valores extremos.

Ejemplo: Efectuar una reunin ininterrumpida hasta llegar a un consenso.

Riesgo: Las personas ms influyentes, por su capacidad o poder de persuasin,
determinan el resultado final.

La tcnica ms conocida es Delphi:

Creada en los aos cuarenta en EEUU.

Difundida en el mbito del software por Barry Boehm.
La mecnica de la tcnica es la siguiente:

Delphi

Un coordinador proporciona a cada experto una especificacin del

proyecto considerado y un impreso para expresar su estimacin.
Todos los expertos rellenan el impreso de forma annima.

Se pide realizar una nueva estimacin (annima), indicando las posibles

razones de la misma.

Se repite el proceso de recogida de estimaciones hasta llegar a un

consenso en la estimacin.

Pueden hacer preguntas al coordinador sobre el proyecto.

No pueden intercambiar opiniones entre ellos.

El coordinador ofrece a cada experto el valor medio de todas las

estimaciones para que la compare con la suya.

No se realizan reuniones en grupo durante todo el proceso.

Boehm propuso una variacin, llamada Delphi de banda ancha, que da

mejores resultados. Consiste en lo siguiente :

Delphi de banda ancha

Un coordinador proporciona a cada experto una especificacin del

proyecto considerado y un impreso para expresar su estimacin.
El coordinador rene a los expertos para que intercambien puntos de
vista sobre el proyecto.
Todos los expertos rellenan el impreso de forma annima.
El coordinador ofrece a cada experto el valor medio de todas las
estimaciones para que la compare con la suya.

Ventajas:

Se pide realizar una nueva estimacin (annima), sin indicar las posibles
razones de la misma.

El coordinador convoca una reunin de grupo para que los expertos

discutan las razones de las diferencias entre sus estimaciones.
Se repite el proceso de recogida de estimaciones hasta llegar a un
consenso.

Permite considerar diferencias entre experiencias pasadas y el proyecto

actual difciles de evaluar sin recurrir a personas experimentadas.

Inconvenientes:

Los consultados pueden expresar una estimacin subjetiva e inexperta.

Estimacin por analoga

Consiste en una variante formal de la tcnica de juicio de expertos:

Las personas involucradas no slo trabajan aqu con su experiencia

acumulada (juicio de expertos), sino que tambin disponen de datos
de proyectos acabados relativamente similares al que hay que estimar.
As, por comparacin, se pueden evaluar las diferencias entre el nuevo
proyecto y los antiguos y extrapolar su estimacin.
Esta tcnica mejora sus resultados segn se disponga de ms datos
de proyectos terminados.
Ventajas:

Se compara el proyecto que se va a desarrollar con uno o ms proyectos

ya terminados de los que existen datos reales recopilados a posteriori.
En funcin de las similitudes y diferencias con dichos proyectos se deduce
la estimacin para el nuevo desarrollo.

Se considera la experiencia real (no slo la subjetiva) en los proyectos.

Inconvenientes:

Es difcil conocer el grado de similitud real del proyecto que se estima con
los elegidos.

Estimacin por descomposicin

Tambin se denomina estimacin por jerarqua de componentes o

analytic hierarchy process.
Consiste en descomponer el producto que se va a desarrollar en sus
componentes (o el proyecto en tareas sencillas) hasta un nivel de
detalle tal que permita estimar directamente cada una de dichas
unidades elementales.
La estimacin total del proyecto ser el resultado de sumar de forma
bottom-up las estimaciones parciales de todas las unidades.
Para poder aplicar esta tcnica con una mnima eficacia se necesita
disponer de un diagrama de descomposicin.

Ventajas:

Lo ms habitual es contar con una WBS, que suele crearse en la

planificacin del proyecto.

Muy intuitiva y permite comprender mejor la tarea (o el producto) a

desarrollar.

Inconvenientes:

Olvidos de actividades (o subproductos) que, por tanto, no se estimarn.

Inclusin de actividades que no son propias del proyecto.

Modelo COCOMO (I)

COnstructive COst MOdel fue publicado por Barry W. Boehm en 1981.

Es un modelo de estimacin basado en ecuaciones no lineales obtenidas
mediante tcnicas de regresin sobre un histrico de proyectos ya terminados.
El mtodo considera tres variables:

Se distinguen tres modos debidos a las tres categoras de proyectos

considerados:

Proyectos orgnicos (organic projects).

Proyectos medianos (semidetached projects).
Proyectos complejos (embedded projects).

A cada categora de proyecto se asocian dos ecuaciones en la forma:

Tamao del software a desarrollar (medido en KLOC): Dato a estimar (en miles).
Esfuerzo del equipo de desarrollo (expresado en personas-mes).
Duracin del proyecto (expresada en meses).

Esfuerzo = A * (Tamao B).

Duracin = C * (Esfuerzo D).
Cada categora de proyecto posee sus propias constantes A, B, C y D.

Se pueden aplicar tres versiones de estimacin o modelos segn el estado

en que se encuentre el desarrollo del proyecto:

Bsico.
Intermedio.
Detallado.

Modelo COCOMO (II)

La entrada al modelo COCOMO es el tamao del software expresado

en miles de lneas de cdigo fuente.
Para contarlas/estimarlas deben seguirse las mismas reglas
predefinidas para todos los proyectos: Hay que establecer un
estndar.
Un conjunto de dichas reglas podra ser:

Contar toda lnea escrita nueva o modificada.

No contar, salvo que tengan un carcter definitivo, las lneas para la
instrumentacin del cdigo (e.g., para las pruebas).
Contar las lneas de los programas de prueba tan slo si se desarrollan con
el mismo nivel de calidad exigido al producto.
Contar las lneas correspondientes a los procedimientos de comandos del
sistema operativo y JCLs (Job Control Language).
No considerar los comentarios (el modelo ya los considera siempre que no
sobrepasen un 10% del tamao global).
Contar como una lnea cada ocurrencia de macro, copy o include.
Contar slo una vez el cdigo generado por las macros, copy o include.
Si se utilizan varios lenguajes de programacin para un mismo proyecto, se
deben fijar las estimaciones refirindose a un solo lenguaje y corregir el

Modelo COCOMO (III)

Para cada uno de los tipos de proyecto identificados en COCOMO difiere la

productividad y, por ende, las ecuaciones propuestas para calcular esfuerzo y duracin:


Las constantes A, B, C y D son propias de cada categora de proyecto.
Los proyectos orgnicos se caracterizan por:


Dominio de la aplicacin perfectamente conocido por todos los miembros del equipo.


Pocas restricciones operacionales, de interfaz o de rendimiento.


Entorno de desarrollo estable, sin material nuevo, ni procedimientos operacionales
novedosos.


Pocas innovaciones en la arquitectura del software o en los algoritmos para el tratamiento.


Organizacin del proyecto simple.
Los proyectos medianos se caracterizan por:


Equipos formados por personas expertas e inexpertas en el dominio de la aplicacin.


Restricciones operacionales, de interfaces o de rendimiento severas para ciertos aspectos
y fciles para otros.


Entorno de desarrollo inestable.


Organizacin del proyecto de complejidad mediana.


Esta categora incluye los proyectos que no se pueden encuadrar en las otras dos.
Los proyectos complejos se caracterizan por:


Grandes restricciones operacionales, de interfaces o de rendimiento.


Suelen ser sistemas hardware/software complejos con influencia clara de la seguridad o
tiempo real.


La especificacin y/o arquitectura son nuevos o complejos.


Organizacin del proyecto de complejidad alta.

Modelo COCOMO (IV)

Las constantes A, B, C y D son las siguientes:

Proyectos orgnicos:

Proyectos medianos:

A: 3.
B: 1.12.
C: 2.5.
D: 0.35.

Proyectos complejos:

A: 2.4 (Para COCOMO Intermedio: 3.2).

B: 1.05.
C: 2.5.
D: 0.38.

A: 3.6 (Para COCOMO Intermedio: 2.8).

B: 1.2.
C: 2.5.
D: 0.32.

Obsrvese que los valores de C y D son muy similares a los de la frmula

genrica que se vio para estimar la duracin a partir del esfuerzo en la
introduccin del apartado de estimacin.

Modelo COCOMO (V)

COCOMO Bsico:

Permite una primera estimacin durante la fase de anlisis previo, cuando la

mayora de los factores que incidirn en el proyecto se desconocen.
Slo parte de las KLOC previstas para dar una estimacin en cuanto al orden de
magnitud del esfuerzo.

COCOMO Intermedio:

Se aplica cuando el proyecto ha sido dividido en subsistemas.

Los valores de la constante A se ven afectados.
Permite considerar las caractersticas ms significativas del proyecto mediante la
aplicacin de factores correctores relativos a atributos del producto software y de
recursos (materiales, mtodos y personal) que influyen significativamente sobre la
productividad y que conciernen a:

Para considerar estos aspectos, Boehm identifica y cuantifica 15 factores que

permiten corregir el esfuerzo estimado:

Esfuerzo = A * (Tamao B) * m; siendo m = fj (j=115).

Ejemplos de dichos factores:

Exigencias particulares que debe cumplir el software.

El entorno (plataforma) empleado durante el desarrollo.
La aptitud y competencia de los equipos de desarrollo.
El contexto tcnico y organizativo del proyecto.

Experiencia en el lenguaje de programacin y Experiencia en el dominio de aplicacin.

COCOMO Detallado:

Distribuye el esfuerzo corregido entre las fases del proyecto y sus actividades
principales con base en unas tablas de distribucin proporcionadas por este modelo.

Modelo COCOMO (VI)

Los supuestos que COCOMO asume son:

La base de la estimacin es el nmero de instrucciones de cdigo fuente

(excluyendo comentarios y en miles) que ser necesario escribir para
desarrollar el proyecto.

Uso de un modelo de desarrollo en Cascada.

19 das/mes * 8 horas/da.

Presupone que se hace una correcta planificacin y gestin, se sigue una

metodologa, etc.

Las actividades de especificacin se debern estimar por separado.

El modelo de referencia de Boehm considera 152 horas de trabajo

efectivo/mes:

Si el proyecto bajo estudio se ejecuta usando otro modelo, los porcentajes de

distribucin deben reinterpretarse o no deben ser considerados.

La estimacin del esfuerzo obtenida mediante COCOMO abarca desde la

fase de diseo hasta las pruebas internas inclusive.

En C y PASCAL una aproximacin sera el nmero de ;.

Ms de una lnea fsica para una sentencia es una lnea de cdigo.
OJO: No son lo mismo para ensamblador que para Java.

Si no es as las estimaciones sufrirn desviaciones importantes (escasa utilidad).

Los factores correctores son independientes entre s (no influyen unos en

Modelo COCOMO II

Boehm y un equipo de colaboradores, fundamentalmente en la

University of Southern California, actualizaron y mejoraron el modelo
COCOMO a mediados de los 90: El resultado es el nuevo modelo
COCOMO II (http://sunset.usc.edu/research/COCOMOII/).
All igual que su predecesor, COCOMO II es en realidad una jerarqua
de modelos de estimacin que se emplean en funcin de la fase de
desarrollo en la que se desea estimar:

Modelo de composicin de aplicacin:

Modelo de diseo temprano:

Se emplea durante las primeras etapas, cuando es fundamental la elaboracin

de prototipos, la consideracin de la interaccin del software y el sistema, la
valoracin del desempeo y la evaluacin de la madurez de la tecnologa.
La estimacin de tamao se basa en puntos objeto (similar al concepto de puntos
de funcin).
Se emplea una vez que se han estabilizado los requisitos y se ha establecido la
arquitectura bsica del software.
La estimacin de tamao se basa en puntos de funcin no ajustados.

Modelo Post-arquitectura:

Se emplea durante la construccin del software.

Se basa en convertir los puntos de funcin no ajustados a KLOC para aplicar un
modelo parecido al COCOMO original donde los factores correctores se han

Puntos de funcin (I)

El mtodo de estimacin por puntos de funcin se denomina FPA:

Puntos de funcin es una mtrica sinttica del tamao del programa que
cuantifica la funcionalidad que hay que entregar al usuario.

Existen diferentes mtodos para contabilizar puntos de funcin.

Function Point Analysis (Anlisis de Puntos de Funcin).

Este mtodo no se basa en las LOC, sino en los puntos de funcin:

La propuesta inicial fue realizada por Allan J. Albrecht en 1979.

Los puntos de funcin son ms fciles de determinar a partir de la

especificacin de requisitos que las LOC y dan una medida ms
exacta sobre el tamao.

Todas las variedades de FPA se apoyan en datos que implican

preferentemente la existencia de una especificacin de requisitos
relativamente formalizada.

Se requiere de un mnimo conocimiento de las funcionalidades y entidades que

intervienen.

Aqu se describir brevemente un mtodo basado en el 1984 IBM

Method, que es la base de:

El mtodo actual de IBM.

El mtodo del International Function Point Users Group.

Puntos de funcin (II)

El nmero de puntos de funcin en un sistema/programa se basa en el

nmero y la complejidad de:

Entradas externas:

Salidas externas:

Son entradas que generan una salida simple e inmediata. Son consecuencia de una
bsqueda y no una actualizacin de un grupo lgico de datos internos.
Se identificar la complejidad de la parte correspondiente a las entradas externas y de la
parte correspondiente a las salidas externas, seleccionndose la ms compleja de las dos
para signar su complejidad.

Archivos lgicos internos o grupos lgicos de datos internos:

Grupos lgicos de datos o mandatos de control a un usuario final o a cualquier otro programa
que salen de la aplicacin. Una salida es nica si difiere en su formato o si es generada por
procesos lgicos diferentes.

Consultas externas:

Grupos lgicos de datos o mandatos de control de un usuario final o cualquier otro programa
que entran en la aplicacin y aaden o cambian informacin en un grupo lgico de datos
interno. Una entrada es nica si difiere en su formato o arranca procesos diferentes.

Grupos lgicos de datos o informacin de control interna que se generan, son usados y
mantiene la aplicacin. No deben incluirse aquellos grupos lgicos de datos que no sean
accesibles a travs de entradas, salidas, ficheros de interfaz o consultas.

Archivos de interfaz externos o grupos lgicos de datos de interfaz:

Grupos lgicos de datos compartidos con otra aplicacin, recibidos o enviados a ella. Los
grupos lgicos internos que son a su vez interfaz deben contarse en ambos grupos.

Puntos de funcin (III)

Para calcular el nmero de puntos de funcin en un sistema/programa se toma

el elemento y se multiplica por el peso indicado en la tabla:
Parmetro
Entradas
Salidas
Consultas
Archivos lgicos internos
Archivos de interfaz externos

Complejidad
alta
x6
x7
x6
x 15
x 10

Factor de ajuste = (0.01 x factores de complejidad) + 0.65.

Ejemplos de factores de complejidad:

Complejidad
media
x4
x5
x4
x 10
x7

La suma de estos nmeros da el total de los puntos de funcin no ajustados.

Despus se calcula un factor de ajuste de complejidad basado en la influencia
que tienen 14 factores sobre el proyecto, valorados en una escala de 0 a 5.

Complejidad
baja
x3
x4
x3
x7
x5

Comunicaciones de datos.
Entrada on-line de datos.
Complejidad del procesamiento.

Se multiplican ambos valores para obtener la suma total de los puntos de

funcin.

El intervalo de este factor de ajuste es de 0.65 a 1.35 ( 35% de variacin).

Puntos de funcin (IV)

Las caractersticas ms destacables de esta tcnica son:

El resultado de esta tcnica se expresa en puntos de funcin, que

posteriormente han de ser pasados a una mtrica de esfuerzo.

Esta traduccin s tiene en cuenta la experiencia y el estilo de

programacin, la aplicacin de una u otra metodologa y la tecnologa.

Este clculo de das de esfuerzo por punto de funcin debe basarse

en histricos, debiendo actualizarse el valor de conversin con
posterioridad a la finalizacin de cada proyecto.

Independencia del entorno tecnolgico de desarrollo.

Independencia de la metodologa que vaya a ser empleada.
Independencia de la experiencia y del estilo de programacin.
Fcilmente entendible por el usuario.

Hay incluso aproximaciones (e.g., Capers Jones) que establecen una

equivalencia entre puntos de funcin y LOC en ciertos lenguajes.

Con el nmero de puntos de funcin se puede comparar el tamao y la

planificacin de proyectos anteriores y se podra estimar una
planificacin a partir de stos.
Otra posibilidad es emplear el mtodo de estimacin de primer orden
de Jones, que se ver ms adelante.

Puntos de funcin (V)

Las variantes ms destacables de esta tcnica son:

En 1985 se crea una nueva versin como parte del modelo de

estimacin de la empresa de Capers Jones.

En 1986 dicha empresa crea otra variedad especialmente adaptada

a aplicaciones de tiempo-real y de software de sistemas.

Cuentan con un factor ms de complejidad pero no requieren catalogar

cada uno de los parmetros de los puntos de funcin no ajustados
segn su complejidad.

Esta variedad se denomina puntos de caractersticas y aade la

contabilizacin y la evaluacin de los algoritmos que se deben emplear
en el sistema a construir.

El mtodo MARK II es una evolucin que contempla el sistema

como una coleccin de transacciones lgicas compuestas por
componentes de entrada, de proceso y de salida.

Estas transacciones lgicas se corresponden exactamente con las

funciones del sistema y es necesario conocer:

Las entidades que intervienen, los tipos de datos de entrada y los de salida.
Si se trata de una funcin por lotes o en lnea.
Si se van a emplear lenguajes 3GL o 4GL.

Estimacin de primer orden de Jones

Es un mtodo desarrollado por Capers Jones.

Si se tiene la suma total de todos los puntos de funcin, este mtodo
permite realizar a partir de ellos un clculo aproximado de la
planificacin (duracin del proyecto en meses).
Consiste en tomar el total de los puntos de funcin y elevarlo a la
potencia apropiada seleccionada de la tabla siguiente:

Clase de software
Sistemas
Gestin
Prt--porter

Mejor caso
0.43
0.41
0.39

Media
0.45
0.43
0.42

Peor caso
0.48
0.46
0.45

Esta tabla de potencias surge del anlisis de su base de datos de

miles de proyectos.
En la tabla se cruza el tipo de software desarrollado con el tipo de
empresa (media, muy organizada y poco organizada).
No es la mejor forma de estimar la planificacin, pero da una primera
aproximacin (mucho mejor que hacerlo a ojo).

Crticas a los modelos de estimacin

Los modelos de estimacin no son la panacea:

Los que dependen de LOC suponen calcular de alguna manera ese dato.

La solucin es adaptar dichos modelos a cada empresa, pero esto puede implicar
tanto esfuerzo como crear un nuevo modelo.

Los factores correctores siempre son difciles de cuantificar y se

consideran independientes, aunque no necesariamente lo son.

El problema es que la cantidad y representatividad de los proyectos no es todo lo

amplia que sera de desear.

Segn diversos estudios, los modelos pierden bastante precisin al

utilizarse en entornos distintos a los que los originaron.

La adivinacin o deduccin por expertos de este valor es muy compleja.

La aplicacin de los puntos de funcin presenta problemas como la

duplicacin de la influencia de factores correctores si se parte de ellos para
calcular LOC, como entrada por ejemplo al modelo COCOMO.
Todos los modelos han surgido del anlisis estadstico de datos.

En muchos casos, aunque hay guas para aplicar de manera uniforme y

consistente los modelos, existe un alto grado de subjetividad.

Los modelos tienen un cierto margen de error que, en algunos casos, es

aceptable (mximo 25% de error sobre el valor final en un 75% de los
casos) aunque, lamentablemente, en otros llega a cifras muy malas (en
algunos estudios desde el 85% al 700% de error).

Recomendaciones

La estimacin se debe basar en el desarrollo de modelos y procedimientos de

estimacin apropiados y adaptados a las caractersticas de cada organizacin:

Esto significa que hay que recoger datos de los proyectos y crear procedimientos de
estimacin que puedan modificarse segn se analizan dichos datos.

En general, no es bueno ceirse a un solo mtodo de estimacin.

El enfoque recomendado consiste en:

Las primeras estimaciones (para negociar contratos disponiendo de poca informacin)

deberan apoyarse en el juicio de expertos con tcnica Delphi, preferentemente
basadas en analogas con datos fiables de proyectos propios.

Una vez que existen especificaciones medianamente detalladas y se puede medir su

tamao, hay que evaluar cada caso:

Recomendacin: Un grupo ms o menos permanente de expertos dedicados a la estimacin.

Ventaja: Estimaciones ms homogneas, que reflejan menos prejuicios o preferencias
personales, y que las personas acumulan experiencia y formacin.

Si el proyecto no es parecido a los asiduos en la organizacin o se desea contrastar las

ecuaciones de estimacin, pueden ser necesarias la estimacin a travs de expertos y la
analoga.
Sin embargo, lo ms normal es aplicar modelos o ecuaciones de estimacin.

Conviene aplicar modelos o ecuaciones locales, es decir, no tomar sin ms modelos

desarrollados en otros entornos u organizaciones.

Es preferible adaptarlos o crear ecuaciones propias.

Lo ideal es trabajar con modelos cuyos parmetros se puedan medir con facilidad en nuestra
organizacin e, incluso, con ecuaciones diferentes y adaptadas a cada fase del desarrollo.