Ingeniería de Software

Unidad 2
Administración de Proyectos de
Software
Unidad 2

Contenido
 Esquema del plan de administración del proyecto
 Técnicas de planificación
 Diagramas de GANTT
 Redes de precedencia (PERT)
 Métricas del proyecto
 Mediciones del software
 Métricas orientadas al tamaño (LDC)
 Métricas orientadas a la función
 Modelo de estimación de costos (COCOMO)
 Seguimiento y supervisión del proyecto
 Gestión de riesgos.
Unidad 2
Esquema del plan de
administración del proyecto
 Existen varias maneras de
elaborar un plan de
administración, sin embargo
una de las mejores es el
estándar IEEE 1058 [Schach, 2004].
 El estándar refleja la
experiencia de la industria y
las universidades.
 Se diseño como marco de
trabajo para usarlo con todo
tipo de sistemas de
información, sin importar el
ciclo de vida o metodología.
 En el caso de sistemas
pequeños algunas secciones
no son relevantes.
1. Descripción general
1.1 Resumen del proyecto
1.1.1 Propósito, alcance y objetivos
1.1.2 Suposiciones y Restricciones
1.1.3 Elementos del proyecto sujetos a entrega
1.1.4 Calendario y resumen del presupuesto
1.2 Evolución del plan de administración del proyecto
2. Materiales de consulta
3. Definiciones y acrónimos
4. Organización del proyecto
4.1 Interfaces externas
4.2 Estructura interna
4.3 Funciones y responsabilidades
5. Planes del proceso administrativo
5.1 Plan inicial
5.1.1 Plan de estimación
5.1.2 Plan de contratación de personal
5.1.3 Plan de adquisición de recursos
5.1.4 Plan de capacitación para el personal del
proyecto
5.2 Plan de trabajo
5.2.1 Actividades de trabajo
5.2.2 Asignación del calendario
5.2.3 Asignación de recursos
5.2.4 Asignación del presupuesto
5.3 Plan de control
5.3.1 Plan de control de requisitos
5.3.2 Plan de control del calendario
5.3.3 Plan de control del presupuesto
5.3.4 Plan de control de la calidad
5.3.5 Plan de generación de informes
7. Planes de procesos de soporte
7.1 Plan del control de la configuración
7.2 Plan de pruebas
5.3.6 Plan de recolección de mediciones
5.4 Plan de manejo de riesgos
7.3 Plan de documentación
7.4 Plan de aseguramiento de la calidad
5.5 Plan de cierre del proyecto
6. Planes del proceso técnico
6.1 Modelo del proceso
7.5 Plan de revisiones y auditorias
7.6 Plan de resolución de problemas
7.7 Plan de control de los
6.2 Métodos, herramientas y técnicas
6.3 Plan de infraestructura
subcontratistas
7.8 Plan de mejora del proceso
6.4 Plan de aceptación del producto 8. Planes adicionales
Unidad 2

Esquema del plan de

administración del proyecto … (2)
 1.- Descripción general
 1.1 Resumen del proyecto
 1.1.1 Propósito, alcance y objetivos. Se da una breve descripción del propósito y las posibilidades del
sistema de información que se va a entregar, así como de los objetivos del proyecto.
 1.1.2 Suposiciones y restricciones. Cualquier suposición subyacente al proyecto se define aquí, junto
con restricciones como la fecha de entrega, el presupuesto, los recursos y artefactos que se van a
utilizar.
 1.1.3 Elementos del proyecto sujetos a entrega. Todos los elementos que se van a entregar al cliente se
enlistan aquí, junto con las fechas correspondientes.
 1.1.4 Calendario y resumen del presupuesto. El calendario general se presenta aquí, junto con el
presupuesto.
 1.2 Evolución del plan de administración del proyecto
 En esta sección se describen los procedimientos y mecanismos formales para cambiar el plan.
 2.- Materiales de consulta
 Todos los documentos referidos en el plan de administración del proyecto se enlistan aquí.
 3.- Definiciones y acrónimos
 Esta información asegura que todos comprendan el plan de administración del proyecto de la misma
manera.
 4.- Organización del proyecto
 4.1 Interfaces externas
 Se deben establecer los mecanismos (quién, cuándo, dónde y propósito) de las reuniones entre el
cliente y los miembros del proyecto.
 4.2 Estructura interna
 En esta sección se describe la estructura de la empresa de desarrollo (grupo de desarrollo, de soporte,
gerencial).
 4.3 Funciones y responsabilidades.
 Para cada función del proyecto y para cada actividad debe identificarse al responsable individual.
