TÉCNICAS DE DOCUMENTACIÓN Y ARCHIVO
Contenido
5 5.2. Evaluación del costo beneficio
PLANIFICACIÓN DE PROYECTOS DE
SOFTWARE
Dr. Ing. CELEDONIO MÉNDEZ
Gestión de proyectos
• La gestión de proyectos de software se hace
necesaria ya que todo proyecto esta sujeto a
restricciones de presupuesto y tiempos.
• La gestión permite asegurar que el software se
lleve a cabo a tiempo y de acuerdo con los
requerimientos especificados.
…Gestión de proyectos
• Las actividades comunes de la gestión de
proyectos software son:
– Redacción de la propuesta.
– Planificación del proyecto
Estimaciones de costo, tiempo y esfuerzo.
– Supervisión y revisión del proyecto.
– Selección y evaluación del personal.
– Redacción y presentación de informes.
5.1. Planificación del tiempo
5.3. Estudio de viabilidad
5.4. Planificación de la documentación
5.5. Gestión de la configuración del software
…Gestión de proyectos
La gestión de proyectos de software son particularmente
difíciles, algunas de las razones son:
– El producto de software es intangible.
– No hay un proceso estándar.
– A menudo los proyectos de software grandes son
únicos.
Que es la Planificación
• Es una guía de desarrollo para cumplir las metas
del proyecto.
• Es un proceso iterativo el cual termina hasta que
el proyecto mismo haya terminado. Esto quiere
decir que su revisión es continua, ya que tanto
requerimientos como restricciones pueden
cambiar a lo largo del desarrollo
1
 Importancia de la Planificación Actividades de la Gestión y
la Planificación
• El éxito o fracaso de un proyecto de software Planificación del
depende en gran parte de la planificación, ya que tiempo
(calendarización)
con ayuda de ésta se pueden evitar problemas a GESTION DE
PLANIFICACION
los que un proyecto está sujeto, tales como: PROYECTOS
• Propuesta
Estimación de
– Retraso de tiempo de entrega • Planificación costos (esfuerzo)
• Supervisión
– Sobrepasar el presupuesto • Personal
• Informal
– Baja calidad del producto Gestión de riesgos y
control de calidad
– Alto costo de mantenimiento, etc.
Gestión de la
configuración de sw

5.1. Planificación del tiempo

• El factor tiempo es muy importante en el
5.1 desarrollo de software ya que ganaremos o
perderemos a un cliente si este no es entregado
en los tiempos establecido o ya negociados.
PLANIFICACIÓN DEL TIEMPO
• La planificación de tiempo se puede definir
como una actividad en la cual se debe estimar
el tiempo que requerirá para llevar a cabo una
tarea y los recursos necesarios para su
realización.

Actividades e Hitos Actividades e Hitos en el desarrollo

de software
• Durante la recolección de requerimientos, se listan
todos los elementos que se deben entregar del
proyecto (actividades e hitos), que son los ítems
que los clientes esperan ver durante el desarrollo
del proyecto.

• La descomposición en hitos y actividades beneficia:

– Tanto a clientes como desarrolladores para
entender el desarrollo y mantenimiento del
sistema.
– Al gestor para juzgar el progreso del software y
puede entonces actualizar costos y el calendario.

2
 Calendarizar el proyecto 5.1.1 Métodos de Planificación
• Una vez definidas las actividades y hitos se debe temporal
calendarizar el proyecto (dividir el trabajo en actividades
o tareas complementarias y considerar el tiempo que
• Existen varios métodos para la planificación :
requiere cada una). – La técnica de revisión y evaluación del
programa(PERT)
• Generalmente se representa con gráficos de barras y
grafos o redes de actividades que muestran las – CPM la ruta crítica
actividades, los responsables, la dependencia entere
actividades y la asignación de recursos.
• También existen varias representaciones gráficas
como son:
• El gestor debe coordinar las tareas del trabajo, asignarles – Redes de actividades
personal y otros recursos de tal manera que se
aprovechen de manera óptima. Las actividades por lo – Gráficos de barras
general duran al menos una semana, la cantidad de
tiempo máxima sugerida es de 8 a 10 semanas.

Diagrama de Actividades
Diagrama de Actividades
Por, medio de una red de actividades se muestra la
dependencia entre las diferentes actividades y se estima el 3 10

tiempo en que tardará cada tarea, se debe considerar que 1

algunas de éstas se podrán realizar en paralelo. 6

Es el tiempo mínimo
2
7 11
requerido para
Tarea T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12 finalizar el proyecto

Duración (días) 8 15 15 10 10 5 20 25 15 15 7 10

4
T1 T2,T4 T1,T2 T1 T4 T3, T6 T5, T7 T9 T11 5
(M1) (M2) (M3) (M1) (M5) (M4) (M7) (M6) (M8)
Dependencias
9 12

•M representa un Hito

Diagramas Gantt … Diagramas Gantt

En un diagrama Gantt las actividades son seguidas
por una barra sombreada (azul) y cuya longitud es
calculada por una herramienta de calendarización.
La barra azul indica que hay flexibilidad en la fecha
de terminación para dichas actividades. Entonces la
ruta crítica se ve afectada solamente si:
• Las actividades que no tienen barra azul no se
completan a tiempo.
• Las actividades con barra azul pasa del límite de
tiempo marcado por ésta.

3
 Personas asignadas a diferentes Métodos PERT (Program Evaluation and Review
Actividades en el Proyecto Technique) y CPM(Crítical Path Method)

Ambos métodos aportaron los elementos

Tarea Ingeniero

Jorge
administrativos necesarios para formar el método del
T1 José

T2 Ana camino crítico actual, utilizando el control de los tiempos

T3 José José de ejecución y los costos de operación, para buscar que
T4 Jorge

T5 María
el proyecto total sea ejecutado en el menor tiempo y al
T6 Ana menor costo posible.
Ana
T7 Raúl

T8 Jorge Tanto PERT como CPM hacen uso de diagramas o redes

T9 José
Raúl
de actividades.
T10 Ana

T11 Jorge

T12 Jorge María

El método PERT Pasos en el planteamiento de PERT

