IIS Unidad 4 Proyecto de software

Introducción a la Ingeniería de Software Carrera de Software
Ph.D. Franklin Parrales 1
23/10/2021
Proyecto de software
Unidad 4
Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo
para uso de los cursos de Introducción a la Ingeniería de Software

23/10/2021
Objetivo general de la Unidad 4
Evaluar la viabilidad y riesgo de un proyecto de
software a través de métricas y estimaciones para
asegurar una adecuada planificación de proyectos
de software

23/10/2021
Contenido
• Introducción a proyectos de software.
– Concepto de proyectos de software
– Características de los proyectos de software
• Planificación de proyectos de software.
– Recursos: Humano, Hardware y software.
– Métricas del software: Técnicas, calidad,
Orientada a las personas, Orientada al tamaño,
Orientada a la función.
– Estimación de proyectos: Modelo COCOMO.
– Identificación y análisis de riesgo

23/10/2021
Contenido

23/10/2021
Proyecto
• Proyecto es un trabajo multitarea que se
ejecuta una sola vez, con:
– un punto de inicio definido,
– un punto de terminación definido,
– un ámbito de trabajo claramente definido,
– un presupuesto, y
– Usualmente, un grupo de trabajo temporal

23/10/2021
Ciclo de vida del proyecto
• Los proyectos nacen cuando se identifica una necesidad de un
usuario (El usuario, puede ser una empresa , un funcionario de una
empresa o un país)
• La vida del proyecto es variable en extensión, desde una semana hasta
varios años
• No todos los proyectos se desarrollan formalmente a través de las
fases formales de la ejecución de proyectos
Gestión y
recursos
tiempo
Inicio Terminación
Fase
inicial
Fase
final
Fase
implementación

23/10/2021
Ciclo de vida del proyecto
Gestión y
recursos
Inicio Terminación
Fase
inicial
Fase
final
Fase
implementación
La producción del sistema da inicio, se
concluyen las instalaciones y se estabiliza el
sistema. Se desarrollan las actividades
rutinarias de operación y mantenimiento
En la fase inicial se efectúa la identificación
de necesidades, problema u oportunidad.
Requiere de documentar y armar un
preproyecto. Se efectúan los análisis de
soluciones y se desarrolla un requerimiento
de cotización.
Se efectúan los análisis de propuestas,
diseño detallado, las negociaciones
convenientes y se da la contratación
Se inician los preparativos y la recepción de
la solución, se capacita al personal, se
efectúan pruebas piloto y pruebas de
aceptación
tiempo

23/10/2021
Definición de software
• Para nosotros será el conjunto de
información:
– capaz de producir en las maquinas el
comportamiento deseado, de forma eficaz y
eficiente,
– que los usuarios puedan utilizar el sistema de
forma eficiente.
– Al que los desarrolladores puedan dar
mantenimiento de forma eficaz y eficiente.

23/10/2021
¿Que es un proyecto Informático?
• Crear una aplicación que automatice el trabajo.
• Implantar una aplicación que automatice el trabajo.
• Auditoria, ...
¿Que?
¿Como?
Hacerlo
Servicio de Aplicación
Analista
Diseñador
Programador
Usuario

23/10/2021
El proyecto de software como una obra
humana
• Algunos autores comparan el software a la
escritura de libros.
– Fruto del intelecto,
– Descripción de realidades y ficciones.
• Cuando el software es grande es como
una novela de varios tomos.

23/10/2021
Fases de un proyecto de tecnología
100 %
Porcentaje
de
avance
Factibilidad
• Formulación de proyecto
• Estudio de factibilidad
• Diseño de estrategia
• Protocolo de aprobación
Planeación y diseño
• Plan de actividades
• Costo y programa de
implementación
• Términos contractuales
y condiciones
• Planeación detallada
Implementación
• Preparación
• Entrega
• Instalación
• Pruebas
Producción
• Afinación
• Mantenimiento
Puesta a punto
de operación
Contratación
Aprobación
Preproyecto
Cierre
Plena
disponibilidad

23/10/2021
¿Porque es difícil desarrollar Software?
• Es complicado explicar los motivos que
hacen tan difícil desarrollar Software.
• Lo cierto es que muchos proyectos de
desarrollo de software fracasan
Área: Sistemas de Defensa en Tiempo Real
0 0.5 1 1.5 2 2.5 3 3.5
Millones de dolares
Pagado pero no entregado
Entregado pero no utilizado
abandonado o rechazado
Utilizado después de cambios
Utilizado como se entrego
Estadística
realizada
sobre
8
proyectos
de
Software
Estadounidenses.

23/10/2021
Gestión de proyectos
Methodology
Requerimientos
Recursos y
facilidades
Objetivos
de negocio
Riesgos y
restricciones
Riesgos y
restricciones
La gestión de proyectos tiene por objetivos el resolver las
necesidades del negocio, cuidando el costo de implementación y
asegurando la oportunidad para la entrega de los servicios y
facilidades

23/10/2021
Contenido

23/10/2021
Características de un proyecto
• Tiene un propósito bien definido
– Propósito especifico en procesos
– Es legitimo para el negocio de la empresa
• Esta compuesto de una serie de tareas
interdependientes
• Utiliza recursos diversos
• Tiene una duración especifica
• Tiene un propietario (usuario, coordinador, cliente)
• Contiene un grado de incertidumbre
• Requiere de metodología
• Requiere de interacción y negociación con terceros

23/10/2021
Características del software.
• Es inmaterial e invisible
• El comprador lo puede evaluar cuando
ya ha sido construido.
• El Software se desarrolla, no se fabrica.
• Es complejo. Los sistemas actuales
están formados por miles de funciones
con interfaces complejas entre ellas.
• Es excesivamente maleable.

23/10/2021
Contenido

23/10/2021
¿El trabajo como se organiza?
• Podemos dejar que
espontáneamente “ocurra”
– No me importa cuanto costará ni
para cuando estará (ideal si estas
en casa se trata de tu hobby).
• Podemos querer aclarar cuando
estará y cuanto costará.
– Cosa habitual en las empresas.

23/10/2021
¿Que es planificar un proyecto
Informático?
• Trazar un plan que nos permita:
– Evaluar lo que costará económicamente y en
tiempos el proyecto.
– Esbozar las tareas, personas, recursos y
asunciones que serán necesarias para que se
realice el plan.

23/10/2021
¿Que es planificar un proyecto
Informático?
EVALUACIÓN
ECONÓMICA
ESTIMACIÓN
DEL
ESFUERZO
IDENTIFICAR
TAREAS Y
ENTREGABLES
ASIGNAR
RECURSOS
PROGRAMAR
CALENDARIO
Esto no es un DFD aquí las cosas interactúan
Especificación
Plan

23/10/2021
Una vez realizada la planificación...
• El director del proyecto tendrá un
documento en el que se reflejaran:
– todos los recursos de que dispondrá.
– Las expectativas del cliente.
– Los compromisos de todos los implicados:
• Consultores,
• Constructores,
• La empresa cliente.

23/10/2021
Contenido

23/10/2021
Introducción
• Aprobada la realización del proyecto, la
gestión de éste se centra en dos temas:
– Crear un equipo de trabajo.
– Hacer un seguimiento de lo planificado.
• Ahora trataremos el: ¿cómo organizar un
equipo de trabajo?”

23/10/2021
¿El trabajo como se organiza?
• Podemos dejar que
espontáneamente “ocurra”
– No me importa cuanto costará ni
para cuando estará (ideal si estas
en casa se trata de tu hobby).
• Podemos querer aclarar cuando
estará y cuanto costará.
– Cosa habitual en las empresas.

23/10/2021
Visión global del desarrollo.
Clientes y
Usuarios
Desarrolladores
software
objetivo
Maquina
Personas, Equipos, Organizaciones
Ideas…Especificación… Diseño… Código

23/10/2021
Recursos del proyecto
project
people
skills
number
location
reusable
software
OTS
components
full-experience
components
new
components
part.-experience
components
environment
hardware
software
tools
network
resources

23/10/2021
Asignación de Recursos
• Consiste en asociar a cada una de las
tareas, en el proyecto, las personas y
materiales necesarios para que estas se
pueda realizar.
• Los recursos humanos constituyen el
componente económico mas importante
de los Proyectos Informáticos. Por encima
de los recursos físicos (HW e
Instalaciones)

23/10/2021
¿Recursos Humanos?
• Las personas no son recursos humanos. Son
individuos vivos, con todo su derecho a ser
diferentes.
• Las empresas
– Tienen en el conocimiento su principal recurso,
– Son organizaciones compuestas fundamentalmente
por especialistas que trabajaran de acuerdo a las
informaciones que reciben.

23/10/2021
Otros Recursos Importantes: El
Hardware
• Los costes del Hw
bajan de forma
continua.
• La utilización de
recursos Hw es
función de la cantidad
de personas
asignadas al proyecto

23/10/2021
Otros Recursos Importantes:
Los Consultores
• Son profesionales
externos.
• Soporte a tareas
donde la empresa no
tiene experiencia.
• Pueden llegar a
suponer un coste
similar al de los
desarrolladores, en
proyectos complejos.