Unidad 2

Esquema del plan de

administración del proyecto … (3)
 5.- Planes del proceso administrativo
 5.1 Plan inicial
 5.1.1 Plan de estimación. Las técnicas utilizadas para estimar la duración y el costo del proyecto se
enlistan aquí, así como la manera en que se rastrearán y, en caso de ser necesario, se modificarán
mientras el proyecto está en proceso.
 5.1.2 Plan de contratación de personal. Se enlista la cantidad y el tipo de personal requerido, junto con
los periodos para los cuales se necesita.
 5.1.3 Plan de capacitación para el personal del proyecto. Toda la capacitación necesaria para una
finalización exitosa del proyecto se enlista en esta subsección.
 5.2 Plan de trabajo
 5.2.1 Actividades de trabajo. Se especifican todas las actividades de trabajo, hasta el nivel de tarea en
caso de ser necesario.
 5.2.2 Asignación del calendario. En general, existe una relación cercana entre los paquetes de trabajo y
la dependencia de eventos externos (análisis primero, después diseño, …). Aquí se especifican las
dependencias relevantes.
 5.2.3 Asignación de recursos. Los diversos recursos enlistados antes se asignan a las funciones,
actividades y tareas propias del proyecto.
 5.2.4 Asignación del presupuesto. Esta subsección se divide el presupuesto general en los niveles de
función, actividad y tarea del proyecto.
 5.3 Plan de control
 5.3.1 Plan de control de requisitos. Se describen los mecanismos para controlar y vigilar los cambios
que se dan en los requisitos.
 5.3.2 Plan de control del calendario. Se enlistan los mecanismos para medir el progreso, junto con una
descripción de las medidas que se deben tomar en caso de que el progreso real no corresponda con el
esperado.
 5.3.3 Plan de control del presupuesto. Los mecanismos para vigilar cuando el costo real excede al
presupuestado, así como las medidas a tomar si esto ocurre.
 5.3.4 Plan de control de la calidad. Las formas en que se medirá y controlará la calidad se describen en
esta sección.
Unidad 2

Esquema del plan de

administración del proyecto … (4)
 5.3.5 Plan de generación de informes. Con el fin de vigilar los requisitos, el calendario, el presupuesto y
la calidad, es necesario establecer los mecanismos para la generación de informes.
 5.3.6 Plan de recolección de mediciones. Se enlistan las mediciones que se van a recopilar (LDC, PF,
…)
 5.4 Plan de manejo de riesgos
 Los riesgos deben identificarse, ponerse en orden de prioridad, mitigarse y darles seguimiento. En esta
sección se deben describir todos los aspectos del manejo de riesgos.
 5.5 Plan de cierre del proyecto
 Las acciones por realizar una vez que el proyecto está terminado, incluyendo la reasignación del
personal y crear el archivo de los artefactos.
 6.- Planes del soporte técnico
 6.1 Modelo del proceso
 En esta sección se da una descripción detallada del modelo del ciclo de vida que se va a utilizar.
 6.2 Métodos, herramientas y técnicas
 Las metodologías de desarrollo y los lenguajes de programación que se van a usar se describen aquí.
 6.3 Plan de infraestructura
 Los aspectos técnicos de hardware y software se describen con detalle en esta subsección (equipo, SO,
la red, SW, CASE, … ), tanto los que se van a utilizar para desarrollar el sistema de información, así
como aquellos en los cuales se ejecutará dicho sistema.
 6.4 Plan de aceptación del producto
 Se deben preparar los criterios de aceptación; el cliente debe aceptarlos por escrito y los
desarrolladores deben entonces asegurar que se cumplan. La manera en que se realizará lo anterior
debe quedar por escrito.
 7.- Planes de procesos de soporte
 7.1 Plan de control de la configuración
 Se da una descripción detallada de los medios por los cuales todos los artefactos se pondrán bajo el
control de la configuración.
Unidad 2

Esquema del plan de

administración del proyecto … (5)
 7.2 Plan de pruebas
 Se necesita de una planeación cuidadosa que incluya los recursos para su aplicación y el calendario
específico de que prueba ha de realizarse.
 7.3 Plan de documentación
 Una descripción de toda la documentación ya sea que se entreguen o no al cliente.
 7.4 Plan de aseguramiento de la calidad
 Todos los aspectos del aseguramiento de la calidad, incluidas las pruebas, los estándares y las