• El método PERT se desarrolló para proyectos con
incertidumbre en el tiempo de las actividades
1. Identificar las actividades y su
(usualmente debido a que el proyecto nunca se había
intentado antes y por tanto no había bases de datos, interdependencia
para los tiempos de las actividades). Esto condujo al 2. Determinar la secuencia de actividades
enfoque probabilístico que se tomó.
3. Construir el diagrama de red
• La principal desventaja es que no es funcional para
grandes proyectos, debido a los tres estimados de 4. Tiempos estimados de actividades
tiempo que se requieren en cada actividad. Además, el 5. Determinar la trayectoria crítica
costo de actualizar y mantener la información del
proyecto con el tiempo en ambientes tan dinámicos, 6. Actualizar según el progreso del proyecto
puede ser excesivamente prohibitivo.

El método CPM Pasos en CPM

El CPM se desarrolló para manejar proyectos
repetitivos o similares (ej., mantenimiento de
plantas químicas).
Obviamente, se gana gran cantidad de
experiencia con el tiempo en tales
circunstancias, aun cuando dos proyectos
puede que no sean iguales.
1. Especificar las actividades individuales.
2. Determinar la secuencia de esas actividades.
3. Dibujar el diagrama de la red.
4. Estimar el tiempo de terminación para cada
actividad.
5. Identificar la ruta crítica (la trayectoria más larga
a través de la red)
6. Actualizar el diagrama del CPM

4
 Método del camino crítico … Método del camino crítico
No solamente se llama camino crítico al
Desde otro punto de vista, camino crítico es
método sino también a la serie de actividades
la trayectoria crítica de mayor duración a
contadas desde la iniciación del proyecto
través de la red. Debido a su impacto en el
hasta su terminación, que no tienen
proyecto entero, el análisis de trayectoria
flexibilidad en su tiempo de ejecución, por lo
crítica es un aspecto importante del
que cualquier retraso que sufriera alguna de
planeamiento del proyecto.
las actividades de la serie provocaría un
retraso en todo el proyecto.

Diferencias entre PERT y CPM

PERT es un método
Probabilístico.
CPM es un método
Determinístico.
5.2
Considera que la variable Considera que los tiempos
de tiempo es una variable de las actividades se EVALUACIÓN DE COSTO-BENEFICIO
desconocida de la cual conocen y se pueden variar 4.2.1. Métricas de Software
solo se tienen datos cambiando el nivel de
estimados. recursos utilizados. 4.2.2. Estimación del proyecto del software
4.2.2.1. Técnicas para la estimación de Software
4.2.2.2. Modelos de estimación
Considera tres tiempos Considera tiempos
4.2.2.3. La decisión a desarrollar o comprar
estimados: normales y acelerados de
4.2.2.4. Herramientas automáticas de estimación
o El más probable una determinada actividad,
o Optimista, según la cantidad de 4.2.3. Evaluación del costo beneficio
o Pesimista. recursos aplicados en la 4.2.3.1. Métodos para el análisis Costo/Beneficio
misma.

5.2 Evaluación del costo-beneficio … Evaluación del costo-beneficio

Actualmente el Software es el elemento más caro en
la mayoría de los sistemas de información, por lo que
la estimación debe realizarse cuidadosamente ya que
un gran error en la estimación del costo puede definir
la diferencia entre beneficios y pérdidas tanto para
clientes y la empresa desarrolladora de software.
Algunas razones por las cuales es crucial
comprender cual será el costo aproximado son :
– Los costos sobredimensionados pueden causar
que los clientes cancelen el proyecto.
– Los costos subestimados pueden no compensar
el tiempo invertido por el equipo del proyecto.
– No se debe olvidar que la estimación es una
actividad compleja que se vale de modelos y de
técnicas y estos a su vez se basan en métricas,
por lo que es necesario profundizar sobre éstas.

5

5.2.1. Métricas de software
“Cuando se puede medir lo que se esta
diciendo y expresarlo con números, significa
que tenemos conocimientos sobre ese tema,
cuando esto no ocurre significa que nuestro
conocimiento es precario y deficiente”.
Porque medir el Software
• Nos indica la calidad del producto
• Nos ayudan a evaluar
– la productividad de la gente que desarrolla el
producto
– los beneficios de utilizar nuevos métodos y
herramientas de ingeniería de software justificando el
uso de éstos.
– Esta evaluación permite una mejora continua al
proceso de desarrollo de software.
• Nos ayuda a establecer una línea base para la
estimación

¿Que es una medida? ¿Que es una métrica?

Una MEDIDA nos indica
cuantitativamente:
MÉTRICA: es una
medida cuantitativa
Capacidad, tamaño, extensión, De algunos
dimensión, cantidad, etc. atributos
Indica en que grado Un sistema o
componente
Que posee de sistema
un proceso
o producto
Posee un
atributo

•Cuando se recopila un solo aspecto de los datos se está

hablando de medidas. Ejemplo: número de líneas de código o
número de errores.

¿Qué es un Indicador? Indicadores de proceso

• Un ingeniero de software recopila medidas y • Brindan una visión profunda sobre la eficacia de
desarrolla métricas para obtener indicadores. un proceso ya existente.

• Un indicador: es una métrica o una combinación • Permiten evaluar lo que está funcionando.
de métricas que proporcionan un visión profunda • Su propósito es mejorar los procesos de
del proceso y proyecto del software o del producto software a largo plazo y conducir a estrategias
en si mismo. que permitan mejorar la calidad del proceso.
• Hay dos tipos de indicadores o métricas:
Indicadores de proceso e indicadores del
proyecto

6
 Indicadores del proyecto