23/10/2021
Otros Recursos Importantes:
Los Clientes y Usuarios
• Están presentes en todas las fases del
proyecto, fundamentalmente en:
– las primeras (análisis) y
– últimas (pruebas).
• No suelen tenerse en cuenta a la hora de
la planificación, se ve cuando:
– Se quejan: “Con el tiempo que...”
– Cuando un usuario se excusa de la asistencia
a una reunión…

23/10/2021
Tipos de recursos usuales.
• Trabajo
• Lugar de trabajo
• Equipamiento
• Material básico para el desarrollo
• Material fungible

23/10/2021
Trabajo
• Equipo de desarrollo
• Soporte al desarrollo
• Clientes y usuarios

23/10/2021
Lugar de trabajo
• Salas de reuniones
• Entorno de desarrollo
Silenciosos
Tranquilos
• Zonas para recogida de datos

23/10/2021
Equipamiento
• Mobiliario de oficina
• Ordenadores
• Material para
presentaciones

23/10/2021
Material básico para el desarrollo
• S.O., Lenguajes de desarrollo,
herramientas de desarrollo (case).
• Manuales del software: iniciación, manual
de usuario, librerías, etc..
• Libros con referencia a técnicas de
desarrollo

23/10/2021
Material fungible
• Material de escritorio: bolígrafos, clips,
grapas
• El material necesario para los equipos:
tinta o toner de impresora

23/10/2021
Límites duración del proyecto y
Asignación de recursos
• Un proyecto de 165 meses/hombre
• Una Persona en 15 AÑOS
– Ya no hará falta
– Costes de oportunidad
– Obsoleto para cuando lo entreguemos
– Puede hacer falta especialistas
• 3.300 Personas en un día
– Orden de las tareas

23/10/2021
La duración de los P.I. se deben
ajustar a los aspectos:
• ...del negocio,
• ...técnicos del desarrollo
– cantidad máxima de recursos en cada tarea,
• ...de gestión
– equipo de desarrollo lo más pequeño posible,
– de evitar problemas de comunicación y
coordinación.

23/10/2021
Duración de las tareas
• Recursos esfuerzo duración
• Esfuerzo y duración de las tareas
• Asignación de personas a tareas
• Tipo y duración de las tareas en función
de la cantidad de personas asignadas

23/10/2021
Esfuerzo y duración de las tareas
Esfuerzo Duración Recursos
Asignados
10 días 5 semanas 2 días/semana
10 días 1 semana 2 personas a
Tiempo
Completo

23/10/2021
Contenido

23/10/2021
Hay varias razones para medir un producto
1. Para indicar la calidad del producto.
2. Para evaluar la productividad de la gente
que desarrolla el producto.
3. Par evaluar los beneficios en términos de
productividad y de calidad, derivados del
uso de nuevos métodos y herramientas de
la ingeniería de software.
4. Para establecer una línea de base para la
estimación
5. Para ayudar a justificar el uso de nuevas
herramientas o de formación adicional.

23/10/2021
¿Por qué es tan importante medir el proceso de
ingeniería del software y el producto (software)
que produce?
La respuesta es relativamente obvia. Si no se
mide, no hay una forma real de determinar si se
está mejorando. Y si no se está mejorando, se
está perdido.

23/10/2021
Conceptos Básicos
• Medida: Indicación cuantitativa de la
extensión, cantidad, dimensiones, capacidad
o tamaño de algunos atributos de un proceso
o producto.
• Medición: Acto de determinar una medida
• Métrica: Medida cuantitativa del grado en que
un sistema, componente o proceso posee un
atributo dado.
• Indicador: Métrica o combinación de métricas
que proporcionan una visión profunda de un
proceso, producto o proyecto.

23/10/2021
Medidas, métricas e indicadores
Recopilación
de datos
Cálculo de
métricas
Evaluación de
métricas
Medidas
Métricas
Indicadores

23/10/2021
Indicadores
• Indicadores de Proceso: Permiten a una
organización tener una visión profunda de la
eficacia de un proceso ya existente. Permiten
evaluar lo que funciona y lo que no. Se recopilan
medidas durante un largo periodo de tiempo.
Proporcionan indicadores que lleven a mejoras
de los procesos de software.
• Indicadores de Proyecto: Permiten evaluar el
estado del proyecto en curso, seguir la pista de
los riesgos, detectar las áreas problemáticas,
ajustar las tareas y evaluar la habilidad del equipo
de trabajo.

23/10/2021
Mediciones del Software
• Medidas directas:
– Costo
– Esfuerzo aplicado
– Líneas de código
producidas
– Velocidad de ejecución
– Tamaño de memoria
– Defectos
informados/observados
en un determinado
periodo de tiempo
• Medidas indirectas:
– Funcionalidad
– Calidad
– Complejidad
– Eficiencia
– Fiabilidad
– Facilidad de mantenimiento
Pueden englobarse en dos categorías: medidas directas y medidas
indirectas.

23/10/2021
MÉTRICAS TÉCNICAS: Se centran en las características de software por
ejemplo: la complejidad lógica, el grado de modularidad. Mide la estructura
del sistema, el cómo esta hecho.
MÉTRICAS DE CALIDAD : proporcionan una indicación de cómo se
ajusta el software a los requisitos implícitos y explícitos del cliente. Es
decir cómo voy a medir para que mi sistema se adapte a los requisitos
que me pide el cliente.
MÉTRICAS DE PRODUCTIVIDAD . Se centran en el rendimiento del
proceso de la ingeniería del software. Es decir que tan productivo va
a ser el software que voy a diseñar.
MÉTRICAS ORIENTADAS A LA PERSONA . Proporcionan medidas e
información sobre la forma que la gente desarrolla el software de computadoras
y sobre todo el punto de vista humano de la efectividad de las herramientas y
métodos. Son las medidas que voy a hacer de mi personal que va hará el
sistema.
MÉTRICAS ORIENTADAS AL TAMAÑO. Es para saber en que tiempo voy a
terminar el software y cuantas personas voy a necesitar. Son medidas directas al
software y el proceso por el cual se desarrolla, si una organización de software
mantiene registros sencillos.
Métricas del software*
*Son
las
que
están
relacionadas
con
el
desarrollo
del
software
como:
funcionalidad,
complejidad,
eficiencia.

23/10/2021
Métricas del software orientadas al tamaño
Las métricas del software orientadas al tamaño provienen de la
normalización de las medidas de calidad y/o productividad
considerando el «tamaño» del software que se haya producido.
• Productividad = KLDC/persona-mes
• Calidad = errores/KLDC
• Documentación = pags. Doc/ KLDC
• Costo = $/KLDC

23/10/2021
Líneas de Código (LDC)
• Las líneas de código fuente (LDC o LOC) es
una métrica de software que se utiliza para
medir el tamaño de un programa informático
contando el número de líneas en el texto del
código fuente del programa.
• LOC se usa generalmente para predecir la
cantidad de esfuerzo que se requerirá para
desarrollar un programa, así como para
estimar la productividad de la programación o
la capacidad de mantenimiento una vez que
se produce el software.

23/10/2021
Métricas del software orientadas a la función
• Las métricas del software orientadas a la función
utilizan una medida de la funcionalidad entregada
por la aplicación como un valor de normalización.
• Ya que la funcionalidad no se puede medir
directamente, se debe derivar mediante otras
medidas directas.
• Punto de función: Se calcula determinando 5
características de dominio de información.
– Factor de Ponderación: simple, medio o complejo.
Valor de complejidad determinado de manera
subjetiva por c/ organización.

23/10/2021
Punto de función
factor de complejidad
puntos función
# de entradas de usuario
# de salidas de usuario
# de peticiones (consultas)
# de archivos
# of interfaces externas
parámetro de medida
3
4
3
7
5
conteo
factor de ponderación
simple prom. complejo
4
5
4
10
7
6
7
6
15
10
=
=
=
=
=
conteo-total
X
X
X
X
X

23/10/2021
Puntos de Función: Valores de ajuste
de complejidad

23/10/2021
Números de entrada de usuario: se cuenta cada entrada del usuario que
proporcione al software diferentes datos orientados a la aplicación. Las entradas
deben ser distinguidas de las peticiones que se contabilizan por separado.
Numero de salida del usuario: se encuentra cada salida que proporciona la
usuario información orientada a la aplicación. En este contexto las salidas se
refieren a informes, pantalla, mensajes de error. Los elementos de datos
individuales dentro de un informe se encuentran por separado.
Números de peticiones al usuario: una petición esta definida como una
entrada interactiva que resulta de la generación de algún tipo de respuesta
en forma de salida interactiva. Se cuenta cada petición por separado.
Numero de archivos: se cuenta cada archivo maestro lógico, o sea
una agrupación lógica de datos que puede ser una parte en una gran
base de datos o un archivo independiente.
Numero de interfaces externas: se cuentan todas las interfaces legibles
por la maquina por ejemplo: archivos de datos, en cinta o discos que son
utilizados para transmitir información a otro sistema.
Punto
de
función
1
2
3
4
5

23/10/2021
Métricas para la calidad del software
• El objetivo primordial de la ingeniería del software es producir
un sistema, aplicación o producto de alta calidad.
– Para lograr este objetivo, los ingenieros del software deben aplicar
métodos efectivos junto con herramientas modernas dentro del
contexto de un proceso maduro de desarrollo de software.
– Además, un buen ingeniero del software (y buenos gestores de la
ingeniería del software) deben medir si la alta calidad se va a llevar
a cabo.
• La calidad de un sistema, aplicación o producto es tan bueno
como los requisitos que describen el problema, el diseño que
modela la solución, el código que conduce a un programa
ejecutable, y las pruebas que ejercitan el software para
detectar errores.
– Un buen ingeniero del software utiliza mediciones que evalúan la
calidad del análisis y los modelos de diseño, el código fuente, y los
casos de prueba que se han creado al aplicar la ingeniería del
software.