revisiones se engloban en esta sección.
 7.5 Plan de revisiones y auditorias
 Se presentan detalles relacionados con la manera como se realizan las revisiones.
 7.6 Plan de resolución de problemas
 Se describe la forma y mecanismos de resolver problemas en cualquiera de las fases del desarrollo del
sistema.
 7.7 Plan de control de los subcontratistas
 Se aplica cuando se requiere y el método para seleccionar y manejar a los subcontratistas debe
aparecer aquí.
 7.8 Plan de mejora del proceso
 Las estrategias para la mejora del proceso se incluyen aquí.
 8. Planes adicionales
 Para ciertos proyectos, los componentes adicionales tal vez necesiten aparecer en el plan. En términos
del marco de trabajo del IEEE, aparecen al final. Los componentes adicionales pueden incluir planes de
seguridad, de prevención, de conversión de datos, de instalación y el plan de mantenimiento del sistema
de información.
Unidad 2

Técnicas de planificación
 Las técnicas contribuyen en la realización del calendario.
 Diagramas de GANTT
 Es la técnica más utilizada cuando se pretende mostrar el tiempo previsto
para diferentes tareas o actividades
 Se utiliza en proyectos pequeños (aproximadamente 25 actividades)
 Permite visualizar los solapamientos de tareas, pero no la dependencia entre
ellas
 Redes de precedencia
 La planificación se realiza en base a grafos.
 Las dos técnicas principales son:
 PERT (Program Evaluation and Review Technique) y
 CPM (Crítical Path Method)
 Son convenientes cuando:
 Todas las actividades están bien definidas
 Las actividades se pueden comenzar, interrumpir y realizar de forma separada dentro
de una secuencia dada.
 Las actividades se pueden relacionar con otras
 Las actividades están organizadas de forma que se pueda seguir una secuencia.
 Una vez comenzada una actividad, debe continuar sin interrupción hasta su
finalización.
Unidad 2

Diagramas de GANTT
 Es un diagrama de barras en forma de tabla donde se hace una
referencia cruzada entre las tareas (filas) y los tiempos de duración
de las mismas (columnas).
 Dentro del diagrama se pueden incluir fases que engloben
diferentes tareas: su duración es la necesaria para terminar dichas
tareas.
Unidad 2

Redes de precedencia
 Se trata de un modelo gráfico que señala las
relaciones secuenciales entre sucesos clave en un
proyecto.
 Esta técnica permite visualizar el camino crítico que
es la base para la planificación.
 Las reglas a considerar al desarrollar una red son:
 Mínimo unos 20 eventos.
 Si se gestiona manualmente no mas de 300 eventos, de lo
contrario utilizar algún software de gestión.
 Útil para proyectos con alto riesgo o incertidumbre, que
involucren muchas personas u organizaciones, los
técnicamente complejos o con tareas a realizar en distintas
localizaciones geográficas.
Unidad 2

Técnica PERT
 Parte de la descomposición del proyecto en actividades.
 Las actividades ocurren entre dos sucesos (inicial y final),
entendiendo como suceso un acontecimiento o punto temporal.
 La representación se realiza por medio de un grafo en donde las
actividades se reflejan mediante arcos y los sucesos mediante
vértices.
A
1 2

Representación de actividad y suceso en PERT

 El siguiente paso es la determinación de las relaciones entre las

actividades.
Unidad 2

Técnica PERT … (2)

 Tipos de relaciones de precedencia
Para iniciar la actividad B es
necesario haber finalizado la
Relaciones de
A B actividad A. El suceso 2 es
precedencia 1 2 3 suceso final de A y suceso
lineales inicio de B.

1 A
Relaciones de Para iniciar la actividad D es
B D necesario haber finalizado
precedencia 2 4 5
C las actividades A, B, y C.
convergentes
3

B 3
Relaciones de Para poder iniciar cualquiera
A C de las actividades B, C, o D,
precedencia 1 2 4
D es necesario que haya
divergentes finalizado la actividad A.
5
Unidad 2

Técnica PERT … (3)

 Algunas combinaciones de precedencia pueden
generar conflictos. Por ejemplo:
 Las actividades A y B preceden a la actividad D.
 Las actividades A, B, y C preceden a la actividad E.
 Para resolver el problema se añade una actividad ficticia F,
de duración cero.
A D A D

