Este documento trata sobre la gestión de proyectos de software. Explica que la gestión eficaz de un proyecto de software se centra en cuatro áreas clave: personal, producto, proceso y proyecto. También describe los roles clave en un proyecto de software y métodos para estimar costos, esfuerzos y plazos, incluyendo el modelo COCOMO.

1. Ingeniería de Software
Profesora Pilar Pardo Hidalgo
pilar.pardo02@inacapmail.cl

2. GESTION DE PROYECTOS
La gestión eficaz de un Proyecto de SW
se centra en “4 P”
Personal Producto Proceso Proyecto

3. Gestores Superiores: Definen los aspectos de negocios que a menudo
tienen una significativa influencia en el proyecto.
Gestores del Proyecto: Son los que planifican, motivan, organizan y
controlan a los profesionales que realizan el trabajo.
Profesionales: Son los que proporcionan las capacidades técnicas
necesarias para la ingeniería de un producto o aplicación.
Clientes: Son los que especifican los requisitos del proyecto.
Usuarios finales: Son los que interactúan con el producto entregado.
PERSONAL
Los participantes que colaboran en el Proceso de SW se pueden clasificar en:

4. PRODUCTO
Antes de Planificar un proyecto se deben establecer:
 Objetivos
 Ámbito del Producto
 Soluciones alternativas
 Dificultades Técnicas
 Dificultades de Gestión
Sin ésta
información es
imposible definir
 Estimaciones de Costo
 Valorización del Riesgo
 Planificación del Proyecto

5. PROCESO
Lo definiremos como un marco de trabajo de las tareas
que se requieren para desarrollar Software
de Alta Calidad.

6. Todos los Proyectos de Software deben ser
PLANIFICADOS Y CONTROLADOS
por una razón principal:
Poder manejar su complejidad
PROYECTO

7.  El ámbito del trabajo a realizar.
 Los riesgos en que se puede incurrir.
 Recursos requeridos
 Tareas a llevar a cabo
 El costo presupuestado
 Plan a seguir.
Es el Primer Nivel del Proceso de Ingeniería del Software
y cubre TODO el proceso de desarrollo desde el comienzo al fin.
Para alcanzar un PROYECTO EXITOSO se debe comprender:

8. Profesora Pilar Pardo Hidalgo
profesora@pilarpardo.cl

9. METRICAS
Hay 4 razones para Medir: Los Procesos de SW, Los Productos y los Recursos.
Caracterizar
Para comprender mejor los: Procesos, Productos, Recursos, Entorno y de esta
forma establecer las líneas bases para las comparaciones con evaluaciones futuras.
Evaluar
Las medidas nos permiten conocer cuando nuestros Proyectos y Procesos están
perdiendo la pista de modo que podamos ponerlos bajo control.
Predecir
Predecimos para poder planificar. Queremos establecer objetivos Alcanzables en
cuanto a Costo, Planificación y Calidad. Las proyecciones y las estimaciones
basadas en datos históricos también nos ayudan a predecir riesgos.
Mejorar :
Medimos para mejorar. Cuando recogemos información cuantitativa podemos
identificar obstáculos , problemas de raíz, ineficiencias y otras oportunidades para
mejorar la Calidad del Producto y el rendimiento del Proceso.

10. MEDIDAS, METRICAS E
INDICADORES
Proporciona una Estimación Cuantitativa de:
La Cantidad, Extensión, Dimensión, Capacidad o Tamaño
de algunos atributos de un Producto o Proceso
Un INGENIERO DE SW recopila MEDIDAS y desarrolla METRICAS
para obtener INDICADORES.
MEDIDA
MEDICION Es el acto de determinar una medida.
METRICA
Es una medida cuantitativa del grado en que un sistema,
componente o proceso posee un atributo dado.
Proporciona una visión profunda que permite al gestor de
proyectos ajustar el proceso, el proyecto o el producto para que
las cosas salgan mejor.
INDICADOR

11. ¿Por qué es tan importante
medir el proceso y el producto
software que produce?
• Si no se mide, no hay una forma real de determinar si se está
mejorando. Y si no se está mejorando, se está perdido.
• La medición es una de las «medicaciones» que pueden ayudar a
curar el «mal del software». La medición proporciona beneficios a
nivel de proyecto, estratégico y técnico.

12. Medidas Directas del Proceso de Software:
 Costo y Esfuerzo.
Medidas Directas del Producto de Software:
 Líneas de Código
 Velocidad de Ejecución.
MEDICIONES DE SOFTWARE
Medidas Indirectas
 Calidad.
 Eficiencia
 entre otras Capacidades
Mas difíciles de evaluar
Se miden indirectamente
Mas fáciles de evaluar
Se miden directamente