23/10/2021
Medidas de la calidad(1)
Aunque hay muchas medidas de la calidad de software, la
corrección, facilidad de mantenimiento, integridad y
facilidad de uso proporcionan indicadores Útiles para el
equipo del proyecto.
• Corrección. Un programa debe operar correctamente o
proporcionará poco valor a sus usuarios.
– La corrección es el grado en el que el software lleva a cabo su
función requerida.
– La medida más común de corrección es defectos por KLDC, en
donde un defecto se define como una falta verificada de
conformidad con los requisitos.

23/10/2021
Medidas de la calidad (2)
• Facilidad de mantenimiento: El mantenimiento del
software cuenta con más esfuerzo que cualquier otra
actividad de ingeniería del software.
– La facilidad de mantenimiento es la facilidad con la que se
puede corregir un programa si se encuentra un error, se
puede adaptar si su entorno cambia, o mejorar si el cliente
desea un cambio de requisitos.
– No hay forma de medir directamente la facilidad de
mantenimiento; por consiguiente, se deben utilizar
medidas indirectas.
– Una simple métrica orientada al tiempo es el tiempo
medio de cambio (TMC), es decir el tiempo que se tarda
en analizar la petición de cambio, en diseñar una
modificación adecuada, en implementar el cambio, en
probarlo y en distribuir el cambio a todos los usuarios

23/10/2021
• Integridad: En esta época de hackers y firewalls la integridad
del software ha llegado a tener mucha importancia. Este
atributo mide la capacidad de un sistema para resistir ataques
contra sus seguridad.
– Para medir la integridad, se tienen que definir dos atributos
adicionales: amenaza y seguridad.
– Amenaza es la probabilidad (que se puede estimar o deducir de
la evidencia empírica) de que un ataque de un tipo determinado
ocurra en un tiempo determinado.
– La seguridad es la probabilidad (que se puede estimar o
deducir de la evidencia empírica) de que se pueda repeler el
ataque de un tipo determinado.
– La integridad del sistema se puede definir como:
integridad = Σ [( 1 - amenaza) x (1 - seguridad)]
– donde se suman la amenaza y la seguridad para cada tipo de
ataque.

23/10/2021
• Facilidad de uso: El calificativo amigable con el usuario se
ha convertido en omnipresente en las discusiones sobre
productos de software.
– Si un programa no es «amigable con el usuario»,
frecuentemente está abocado al fracaso, incluso aunque
las funciones que realice sean valiosas.
– La facilidad de uso es un intento de cuantificar «lo
amigable que puede ser con el usuario » y se puede medir
en función de cuatro características:
1. Habilidad intelectual y/o física requerida para aprender el sistema;
2. Tiempo requerido para llegar a ser moderadamente eficiente en el
uso del sistema
3. Aumento neto en productividad (sobre el enfoque que el sistema
reemplaza) medida cuando alguien utiliza el sistema moderadamente
y eficientemente; y
4. Valoración subjetiva (a veces obtenida mediante un cuestionario) de
la disposición de los usuarios hacia el sistema

23/10/2021
• Eficacia de la Eliminación de Defectos: Una métrica de la
calidad que proporciona beneficios tanto a nivel del proyecto
como del proceso, es la eficacia de la eliminación de defectos
(EED).
– EED es una medida de la habilidad de filtrar las actividades de
la garantía de calidad y de control al aplicarse a todas las
actividades del marco de trabajo del proceso.
– Cuando un proyecto se toma en consideración globalmente,
EED se define de la forma siguiente:
EED = E / (E + D)
donde E es el número de errores encontrados antes de la entrega del software al
usuario final y D es el número de defectos encontrados después de la entrega.
– El valor ideal de EED es 1. Esto es, no se han encontrado
defectos en ei software. De forma realista, D será mayor que
cero.

23/10/2021
Línea Base de métricas
• Estableciendo una línea base de métricas se
pueden obtener beneficios a nivel de proceso,
proyecto y producto (técnico).
• Sin embargo la información reunida no necesita
ser fundamentalmente diferente. Las mismas
métricas pueden servir varias veces.
• Las líneas base de métricas constan de datos
recogidos de proyectos de software desarrollados
anteriormente y pueden ser tan simples como una
tabla de datos o tan complejas como una gran
base de datos que contenga docenas de medidas
de proyectos y las métricas derivadas de ellos.

23/10/2021
Proceso de recopilación de métricas de SW
Proceso de
ingeniería del
software
Proyecto
del software
Producto del
software
Recopilación
de datos
Cálculo de
métricas
Evaluación de
métricas
Medidas
Métricas
Indicadores

23/10/2021
Contenido

23/10/2021
Estimación
Intento por determinar cuánto dinero, esfuerzo,
recursos y tiempo tomará construir un sistema o
producto específico basado en software

23/10/2021
Problemática de la estimación
• Averiguar lo que costara de desarrollar
una aplicación.(meses-persona, $, …)
• Momento en que se desea conocer el
coste (gráfico de Boehm)
• Siempre se quiere muy pronto (Yourdon)

23/10/2021
Proceso de Estimación propuesto
Medir lo que
quiere el
usuario
Estimar lo
que Costara
(esfuerzo)
Descomponer
por fases y
tareas
Historial
Empresa
Especificación de
requerimientos
Requisitos a
Cumplir
Medida de lo que
quiere el usuario
Estimación
del Esfuerzo
Tareas a
realizar

23/10/2021
Medir lo que quiere el usuario.

23/10/2021
Estimar lo que costara
• Experiencia Individual
• Experiencia de Empresa

23/10/2021
Siete maneras de estimar costos...
1. Modelado algorítmico de costos
– Usando algunas métricas de software (generalmente tamaño) e información
histórica de costos
– Puntos de Función, COSMIC FFP, Puntos de Objecto
– Fórmulas Matemáticas: Curva Raleigh-Putnam
– Modelos de Regresión: COCOMO
2. Juicio de un experto
3. Estimación por analogía
4. Ley de Parkinson
– El trabajo se amplía para llenar el tiempo disponible...
5. De acuerdo al precio para ganar el proyecto (Pricing to win)
6. Estimación Top-down
– Se estima en base a las funciones lógicas y no en base los componentes
requeridos para implementarlos.
7. Estimación Bottom-up
– Agregar el costo de los componentes hasta llegar al costo de todo el
producto.

23/10/2021
COnstructive COst MOdel I
B. Boehm (1981)
• Su primera versión surgió en 1981 (Bohem, 1981).
– "Software Engineering Economics" (Prentice-Hall, 1981)
• COCOMO I es una jerarquía de modelos de estimación de
costes software que incluye submodelos básico, intermedio y
detallado.
• Trata de establecer una relación matemática que permita
estimar el esfuerzo y tiempo requerido para desarrollar un
producto.
• La aparición y generalización del uso de las computadoras
provocó cambios en el modelo.
– En 1983 se introduce el lenguaje de programación ADA (American
National Standard Institute) para reducir los costos de desarrollo de
grandes sistemas. Aquello provocó un gran impacto en los costos
de desarrollo y mantenimiento.
– Sufrió un refinamiento para el desarrollo de software en ADA
(Bohem y Royce, 1989)

23/10/2021
Modelos de COCOMO I
B. Boehm (1981)
• Modelo básico: Este modelo trata de estimar, de una manera
rápida y más o menos burda, la mayoría de proyectos pequeños y
medianos.
• Modelo intermedio: En este modelo se introducen 15 atributos de
coste para tener en cuenta el entorno de trabajo. Estos atributos se
utilizan para ajustar el coste nominal del proyecto al entorno real,
incrementando la precisión de la estimación.
• Modelo detallado: Este modelo puede procesar todas las
características del proyecto para construir una estimación. Introduce
dos características principales
• Multiplicadores de esfuerzo sensitivos a la fase. Algunas fases se
ven más afectadas que otras por los atributos. El modelo detallado
proporciona un conjunto de multiplicadores de esfuerzo para cada
atributo. Esto ayuda a determinar la asignación del personal para cada
fase del proyecto.
• Jerarquía del producto a tres niveles. Se definen tres niveles de
producto. Estos son módulo, subsistema y sistema. La cuantificación se
realiza al nivel apropiado, esto es, al nivel al que es más susceptible la
variación.
1
2
3

23/10/2021
Constantes de COCOMO I: a y b
• Las ecuaciones de estimación del esfuerzo de desarrollo
tienen la forma
Effort = a * (SIZE)b *M
• a y b se pueden determinar por un procedimiento de
ajuste de curva (análisis de la regresión).
• Pero la mayoría de las organizaciones no tienen
suficientes datos para realizar dicho análisis.
• Por ello Boehm construyó el modelo e identificó 3 niveles
de dificultad (submodelos) que parecen categorizar
muchos proyectos de software.
• Otra asunción de COCOMO:
1 mes = 152 horas productivas
(8 horas por día, 19 días/mes)
(menos fines de semana, feriados, etc.)
Multiplicador
Miles de Líneas de código (KLOC) Factores de escala