B
B
F
C E
C E

Ejemplo de conflicto PERT Ejemplo de resolución del conflicto PERT

Unidad 2

Técnica PERT … (4)

 Ejemplo: Matriz de encadenamientos
 Supongamos que se tiene
que realizar un proyecto que
tiene las siguientes
actividades: A, B, C, D, E, F
y G. Las relaciones entre las
actividades son las
siguientes:
 A precede a B, C y D
 B precede a E Cuadro de relaciones de precedencia
 C precede a F
 D precede a G
 E, F preceden a H
 Existen dos formas de
manipular las relaciones de
precedencia:
 Matriz de encadenamientos
 Matriz de precedencia
Unidad 2

Técnica PERT … (5)

 Ejemplo … (continuación)
 La red resultante del ejemplo es la siguiente:

3 E
B
6
C F H
A
1 2 4
D
7
G
5

Ingeniería de software
Unidad 2

Técnica PERT … (6)

 Asignación de los tiempos de cada actividad
 Estimación de tiempo pesimista (tp)
 Representa el tiempo máximo en que podría finalizarse la actividad si
aparecen todas las circunstancias negativas que pueden darse
durante su ejecución.
 Estimación de tiempo más probable (tn)
 Representa el tiempo normal de duración de la actividad
considerando que hay problemas durante las actividades, pero no
aparecen en su totalidad.
 Estimación de tiempo optimista (to)
 Representa el tiempo mínimo si no aparece ningún problema durante
la ejecución de la actividad.
 Basándose en las estimaciones anteriores se puede trabajar con
un tiempo simplificado PERT (T) que se calcula como:
 t p  4t n  t o
T 
6
Ingeniería de software
Unidad 2

Técnica PERT … (7)

 Cálculo de los tiempos más temprano posible (early) y más
tardíos (late).
 El tiempo early del suceso j (TEj) será igual a:
TEj = máx [TEi + Tij], j
 El Tiempo late (TLi) del último suceso coincide con su tiempo
early y el resto de los tiempos late se calculan como:
TLi = min [TLj - Tij], j
Tiempo más temprano para comenzar Tiempo más temprano para
la actividad A (Tiempo early) finalizar actividad A

Tiempo más tardío para comenzar Tiempo más tardío para

la actividad A (Tiempo late) finalizar actividad A

TEi TLi A TEj TLj

Suceso i Suceso j
Tij: duración de la actividad que comienza
en el suceso i y finaliza en el suceso j
Ingeniería de software
Unidad 2

Técnica PERT … (8)

 Ejemplo:
 Tomando la red del ejemplo anterior y suponiendo que se tienen
calculados los tiempos PERT para cada actividad, el cálculo de
los tiempos early es:

13
6 19
3
5 E
21
B
6
8 6 7 3
0 8 14
F H 22
1 A 2 C 4
5 24
D 9 7
13
TEj = máx [TEi + Tij], j G
5
Ingeniería de software
Unidad 2

Técnica PERT … (9)

 Ejemplo … (continuación)
 El cálculo de los tiempos late es:
TLi = min [TLj - Tij], j 13 15
6
3
5 E
21 21
10 10 B
6
8 6 7 3
0 0 8 8 14 14
F H
1 A 2 C 4
5 24 24
 La holgura total de una actividad está
D 9 7
dada por:
HT = TLj – TEi - Tij 13 15 G
 Representa el número de unidades de 5
tiempo que puede retrasarse la
actividad sin que aumente la duración
del proyecto.
 Las actividades que tienen un holgura
total igual a cero se denominan
actividades críticas.
 La unión de todas las actividades
críticas forman el camino crítico.

Ingeniería de software
Unidad 2

Métricas del proyecto

 Las métricas de software se refieren a un amplio elenco de mediciones para el
software de computadora.
 Hay cuatro razones para medir los procesos del software, los productos y los
recursos
 Caracterizar
 Para comprender mejor los procesos, los productos, los recursos y los entornos y
para establecer la líneas base para las comparaciones con evaluaciones futuras.
 Evaluar
 Para determinar el estado con respecto al diseño. Las medidas dicen cuando el
proyecto y los procesos están perdiendo la pista. También se evalúa para valorar el
logro de los objetivos de calidad, el impacto de la tecnología y las mejoras en los
productos y procesos.
 Predecir
 Para poder planificar. Medir para predecir implica aumentar la comprensión de las