Son utilizadas para supervisar el progreso durante
el desarrollo de software y controlar la calidad del
producto, además se utilizan para realizar las
estimaciones de tiempo y esfuerzo. Permiten al
gestor de proyecto:
• Evaluar el estado del proyecto
• Seguir las pistas de los riesgos potenciales
• Detectar las áreas de problemas para evitar áreas
críticas
• Ajustar el flujo y las tareas del trabajo
• Evaluar la habilidad del equipo del proyecto para
controlar la calidad del producto de software.
Métricas de Software
Podemos definir las Métricas de Software o
Medidas de Software como:
• La aplicación continua de técnicas basadas en
las medidas de los procesos de desarrollo del
software y sus productos, para producir una
información de gestión significativa y a tiempo.
Esta información se utilizará para mejorar esos
procesos y los productos que se obtienen de
ellos.
Métricas de Software
Esencialmente, las Métricas de Software se
aplican al producto Software y a los procesos
mediante los que se desarrolla.
Por tanto, las medidas del software y los
modelos de medida son entonces útiles para
estimar y predecir costos y para medir la
productividad y la calidad del producto.
Métricas de Software
Aplicación continua de
técnicas basadas en las
medidas de los procesos
de desarrollo del software
y sus productos, para
producir una información
de gestión significativa y a
tiempo.
…Métricas de Software
Estas medidas son aplicables a todo el ciclo
de vida del desarrollo, desde la iniciación,
cuando debemos estimar los costos, al
seguimiento y control de la fiabilidad de los
productos finales, y a la forma en que los
productos cambian a través del tiempo
debido a la aplicación de mejoras.
Características de las métricas de
Software
Una medida ideal debería ser:
• Objetiva.
• Sencilla, definible con precisión para que pueda
ser evaluada.
• Fácilmente obtenible (a un coste razonable).
• Valida, la métrica debería medir exactamente lo
que se quiere medir y no otra cosa.
• Robusta. Debería de ser relativamente
insensible a cambios poco significativos en el
proceso o en el producto.
7
 Métricas de producto
Son medidas del producto software durante
cualquier fase de su desarrollo, desde los
• Métricas de requisitos hasta la instalación.
Producto
Las Métricas de Producto pueden medir la
Clasificación complejidad del diseño, el tamaño del producto
de las final (fuente u objeto) o el número de páginas de
Métricas de Software documentación producida.
• Métricas de
Proceso

OTRAS CLASIFICACIONES DE MÉTRICAS

Métricas de proceso
Son medidas del proceso de
desarrollo del software tales
como tiempo de desarrollo total,
esfuerzo en días/hombre o
meses/hombre de desarrollo del
producto, tipo de metodología
utilizada o nivel medio de
experiencia de los
programadores.
POR LAS PROPIEDADES OBJETIVAS Y
SUBJETIVAS
Por ejemplo, el tamaño del producto medido en
líneas de código (LOC) es una medida objetiva del
producto, y una medida subjetiva sería la
clasificación del software según el modelo de
estimación de costos de Bohem (COCOMO) en
orgánico, semilibre o rígido.
Para medida de procesos, el tiempo de desarrollo es
una medida objetiva y el nivel de experiencia de un
programador es una medida subjetiva.

Métricas orientadas al Tamaño:

• Métricas de Productos
– Métrica orientadas al tamaño
• Líneas de Código
– Métricas orientadas a la función
• Puntos de Función
– Métricas de calidad
• Métricas de Procesos
• Conclusiones (métricas)
Líneas de código
La medida más utilizada de la longitud del código fuente de
un programa es el Número de Líneas de Código (Lines of
Code en ingles, abreviado LOC). La definición más común
es la siguiente:
• Una línea de código es cualquier línea de un texto de un
programa que no es un comentario o línea en blanco, sin
tener en cuenta el número de instrucciones o parte de
instrucciones en la línea. Esta medida se suele
representar por NCLOC (No Comentary Lines of Code).

8
 … Métricas orientadas al Tamaño: Problemas
Líneas de código
a) No se tiene en cuenta el concepto de
• Si queremos conocer la longitud real del programa reutilización.
esta sería:
b) No se tiene en cuenta el concepto de costes
LOC = NCLOC + CLOC fijos ni tareas que se desarrollan que no
Donde CLOC (Comentary Lines of Code) es el número producen instrucciones. Por ello, no debe ser
de líneas de comentarios. utilizada esta medida directamente en la
estimación de esfuerzo o productividad.
• Una medida indirecta de la densidad de comentarios
sería:
CLOC / LOC

… Problemas Ventajas y desventajas

Cuando se esté buscando la noción pura de longitud
existen dos alternativas aceptables si se quiere utilizar Ventajas:
bajo el concepto de tasa (ratio): • Que son fáciles de
• Medir la longitud en términos de número de bytes calcular en cualquier
de almacenamiento requerido para contener el texto proyecto
del programa.
• Existen varias
• Medir la longitud en términos de número de
herramientas de
caracteres en el texto del programa (char).
estimación basadas en
Si se conoce el número medio de caracteres por línea las líneas de código
de texto, NL; el número de líneas sería:
LOC = CHAR/NL

… Ventajas y desventajas
Desventajas:
• La falta de una definición universal de línea de código • Métricas de Productos
• Las líneas de código dependen de los lenguajes de – Métrica orientadas al tamaño
programación y por lo tanto perjudica a los programas • Líneas de Código
más cortos pero bien diseñados.
– Métricas orientadas a la función
• El estilo de programación dependerá de cada persona.
Comparar la productividad utilizando lenguajes diferentes • Puntos de Función
de programación puede llevar a conclusiones erróneas – Métricas de calidad
respecto a la productividad de los programadores.
• Métricas de Procesos
• El decidir que líneas de código se contabilizaran ya sean
nuevas, líneas modificadas, reutilizadas más definiciones • Conclusiones (métricas)
de datos y comentarios.
• Dificultad de estimar en fases tempranas del desarrollo la
cantidad de líneas que tendrá una aplicación.

9
 Métricas orientadas a la Función
