Diapositiva 1

1
Aguilar Nájera Mariela Camargo
Linares Belem I. Mora Haro Benjamín
Pérez Ríos Félix
Integrantes
e-mail inovatec_is_at_yahoo.com.mx
2
I N T R O D U C C I Ó N La estimación de costos
de un producto de programación es una de las más
difíciles y erráticas tareas de la ingeniería de
software es difícil hacer estimaciones exactas
durante la fase de planeación de un desarrollo
debido a la gran cantidad de factores
desconocidos en ese momento. Reconociendo este
problema, algunas organizaciones utilizan una
serie de estimadores de costos. A continuación
se presentan los principales factores en los
costos de un producto de programación.
3
Factores principales que influyen en el costo del
software

• Capacidad del programador
• 2. Complejidad del producto
• 3. Tamaño del programa
• 4. Tiempo disponible
• 5. Confiabilidad requerida
• 6. Nivel tecnológico

4

• 1. Capacidad del programador. Por numero de
  líneas que puede generar al mes. En proyectos muy
  grandes, las diferencias individuales tienden a
  compensarse, pero en proyectos de cinco
  programadores o menos la diferencia puede ser muy
  importante.
• 2.
  Complejidad del producto
• Programas de aplicación Programas de
  apoyo Programas de sistema
• Procesamiento de datos Compiladores
  Sistemas de base de datos
• Programas científicos Ligadores
  Sistemas operativos
• Sistemas de inventarios
  Sistemas de tiempo real

Esfuerzo total en meses del programador
(PM) KDSI (número de millares de instrucciones
de código fuente entregadas con el
producto) Programas de aplicación PM 2.4
(KDSI) 1.05 Programas de apoyo PM
3.0 (KDSI) 1.12 Programas de sistema
PM 3.6 (KDSI) 1.20
5
Tiempo de desarrollo para un programa (TDEV) en
meses Ya habiendo calculado PM Programas de
aplicación TDEV 2.5 (PM) 0.38 Programas
de apoyo TDEV 2.5 (PM)
0.35 Programas de sistema TDEV 2.5
(PM) 0.32
Nivel promedio de contratación (personas por
proyecto) Dado el número total de meses
programador de un proyecto y el tiempo nominal de
desarrollo requeridos Programas de aplicación
176.6 PM / 17.85 MO 9.9 programadores Programa
s de apoyo 294 PM / 18.3 MO 16
programadores Programas de sistema 489.6
PM / 18.1 MO 27 programadores
3. Tamaño del producto
6
4. Tiempo Disponible

• Es el esfuerzo total del proyecto que se
  relaciona con el calendario del trabajo
  asignado para la terminación
• del proyecto , donde se estudia la
  cuestión del tiempo optimo de desarrollo.
• En el cual se a estudiado el trabajo
  adaptado por Boehm y Putman.
• Donde para Boehm es muy importante las
  siguientes variables.
• Esfuerzo Relativo ( E/ E Nominal)
• Calendario Relativo T Deseado/ T Nominal.
• Para Putman, el esfuerzo de un proyecto es
  inversamente proporcional al tiempo de
  desarrollo elevado
• a la cuarta que se ve reflejado en una
  curva llamada curva de Putman
• 
  E K/ /Td4).

7

• 5. Confiabilidad requerida
• La confiabilidad de un producto de
  programación puede definirse como la
  probabilidad de que un
• Programa desempeñe una función requerida
  bajo ciertas condiciones especificadas y
  durante cierto
• Tiempo.
• La confiabilidad puede expresarse en
  términos de los siguiente puntos
• Exactitud
• Firmeza
• Cobertura
• Consistencia del código fuente
• Las características de la confiabilidad pueden
  instrumentarse en un producto de
  programación,

8
Factores multiplicadores de esfuerzo para
ajustes por confiabilidad
Categoría Consecuencia de
la falla Factor
Muy baja Alguna molestia
menor 0.75
Baja Las perdidas son
fáciles de recuperar 0.88
Nominal Dificultad relativa
en la recuperación 1.00 Alta
Gran perdida financiera
1.15 Muy
alta Riesgo de una vida
1.40E
9
6. Nivel tecnológico
El nivel de tecnología empleado en un
proyecto de programación se refleja en el
lenguaje utilizado, La maquina abstracta (Tanto
el equipo como los programas de apoyo), las
practicas y las herrami- entas de
programación utilizadas. Se sabe que el
numero de líneas de código fuente escrita
por dia es por completo independiente del
lenguaje ocupado y que las proposiciones
escritas en un len- guaje de alto nivel como
el FORTRAN o el PASCAL suelen general
varias instrucciones a nivel de Maquina .
10
TECNICAS DE ESTIMACION DE COSTOS