relaciones entre los procesos y los productos y la construcción de modelos de estas
relaciones, logrando así establecer objetivos alcanzables para el coste, planificación y
calidad. Además las predicciones y estimaciones basadas en datos históricos ayudan
a analizar riesgos.
 Mejorar
 Cuando se recaba información cuantitativa es posible identificar obstáculos,
problemas de raíz, ineficiencias y otras oportunidades para mejorar la calidad del
producto y el rendimiento del proceso

Ingeniería de software
Unidad 2

Métricas del proyecto … (2)

 Una métrica es una medida cuantitativa del grado en Las métricas del
software le
que un sistema, componente o proceso posee un permiten conocer
atributo dado [IEEE93]. cuándo reír y
cuándo llorar
 Una métrica de software relata de alguna forma las [Tom Glib]

medidas individuales sobre algún aspecto (número

promedio de errores encontrados por revisión). No todo lo que se
puede contar
 La recopilación de medidas y desarrollo de métricas cuenta, y no todo
se utilizan para obtener indicadores. lo que cuenta se
puede contar
 Un indicador proporciona una visión profunda que
permite al gestor del proyecto o a los ingenieros de
software ajustar el producto, el proyecto o el proceso
para que las cosas salgan mejor [Pressman, 2002].

Ingeniería de software
Unidad 2

Métricas del proyecto … (3)

 Las métricas del proyecto y los indicadores derivados de ellos son utilizados por
un equipo de software y el gestor del proyecto para adaptar el flujo de trabajo
del proyecto y las actividades técnicas.
 Regularmente las métricas de proyectos tienen su primera aplicación durante la
estimación. Aquí se compara respecto a proyectos anteriores (esfuerzo y
tiempo).
 Conforme avanza el proyecto se compara el tiempo y esfuerzo estimado con el
tiempo y esfuerzo real para hacer los ajustes pertinentes.
 Durante el transcurso del trabajo técnico se miden índices de producción
representados mediante páginas de documentación, horas de revisión, puntos
de función, líneas fuente entregadas. Además se sigue la pista de los errores
detectados durante todas las tareas.
 La recopilación de métricas técnicas durante la evolución de la especificación al
diseño permite evaluar la calidad y proporciona indicadores para la generación
y prueba del código.
 La utilización de métricas para el proyecto tiene dos aspectos
 Minimizar la planificación del desarrollo haciendo ajustes necesarios para evitar
retrasos y reducir problemas y riesgos potenciales.
 Evaluar la calidad de los productos en el momento actual y cuando sea necesario,
modificando el enfoque técnico que mejore la calidad.

Ingeniería de software
Unidad 2

Mediciones del software

 Al igual que en el mundo físico, en el software se
pueden categorizar dos formas de medir:
 Medidas directas
 En el proceso: coste y esfuerzo aplicado.

 En el producto: líneas de código producidas, velocidad de

ejecución, tamaño de memoria y los defectos detectados
durante un periodo de tiempo establecido.
 Medidas indirectas
 Funcionalidad, calidad, complejidad, eficiencia, fiabilidad,
facilidad de mantenimiento y muchas otras capacidades

Ingeniería de software
Unidad 2

Métricas orientadas al tamaño

(LDC)
 Provienen de la normalización de las medidas de calidad y/o productividad
considerando el tamaño del software producido.
 Se pueden mantener registros históricos sencillos y crear una tabla de datos
orientados al tamaño. El coste y esfuerzo reflejados en la tabla involucran
todas las actividades de la ingeniería de software (no solo la codificación).
 Para desarrollar métricas que se puedan comparar entre distintos proyectos,
se seleccionan las líneas de código (LDC) como valor de normalización.
 A partir de los datos de la tabla se pueden obtener métricas simples orientadas
al tamaño.
 Errores por KLDC
 Defectos por KLDC
 páginas documentación x KLDC
 Errores persona-mes
 LDC por persona-mes
 $ por página de documentación

Ingeniería de software
Unidad 2

Métricas orientadas a la
función
 Se mide la funcionalidad a partir de mediciones directas.
 Se utiliza una medida llamada punto de función [Albretch], derivado con una
relación empírica según las medidas contables (directas) del dominio de la
información y las evaluaciones de la complejidad del software.
 Se determinan cinco características de dominios de información:
 Número de entradas de usuario
 Se cuenta cada entrada de usuario que proporciona diferentes datos orientados a la