Es un método para cuantificar el tamaño y la
complejidad de un sistema software en términos
de las funciones que el usuario desarrolla o
desarrollará.
Se entiende por funciones a las entradas, salidas,
archivos, etc.
Metodología Original de Puntos de
Función
La proposición de puntos de función tuvo los siguientes
objetivos:
• Medir lo que el usuario pide y recibe.
• Medir independientemente de la tecnología utilizada
en la implantación del sistema.
• Poder ser aplicados tempranamente en el ciclo de
vida del producto.
• Proporcionar una métrica de tamaño que dé soporte
al análisis de la calidad y la productividad.
• Ser independientes de código fuente o lenguaje.
Metodología Revisada de Puntos de Función
Revisión de la métrica Puntos de Función realizada por IBM
Métricas Funcionales
Un punto de función es una métrica sintética que
se compone de la suma ponderada de los totales
de las entradas, las salidas, las consultas, los
archivos lógicos, e interfaces que se identifican
en la aplicación.
PARÁMETROS
Inicialmente consideró solo 4 parámetros básicos y
un factor de ajuste de complejidad.
La siguiente tabla ilustra el método original.
Ejemplos de entradas:
Formatos de datos llenadas por usuarios en pantallas, discos
magnéticos, entradas en pantallas sensibles al tacto, clicks de
mouse.
Entradas: Pantallas o formularios a través de los cuales
usuarios de una aplicación agregan nuevos datos o actualizan
datos existentes. Si una pantalla de entrada es muy grande para
ser desplegada de una vez (asumiendo 80 columnas y 25 líneas) y
requiere de una segunda pantalla, el conjunto cuenta como una
(1) sola entrada. Se deben considerar entradas que requieren
procesamiento único.
10
 Ejemplos de salidas: Ejemplos de archivos lógicos internos: Colección
Pantallas de datos de salidas, informes impresos, archivos en lógica de registro que la aplicación modifica o
disco, sets de cheques, facturas impresas. En general,
actualiza. Un archivo puede ser una base de datos en
contabilizar como una salida entidades que son referenciales
por un nombre; contabilizar independientemente salidas que PC, una rama de una base de datos jerárquica, una
comparten los datos pero varían en formato. Por ejemplo, una tabla de una base de datos relacional.
tabla y un histograma.
Ejemplos de (archivos externos lógicos de) interfaz:
Salidas: Pantallas o informes que la aplicación produce para bases de datos compartidas, archivos lógicos
uso humano o para otros programas. En una aplicación de
remuneraciones una función de salida que genere 100 cheques
direccionables desde o hacia otra aplicación.
contaría como una sola salida.
Interfaces: Archivos compartidos con otras aplicaciones,
como archivos en que vienen o que van, bases de
datos compartidas, o listas de parámetros.

Las consultas se dividen en dos partes: la porción de 14 factores de influencia

entrada y la porción de salida. Ejemplos de consultas: C1 Comunicación de datos
consulta de un usuario sin actualizar un archivo, C2 Funciones distribuidas
mensajes de ayuda, mensajes de selección. Una C3 Objetivos de performance
consulta típica sería una relacionada con una C4 Configuración usada fuertemente
reservación aérea. C5 Tasa de transacciones
La porción de entrada sería la pregunta (por ejemplo: C6 Entrada de datos en línea
¿qué vuelos de Lan salen de Lima a Trujillo después de C7 Eficiencia del usuario final
las 5 pm?) y la porción de salida la respuesta (por C8 Actualización en línea
ejemplo: Vuelo 143 a las 6:05 pm). C9 Procesamiento complejo
Consultas: Pantallas que le permiten a los usuarios C10 Reusabilidad
interrogar una aplicación y solicitar asistencia o C11 Facilidad de instalación
información, tal como pantallas de ayuda (HELP). C12 Facilidad operacional
C13 Sitios múltiples
C14 Facilitamiento del cambio

Comunicación de datos:
La escala de evaluación tiene el siguiente significado:
Implica que datos y/o información de control son
enviadas o recibidas sobre facilidades de
0 factor no presente o sin influencia comunicación. La evaluación se reflejaría en un 0
1 influencia insignificante para aplicaciones batch, y un 5 para aplicaciones
2 influencia moderada interactiva.
3 influencia promedio
Funciones distribuidas:
4 influencia significativa
Analiza si una aplicación es monolítica y opera en
5 influencia fuerte
un solo procesador o si es distribuida entre varios
procesadores. La evaluación arrojaría un 0 para
aplicaciones monolíticas puras, y un 5 para
aplicaciones que se ejecutan dinámicamente en
varios procesadores.

11
 Objetivos de performance: la evaluación sería un 0 si
no hay establecido ningún criterio especial de
performance por los usuarios, y un 5 si los usuarios
insisten en objetivos de performance muy rigurosos que
requieren un esfuerzo considerable para ser logrados.
Configuración usada fuertemente: la evaluación
sería un 0 si la aplicación no tiene restricciones
especiales de uso, y un 5 si el uso anticipado requiere
especial esfuerzo para ser logrado.
Entrada de datos en línea: la evaluación sería un 0 si
menos del 15% de las transacciones son interactivas, y un
5 si más del 50% de las transacciones son interactivas.
Eficiencia del usuario final: la evaluación sería un 0 si no
hay usuarios finales o no hay requerimientos especiales
para los usuarios finales, y un 5 si los requerimientos de
eficiencia de usuarios finales son lo suficientemente
rígidos como para requerir un esfuerzo
Actualización en línea: la evaluación sería un 0 si no hay,
y un 5 si las actualizaciones son obligatorias y
especialmente difíciles, quizás debido a la necesidad de
proteger datos de cambios accidentales.
Facilidad de instalación: la evaluación sería un 0
si este factor es insignificante, y un 5 si la
instalación es importante y tan restrictiva que
requiere un esfuerzo especial para cumplirla
satisfactoriamente.
Facilidad operacional: la evaluación sería un 0 si
este factor es insignificante, y un 5 si la facilidad
operacional es tan restrictiva que requiere un
esfuerzo especial para alcanzarla.
Tasa de transacciones: la evaluación sería un 0 si el
volumen de transacciones no es significativo, y
un 5 si el volumen es lo suficientemente
significativo como para producir stress en la
aplicación y requerir un esfuerzo especial para
alcanzar throughputs deseados.
Entrada de datos en línea: la evaluación sería un 0
si menos del 15% de las transacciones son
interactivas, y un 5 si más del 50% de las
transacciones son interactivas.
Procesamiento complejo: la evaluación sería un 0 si
no hay, y un 5 en casos que requieren decisiones
lógicas extensas, matemática compleja,
procesamiento truculento de excepciones, o
esquemas de seguridad elaborados.
Reusabilidad: la evaluación sería un 0 si la
funcionalidad se planifica para permanecer local a
la aplicación actual, y un 5 si mucha de la
funcionalidad y los artefactos del proyecto se
pretende que sean usados ampliamente por otras
aplicaciones.
Sitios múltiples: la evaluación sería un 0 si hay
solo un sitio planificado de uso, y un 5 si el
proyecto y sus artefactos se pretenden sean
usados en muchos lugares.
Facilitamiento del cambio: la evaluación sería un
0 si el cambio no ocurre, y un 5 si la aplicación se
desarrolla específicamente para permitir a los
usuarios finales el hacer cambios rápidos para
controlar datos o tablas que ellos mantienen con
la ayuda de la aplicación.
12
El procedimiento para calcular el factor de ajuste
es el siguiente: Ejemplo
• Asignar una evaluación individual a cada uno de los 14
Suponga una aplicación con 10 entradas, 10
factores salidas, 10 consultas, 1 archivo de datos y 1
archivo de interfaz, todos ellos de complejidad
• Sumar las evaluaciones (esta dará un valor entre 0 y 70)
promedio.
• Multiplicar la suma de evaluaciones por 0.01 para Suponga que los factores de influencia se
obtener un valor decimal
determinaron de la siguiente manera:
• Sumar 0.65 al valor decimal para crear un factor de
complejidad (un valor entre 0.65 y 1.35)