• Dentro de la mayor parte de las organizaciones,
  la estimación de costos de la programación se
  basa en las experiencia pasadas.
• La estimación de costos puede llevarse a cabo en
  forma jerárquica hacia abajo o en forma
  jerárquica hacia arriba.
• La estimación jerárquica hacia abajo se enfoca
  primero a los costos del nivel del sistema, así
  como a los costos de manejo de la configuración,
  del control de calidad, de la integración del
  sistema , del entrenamiento y de las
  publicaciones de la documentación.
• Estimación jerárquica hacia arriba, primero se
  estima el costo del desarrollo de cada modulo o
  subsistema tales costos se integran para obtener
  un costo total. Esta técnica tiene la ventaja de
  enfocarse directamente a los costos del sistema,
  pero se corre el riesgo de despreciar diversos
  factores técnicos relacionados con algunos
  módulos que se desarrollaran.

11
Juicio experto

• La mayor desventaja de la estimación de grupo es
  el efecto de la dinámica interpersonal del grupo
  que pueda tener en cada uno de los individuos
  los miembros de un grupo pueden ser inocentes con
  respecto a los factores de tipo políticos, a la
  presencia de alguna autoridad dentro del grupo, o
  al dominio de un miembro dentro del grupo con una
  fuerte personalidad.

ESTIMACION DE COSTO POR LA TENICA DELFI

• La técnica DELFI fue desarrolla en la corporación
  RAND en 1948, con el fin de obtener el consenso
  de un grupo de expertos sin contar con los
  efectos negativos de las reuniones en grupo la
  técnica puede adaptarse a la estimación de costos
  de la siguiente manera.

12
1. Un coordinador proporciona a cada experto la
documentación con la definición del sistema y una
papeleta para que escriba su estimación. 2.Cada
experto estudia la definición y determina su
estimación en forma anónima los expertos pueden
consultar con el coordinados, pero no entre
ellos. 3. El coordinador prepara y distribuye un
resumen de la estimaciones efectuadas, incluyendo
cualquier razonamiento extraño efectuado por
alguno de los expertos.
4.Los expertos realizan una segunda ronda de
estimaciones, otra vez anónimamente, utilizando
los resultados de la estimación anterior, en los
casos que una estimación difiera mucho de las
demás, se podrá solicitar que también en forma
anónima el experto justifique su estimación.

• El proceso se repite tantas veces como se juzgue
  necesario, impidiendo una discusión grupal
  durante el proceso.

13
Proyecto sistema operativo Fecha
27/09/05 Estimación en la 3a. vuelta
Su estimación es
Estimación de la mediana
Meses de programador
Estimación para la siguiente vuelta es de 35
PM Razones para la estimación Para un sistema
normal de control de procesos. Nuestra gente a
tenido gran experiencia en proyectos
similares. No se espera que haya problemas con
este proyecto.
14

• Estimacion para la siguiente vuelta es de 35 PM
• Razones para la estimacion
• Para un sistema normalde control de procesos.
• Nuestra gente a tenido gran experiencia en
  proyectos similares.
• No se espera que haya problemas con este
  proyecto.

Estructuras de división de trabajo

• El juicio experto y el consejo de un grupo son
  técnicas de estimación de tipo jerárquico hacia
  abajo la estructura de división de trabajo o
  WBS, es un método de tipo jerárquico hacia
  arriba. Una estructura de división de trabajo es
  un organigrama jerárquico donde se establecen las
  partes de un sistema. Un organigrama WBS refleja
  la jerarquía de los productos o bien de procesos.

15
Estructuras de división de trabajo

• Algunos planificadores ocupan tanto el WBS de
  productos como de procesos para realizar sus
  estimaciones de costos. Las ventajas primordiales
  de esta técnica son la identificación y
  contabilización de los diversos procesos y
  factores de productos de un sistema, así como la
  aclaración con exactitud de que costos se
  incluyen en la estimación.