aplicación. Las entradas se deberían diferenciar de las peticiones, las cuales se cuentan
de forma separada.
 Número de salidas de usuario.
 Se cuenta cada salida que proporciona al usuario información orientada a la aplicación.
En este contexto la salida se refiere a informes, pantallas, mensajes de error, etc. Los
elementos de datos particulares dentro de un informe no se cuentan de forma separada.
 Número de peticiones de usuario
 Una petición (consulta) de usuario se define como una entrada interactiva que produce la
generación de alguna respuesta del software inmediata en forma de salida interactiva. Se
cuenta cada petición por separado.
 Número de archivos
 Se cuenta cada archivo maestro lógico (esto es, un grupo lógico de datos que puede ser
una parte de una gran pase de datos o un archivo independiente)
 Número de interfaces externas
 Se cuentan todas las interfaces legibles por la máquina (por ejemplo: archivos de datos
de cinta o disco) que se utilizan para transmitir información a otro sistema.
Ingeniería de software
Unidad 2

Métricas orientadas a la función

… (2)
 Cuantificadas la cinco
características del dominio de
la información se debe
determinar si una entrada en
particular es simple, mediana o
compleja. Sin embargo esta
determinación suele ser
subjetiva.
 Para calcular puntos de
función (PF) también se debe
calcular un factor de
complejidad (Fi) según las
respuestas (en un rango de 0 a
5) a una serie de preguntas.
 Así se tiene que:

 14

PF  CunetaTotal  0.65  0.01  6 Fi 
 1 

Ingeniería de software
Unidad 2

Métricas orientadas a la función

… (3)
 Ejemplo:
 Sistema hogar seguro
 La función gestiona la interacción con el
usuario, aceptando una contraseña de usuario
para activar/desactivar el sistema y permitiendo
consultas sobre el estado de las zonas de
seguridad y varios sensores de seguridad.
 Se identifican:
 Tres entradas de usuario: contraseña,
interruptor de emergencia y activar/desactivar
 Dos consultas: consulta de zona y consulta de
sensor
 Un archivo: datos de configuración del sistema
 Dos salidas de usuario: mensajes y estados del
sensor
 Cuatro interfaces externas: sensor de prueba,
configuración de zona, activar/desactivar y
alerta de alarma.
 14

Sensor de prueba Sensores PF  CunetaTotal  0.65  0.01  6 Fi 
 1 
Configuración de zona 14
Suponiendo: 6 Fi  46 (moderadamente complejo)
Contraseña
Funciones de
Consulta de zona interacción del Mensajes
Usuario 1
usuario con
Usuario Consulta de sensor
Interruptor de
Hogar Seguro Estado del sensor
Se tiene: PF  50  0.65  (0.01 46)  56
Activar/Desactivar
emergencia
Subsistema En base al valor calculado y los datos históricos de que se
Activar/desactivar Alerta de
alarma de dispongan, se pueden estimar: LCD, esfuerzo, etc.
monitorización
Contraseñas, sensores, … Por ejemplo: un PF supone 60 líneas de código y un mes-
Datos de configuración del sistema persona produce 12 PF. ¿Cuál es tamaño y esfuerzo?.
Ingeniería de software
Unidad 2

Modelo de estimación de
costos (COCOMO)
 COCOMO
 COnstructive COst MOdel
 Uno de los modelos más completos y detalladamente
documentados para la estimación de costos por lo que también
es el más conocido.
 Se trata de un modelado algorítmico de costos
 Se construye analizando los costos y atributos de los proyectos
realizados.
 Se utiliza una fórmula matemática para predecir los costos
basados en estimaciones de tamaño del proyecto (LDC), número
de programadores y otros factores de los procesos y productos.
 La fórmula tiene un componente exponencial, lo que refleja el
hecho de que los costos normalmente no se incrementan de
forma lineal con el tamaño del proyecto.

Ingeniería de software
Unidad 2

Modelo de estimación de costos

(COCOMO) … (2)
 En su forma más general, la ecuación del Ecuaciones de esfuerzo y tiempo de COCOMO
esfuerzo se expresa como: [BOEHM, 1981]
 Esfuerzo = A  TamañoB
 Donde:
 A es un factor constante que depende de las
prácticas organizacionales locales y del tipo
de software que se desarrolla.
 Tamaño es una valoración del tamaño del
código o una estimación de la funcionalidad.
 B por lo general se encuentra entre 1 y 1.5;