Conversión de Puntos de Función

a líneas de Código
Ejemplo
LENGUAJE FACTORES DE CONVERSIÓN
Por ejemplo, si al aplicar el procedimiento de cálculo
Ada 75 para puntos de función sin ajustar se obtiene un
Basic Compilado 90 resultado de 165 UNFP (Puntos de Función sin
Basic Interpretado 128 Ajustar) y el proyecto va a desarrollarse en el
Ensamblador 320 lenguaje de programación C++:
C 128
C++ 29
165 UNFP x 29 = 4785 SLOC (Líneas de Código
Fuente)
Visual Basic 30
Cobol80 96 Haciendo la conversión mencionada anteriormente:
Prolog 61 4785/1000= 4.785 KSLOC (Miles de Líneas de
Pascal 90 Código Fuente).
Lisp 61
Modula2 80

13

• Métricas de Productos
– Métrica orientadas al tamaño
• Líneas de Código
– Métricas orientadas a la función
• Puntos de Función
– Métricas de calidad
• Métricas de Procesos
• Conclusiones (métricas)
Corrección
Es el grado en el que el software
lleva a cabo su función. Se mide
en “defectos por KLDC” (miles de
líneas de código), entendiéndose
por “defecto” cualquier falta de
concordancia con los requisitos.
Integridad
Mide la habilidad de un sistema para resistir ataques
contra su seguridad. El proteger los datos, programas
y documentación debe ser una prioridad. Para medirla
se consideran dos atributos adicionales:
Amenaza, que es la probabilidad estimada o
deducida de que se produzca un ataque de un
tipo determinado.
Seguridad, probabilidad estimada o deducida de
el nuestro sistema pueda repeler dichos ataques.
Métricas de Calidad
• Cualquier proyecto de ingeniería del software tiene
como objetivo principal obtener sistemas y productos
de alta calidad
• La calidad es difícil medirla directamente, no obstante
hay indicadores que nos pueden dar una idea sobre la
misma. Estos indicadores se basan en los siguientes
aspectos:
– Corrección
– Facilidad de mantenimiento
– Integridad
– Facilidad de uso
Facilidad de Mantenimiento
Se mide por la facilidad de:
• Corregir defectos encontrados,
• Adaptar ese programa a nuevos entornos, y
• Mejorar el programa si el cliente desea cambios.
La facilidad de mantenimiento se mide indirectamente
por medio de una métrica orientada al tiempo: “tiempo
medio del cambio (TMC)”, es decir, por el tiempo que se
tarda en analizar la petición del cambio, diseñar la
modificación, implementarla, probarla y distribuir la
notificación del cambio a los usuarios.
Facilidad de uso
Entendiéndose como tal lo “amigable” que resulta
al usuario el sistema. Es un intento de cuantificar
los “amigable” que es el sistema. Se puede deducir
a partir de cuatro características:
• Habilidad intelectual o física requerida para
aprender el sistema.
• El tiempo requerido para llegar a ser
moderadamente eficiente en el uso del sistema.
• El aumento de productividad de alguien que usa
el sistema.
• Valoración subjetiva de la disposición de los
usuarios hacia el sistema.
14
 Estimación de Proyectos
• La primer tarea en la gestión de proyectos es la
estimación.
• La estimación se define como el proceso que proporciona
Técnicas de Estimación un valor a un conjunto de variables para la realización de
un trabajo, dentro de un rango aceptable de tolerancia.
de Costos • Podemos definirlo también como la predicción de
personal, del esfuerzo, de los costos y de la planificación
5.2.2. Estimación del proyecto de software
que se requerirá para realizar todas las actividades y
construir todos los productos asociados con el proyecto.
• Uno de los parámetros críticos de la estimación es
determinar su exactitud. La estimación puede realizarse
a partir de datos históricos o con herramientas.

Tareas críticas en la Gestión de Proyectos

Relación entre las actividades clave
Hay tres tareas que son críticas y que deben ser de la Gestión de Proyectos
desarrolladas correctamente si se desea que el proyecto
termine bien, estas son:
Estimación de duración, costo y esfuerzo necesarios
para construir el producto.
Planificación de tareas a realizar, asignación de
personas, tiempos, etc. para construir el producto.
Seguimiento durante la realización del trabajo, para
asegurar el cumplimiento de lo planificado en
cuanto a costes, fechas, etc. En caso de
desviaciones del plan, se deben tomar las medidas
pertinentes.

Técnicas de Estimación
Existen cuatro técnicas básicas y comunes
• La opinión de los expertos: se basa en la experiencia
profesional de los participantes en el proyecto de estimación.

5.2.2.1. • La analogía: Es una aproximación más formal que la

experiencia de los expertos y se basa en la comparación
directa de uno o más proyectos pasados.
Técnicas para la estimación • La descomposición: Consiste en la descomposición de un
del software producto en componentes más pequeños, o descomponer un
proyecto en tareas de nivel inferior.
• Las ecuaciones de estimación: Fórmulas matemáticas
que establecen la relación de algunas medidas de entrada
(que normalmente es la medida del tamaño del producto) y
determinan el esfuerzo que se requerirá.