16
ESTRUCTURA WBS DE DIVISIÓN DEL TRABAJO POR
PRODUCTO
17
ESTRUCTURA WBS DE DIVICION DEL TRABAJO POR
PROCESOS
Proceso
Admon. proyecto
Desarrollo
Pruebas
Servicios
P y R
Revisión y auditoria
Plan
Integración
Aceptación
Servicio de computo
Publicaciones
Prueba de la unidad
Depuración
Diseño
18
Modelos de costo por algoritmos o módulos
En los modelos de costo basado en algoritmos o
módulos, los costos se estiman mediante la
adición de los costos de cada uno de los módulos
o subsistemas que conforman al sistema, de modo
que esta técnica es del tipo jerárquica hacia
arriba.
El modelo constructivo de costos o COCOMO
(Constructive Cost Model) es un modelo de costos
por algoritmos descrito por Boehm
19
Cuando se usa el COCOMO las ecuaciones para
calculo de la complejidad, TDEV y programadores,
se emplean para proporcionar los valores
nominales de la estimación de meses de
programador y calendario de desarrollo para cada
unidad de trabajo, basándose en el numero de
instrucciones de código fuente entregadas (DSI)
de cada unidad.
Después, se utilizan factores multiplicadores
para ajustar la estimación de acuerdo con los
atributos del producto, de la computadora, del
personal dedicado y del proyecto.
20
(No Transcript)
21
Las ecuaciones y los multiplicadores se
obtuvieron con el examen de datos de 63 proyectos
de programación y mediante la técnica DELFI entre
un grupo de expertos de programación.
Las ecuaciones del COCOMO incorporan algunas
suposiciones importantes por ejemplo, las
ecuaciones para la carga nominal orgánica
(programas de aplicación) deben usarse en las
siguientes situaciones

• Desde programas pequeños hasta medianos (2K hasta
  32K DSI)
• En una área de aplicación conocida
• Con una maquina virtual estable y bien conocida
• Y para un desarrollo interno

22
Con el fin de modificar las suposiciones
anteriores se utilizan los multiplicadores de
esfuerzo. Las siguientes actividades se cubren
con estas estimaciones

• Se abarca desde el diseño hasta las pruebas de
  aceptación.
• Incluye los costos de documentacion y revisiones.
• Incluye los costos del gerente del proyecto y del
  bibliotecario de programas.

Los estimadores de esfuerzo excluyen los costos
de plantación, análisis, instalación y
entrenamiento, así como los costos de
secretarias, personal de limpieza y operadores
del equipo de computo.
23
Otras suposiciones concernientes a la naturaleza
del proyecto en estimación en COCOMO son las
siguientes

• Un pequeño numero de personas capaces efectúan
  una definición cuidadosa y la validación de los
  requisitos.
• Los requisitos permanecen constantes durante el
  proyecto.
• Un pequeño numero de personas capaces realizan la
  definición y validación minuciosa del diseño
  arquitectónico del sistema.
• Grupos paralelos de programadores, trabajando en
  grupos, desarrollan el diseño detallado, la
  codificación y las pruebas por unidad.
• Las pruebas de integración se elaboran de acuerdo
  con una anticipada planeación al respecto.
• Los errores en las interfaces se encuentran casi
  siempre en las pruebas por unidad y en las
  inspecciones y los recorridos efectuados antes de
  las pruebas de integración
• La documentacion se genera en forma creciente
  como parte del proceso de desarrollo

24
Procedimiento para la estimación de costos usando
COCOMO

• Identificar todos los subsistemas y los módulos
  del producto.
• Estimar el tamaño de cada modulo y calcular el
  tamaño de cada subsistema y del sistema en total.
• Especificar los factores multiplicadores de
  módulos para cada uno, estos son complejidad del
  producto, capacidad de programación, experiencia
  en maquinas virtuales y experiencia en lenguajes
  modernos de programación.
• Calcular el esfuerzo para cada modulo, así como
  el tiempo de desarrollo, para lo anterior usar
  las ecuaciones de estimación nominal junto con
  los factores relevantes a cada modulo.
• Especificar los once multiplicadores restantes
  de cada subsistema.