refleja el esfuerzo requerido para proyectos
grandes.
 Los tipos de proyectos pueden ser: La precisión de las estimaciones depende de la
 Orgánico. Información disponible del sistema. Conforme
 Desarrollo en un entorno estable, con poca avanza el proceso, se dispone de más información
innovación técnica, con pocas presiones de y por tanto las estimaciones son más precisas.
tiempo y tamaño relativamente pequeño
 Empotrado 4x
 Desarrollo de software con requisitos muy
restrictivos, con gran volatilidad de requisitos, 2x
complejo, en un entorno con gran innovación
técnica. x
Factibilidad Requerimientos Diseño Código Entrega
 Semi-libre 0.5x
 Situaciones entre el modo orgánico y el
empotrado 0.25x
Ingeniería de software
Unidad 2

Modelo de estimación de costos

(COCOMO) … (3)
 Se distinguen tres modelos distintos que se
corresponden con diferentes cantidades de
información disponible en las etapas del ciclo
de vida:
 COCOMO básico
 Para estimaciones iniciales moderadamente
precisas al inicio del proyecto cuando no se
dispone de detalles (por ejemplo, para empezar a
negociar el contrato). Consiste en aplicar
básicamente la ecuación del esfuerzo.
 COCOMO intermedio
 Cuando tenemos identificados los principales
componentes del sistema (especificación de
requisitos ± terminada). Se emplea para estimar
el coste de los componentes y consiste en aplicar
la ecuación del esfuerzo y hacer un ajuste
incorporando 15 factores de coste.
 COCOMO detallado
 Cuando están identificados los componentes
individuales del sistema (especificación de
requisitos completa o diseño general bien
definido). En este caso, el modelo COCOMMO
proporciona tablas para poder distribuir las
cantidades, ajustadas a los entorno, del esfuerzo
y el tiempo de desarrollo del proyecto a lo largo
de las distintas fases del mismo. Incluso permite
refinar el ajuste de los factores para adaptarlo a
las peculiaridades de cada etapa del proyecto

Ingeniería de software
Unidad 2

Modelo de estimación de costos

(COCOMO) … (4)
 Ejemplo:
 Se trata de estimar el esfuerzo de desarrollo de un sistema de comunicaciones de 30 KLDC, de alta
complejidad. Afortunadamente se puede emplear personal de muy alta calificación con una gran
experiencia específica en ese tipo de software. El coste del salario mensual de cada persona es de
1350 euros al mes.
 Aplicando COCOMO, se puede observar que el esfuerzo estimado será:
Esfuerzo = 3.2  (30)1.05 = 113.79 PM
Se aplicó el modo orgánico porque la aplicación no supera las 50 KLDC y no hay datos que señalen
alguna complejidad especial.
El ajuste del esfuerzo sería:
Esfuerzoa = 113.79 PM  1.15 (complejidad)  0.70 (personal)  0.91 (experiencia)
Esfuerzoa = 83.35 PM
Coste = 83.35  1350 = 112522.5 euros
Tiempo = 2.5  83.350.38 = 13.42 meses
No Promedio de personas = 83.35 / 13.42 = 6.2 personas
¿Sería más rentable emplear a personas de nivel medio cuyo salario es 1275 euros?
Haciendo cálculos:

Esfuerzoa = 113.79 PM  1.15 (complejidad)  0.91 (personal) = 119.08 PM

Coste = 119.08  1275 = 151827 euros (es más caro)

Ingeniería de software
Unidad 2

Seguimiento y supervisión del

proyecto
 El seguimiento y supervisión del proyecto implica seguir, revisar
y comparar los logros y los resultados obtenidos, frente a las
estimaciones, los compromisos y los planes del proyecto,
actualizándolos en función de estos resultados.
 Se puede decir que los objetivos que se pretenden con el
seguimiento y supervisión del proyecto del software son:
 Comparar los resultados actuales con los previstos
 Tomar acciones correctivas cuando existan desviaciones
significativas de los planes previstos
 Acordar compromisos con el personal afectado por las acciones
correctivas.

Si no sabes dónde estas,

un mapa no te ayudará
[Humphery, 1989]
Ingeniería de software
Unidad 2

Seguimiento y supervisión del

proyecto … (2)
 En la supervisión de los resultados actuales con los planes
previstos se han de desarrollar:
 Estándares que establezcan las condiciones o medidas que
deben cumplirse cuando se realicen las diferentes tareas del
proyecto.
 Establecer sistemas de supervisión y de informes, para lo cual