13. ESTIMACIONES
DE COSTOS Y ESFUERZOS
1) Basar las estimaciones en proyectos similares ya terminados.
– Es razonable si: El cliente, la administración, el medio ambiente, los
requisitos, las fechas límites, son similares a proyectos anteriores.
– A pesar de eso la experiencia anterior no ha sido siempre un buen indicador
de resultados futuros.
2) Utilizar técnicas de descomposición del problema.
– Utilizan un enfoque de divide y vencerás.
– Descomponen el proyecto en sus funciones principales y la estimación del
costo y esfuerzo puede realizarse en base a métricas históricas de manera
más fiable.
3) Desarrollar un modelo empírico de cálculo de costos y esfuerzos.
– Se basan en datos históricos y son de la forma d = f (vi) donde d es el valor
estimado (p.e. esfuerzo, costo, duración del proyecto) y los vi son algunos
parámetros independientes (p.e. LDC o PF estimados).

14. METRICA DE LOS PUNTOS
DE FUNCION
Este método de estimación contempla la aplicación a
desarrollar en forma externa, es decir, no se
interesa por las interioridades de la aplicación, sino
que se centra en lo que puede ver el usuario
 Entradas
 Salidas
 Consultas
 Ficheros Lógicos o Internos
 Ficheros de Interfaz
ELEMENTOS DE FUNCION

15. 1. ¿Requiere el sistema copias de seguridad y de
recuperación fiables?
2. ¿Se requiere comunicación de datos?
3. ¿Existen funciones de procesamiento distribuido?
4. ¿Es critico el rendimiento?
5. ¿Se ejecutará el sistema en un entorno operativo
existente y fuertemente utilizado?
6. ¿Requiere el sistema entrada de datos interactiva?
7. Requiere la entrada de datos interactiva que las
transacciones de entrada se lleven a cabo sobre
múltiples pantallas u operaciones.
8. ¿Se actualizan los archivos maestros de forma
interactiva?
FACTORES DE COMPLEJIDAD (1)

16. 9. ¿Son complejas las entradas, salidas, los archivos o las
peticiones?
10. ¿Es complejo el procesamiento interno?
11. ¿Se ha diseñado el código para ser reutilizable?
12. ¿Están incluidas en el diseño la conversión y la
instalación?
13. ¿Se ha diseñado el sistema para soportar múltiples
instalaciones en diferentes organizaciones?
14. ¿Se ha diseñado la aplicación para facilitar los cambios
y para ser fácilmente utilizada por el usuario?
FACTORES DE COMPLEJIDAD (2)

17. FACTORES DE COMPLEJIDAD
 Son catorce factores.
 Toman un valor entre 0 y 5
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

18. CALCULO PF
PF = T *( 0,65 + 0,01 * Σ(Fi) )
En donde T es la cuenta total o suma de
todas las entradas obtenidas en el cuadro
anterior.
F (i=1 al 14) son valores de ajuste de la
complejidad según las respuesta a las
siguientes preguntas:
Ver Ejemplo Práctico de Guía

19. Modo Orgánico: Proyectos de software
relativamente pequeños y sencillos en los que
trabajan pequeños equipos, con buena
experiencia en la aplicación, sobre un conjunto
de requisitos poco rígidos (por ejemplo, un
programa de análisis termal desarrollado para un
grupo calórico).
Los modelos COCOMO están
definidos para tres tipos de
proyectos de software.

20. Modo Semiacoplado: Proyectos de
software intermedios (en tamaño y
complejidad) en los que equipos, con
variados niveles de experiencia, deben
satisfacer requisitos poco o medio rígidos
(p. ej.: un sistema de procesamiento de
transacciones con requisitos fijos para un
hardware de terminal o un software de
gestión de base de datos.
Modelo COCOMO

21. Modo Empotrado: Proyectos de software
que deben ser desarrollados en un
conjunto de hardware, software y
restricciones operativas muy restringido
(p. ej.: software de control de navegación
para un avión).
Modelo COCOMO

22. Las ecuaciones del COCOMO Básico
tienen la siguiente forma:
Proyecto de Software ab bb cb db
Orgánico 2.4 1.05 2.5 0.38
Semiacoplado 3.0 1.12 2.5 0.35
Empotrado 3.6 1.20 2.5 0.32
E : Esfuerzo aplicado en personas mes.
D : Tiempo de desarrollo en meses cronológicos.
KLDC : Número estimado de líneas de código (en miles) para el proyecto.
Los coeficientes ab y Cb y los exponentes bb y db se muestran en la Tabla.
E = (ab)(kLDC)^ bb
D = (cb)(E)^db

23. Ejemplo COCOMO Básico
Función Optimista Pesimista Realista
Función 1 1800 2650 2340
Función 2 4100 7400 5380
Función 3 4600 8600 6600
Función 4 2950 3600 3350
Función 5 4050 6200 4950
Función6 2000 2450 2140
Función 7 6600 9800 8400
Total LDC 33360 = 33,3

24. La duración del Proyecto permite
recomendar un número de
personas para abordar el
desarrollo:
N = E / D
= 152/14,5
= 11 personas.