23/10/2021
COCOMO I puede ser aplicado a tres tipos de proyectos software. Esto
nos da una impresión general del proyecto. Por ello incluye 3
submodelos con un nivel de detalle cada vez mayor
• Proyectos Orgánicos (Organic) – proyectos realmente sencillos,
menores de 50 KDLC (líneas de código), en los cuales se tiene
experiencia de proyectos similares y se encuentran en entornos
estables.
• Proyectos medianos (Semi-detached) – son intermedios en
tamaño (menores de 300 KDLC) y complejidad, donde la experiencia
en este tipo de proyectos es variable (no tienen la misma experiencia
todos los miembros del equipo), y las restricciones son intermedias
(hay más requisitos pero no son tan rígidos).
• Proyectos embebidos (Embedded) – Son proyectos software que
se deben desarrollar con unos requisitos de hardware, software y de
operación.
Submodelos de COCOMO I
B. Boehm (1981)

23/10/2021
Modelos de estimación COCOMO I
• Modelo básico
– El modelo básico se usa para obtener una
aproximación rápida del esfuerzo.
– Usa las variables a, b, c y d, que varían en función de
los modos.
– Conforme se aumenta la complejidad del modo,
aumentan los valores de las variables (esfuerzo).
Effort = a * (SIZE)b
1
Miles de Líneas de código Factores de escala
Submodelos básicos a b c d
Orgánico 2,4 1,05 2,5 0,38
Semi-acoplado 3,0 1,12 2,5 0,35
Empotrado 3,6 1,20 2,5 0,32

23/10/2021
Effort = a*(Volume)b
DevTime = c*(Effort)d
“KLOC”
PM Personas Mes
M Meses
“MODELO BASICO (Orgánico)”
Submodelos básicos a b c d
Orgánico 2,4 1,05 2,5 0,38
Semi-acoplado 3,0 1,12 2,5 0,35
Empotrado 3,6 1,20 2,5 0,32
ATENCIÓN: Hay que utilizar con mucho cuidado el modelo básico puesto que se
obvian muchas características del entorno.

23/10/2021
La ecuación de COCOMO en este modo básico es:
E = a(KLOC)b
D = c(E)d
P = E/D
C = P *Salario
Donde :
• E = El esfuerzo aplicado en persona-mes.
• D= El tiempo de desarrollo en meses.
• KLOC = El número de líneas estimadas para el proyecto (en miles o
kilos)
• P = El número de personas necesarias para el proyecto.
• C= Costo total del proyecto (P * Salario medio) entre los
programadores y analistas.

23/10/2021
Ejemplo “MODELO BASICO”
Partimos de conocer el número de líneas que tendrá la
futura aplicación: Volumen = 30000 LOC = 30KLOC
Proyecto Orgánico
Esfuerzo = 2.4 * (30)1.05 = 85 PM (Personas-Mes)
DevTime = 2.5 * (85)0.38 = 13.5 M (Meses)
=> Personas: 85/13.5 = 6.3 personas
=> Productividad: 30000/85 = 353 LOC/PM
Compare:
Medio: 135 PM 13.9 M 9.7 personas
Embebido: 213 PM 13.9 M 15.3 personas
Ej.:

23/10/2021
• Modelo Intermedio
– Añade al modelo básico 15 factores de ajuste, también llamados
multiplicadores del esfuerzo o guías de coste.
• Tamaño B.D., experiencia analistas, herramientas, … (15 en total,
varían de 0.75-1.66)
– Se logra una mayor precisión en la estimación gracias a los
nuevos factores.
– La fórmula es la misma que la del modelo básico pero con el
añadido del factor (multiplicando).
Effort = a * (SIZE)b *M
2
Multiplicador FAE
Submodelos intermedios a b c d
Orgánico 3,2 1,05 2,5 0,38
Semi-acoplado 3,0 1,12 2,5 0,35
Empotrado 2,8 1,20 2,5 0,32
FAE es un factor de ajuste de esfuerzo que normalmente fluctúa entre 0,9 y 1,4.

23/10/2021
Cálculo de FAE
Es a través de los Puntos de Función (PF).
Hoy en día es la forma más utilizada y para ello se requiere utilizar
los factores de conversión correspondiente al lenguaje utilizado.
Para ello se debe utilizar la siguiente tabla (Factores de costo), que
contiene 15 atributos que deben ser evaluados para el proyecto.
Estos atributos se utilizan para ajustar el esfuerzo del proyecto al
entorno real, incrementando la precisión de la estimación

23/10/2021
Atributos del modelo Intermedio
• Software:
• RELY: Indica las
consecuencias para el usuario
si falla el producto.
• DATA: Relación Tamaño de la
BD / Líneas de código.
• CPLX: Complejidad del
producto.
• Hardware:
• TIME: Limitaciones en el
porcentaje del uso de la CPU.
• STOR: Limitaciones en el
porcentaje del uso de la
memoria.
• VIRT: Volatilidad de la máquina
virtual.
• TURN: Tiempo de respuesta.
• Personal:
• ACAP: calificación de los
analistas.
• AEXP: experiencia del
personal.
• PCAP: calificación de los
programadores.
• VEXP: experiencia del personal
en la máquina virtual.
• LEXP: experiencia en el
lenguaje.
• Proyecto:
• MODP: uso de prácticas
modernas de programación.
• TOOL: uso de herramientas de
desarrollo de software.
• SCED: limitaciones en el
cumplimiento de la
planificación.

23/10/2021
Cálculo de FAE
Factores de Costo

23/10/2021
SIZE con Puntos de Función (1)
Después de valorizar los Factores de Costo del Proyecto, se procede a
valorizar los Factores Funcionales de Peso, con la siguiente tabla:
Para obtener los Factores Funcionales de Peso, se debe seleccionar la
complejidad del Proyecto, y multiplicarlo, por cada valor obtenido para los
factores funcionales. Para ello se requiere previamente un prototipo, del
cual se obtendrán N° de Entradas de usuario, N° salidas usuario, etc.
Luego de esto, se debe sumar el resultado total de la multiplicación para
los 5 puntos evaluados (factores funcionales de peso).

23/10/2021
SIZE con Puntos de Función (2)
Del resultado obtenido, se puede obtener los
puntos de función aplicando la siguiente
fórmula:
PF = [Σfactores funcionales de peso] * [0.65 +
(0.01 * Σfactores costo)]
El valor resultante de la conversión PF, debe
ser multiplicado por la tabla de conversión a
líneas de código (LOC), la cual está
determinada por el lenguaje de desarrollo a
utilizar en el proyecto.
LOC = PF * Correlación
La tabla de conversión es la siguiente ->
Tabla
de
Conversión
de:
Correlación
Código
Fuente
a
PF

23/10/2021
Ejemplo “SIZE con Puntos de Función”
Supongamos que se quiere desarrollar un proyecto transaccional
que operará en plataforma web y su tamaño es mediano.
¿Cuál será el esfuerzo requerido, tiempo de desarrollo, personal utilizado
en el proyecto ?
1

23/10/2021
Utilizando un prototipo se llena la tabla asociada a los factores de Peso.
PF = [Σfactores funcionales de peso] * [0.65 + (0.01 * Σfactores de costo)]
Aplicando la formula se tiene:
PF = [513] * [0,65 + (0,01 * 14,91)]
PF= 409,9383
Continuación Ejemplo:

23/10/2021
Continuación Ejemplo
Luego se procede a aplicar la formula de Conversión a LOC:
Como ya se dijo anteriormente, el lenguaje a utilizar es JAVA.
Entonces se tiene que
LOC = PF * Correlación
LOC = 409,9383 * 46
LOC =18857,1618 (Líneas de Código)
KLOC = 18857,1618 / 1000
KLOC = 19 (Kilo o miles de línea de código)

23/10/2021
Calculo de la variable FAE (multiplicador):
FAE = 0,88 * 1,08 * 1,15 * 1,3 * 1,00 * 1,15 * 1,00 * 1,29 * 0,86 *
1,21 * 1,07 * 0,91 * 0,91 * 1,1 = 2.137854971

23/10/2021
E = a(KLOC)b * FAE
D = c(E)d
P = E/D
C = P *Salario
Como ya se había dicho, el proyecto es de mediano tamaño.
Entonces se tiene:
Esfuerzo (E) = 3,0*( 19)1,12 * 2,137 = 173,48 meses/hombre
Duración (D)= 2,5*(173,48)0,35 = 6,07 meses
Personal (P)= 173,48 / 6.07 = 28,54 personas
Orgánico 3,2 1,05 2,5 0,38
Semi-acoplado 3,0 1,12 2,5 0,35
Empotrado 2,8 1,20 2,5 0,32

23/10/2021
Ejemplo “MODELO INTERMEDIO”
• Debemos desarrollar un
software de no muy elevada
dificultad, con las siguientes
restricciones:
• 3 meses para el desarrollo
del proyecto software.
• Debe estar implementado
en el lenguaje Visual Basic
• PF=261,36 (dato conocido)
• Calculo del esfuerzo:
Necesitamos hallar la
variable SIZE.
LENGUAJE LDC/PF
Ensamblador 320
C 150
COBOL 105
Pascal 91
Prolog/LISP 64
C++ 64
Visual Basic 32
SQL 12
2