hay que determinar: los datos necesarios, quién los recibe y
cuándo se reciben.
 Medir los resultados, lo que permite determinar la consecución o
la desviación de los objetivos y estándares.
 Otros aspectos importantes a considerar son:
 Seguimiento de costes y calendario
 Seguimiento de aspectos técnicos
 Generación de datos históricos No tratare de estar
bien hoy a expensas
 Seguimiento de hitos
de mañana
Ingeniería de software
Unidad 2

Seguimiento y supervisión del

proyecto … (3)
 Acciones correctivas
 Cuando no se cumplen los planes, se ejecutan diversas acciones
correctivas que pueden incluir desde la revisión del plan de
administración del proyecto hasta la replanificación del mismo.
 La razón principal para el seguimiento y el estado del progreso
es detectar problemas y resolverlos lo más rápido posible.
 Los dos objetivos esenciales del seguimiento y la supervisión
son:
 Las acciones correctivas se realizan y gestionan cuando los
resultados reales se desvían significativamente de los planes
 Los grupos y los individuos afectados llegan al acuerdo de los
cambios en los compromisos.
 En general las acciones correctivas pueden ser:
 Ajustar/añadir personal o número de hora extra
 Reasignar a los empleados para mejorar la eficiencia
 Reducir el alcance o contenido de una entrega
 Alargar o retrasar el calendario, negociando con el cliente.
Ingeniería de software
Unidad 2

Gestión de riesgos
 Riesgo
 Se puede definir como cualquier elemento potencial que provoca
resultados insatisfactorios en un proyecto.
 Es la forma de expresar la incertidumbre a lo largo del ciclo de
vida: la probabilidad de que en un punto del ciclo de vida no se
alcancen los objetivos propuestos con los recursos disponibles
[AFSC, 1988].
 Estrategias de riesgo
 Reactivas
 “Escuela de gestión del riesgo de Indiana Jones” (no te preocupes,
pensaré en algo).
 En el mejor de los casos, supervisa el proyecto en previsión de
posibles riesgos y no se hace nada hasta que algo sale mal.
 Proactivas
 Inicia mucho antes de que inicie el trabajo técnico.
 Se identifican los riesgos potenciales, se valúa su probabilidad e
impacto y se establece un orden de prioridad.
 Una vez hecho el paso anterior se establece un plan para controlar
el riesgo. Si usted no ataca los
riesgos activamente,
 El objetivo principal es evitar el riesgo, sin embargo no se pueden ellos le atacarán
evitar todos ellos, por lo que también es necesario un plan de activamente a usted.
[Tom Glib]
Ingeniería de software
contingencia.
Unidad 2

Gestión de riesgos … (2)

 Categorías de riesgos
 Riesgos del proyecto
 Amenazan al plan del proyecto
 Si ocurren es probable que la planificación temporal del proyecto se retrace o que los
costos aumenten.
 Identifican problemas potenciales de presupuesto, planificación temporal, personal,
recursos, cliente y requisitos.
 Riesgos técnicos
 Amenazan la calidad y la planificación temporal del software.
 Si ocurre la implementación puede llegar a ser difícil o imposible.
 Identifican problemas potenciales de diseño, implementación, de interfaz, verificación y
de mantenimiento.
 Riesgos del negocio
 Amenazan la viabilidad del software a construir.
 Los principales riesgos de negocios son:
 Construir un producto o sistema excelente que nadie quiere en realidad (riesgo de mercado).
 Construir un producto que no encaja en la estrategia comercial general de la compañía (riesgo
estratégico).
 Construir un producto que el departamento de ventas no sabe cómo vender.
 Perder el apoyo de una gestión experta debido a cambios en el personal o de enfoque (riesgo de
dirección).
 Perder presupuesto o personal asignado (riesgos de presupuesto).

Ingeniería de software
Unidad 2

Gestión de riesgos … (3)

 Plan RSGR
 Es el Plan de Reducción,
Supervisión y Gestión del
Riesgo.
 La reducción del riesgo evita
problemas
 La supervisión da seguimiento al
proyecto con tres objetivos:
 Evaluar cuando un riesgo
previsto ocurre
 Asegurarse de que los
procedimientos para reducir los
riesgos se apliquen
apropiadamente
 Recopilar datos históricos
 Puede llevarse a la práctica
documentando cada riesgo en
una hoja de información de
riesgo.

Ingeniería de software