15
 La opinión de los expertos Estimación por Analogía
Se basa en: • Constituye un complemento a la de juicio de expertos.
Se emplea la opinión de más • En esta la personas involucradas no sólo trabajan con su
Experiencia
experiencia acumulada, sino que disponen también de datos
de un experto para obtener de proyectos acabados relativamente similares al que hay
una mayor fiabilidad en la que estimar. Así por comparación, se pueden evaluar las
Objetividad diferencias entre el nuevo proyecto y los antiguos y
estimación. En algunos extrapolar su costo.
casos, simplemente se
calcula la media de los • La ventaja de esta técnica está en que es precisa si está
valores ofrecidos por las disponible la información del proyecto con el cuál se va a
distintas personas. comparar.
Del estimador • La desventaja es que es imposible de comparar si el
proyecto ha sido abordado. Trae consigo costos de
La técnica más utilizada es la Delphi, Bohem la refinó en mantenimiento de la base de datos.
1981 (Delphi de banda ancha)

Estimación por descomposición 5.2.2.2. Modelos de estimación

• En esta técnica el responsable de cada
componente del software que hay que construir
Modelos
estima el costo de su desarrollo.
Algorítmicos

• La estimación para el proyecto completo se calcula Modelos de

mediante la suma de las cantidades parciales Estimación
Paramétricos
Modelos
Empíricos
No paramétricos

MODELOS ALGORÍTMICOS MODELOS EMPÍRICOS

• Son modelos que expresan la relación entre el
esfuerzo y los factores que lo influencian. Utilizan
ecuaciones donde el esfuerzo es la variable
dependiente y varios factores como la
experiencia, tamaño (que es el de mayor
influencia) y tipo de sistema, son las variables
independientes.
• Estos modelos suelen basarse en el tamaño del
software.
Los Modelos empíricos se dividen en:
• Paramétricos. Los cuales tiene una formula
funcional explícita, relacionando una variable
dependiente con una o más variables.
• No paramétricos. No tiene una formula funcional
explícita, por ejemplo, un modelo desarrollado usando
la técnica de aprendizaje máquina como una red
neuronal.

16
MODELOS PARÁMETRICOS EMPÍRICOS MODELOS PARÁMETRICOS
Los modelos de estimación más comunes son los EMPÍRICOS
Modelos paramétricos empíricos.
• Utilizan fórmulas derivadas empíricamente para E = A + B X (ev) c
predecir el esfuerzo como una función de LDC o PF.
• Utilizan datos empíricos obtenidos de una muestra de
Donde:
proyectos:
A y B son constantes obtenidas empíricamente
• Son difíciles de usar para todas las clases de software y E esfuerzo en meses/persona
todos los entornos de desarrollo ev variable de estimación (LDC o PF)
• Se deben calibrar para las condiciones específicas de
una organización

EL MODELO COCOMO … EL MODELO COCOMO

(Constructive Cost Model) (Constructive Cost Model)
COCOMO: Constructive Cost Model. Desarrollado en la Todos utilizan la misma fórmula:
década del ’70 por Boehm. Revisado con una nueva
revisión en 1995.
E = aSbFA
Es una colección de tres modelos:
• Básico: aplicable cuando se conoce muy poco del Donde:
proyecto – E: esfuerzo en personas mes
– S: tamaño medido en KLDC
• Intermedio: aplicable luego de la especificación de
requerimientos – FA: Factor de ajuste (igual a 1 en el modelo
básico)
• Avanzado: aplicable cuando se termina el diseño. – a, b: s/tablas del modelo en función del tipo de
sistema

EL MODELO COCOMO EL MODELO COCOMO

(Constructive Cost Model)
Por otro lado, COCOMO define tres modos de desarrollo o tipos de proyectos:
1. Orgánico. Proyectos relativamente sencillos, menores de 50KDLC, en los
cuáles se tiene experiencia de proyectos similares.
2. Semi-acoplado. Proyectos intermedios en complejidad y tamaño (menores
de 300KDLC), donde la experiencia en este tipo de proyectos es variable.
3. Empotrado. Proyectos bastante complejos, en los que apenas se tiene
experiencia y se engloban en un entorno de gran innovación técnica.
(Constructive Cost Model)
Cuando se conoce un poco mas: el lenguaje, herramientas a
utilizar se puede aplicar COCOMO intermedio. Se eligen los
conductores de costos de una tabla que presenta 15.
• La importancia de cada conductor de costo es clasificada en
una escala ordinal con seis puntos: Muy Baja, Baja, Media,
Alta, Muy Alta, Extra Alta.

Básico Intermedio • A cada punto le corresponde un valor de factor de ajuste

Ejemplo: Si se estimó la Capacidad de Análisis como Muy Baja,
Modo a b c d a b c d
el factor es 1.46, quiere decir que se debe aumentar
Orgánico 2.4 1.05 2.5 0.38 3.2 1.05 2.5 0.38
el esfuerzo calculado previamente en un 46%.
Semi-acoplado 3.0 1.12 2.5 0.35 3.0 1.12 2.5 0.35

Empotrado 3.6 1.2 2.5 0.32 2.8 1.2 2.5 0.32

17
 MODELO BÁSICO