23/10/2021
• SIZE = (PF * Líneas de código por cada PF)/1000 = (261,36*32)/1000
= 8,363
• Usaremos el tipo Orgánico ya que núestro proyecto no supera
las 50 KLOC, y es el mas apropiado en este caso.
• Coeficientes a usar:
Ejemplo estimación
Orgánico 3,2 1,05 2,5 0,38
Semi-acoplado 3,0 1,12 2,5 0,35
Empotrado 2,8 1,20 2,5 0,32

23/10/2021
• Calculo de la variable FAE (multiplicador):
CONDUCTORES DE COSTE VALORACIÓN
Muy
bajo
Bajo Nominal Alto Muy
alto
Extr.
alto
Fiabilidad requerida del software 0,75 0,88 1.00 1,15 1,40 -
Tamaño de la base de datos - 0,94 1.00 1,08 1,16 -
Complejidad del producto 0,70 0,85 1.00 1,15 1,30 1,65
Restricciones del tiempo de ejecución - - 1.00 1,11 1,30 1,66
Restricciones del almacenamiento principal - - 1.00 1,06 1,21 1,56
Volatilidad de la máquina virtual - 0,87 1.00 1,15 1,30 -
Tiempo de respuesta del ordenador - 0,87 1.00 1,07 1,15 -
Capacidad del analista 1,46 1,19 1.00 0,86 0,71 -
Experiencia en la aplicación 1,29 1,13 1.00 0,91 0,82 -
Capacidad de los programadores 1,42 1,17 1.00 0,86 0,70 -
Experiencia en S.O. utilizado 1,21 1,10 1.00 0,90 - -
Experiencia en el lenguaje de programación 1,14 1,07 1.00 0,95 - -
Prácticas de programación modernas 1,24 1,10 1.00 0,91 0,82 -
Utilización de herramientas software 1,24 1,10 1.00 0,91 0,83 -
Limitaciones de planificación del proyecto 1,23 1,08 1.00 1,04 1,10 -
Ejemplo estimación

23/10/2021
– Calculo de la variable FAE (multiplicador):
• FAE = 1,15 * 1,00 * 0,85 * 1,11 * 1,00 * 1,00 * 1,07 * 0,86 * 0,82 * 0,70
* 1,00 * 0,95 * 1,00 * 0,91 * 1,08 = 0,53508480
– Cálculo del esfuerzo del desarrollo:
• E = a (SIZE)b * FAE = 3,2 * (8.363)1,05 * 0,53508480 = 15,91 personas
/mes
– Cálculo tiempo de desarrollo:
• T = c Esfuerzod = 2,5 * (15,91)0,38 = 7,15 meses
– Productividad:
• PR = SIZE/Esfuerzo = 8363/15,91 = 525 ,64 LDC/personas mes
– Personal promedio:
• P = E/T = 15,91/7,15 = 2,22 personas
Ejemplo estimación
Según los resultados necesitaremos un equipo de 3 personas trabajando alrededor de 7 meses, pero
como una restricción era 3 meses incrementamos a 6 el numero de personas. 1 Jefe de proyecto, 2
Analistas, 2 programadores y 1 Responsable de calidad.

23/10/2021
• Modelo Detallado: Este modelo puede procesar todas
las características del proyecto para construir una
estimación. Introduce dos características principales:
– Multiplicadores de esfuerzo sensitivos a la fase.
Algunas fases se ven más afectadas que otras por los
atributos. El modelo detallado proporciona un conjunto de
multiplicadores de esfuerzo para cada atributo. Esto ayuda
a determinar la asignación del personal para cada fase del
proyecto.
– Jerarquía del producto a tres niveles. Se definen tres
niveles de producto. Estos son módulo, subsistema y
sistema. La cuantificación se realiza al nivel apropiado,
esto es, al nivel al que es más susceptible la variación.
3

23/10/2021
Modelo Detallado: Estimación del
esfuerzo
Fases de desarrollo: El desarrollo del software se lleva a
cabo a través de cuatro fases consecutivas:
requerimientos/planes, diseño del producto, programación
y prueba/integración.
1. Requerimientos/planes. Esta es la primera fase del
ciclo de desarrollo. Se analiza el requerimiento, se
muestra un Plan de Producto y se genera una
especificación completa del producto. Esta fase
consume del 6% al 8% del esfuerzo nominal Kn, y
dura del 10% al 40% del tiempo nominal de
desarrollo td. Estos porcentajes dependen del modo
y del tamaño (de 2000 LOC a 512000 LOC).

23/10/2021
Modelo Detallado: Estimación del
esfuerzo
2. Diseño del producto. La segunda fase del ciclo de
desarrollo COCOMO se preocupa de la determinación de
la arquitectura del producto y de las especificaciones de
los subsistemas. Esta fase requiere del 16% al 18% del
esfuerzo nominal Kn, y puede durar del 19% al 38%
del tiempo nominal de desarrollo td.
3. Programación.La tercera fase del ciclo de desarrollo
COCOMO se subdivide en dos subfases: diseño detallado
y prueba del código. Esta fase requiere del 48% al 68%
del esfuerzo nominal Kn, y dura del 24% Al 64% del
tiempo nominal de desarrollo.
4. Prueba/Integración. Esta última fase consiste
principalmente en unir las diferentes unidades ya
probadas. Se utiliza del 16% al 34% del coste nominal
Kn y dura del 18% al 34% del td.

23/10/2021
Problemas con COCOMO I
• ¿Cuál de los modelos aplica al software que queremos
estimar?
• La medición por líneas de código no es válida
para orientación a objetos; entre otras cosas por la
"reusabilidad" y la herencia, características de este
paradigma (e.g., puede implicar importante aumento en
productividad; pero no en líneas de código).
• COCOMO I excluye las siguientes actividades:
– Administración
– Gastos generales
– Viajes y Otros Costos Secundarios
– Factores del entorno de trabajo
• COCOMO I asume un modelo básico de proceso de cascada
– 30% diseño;
– 30% codificación;
– 40% integración y pruebas.

23/10/2021
4 diferentes modelos:
• Modelo De Composición De la Aplicación: prototipado,
uso de componentes existentes, basado en “Puntos de
Objetos”.
• Modelo de Diseño inicial: etapa del diseño de la
arquitectura, más cercano a COCOMO original, utiliza
Puntos de Función como estimación del tamaño.
• Modelo de Reuso: Usado para calcular el esfuerzo de
integrar componentes reutilizables.
• Modelo Post-Arquitectura: Para la etapa de desarrollo
propiamente dicha y mantenimiento; usa FP o LOCs
como medida del tamaño; modelo de COCOMO II mas
detallado.
COnstructive COst MOdel II
B. Boehm (1995)

23/10/2021
Fases Del Ciclo de Vida
Plans &
Requirements
Product
Design
Detailed
Design
Code
& Unit Test
Imple-
mentatio
n
Operations &
Maintenance
Phase
out
Inception Elaboration Construction Transition
LCR
SRR
PDR
CDR
UTC
SAR
Integration
& Test
IRR
LCO
LCA
IOC
PRR
Early Design Model Post Architecture Model
COCOMO II estimation endpoints
Waterfall
RUP

23/10/2021
Hitos (Milestones)
• Hitos del Modelo Cascada
– LCR = Revisión de los Conceptos del Ciclo de vida
– SRR = Revisión de los Requisitos del Software
– PDR = Revisión del Diseño del Producto
– CDR = Revisión de Diseño Crítico (walkthrough design)
– UTC = Satisfacción de los Criterios de las Pruebas de
Unidad
– SAR = Revisión de la aceptación del software
• Hitos del Desarrollo de Procesos RUP :
– IRR = Revisión de la preparación para el Inicio
– LCO = Revisión de los Objetivos del Ciclo de Vida
– LCA = Revisión de la Arquitectura del Ciclo de Vida
– IOC = Capacidad Inicial de las Operaciones
– PRR = Revisión de la Liberación Del Producto

23/10/2021
Objetos”.
• Modelo de Reuso. Usado para calcular el esfuerzo de
detallado.
B. Boehm (1995)
1

23/10/2021
Modelo De Composición De la Aplicación
Assess Object
Counts
Clasificación de
niveles de complejidad
Asignar un peso de
complejidad a cada objeto
Determinar puntos de
objeto (object points)
Calcular Nuevos
Object Points
Calcular la tasa de
Productividad
Calcular el esfuerzo
en personas-meses.
Se modela el esfuerzo
requerido para desarrollar
sistemas que se crean a
partir de componentes
reutilizables.
Se utiliza durante las primeras etapas de la
ingeniería de software, cuando la creación
de prototipos de interfaces de usuario, la
consideración del software y la interacción
del sistema y la evaluación del rendimiento
son primordiales.

23/10/2021
Assess object counts: Estime la cantidad de pantallas, informes y
componentes 3GL que compondrán esta aplicación.
Clasificación de niveles de complejidad:
o Sencillo
o Medio
o difícil
Asignar peso de complejidad a cada objeto:
Los pesos se utilizan para tres tipos de objetos
o Pantalla
o Reporte
o Componentes 3GL