25
6. De los pasos 4 y 5, calcular el esfuerzo y el
tiempo de desarrollo estimados para cada
subsistema. 7. Del paso 6, calcular el esfuerzo y
tiempo de desarrollo totales para el sistema. 8.
Efectuar un análisis de sensibilidad sobre la
estimación, estableciendo comparaciones para
diversos factores. 9. Sumar los otros
ingredientes en el costo del desarrollo, como la
plantación y el análisis, que no se hayan
incluido antes. 10. Comparar la estimación con
otra obtenida a partir de la técnica DELFI,
identificando y corrigiendo las diferencias en la
estimación.
La mayor ventaja del modelo es que puede servir
para obtener una visión intuitiva de los factores
de costo dentro de una organización. Los datos
pueden recolectarse y analizarse, identificarse
nuevos factores y los factores multiplicadores de
esfuerzo pueden ajustarse tanto como sea
necesario para calibrar el COCOMO dentro de un
ambiente especifico.
26
Tal vez la mayor desventaja del mismo es que el
uso de factores de ajuste parte de la suposición
de que son independientes entre si. En realidad
la modificación de un factor suele implicar la
variación de otros. En ocasiones no queda claro
como influyen las modificaciones de un factor en
los otros.
La mayor parte de los modelos de estimación de
costos no incorporan factores de costo para que
el código existente se vuelva a utilizar.
27
Estimación del nivel de contratación
La cantidad de personal requerida a través de un
proyecto de desarrollo no es constante, por lo
regular, la planeación y el análisis lo efectúa
un grupo pequeño el diseño un grupo mayor,
aunque todavía pequeño, y el diseño detallado un
grupo grande de personas.
La fase inicial del mantenimiento puede requerir
un numero considerable de personas, pero este
numero deberá disminuir en poco tiempo.
Si no existen mejoras o adaptaciones importantes,
el numero de personas para el mantenimiento
permanecerá pequeño.
28
Estimación de los costos de mantenimiento de
software
El mantenimiento de sw suele necesitar de 40 a
60 y en algunos casos hasta 90 del esfuerzo
total durante el ciclo de vida del proyecto,
estas actividades comprenden agregar mejoras al
producto, adaptar el producto para nuevos
ambientes de proceso y corregir los problemas de
los programas.
Una regla útil muy usada para la distribución del
esfuerzo de las actividades de mantenimiento es
asignar 60 del tiempo a mejoras, 20 a
adaptación, y 20 a la depuración o corrección de
problemas.
La mayor preocupación con respecto al
mantenimiento durante la fase de planeacion de un
proyecto de programación es estimar el numero de
programadores de mantenimiento que se requerirán,
así como especificar las facilidades necesarias
para que se lleve a cabo.
29
Un estimado muy usado en la determinación del
numero de personal es el total de líneas de
código que puede mantener cada programador en
forma individual.
Algunos autores han determinado que un
programador común en el ambiente de procesamiento
de datos puede mantener hasta 32K de
instrucciones.
Para una aplicación en tiempo real o en programas
relacionados con proyectos de aeronáutica, el
numero de líneas varia entre 8K y 10K.
Un estimado del numero de personal de tiempo
completo requerido en el mantenimiento de un
proyecto de programación puede obtenerse con la
división del numero estimado de líneas de código
que se mantendrán entre el total de líneas de
código que puede mantener un programador.
30
BOEHM sugiere que el esfuerzo de mantenimiento
puede estimarse mediante el empleo de un cociente
de actividad, que se calcula como el numero de
instrucciones de código fuente que serán
agregadas o modificadas durante un periodo,
divididas entre el numero total de instrucciones
ACT (DSIagregadas DSImodificadas) / DSItotales
Este cociente se multiplica por el numero de
meses de programador empleados durante el periodo
especifico de desarrollo, con el fin de
determinar el numero de meses programador
requeridos para el periodo de mantenimiento
PMm ACT MMdev
31
Se logra una modificación posterior usando un
factor de ajuste de esfuerzo, EAF, donde se
considera que los factores multiplicadores de
esfuerzo pueden diferir, durante el
mantenimiento, de los utilizados para el
desarrollo
PMm ACT EAF MMdev
Por ejemplo, una gran atención en la
confiabilidad y el empleo de técnicas modernas de
programación utilizadas en la fase de desarrollo
puede reducir la cantidad de esfuerzo requerido
para el mantenimiento, en caso contrario, puede
incrementar la dificultad del mantenimiento.
32
RESUMEN
En resumen la estimación de costos de los
productos de programación es una de las tareas
mas difíciles y erráticas de la ingeniería de
programación.
Las técnicas de estimación se basan en gran
medida en la experiencia y los datos históricos
de cada organización.
La mayor parte de las estimaciones de costos
están en función del numero estimado de
instrucciones finales del producto por
desarrollar, la estimación del costo de producto
no será superior que la capacidad de estimar el
numero de instrucciones finales existentes en el.
El juicio experto y la predicción de módulos son
dos enfoques fundamentales para la estimación del
costo, en la practica se deben ocupar diversas
técnicas de estimación, para luego comparar y
conciliar los resultados.