Modelo Orgánico, Semi Acoplado y Empotrado
Para determinar el esfuerzo del personal
E = aSbFA
Para determinar el tiempo de desarrollo
T=c Ed
EL MODELO COCOMO II
(Constructive Cost Model)
• Es un modelo de estimación de tiempo y de costo del
software de acuerdo con los ciclos de vida utilizados en
los 90 y en la primera década del 2000.
• Desarrolla bases de datos con costos de software y
herramientas de soporte para la mejora continua del
modelo.
• Proporcionar un marco analítico cuantitativo y un
conjunto de herramientas y técnicas para la evaluación
de los efectos de la mejora tecnológica del software en
costes y tiempo del ciclo de vida software.
Modelo de Putnam – Modelo SLIM
• Surge en 1978 como solución a un requerimiento de la marina
de EEUU para proveer un método para estimar esfuerzo y
tiempo. Fue desarrollado por Putnam y lo llamó modelo SLIM.
• Se utiliza para proyectos con mas de 70.000 LOC
• Puede ser ajustado para proyectos mas pequeños
• Asume que el esfuerzo para proyectos de desarrollo de
software es distribuido en forma similar a una colección de
curvas de Rayleigh, una para cada una de las actividades
principales del desarrollo.
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.
Para determinar el esfuerzo del personal: E = aSbFA
Para determinar el tiempo de desarrollo: T=c Ed
Para determinar la productividad: PR=LDC/E
Para calcular el Personal promedio: P=E/T
Modelos de COCOMO II
• El modelo de Composición de Aplicaciones.
Indicado para proyectos construidos con herramientas modernas
de construcción de interfaces gráficos para usuario.
• El modelo de Diseño anticipado.
Este modelo puede utilizarse para obtener estimaciones
aproximadas del costo de un proyecto antes de que esté
determinada por completo su arquitectura. Utiliza un pequeño
conjunto de drivers de costo nuevo y nuevas ecuaciones de
estimación. Está basado en Punto de Función sin ajustar o KSLOC
(Miles de Líneas de Código Fuente).
• El modelo Post-Arquitectura.
Este es el modelo COCOMO II más detallado. Se utiliza una vez
que se ha desarrollado por completo la arquitectura del proyecto.
Tiene nuevos drivers de costo, nuevas reglas para el recuento de
líneas y nuevas ecuaciones.
Curvas de Rayleigh para el modelo SLIM
18
 Modelo SLIM
Putnam utiliza observaciones empíricas sobre niveles de
productividad para derivar su ecuación de software a partir de la
fórmula básica de la curva de Rayleigh
Donde:
Tamaño: Medido en LOC
C : Factor tecnológico que incluye 14 conductores de costos
y puede tomar hasta 20 valores distintos
K : Total del esfuerzo del proyecto calculado en personas
año
Td : Tiempo transcurrido para la entrega, medido en años. td
es el punto en el cual la curva alcanza un máximo.
5.2.2.4. Herramientas automáticas
de estimación
• Implementan técnicas de descomposición y modelos
empíricos. Permiten al planificador estimar costos y esfuerzos,
así como llevar a cabo análisis del tipo, “que pasa si”, con
importantes variables del proyecto, tales como la fecha de
entrega o la selección del personal.
• Dependiendo de los datos, el modelo implementado por la
herramienta proporciona estimaciones del esfuerzo requerido
para llevar a cabo el proyecto, los costos, la carga de personal,
la duración, y en algunos casos la planificación temporal de
desarrollo y riesgos asociados.
5.2.3. Evaluación del costo-beneficio
• El análisis económico incluye lo que se llama, el análisis o
evaluación de costo–beneficio, significa una valoración de la
inversión económica comparado con los beneficios que se
obtendrán en la comercialización y utilidad del producto o
sistema.
• El análisis económico sirve para :
– Valorar la necesidad de la realización de un proyecto.
– Seleccionar la alternativa más beneficiosa para la
realización del proyecto.
– Estimar adecuadamente los recursos económicos
necesarios en el plazo de realización del proyecto.
5.2.2.3. ¿Desarrollar o comprar?
• En muchas ocasiones es más aconsejable adquirir un
producto de software que desarrollarlo. Los gestores son
los que tienen que tomar esta decisión y deben tener en
cuenta lo siguiente:
– Comprar/alquilar el software ya desarrollado con licencia y
que se ajuste a las especificaciones.
– Comprar componentes de software parcial o totalmente
experimentados y luego modificarlos para ajustarse con las
especificaciones.
– Encargar la construcción del software a una empresa
externa.
• En cualquiera de las tres alternativas, un factor
importantísimo es la disponibilidad de recursos humanos,
Técnicos/hardware/ software.
… Herramientas automáticas de
Estimación
• Qué datos necesitan:
– Datos cuantitativos sobre el tamaño del proyecto (LDC, PF)
– Características cualitativas del proyecto.
– Datos relacionados con el entorno y personal de
desarrollo.
• En resumen el planificador del Proyecto de Software tiene que
estimar tres cosas antes de que comience el proyecto: cuanto
durara, cuanto esfuerzo requerirá y cuanta gente necesitará
para su realización.
• La estimación del proyecto de software nunca será una
ciencia precisa, pero la combinación de buenos datos
históricos y técnicas puede mejorar la precisión de la
estimación.
…Evaluación del costo-beneficio
• Algunos costos y beneficios pueden
cuantificarse fácilmente: ahorros en costos,
tales como una disminución en costos de
operación y aumentos en las utilidades directas.
Otros ejemplos de beneficios tangibles son :
– Disminución de errores
– Incremento de rentabilidad
– Reducción de costos anteriores (fijos o
variables)
19
 …Evaluación del costo-beneficio