23/10/2021
Determinar puntos de objeto (object points): Agregue todas las
instancias de objetos ponderados para obtener un número y esto se
conoce como recuento de puntos de objeto.
Calcular Nuevos Object Points: Tenemos que estimar el porcentaje
de reutilización a conseguir en un proyecto. Dependiendo del
porcentaje de reutilización, se calculan los puntos de nuevo objeto
(NOP).
Object Points * (100 - %reuse)
NOP = ---------------------------------------------
100
NOP son los puntos de objeto que deberán desarrollarse y difieren del
recuento de puntos de objeto porque puede haber reutilización
(porcentaje del desarrollo del Producto que se logra aprovechando la
existencia del esfuerzo de diseño o desarrollo del componente
existente).

23/10/2021
Calcular la tasa de Productividad: La tasa de productividad se puede
calcular como:
Productivity rate (PROD) = NOP/Person month
Calcular el esfuerzo en personas-meses: Cuando se conoce PROD,
podemos estimar el esfuerzo en meses-persona como:
NOP
Effort in PM = ------------
PROD

23/10/2021
Considere un proyecto de aplicación de base de datos con las
siguientes características:
➢ La aplicación tiene 4 pantallas con 4 vistas cada una y 7 tablas de
datos para 3 servidores y 4 clientes.
➢ La aplicación puede generar dos informes de 6 secciones cada uno
a partir de 7 tablas de datos para dos servidores y 3 clientes. Hay
un 10% de reutilización de puntos de objeto.
➢ La experiencia y la capacidad del desarrollador en un entorno
similar es baja. La madurez de la organización en términos de
capacidad también es baja. Calcule el recuento de puntos del
objeto, los puntos del nuevo objeto y el esfuerzo para desarrollar
dicho proyecto.
Ejemplo: Modelo De Composición De
la Aplicación

23/10/2021
Ejemplo: Modelo De Composición De la Aplicación
No. de vistas
contenidas en
una pantalla
Total<4
(<2 servidores
<3 clientes)
Total<8
(2-3 servidores
3-5 clientes)
Total 8+
(>3 servidores
>5 clientes)
<3 Simple Simple Medium
3-7 Simple Medium Difficult
>8 Medium Difficult Difficult
No. de
secciones
contenidas en
un reporte
Total<4
(<2 servidores
<3 clientes)
Total<8
(2-3 servidores
3-5 clientes)
Total 8+
(>3 servidores
>5 clientes)
0 o 1 Simple Simple Medium
2 o 3 Simple Medium Difficult
4+ Medium Difficult Difficult
Solución: Echemos un vistazo a las tablas para pantallas, informes, ponderaciones
de complejidad para cada nivel.

23/10/2021
la Aplicación
ObjectType Simple
Complexity
Medium
Complexity
Difficult
Complexity
Screen 1 2 3
Report 2 5 8
3GL - - 10
• Este proyecto se incluye en la categoría de modelo de estimación de
composición de aplicaciones.
• Número de pantallas = 4 con 4 vistas cada una
• Número de informes = 2 con 6 secciones cada uno
• Desde la Tabla de esta slide sabemos que cada pantalla será de
complejidad media y cada informe será de complejidad difícil.
• Usando la Tabla de pesos de complejidad, podemos calcular el
recuento de puntos del objeto
= 4 x 2 + 2 x 8 = 24

23/10/2021
la Aplicación
Experiencia y capacidad
del desarrollador
PROD (NOP/PM)
Very low 4
Low 7
Nominal 13
High 25
Very high 50
Usando la fórmula NOP se calcula como:
NOP = 24 * (100-10) /100=21.6
El valor bajo de la productividad se da en la tabla de
productividad anterior = 7
Esfuerzo en PM = NOP / PROD = 21.6 / 7 = 3.086 PM

23/10/2021
Objetos”.
detallado.
B. Boehm (1995)
2

23/10/2021
Modelo de Diseño Inicial
• Las estimaciones pueden realizarse cuando
se ha llegado a un acuerdo sobre los
requerimientos.
• Basada en una fórmula estándar
E = A  SizeB  M
– M = producto de todos los multiplicadores;
– A = 2.94 (calibración inicial),
– Size en KLOC,
– B varía desde 1.1 to 1.24 dependiendo de los factores
de escala.

23/10/2021
Factores de Escala B
• PREC = Precedencia (familiaridad con la
aplicación que se va a desarrollar)
• FLEX = Flexibilidad del Desarrollo
• RESL = Proceso de Resolución del Riesgo
• TEAM = Cohesión del Equipo
• PMAT = Madurez del Proceso
• El grado de RESL y TEAM es el promedio
subjetivo de las características mencionadas
posteriormente.
• PMAT es evaluado en base a los niveles de
madurez del SEI.

23/10/2021
Factores de Escala B

23/10/2021
If B=1.0, then Linear relationship b/w Effort & Size.
If B ≠ 1.0, then Non-Linear relationship b/w Effort & Size.
If B<1.0, then the rate of increase of effort decreases as the size of
the product increases.
If B>1.0, then the rate of increase of effort increases as the size of
the product increases.
B = 0.91 + 0.01 * (Sum of rating on scaling factors for the project)
When all the scaling factors of a project are rated as extra high,
then the best value of B= 0.91 (for COCOMO II.2000)
when all the scaling factors of a project are rated as very low,
Then the worst value of B= 1.23 (for COCOMO II.2000)
Hence, the value of B may vary from 0.91 to 1.23
Cálculo del Factor de Escala B

23/10/2021
Multiplicadores M
• RCPX = Confiabilidad y complejidad de producto.
• RUSE = Desarollo pensando en reutilización
• PDIF = Dificultad de la Plataforma
• PERS = Capacidad del Personal
• PREX = Experiencia del Personal
• FCIL = Recursos disponibles para el desarrollo
• SCED =Calendario requerido para el desarrollo.
Early Design
Cost Drivers
Extra
Low
Very
Low
Low Nominal High Very
High
Extra
High
RCPX 0.73 0.81 0.98 1.0 1.30 1.74 2.38
RUSE - - 0.95 1.0 1.07 1.15 1.24
PDIF - - 0.87 1.0 1.29 1.81 2.61
PERS 2.12 1.62 1.26 1.0 0.83 0.63 0.50
PREX 1.59 1.33 1.12 1.0 0.87 0.71 0.62
FCIL 1.43 1.30 1.10 1.0 0.87 0.73 0.62
SCED - 1.43 1.14 1.0 1.0 1.0 -

23/10/2021
Ejemplo: Modelo de diseño inicial
Question: A software project of application generator category with estimated 50 KLOC has to
be developed. The scale factor (B) has low precedentness, high development flexibility and
low team cohesion.
Other factors are nominal. The early design cost drivers like platform difficult (PDIF) and
Personnel Capability (PERS) are high and others are nominal.
➢Calculate the Effort in person-months for the development of the project.
Early Design
Cost Drivers
Extra
Low
Very
Low
Low Nominal High Very
High
Extra
High
RCPX 0.73 0.81 0.98 1.0 1.30 1.74 2.38
RUSE - - 0.95 1.0 1.07 1.15 1.24
PDIF - - 0.87 1.0 1.29 1.81 2.61
PERS 2.12 1.62 1.26 1.0 0.83 0.63 0.50
PREX 1.59 1.33 1.12 1.0 0.87 0.71 0.62
FCIL 1.43 1.30 1.10 1.0 0.87 0.73 0.62
SCED - 1.43 1.14 1.0 1.0 1.0 -

23/10/2021
B = 0.91 + 0.01 * (Sum of rating on scaling factors for the project)
= 0.91 + 0.01 * (4.96 + 2.03 + 4.24 + 4.38 + 4.68)
= 0.91 + 0.01(20.29)=1.1129
= 2.5 * (50)1.1129 = 194.41 Person-months
here A=2.5 (for COCOMO II.2000) predefined
The 7 cost drivers are:
PDIF = high (1.29) PERS = high (0.83)
RCPX = nominal (1.0) RUSE = nominal (1.0)
PREX = nominal (1.0) FCIL = nominal (1.0)
SCEO = nominal (1.0)
Solución :
= 194.41 * [1.29 x 0.83]
= 194.41 x 1.07
= 208.155 Person months

23/10/2021
Modelo de Diseño Inicial
1. Estimación del tamaño
– Líneas de código
– Puntos de Función no
ajustados (IFPUG), los
cuales se los debe convertir
a LOC.
2. Estimación de Esfuerzo (lo
obtiene el software)
3. Estimación de Tiempo (lo
obtiene el software)
http://softwarecost.org/tools/COCOMO/

23/10/2021
Objetos”.
detallado.
B. Boehm (1995)
3

23/10/2021
• Modelo de estimación más detallado.
• Se utiliza cuando se ha completado una arquitectura de ciclo de
vida del software.
• Se utiliza en el desarrollo y mantenimiento de productos de
software en los sectores de generación de aplicaciones, integración
de sistemas o infraestructura.
Donde
EM : Effort multiplier, el cual es el producto de 17 cost drivers.
PMnominal = Effort del Proyecto en person-months.
❑Lines of Codes Counting Rules
❑Function Points
❑Cost Drivers
Modelo Post-Arquitectura