• Beneficios intangibles son aquellos que en el
momento del análisis, no se pueden cuantificar y
con frecuencia están relacionados a la calidad de
la información que proporciona el sistema, tales
como los listados a continuación:
– Satisfacción en el servicio al cliente
– En las actividades administrativas, mejora en
la toma de decisiones
Punto de equilibrio
• Es el tiempo que tomaría para que el total de los ingresos
incrementados y/o la reducción de gastos sea igual al costo
total.
• Es una de las formas más sencillas de hacer el análisis de
costo beneficio.
• La desventaja es que no toma en cuenta el valor del dinero
en el tiempo.
Fórmula:
PE = (Costo / Total de ingresos incrementados y/o reducción
de gastos) x 12 meses
Valor presente neto
• El NVP representa el Valor Presente (PV) de los flujos salientes
de caja menos la cantidad de la inversión inicial (I).
• Simplemente NPV = PV – I
• El valor presente del flujo de caja futuro es calculado
utilizando el costo del capital como un factor de descuento.
El propósito del factor de descuento es contar el Valor Futuro
del dinero en Valor Presente (dólares futuros a dólares
presentes) y se expresa como 1 + la tasa de interés (i).
Fórmula
PV = ((ingresos + Valor Asegurado) / Factor de descuento)
NPV = PV – inversión (I)
5.2.3.1 Métodos para el análisis
Costo / Beneficio
• Diferentes métodos pueden ser utilizados para calcular la
relación costo–beneficio. Los métodos más sofisticados
consideran el tiempo–valor del dinero como parte del
análisis costo beneficio.
• Los métodos comunes para el análisis de costo beneficio
incluyen:
– Punto de equilibrio
– Periodo de devolución
– Valor presente neto
– Tasa interna de retorno
Período de devolución
Es el tiempo requerido para recuperar el monto inicial de
una inversión de capital.
Evalúa el tiempo que se tomaría para lograr un flujo de
caja positivo igual a la inversión total. Toma en cuenta
beneficios, tales como el valor asegurado.
Indica fundamentalmente la liquidez del esfuerzo por
mejorar un proceso en vez de su rentabilidad. Al igual
que el análisis del punto de equilibrio, el análisis del
periodo de devolución no tiene en cuenta el valor del
dinero en el tiempo.
Fórmula:
PD = [(Costo – Valor Asegurado) / Total de ingresos
incrementados y/o reducción de gastos] x 12 meses
Tasa interna de retorno
• La tasa interna de retorno es la tasa de interés que hace
la ecuación de la inversión inicial (I) con el Valor presente
(PV) de los futuros flujos de caja entrantes .
• Cuando se calcula la TIR, el NPV se fija en cero y se
resuelve para un interés (i). en este caso, el factor de
descuento es (1 + i) ya que no conocemos el interés
verdadero, solamente conocemos el interés deseado.
Fórmula
PV = ((ingresos + Valor Asegurado) / Factor de
descuento)
NPV = PV – inversión (I)
20
 Tasa interna de retorno
Datos Descripción
-70.000 Costo inicial de un negocio
12.000 Ingresos netos del primer año
5.3
1 15.000 Ingresos netos del segundo año
2 18.000 Ingresos netos del tercer año ESTUDIO DE FACTIBILIDAD
3 21.000 Ingresos netos del cuarto año
4 26.000 Ingresos netos del quinto año
5 Fórmula Descripción (Resultado)
6 =TIR(A2:A6)Tasa interna de retorno de la inversión después
de cuatro años (-2%)
7 =TIR(A2:A7)Tasa interna de retorno después de cinco años
(9%)

5.3. Estudio de factibilidad 5.3.1. Viabilidad Económica

• El proceso de ingeniería de requerimientos comienza con
un estudio de viabilidad. Este es un estudio corto que
ayuda a resolver si un nuevo sistema de software es o no Es una evaluación de costo – beneficio del sistema que se
candidato para desarrollarse de acuerdo a los recursos y quiere desarrollar, para saber que tan efectivo resultará su
restricciones impuestas por al organización. desarrollo, si contribuye o no a los objetivos del negocio, lo
• Llevar a cabo un estudio de factibilidad comprende la que determinará si vale la pena o no la inversión económica.
evaluación y recolección de información y la redacción de
informes.

Viablidad Viabilidad Viabilidad

Técnica Económica Operativa

5.3.2. Viabilidad Técnica 5.3.3. Viabilidad Operativa

• Es un estudio de funciones, rendimiento y
• Se trata de averiguar si el nuevo sistema es el
restricciones que puedan afectar la realización de un
adecuado para la organización.
sistema aceptable.
• También se debe establecer si el nuevo sistema es
• Las restricciones además de presupuesto y tiempo
flexible y puede integrarse a otros ya existentes en
incluyen los recursos humanos, hardware y software.
la organización.
• Con este estudio se determina si con la tecnología
existente se puede implementar el nuevo sistema, o si
hay que adquirir nueva tecnología.

21
 5.4. Planificación de la
documentación
• Para mantener informado al cliente acerca de los riesgos, de la
5.4 planificación de tiempo y de la organización usualmente se
prepara un documento llamado “plan de proyecto”.
• El plan del proyecto de software se produce como culminación
de la etapa de planificación. Es un documento breve, dirigido a
PLANIFICACIÓN DE LA una diversa audiencia y debe :
– Comunicar el alcance y recursos a los gestores del Software,
DOCUMENTACIÓN personal técnico y clientes.
– Definir los riesgos y sugerir planes de contingencia
– Definir el costo y el plan temporal para la revisión de la
gestión.
– Proporcionar una aproximación global del desarrollo del
software para todo el personal involucrado en el proyecto.
– Describir cómo se garantizará la calidad y la gestión de
cambios.

5.5 Gestión de la configuración del

software (GCS)
5.5 • Los cambios durante el proceso de construcción
de un software:
GESTIÓN DE LA CONFIGURACIÓN
– Son inevitables
DEL SOFTWARE
– Provocan confusión e incertidumbre
4.5.1. Planificación de la GCS – Pueden ocurrir en cualquier momento

4.5.2. El proceso de gestión de la configuración del

software • Estos cambios aumentan conforme avanza el
tiempo.

5.5.1 Planificación de la GCS

Que es la gestión de la configuración
“El arte de coordinar el desarrollo de software para
minimizar…la confusión, se denomina gestión de la
configuración. La gestión es el arte de identificar,
organizar y controlar las modificaciones que sufre
el software…la meta es maximizar la productividad
minimizando errores.”
Babich
• La planificación de la GCS empieza durante las primeras
fases del proyecto y debe definir el o los documentos que
se controlarán. Aquellos documentos que puedan
requerirse para el futuro mantenimiento del software,
deberán ser identificados y especificados como
documentos de control.
• El plan de la GCS incluye:
– La asignación de responsabilidades
– Las políticas de la GCS
– La definición de archivos de la GCS que deben ser
controladas.
– La definición de la base de datos
– Puede incluir información de software externo, proceso
de auditoría, etc.

22
 5.5.2 El proceso de gestión de la
configuración del software
• La GCS es un elemento importante de garantía de
calidad, ya que es responsable de controlar los
cambios.
• El proceso se puede definir en cinco tareas de GCS:
1. Identificación
2. Control de versiones
3. Control de cambios
4. Auditorias de configuración
5. Generación de informes

23