23/10/2021
Cost Drivers of Post Architecture
• Required Software Reliability (RELY)
• Database Size (DATA)
• Product Complexity (CPLX)
• Documentation (DOCU)
• Required Reusability (RUSE)
Product
Attributes
• Execution Time Constraint (TIME)
• Platform Volatility (PVOL)
• Main Storage constraint (STOR)
Computer
Attributes
• Analyst Capability (ACAP)
• Personnel Continuity (PCON)
• Programmer Experience (PEXP)
• Programmer Capability (PCAP)
• Analyst Experience(AEXP)
• Language & Tool Experience (LTEX)
Personnel
Attributes
• Use of Software tools (TOOL)
• Required development schedule (SCED)
• Site Locations & Communications Technology
b/w sites (SITE)
Project
Attributes

23/10/2021
Cost Drivers of Post Architecture
Added Cost Drivers
7 cost drivers
• DOCU
• RUSE
• PVOL
• PLEX
• LTEX
• PCON
• SITE
Deleted Cost Drivers
5 Cost Drivers
• VIRT
• TURN
• VEXP
• LEXP
• MODP

23/10/2021
Cost
Drivers
Very Low Low Nominal High Very High Extra High
RELY 0.75 0.88 1.00 2.48 1.24 0.00
DATA 0.93 1.00 2.03 2.03 0.00
CPLX 0.75 0.88 1.00 2.83 1.41 0.00
RUSE 0.91 1.00 2.19 1.10 0.00
DOCU 0.89 0.95 1.00 3.12 1.56 0.00
TIME 1.00 1.11 1.31 1.67
STOR 1.00 1.06 1.21 1.57
PVOL 0.87 1.00 1.15 1.30
ACAP 1.50 1.22 1.00 0.83 0.67
PCAP 1.37 1.16 1.00 0.87 0.74
PCON 1.24 1.10 1.00 0.92 0.84
AEXP 1.22 1.10 1.00 0.89 0.81
PEXP 1.25 1.12 1.00 0.88 0.81
LTEX 1.22 1.10 1.00 0.91 0.84
TOOL 1.24 1.12 1.00 0.86 0.72
SITE 1.25 1.10 1.00 0.92 0.84 0.78
SCED 1.29 1.10 1.00 1.00 1.00
17
Cost
Drivers

23/10/2021
Estimación del Tiempo de desarrollo
El tiempo de desarrollo se puede calcular usando PMadjusted
como factor clave y la ecuación es :
Donde
= constant, provisionally set to 3.67, B = Scaling factor
TDEVnominal = calendar time in months with a scheduled constraint
PMadjusted = Estimated effort in Person months (after adjustment)
Size can be measured in any unit and the model can be calibrated
accordingly. However, COCOMO II details are:
I. Application composition model uses the size in object points.
II. The other two models use size in KLOC.
Size Measurement

23/10/2021
Ejemplo: Modelo Post-Arquitectura
Enunciado: A software project of application generator category with estimated
50 KLOC has to be developed. The scale factor (B) has low precedentness, high
development flexibility and low team cohesion.
The identified 17 Cost drivers are high reliability (RELY), very high database size
(DATA), high execution time constraint (TIME), very high analyst capability
(ACAP), high programmers capability (PCAP). The other cost drivers are nominal.
➢
➢Calculate the effort in Person-Months for the development of the project.
Here B = 1.1129
PMnominal = 194.41 Person-months
= 194.41 x (1.15 x 1.19 x 1.11 x 0.67 x 0.87)
= 194.41 x 0.885
= 172.05 Person-months
Solución :

23/10/2021
Contenido

23/10/2021
El Fracaso y sus Causas.
• Los proyectos Informáticos fracasan por:
– El SW nunca llega a funcionar.
– No se cumplen los plazos de entrega.
– No cumple con las funcionalidades esperadas.
• Razones:
– La complejidad era muy alta (comunicaciones,
interrelación con otros sistemas, etc..)
– Incertidumbre. No se tenia una idea clara de lo que
se quería obtener.

23/10/2021
Definición de Riesgo
• Riesgo es un problema potencial.
– Un problema es un riesgo materializado.
• Por problema entendemos una situación no
deseable en la que necesitaremos tiempo o
dinero para solucionarla.
• Un problema potencial se caracteriza por:
– La probabilidad de que ocurra (0<P<1)
– Una perdida asociada, cuantificable
– ...

23/10/2021
Circunstancias no previstas / intangibles
Un proyecto puede
convertirse en una
serie de reacciones y
eventos no esperados
• Las circunstancias no previstas ponen en riesgo el
cumplimiento de los objetivos del proyecto
• El reto para el responsable del proyecto es prevenir,
anticipar
y manejar tales circunstancias
• El proyecto debe contener los elementos para el manejo y
reducción de riesgos:
• Plan de contingencia
• Diseño del elemento contractual
• Capacidad de negociación
• Alternativas técnicas
• Recursos externos a los originales

23/10/2021
Formas en las que se afrontan las
causas de las desviaciones
• Podemos observar que hay dos puntos de vista
respecto a la gestión de riesgos en P.I.
– muchas de las causas de fracaso se los P.I. son
comunes.
• Se identifican e intenta situar a la organización en una
situación fuerte.
– cada proyecto tiene unos riesgos específicos,
• hay que gestionar los riesgos de forma especifica en cada
caso.
• Realmente son visiones complementarias del
problema

23/10/2021
Causas comunes de fracaso (1)
(Caper Jones)
• Ambigüedad del objetivo.
• Requerimientos Cambiantes.
• Tardó demasiado para el mercado.
• Estimaciones inadecuadas.
• Oficinas de trabajo muy llenas.
• Presión excesiva de la planificación.
• Fricciones:
– Contratistas y Clientes.
– Directores Empresa y SW.
• Salarios inadecuados.

23/10/2021
(Caper Jones)
• Falta de especialización.
• Inadecuada estimación de la calidad
• Sistema de adquisición de paquetes
inadecuado
• Inadecuada política de estándares
• Herramientas y métodos inadecuados
• Inadecuado control de configuración.
• Documentación inadecuada
• Falta de reutilización de código, datos,
pruebas, interfaces

23/10/2021
(Caper Jones)
• Bajo nivel de satisfacción de los usuarios.
• Curriculum inadecuados en los desarrolladores.
• Costes altos de mantenimiento.
• Ciclos de vida parciales.
• Inversiones pobres en tecnología.
• El síndrome de la bala de plata.
• Baja productividad.

23/10/2021
Causas especificas.
Gestión de los Riesgos.
• “Cuando un proyecto tienen éxito, no es
porque no haya tenido problemas, sino
porque se han superado.”
• Podemos actuar de dos formas:
– Reactivamente:
• esperamos que aparezcan los problemas y los
solucionamos.
– Proactivamente:
• Tratamos de identificar problemas potenciales y
los atajamos

23/10/2021
Primer análisis de riesgos
• Identificar los riesgos más probables para
el proyecto
• Estimar el costo / impacto si el riesgo se
vuelve un problema
• Identificar las señales que indiquen que el
riesgo se está volviendo un problema
• La intención es balancear los beneficios
con sus riesgos
• Un riesgo no forzosamente es algo malo.

23/10/2021
Evaluación y toma de decisión de
seguir adelante
• En base a lo anterior se analiza si:
– ¿Los objetivos son viables y medibles?
– ¿Son factibles?
– ¿Son los riesgos demasiado altos?
– ¿Es el costo de los objetivos razonable?
– ¿Las personas implicadas están de acuerdo y
dispuestas?
– ¿Se justifica el proyecto?
– ¿Hay razones para cancelarlo?

23/10/2021
Elementos de la Gestión de Riesgos
1. Identificar los factores de Riesgo.
2. Evaluar la probabilidad y el efecto sobre el
proyecto.
3. Desarrollo de estrategias para mitigar los
riesgos.
4. Monitorizar los factores de riesgo.
5. Invocar el plan de contingencias.
6. Gestionar la crisis.
7. Recuperarse de la crisis.
» Fairley, R. IEEE Software Mayo 1994

23/10/2021
Identificar los factores de Riesgo
• Se trata de visualizar el desarrollo y tomar
notas de las cosas “malas” que podrían
ocurrirnos.
• Es aconsejable el disponer de una lista
con los problemas acaecidos en otros
proyectos y revisarla.
– “Quien no conoce su pasado esta condenado
a repetirlo”
1

23/10/2021
Identificar los factores de Riesgo
• Hay que diferenciar entre causa (factores
de riesgo), problema y síntomas.
• Todos los problemas potenciales no son
malos, realmente son los que hacen que
este proyecto no se haya realizado
anteriormente.
– El mismo problema puede se visto como un
reto, una oportunidad o algo indeseable.

23/10/2021
Identificación de los riesgos
1. Reunir los stakeholders para revisar y adaptar una lista
de potenciales riesgos de requerimientos
• Para esto es necesario usar una lista inicial de riesgos
comunes, como por ejemplo:
– Falta de involucramiento del usuario.
– Expectativa del cliente poco realista.
– Los desarrolladores añaden funcionalidades innecesarias.
– Constante cambio de requerimientos.
– Pobre análisis del impacto cuando las necesidades cambian y
evolucionan.
– Uso de nuevas técnicas o herramientas de requerimientos.
– Requisitos poco claros, ambiguos.
– Requisitos contradictorios (conflictivos).
– Falta de requisitos.
– Lluvia de ideas para identificar riesgos adicionales en base a la
experiencia del equipo, como de la cultura de la empresa y su
medio ambiente

23/10/2021
2. Clasificar los riesgos
• Analizar cada riesgo de acuerdo a su probabilidad y su impacto.
• La probabilidad. Riesgo estimado para causar un problema. Usar
una escala o rango como es:
a) Bajo: Remota posibilidad que el riesgo se realizará. Entre 0% - 25%.
b) Medio: Probabilidad moderada que ocurra el riesgo. Entre 26% -
74%.
c) Alto: Gran probabilidad o certeza de que el riesgo ocurra. Entre 75% -
-- 100%
• El impacto es el grado en que el riesgo afectan negativamente al
proceso de requisitos.
a) Bajo: Puede presentar algún impacto, insignificante.
b) Medio: Impacto manejable o marginal.
c) Alto: Impacto critico o catastrófico. Principales problemas que
necesitan ser analizados.
• Clasificar cada riesgo de acuerdo a cada dimensión (probabilidad e
impacto)

23/10/2021
3. Representar gráficamente las clasificaciones y
ponerse de acuerdo en los riesgos que se
abordarán.
• Una forma de representar la clasificación final podría
ser:
Relación entre la
probabilidad e
impacto de los
riesgos

23/10/2021
4. Determinar las formas de controlar, evitar o
mitigar los posibles riesgos críticos
– Asignar cada riesgo crítico a un miembro del equipo quien
tendrá la responsabilidad de monitorear el riesgo.
Identificar las acciones que él o ella tendrá, los recursos
necesarios para llevar acabo las acciones, y la manera
que él o ella comunicará las acciones al equipo.
– Asegurar que el sponsor y el líder del equipo estén de
acuerdo con las acciones.
– Asegurarse que los miembros del equipo entienden como
sus acciones afectan sus requerimientos.
– Monitorear los riesgos a lo largo del desarrollo y gestión
de requisitos.
– Analizar y adicionar nuevos riesgos a los requerimientos
como ocurran, y actualizar la estrategia de mitigación de
riesgo como sea necesario.

23/10/2021
Algunos riesgos y estrategias que comúnmente ocurren
en los proyectos de desarrollo
Riesgos comunes en los
requerimientos
Estrategias de mitigación
Falta de participación del usuario
• Identificar a los interesados del producto.
• Crear un plan de participación de interesados.
• Usar técnicas de elicitación que atraigan a los usuarios en el
proceso
Expectativas poco realistas de los
clientes.
• Crear la visión del producto.
• Desarrollar modelos de alcance del proyecto.
• Validar requerimientos con prototipos operacionales.
Desarrolladores agregan
funcionalidades innecesarias .
• Crear la visión del producto.
• Priorizar requerimientos.
Constante cambio de
requerimientos.
• Desarrollar modelos de alcance.
• Crear una línea base para requerimientos y establecer
mecanismos de control de cambios.
Pobre análisis del impacto cuando las
necesidades cambian y evolucionan.
• Crear una línea base y seguimiento de requerimientos.
• Formalizar documentos de requerimientos.
Uso de nuevas técnicas o herramientas de
requerimientos.
• Adaptar los procesos de requerimientos para el
proyecto.
• Conducir una retrospectiva de los requerimientos.
Requisitos poco claros, ambiguos.
• Desarrollar la visión del producto.
• Desarrollar múltiples modelos de requerimientos.
• Validar los requerimientos.
Requisitos contradictorios
(conflictivos).
• Formalizar el documento de visión.
• Validar los requerimientos con el modelo de validación.
Falta de requisitos
• Desarrollar múltiples modelos de requerimientos.
• Verificar la falta de requerimientos con el modelo de
validación.

23/10/2021
Evaluar la probabilidad y el efecto
sobre el proyecto
• Evaluar la probabilidad de tener el problema.
• Evaluar los efectos sobre el proyecto.
• Clasificar los riesgos en base a la
EXPOSICIÓN AL RIESGO, que se calcula
como:
– Probabilidad * Efecto
• Como consecuencia de esta clasificación
habrán riesgos importantes y otros menores.
2

23/10/2021
Evaluación de la probabilidad de que
se de el problema.
• No todos tienen la misma probabilidad.
• Aveces es difícil asignar una probabilidad
a un problema en concreto,
– Casos similares.
– Optimista, pesimista y lo mas probable.
– Recordar la ley de Murphy:
• “Si algo puede salir mal, saldrá mal.”
• Existen herramientas de simulación.

23/10/2021
Desarrollo de estrategias para mitigar
los riesgos
• Las estrategias
pueden ser de dos
tipos:
– Plan de Acción.
• minimizamos o
hacemos desaparecer
el riesgo.
– Plan de Contingencia.
• aceptamos el riesgo y
preparamos el plan por
si el problema se
materializa.
3

23/10/2021
Plan de Acción
• Minimizamos o hacemos desaparecer el
riesgo.
• La acción se realiza antes de que pueda
darse el problema.
– Por ejemplo:
• Problema: Pueden aparecer dificultades al utilizar
nuevas herramientas.
• Acción: Contratamos a personas experimentadas
con estas herramientas.

23/10/2021
Plan de Contingencia
• Aceptamos el riesgo y preparamos el plan
por si el problema se materializa.
• Las actividades a realizar son las siguientes:
– Identificar las variables a monitorizar (factores de
riesgo) para detectar que el problema se ha
materializado.
– Crear un plan de acción para la Crisis,
consecuencia de este problema.
– Planificar la recuperación de esta crisis.

23/10/2021
Mitigar el riesgo en los requerimientos
• Los riesgos en los requerimientos son sucesos o
condiciones que ponen en peligro el desarrollo
satisfactorio del producto.
• Los riesgos deben ser evaluados, rastreados y
controlados a lo largo del proyecto, esto ocasiona
que se pueda tener un gran impacto de éxito en el
proyecto.
• Es necesario establecer estrategias que permitan
evaluar los requerimientos relacionados con el
riesgo e identificar acciones para evitar o
minimizar estos riesgos.

23/10/2021
Estrategia para mitigar el riesgo en los
requerimientos
• La estrategia para mitigar el riesgo en los
requerimientos, permite:
– Identificar los riesgos que podrían impedir el
desarrollo efectivo y la gestión de requisitos.
– Involucrar múltiples stakeholders que categorizan
el riesgo de cada requerimiento de acuerdo a su
grado de ocurrencia y a su impacto.
– Al equipo comunicar honestamente acerca de los
potenciales obstáculos.
– Identificar alternativas para administrar los
riesgos por parte del equipo.

23/10/2021
Ejemplo: catálogo de riesgos y estrategias de mitigación
Factor de riesgo Probabilidad Impacto
Estrategia de mitigación
Responsable
Falta de
disponibilidad del
rector para aclarar el
alcance
Media Alto Llevar a cabo un taller de
visionamiento con el actual
rector y crear modelos de
alcance en el taller.
Juan Peralta
(Gerente proyecto)
No involucramiento
del contratista
Media Alto Llevar a cabo una visita (por
ejemplo en el lugar de trabajo
hacer el seguimiento por un
medio día).
Llevar a cabo una entrevista con
el contratista cada cierto periodo
de tiempo.
María Piguave
(Analista).
Poco interés de las
secretarias de los
centros
Media Bajo Realizar un taller para indicar
las bondades de un sistema
automatizado.
Juan Peralta
(Gerente proyecto)
Poco interés de las
secretarias de
escuela
Alto Alto Realizar reuniones informativas
sobre el nuevo proceso
automatizado para resolver los
trámites de los estudiantes.
Juan Peralta
(Gerente proyecto) y
el sponsor del
proyecto.

23/10/2021
Monitorizar los factores de riesgo
• Se trata de los síntomas que hemos identificado
en el caso anterior, agrupados.
• Deberán de cuantificarse de forma precisa
mediante medidas objetivas y puntuales.
• Hay que disponer de un sistema de trazabilidad
entre los factores de riesgo y los problemas
asociados, así como los limites de control.
4

23/10/2021
Invocar el plan de contingencias
• Sí algún factor de riesgo excede los
limites de control habrá de tomarse las
medidas previstas.
• Es habitual varios niveles limites,
– ante los primeros excesos se notifique el
problema a nivel operativo,
– si este no se corrige, se excede el siguiente
limite, se pondrá en marcha el plan de
contingencia previsto.
5

23/10/2021
Gestionar la crisis
• El que la situación de crisis este prevista no
quiere decir que podamos relajarnos, más bien
al contrario. Deberemos estar más atentos al
control de la crisis y del resto.
• Puedes suceder que el plan de contingencia:
– funcione de acuerdo a lo previsto.
– fracase. En este caso pasaremos a una situación de
crisis (vista en el tema anterior)
6

23/10/2021
Recuperarse de la crisis
• Si el plan de contingencia ha ido de
acuerdo a lo previsto como si no,
deberemos:
– Recompensar a las personas a las que se ha
forzado a trabajar más duro (ver tema
anterior),
– Replanificar el proyecto con los retrasos y los
costes que esa situación hayan provocado.
7

23/10/2021
Proyecto de software
Unidad 4
Final de la unidad
Y del curso…. !Muchas gracias
a todos!

IIS Unidad 4 Proyecto de software

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a IIS Unidad 4 Proyecto de software

Similar a IIS Unidad 4 Proyecto de software (20)

Más de Franklin Parrales Bravo

Más de Franklin Parrales Bravo (20)

Último

Último (11)

IIS Unidad 4 Proyecto de software