Iet Isw Unidad2

Ingeniera de Software Unidad 2
Gestin de Proyectos de Software
Mediciones en Productos y Procesos de Software Modelos de Estimacin en Proyectos de Software Aseguramiento de la Calidad del Software
MEDICIONES EN PRODUCTOS Y PROCESOS DE SOFTWARE
Gestin de Proyectos de Software - Medicin

Es necesario medir? Cmo evaluar las mejoras en el proceso de desarrollo de software? Beneficios de la Medicin: Mejoras en la calidad y productividad Mejor precisin en la planificacin y estimacin de proyectos de software Requisitos para la Medicin: Disposicin de personal adecuado y motivado Existencia de estructura organizacional adecuada Uso de herramientas y tcnicas efectivas para el proceso Espacio fsico y ambiente de trabajo adecuado

Medicin: Representacin desde el mundo real y emprico a una representacin matemtica, donde puede ser ms fcilmente entendible en atributos de entidad y sus relaciones con otras entidades. El desafo real es interpretar el comportamiento matemtico y juzgar qu significa en el mundo real. Aspectos esenciales de una medicin: Datos duros: Son cuantificables, con poca o ninguna subjetividad (esfuerzo, volumen, documentacin, errores detectados, etc.) Datos blandos: Presentan un grado de subjetividad (habilidad, experiencia, satisfaccin del cliente, etc.) Datos normalizados: Se utilizan con propsitos comparativos (LOC, PF, PO)
5

Algunos aspectos a medir en ingeniera de software: Procesos o tareas a ejecutar (modelamiento, diseo, prueba, etc.) Productos entregados durante el proceso (documentacin de diseo, cdigo fuente, registro de pruebas) Recursos que permiten realizar el proceso (recursos financieros, personal, equipos, etc.) Atributos Internos y Externos: Atributo interno: Es medido directamente desde la entidad, por ej: Entidad = cdigo fuente Atributo interno = lneas de cdigo Atributo Externo: Medida de la entidad con relacin a una necesidad externa definida por el ambiente en el cual es desarrollada o utilizada, por ej: Entidad = cdigo fuente Atributo externo = mantenibilidad
6

PRODUCTO Entidades Especificaciones Atributos Internos Tamao, re-uso, modularidad, redundancia, funcionalidad, correctitud Tamao, re-uso, modularidad, acoplamiento, cohesin, funcionalidad Tamao, re-uso, modularidad, acoplamiento, funcionalidad, complejidad algortmica, estructuracin Tamao, nivel de cobertura Atributos Externos Comprensibilidad, mantenibilidad Calidad, complejidad, mantenibilidad
Diseo
Codificacin
Confiabilidad, usabilidad, mantenibilidad
Datos de prueba
Calidad

PROCESOS Entidades Especificacin de requerimientos Atributos Internos Tiempo, esfuerzo, nmero de cambios en los requerimientos Tiempo, esfuerzo, nmero de especificaciones errneas detectadas Tiempo, esfuerzo, nmero y errores encontrados Diagrama de distribucin Atributos Externos
Calidad, costo, estabilidad
Diseo detallado
Costo, costo-eficacia
Pruebas
Costo, costo-eficacia, estabilidad Nodo, componente, dependencia, localizacin

8
Vista de distribucin

RECURSOS Entidades Personal Atributos Internos Aos de experiencia, tasa de trabajo Tamao, nivel de comunicacin, estructuracin Tamao, costo Precio, velocidad, capacidad de memoria Tamao, temperatura, luz Atributos Externos Productividad, experiencia, inteligencia Productividad, calidad Usabilidad, confiabilidad Confiabilidad Confort, calidad
Equipos Software Hardware Oficinas

Definiciones de los Atributos Atributo Calidad Cohesin Grado de excelencia Definicin Acoplamiento Grado de fuerza de la interconexin entre los componentes del sistema Grado de relacin entre los componentes de una entidad Grado en que una entidad satisface las especificaciones y cumple los Correctitud objetivos del usuario Complejidad Diversidad de elementos que componen una entidad Complejidad Grado de dificultad computacional relativa de una funcin algortmica Costo Costo monetario para conseguir un objetivo determinado CostoGrado en que el costo est relacionado con la eficiencia de la solucin eficiencia Confiabilidad Grado de precisin con que una entidad efecta su funcin Confort Eficiencia Esfuerzo Grado de comodidad Cantidad de recursos y cdigo requeridos por una entidad para realizar una funcin Nivel de empleo de recursos en la consecucin de algn fin
10

Definiciones de los Atributos Atributo Estabilidad Definicin Grado de permanencia y equilibrio ante efectos externos Grado en que las partes de una entidad estn en una estructura Estructuracin determinada Experiencia Nivel de prctica o conocimiento de algn tema Funcionalidad Cun prctico y til es el resultado obtenido Inteligencia Mantenibilidad Nivel de cobertura Nivel de comunicacin Productividad Tasa de trabajo Usabilidad Re-uso Esfuerzo requerido para localizar y corregir un error en un programa en funcionamiento Grado en que un componente abarca o contempla cierto mbito solicitado Grado de comunicacin entre los distintos desarrolladores Grado de produccin por unidad de trabajo Medida de trabajo en el tiempo Esfuerzo necesario para aprender, operar, preparar entradas e interpretar las salidas de un programa Grado en que una entidad se puede utilizar en otras actividades
11

Otros Atributos Atributo Definicin
Flexibilidad Esfuerzo requerido para modificar un programa en funcionamiento Facilidad de Esfuerzo requerido para probar un programa (y para garantizar que prueba es capaz de realizar las funciones requeridas) InteroperabiliEsfuerzo requerido para acoplar un programa a otros sistemas dad Portabilidad Esfuerzo requerido para transferir un programa desde una configuracin de hardware o entorno de software, a otro
12

Mediciones Comunes Proceso: Costo Tiempo Esfuerzo Producto: Lneas de cdigo (LOC) Puntos de funcin (PF) Pginas de documentacin Velocidad de ejecucin de los programas Defectos detectados en un perodo Recursos: Tipo y cantidad de personal involucrado en el desarrollo Costo, disponibilidad de herramientas de apoyo Etc.
13

Mtricas de Calidad y Productividad. Productividad = KLOC / PM Calidad = defectos / KLOC Costo = $ / LOC Documentacin = pginas de documentacin / KLOC KLOC = miles de lneas de cdigo PM = Personas Mes Observacin: Las mediciones asociadas con LOC estn en permanente discusin, puesto que dependen del lenguaje de programacin y no son fciles de utilizar en lenguajes no procedurales.
14

Tcnicas de Estimacin. Etapa de planificacin del proyecto En base a mediciones de proyectos anteriores (informacin histrica) Divisin del proyecto en unidades ms pequeas y fciles de estimar Puntos que caracterizan el proyecto a estimar: Complejidad del proyecto: Medida relativa que se ve afectada por la familiaridad con proyectos anteriores. Genera incertidumbre en la planificacin Tamao del proyecto: Generalmente aumenta con la interdependencia entre los distintos componentes del software. Puede afectar a la precisin de las estimaciones Grado de estructuracin del proyecto: Facilidad con que las funciones pueden ser divididas y la naturaleza jerrquica de la informacin que se debe procesar. Tiene efectos sobre el riesgo en la estimacin.
15

Incertidumbre en las Estimaciones. Generalmente provocada por los cambios en los requerimientos del software Se puede minimizar con un anlisis profundo de los requisitos del software, lo cual puede demorar semanas o incluso meses. Las estimaciones son necesarias al inicio del proyecto y se actualizan continuamente Importancia de las reuniones iniciales entre analista y cliente Preguntas preliminares: Quin efectu la peticin del trabajo? Quin usar la solucin? Cul es el beneficio econmico de la solucin? Existen otras razones para implementar la solucin?
16

Preguntas orientadas a conocer mejor el problema y el cliente: Cmo caracteriza el cliente un buen rendimiento de la solucin? Cul es el problema que se intenta solucionar? Se puede describir o examinar el ambiente en que se usar la solucin? Existen limitaciones de algn tipo que puedan abortar el desarrollo? Preguntas enfocadas a la eficacia de las reuniones: Es usted la persona correcta para responder las preguntas? Es usted el interlocutor autorizado oficial? Son mis preguntas relevantes al problema que tiene? Hay algn otro tema que deba preguntar?
17

Estimacin de Costos de Software. Todo proyecto de software se debe ajustar a un presupuesto Dicho presupuesto se basa en las estimaciones iniciales del costo de desarrollo Se requiere experiencia, informacin histrica y uso de mtricas cuantitativas (cuando existan los datos para ello) Tcnicas para la estimacin de costos de software: Modelos algortmicos: En base a informacin histrica de mtricas de proyectos Juicio experto: Se obtiene por consenso de expertos en el desarrollo Estimacin por analoga: Se basa en el desarrollo previo de proyectos similares Precio por ganar: El costo se estima segn el presupuesto disponible Estimacin top-down: El costo se estima considerando la funcionalidad total del producto (funciones lgicas) Estimacin bottom-up: Se estima el costo de cada componente y luego se agrega en un costo total
18

Estimacin Top-Down: Primero se enfocan los costos a nivel de sistema, adems de: Manejo de la configuracin Control de calidad Integracin del sistema Entrenamiento Documentacin Personal Estimacin Bottom-Up: Primero se enfoca el costo de desarrollo de cada mdulo o subsistema (y las tareas de c/u) Luego tales costos se integran para obtener un costo total. Ventaja Se enfoca directamente en los costos del sistema Desventaja Riesgo de despreciar otros costos como: control de calidad, manejo de la configuracin, etc.
19

POSIBLES COSTOS DE UN SISTEMA DE INFORMACION Costos de consultora Costos de arriendo o compra de equipos Costos de Costos de modificacin del emplazamiento de los equipos elaboracin Costos de capital Costos de gestin y de personal Costos de software del sistema operativo Costos de Costos de instalacin de equipos de comunicaciones Costos de personal para la puesta en marcha puesta en Costos de contratacin de personal y arriendos marcha Costos de interrupcin en el resto de la organizacin Costos de gestin necesarios para dirigir la actividad inicial Costos de adquisicin del software de aplicacin Costos de la adecuacin del software a los sistemas locales Costos Costos de personal y gastos generales relacionados Costos de entrenamiento del personal y usuarios con el proyecto Costos de captura de informacin y procedimientos de instalacin Costos de documentacin Costos de supervisin Costos de mantenimiento del sistema (software, hardware, instalaciones) Costos del Costos de suministros (electricidad, telfono, etc.) Costos de depreciacin del hardware proceso Costos del personal involucrado en la operacin del sistema
20
10

Estimacin de Recursos. Recursos Humanos: Determinar el personal necesario, la posicin dentro de la organizacin. La cantidad de personal se determina despus de hacer la estimacin del esfuerzo de desarrollo Recursos de Hardware: Considerar tres categoras de hardware: El sistema dnde se desarrollar el producto La mquina objetivo hardware en que operar el sistema (produccin) Perifricos necesarios Recursos de Software: Herramientas que apoyan el proceso de desarrollo del nuevo sistema (gestin de proyectos, diseo, programacin, IDE, etc.)
21
ESTIMACION EN PROYECTOS DE SOFTWARE
22
11
Gestin de Proyectos de Software - Estimacin

Precisin en la Estimacin
Precisin real
Precisin requerida
Pequeo Fcil
Tamao de proyectos Dificultad
Grande Difcil
23

Caractersticas Deseables de una Buena Estimacin: Explicable: Pasos seguidos para llegar al resultado final Datos usados como fuente de la estimacin Suposiciones efectuadas Revisable: A medida que el proyecto avanza se cuenta con mayor informacin La estimacin se puede revisar y ajustar
24
12
Lmite superior
E s t i m a c i n
Lmite inferior Requerimientos Anlisis Diseo Codificacin
Real
Pruebas
Duracin
25

Distribucin Histrica del Esfuerzo
Pruebas 25%
Requerimientos 20%
Codificacin 15%
Diseo 40%
26
13

Estimacin por analoga en base a datos histricos. Proyecto similar anterior = 200 horas Estimacin por Fase: Requerimientos = 40 horas (200 x 20%) Valor real = 50 horas (10 horas de diferencia = 25%)
Fase
Requerimientos Diseo Codificacin Pruebas Total
Estimado
40 80 30 50 200
Real
50
Revisado
Diferencia
+10
100 38 63 250
+20 +8 +13 +50
27

Una buena estimacin del tiempo y esfuerzo permite ajustar y/o minimizar la inversin en un proyecto de software El enfoque bottom-up utiliza tcnicas de descomposicin del proyecto Es decir, se divide el problema en mdulos pequeos ms manejables Luego se aplica la metodologa de estimacin a los mdulos individuales Esto permite ajustar la estimacin de tiempo y personal necesario para el desarrollo del proyecto Dos esquemas de estimacin se utilizan ampliamente: Lneas de cdigo (LOC, KLOC) Puntos de funcin (PF) Ambos se puede utilizar. . . Como variable de estimacin para dimensionar los elementos de software Como mtricas de proyectos anteriores, para desarrollar estimaciones de costo y esfuerzo
28
14

Ventajas y Desventajas de LOC.
Ventajas
Fcil Base
Desventajas
Dependencia
del lenguaje de
de calcular
programacin
Difcil
de clculo de modelos de estimacin de costos de software existentes de literatura al respecto
de estimar en etapas tempranas del proyecto de estimar en lenguajes de programacin no procedurales todas las lneas de cdigo tienen la misma complejidad
Difcil
Existencia Fcil
de automatizar
No
29

Puntos de Funcin. Productividad = N productos / unidad de trabajo = N productos / costo total Cul es el producto del proceso de software? Funcionalidad entregada (apoyo al negocio) En general: Productividad = [outputs/inputs] (en un perodo de tiempo) Cmo se puede mejorar la productividad? Medir la productividad implica medir: Eficacia logro de los objetivos Eficiencia uso de recursos
30
15

Puntos de Funcin (cont.) Productividad del Software: PF v/s inputs PF/hora; hora/PF; PF/persona-mes Indica el costo promedio de produccin de software (unidad de costo) Qu Impacta la productividad del software? Tamao del proyecto: A mayor tamao menor productividad Habilidades individuales: Experiencia de los desarrolladores Habilidades en la gestin: Proyectos grandes requieren mayor habilidad para gestionarlos Tecnologa: Automatizacin de algunas tareas
31
Horas por Punto de Funcin
Tamao en Puntos de Funcin

32
16

Puntos de Funcin (cont.) Costo marginal cunto cambia el costo por unidad, a medida que cambia el tamao del proyecto? A medida que el tamao del proyecto aumenta: La complejidad aumenta Se requiere completar un mayor nmero de tareas Se requiere gestionar un mayor nmero de personas Las lneas de comunicacin aumentan Ausencia de economas de escala (costos fijos mnimos) Puntos de Funcin: Constituyen el output del proceso de desarrollo de software Unidad de software No vara con la habilidad del personal o el lenguaje utilizado Permiten calcular el costo promedio del producto
33

Puntos de Funcin (cont.) Costo promedio Ejemplo:
Costo de fabricar 1.000 productos X = $ 25.000 Costo por unidad = $ 25 Materia prima A = $ 5.000 ($ 5 por unidad) Materia prima B = $ 8.000 ($ 8 por unidad) Materia prima C = $ 12.000 ($ 12 por unidad)
El software no requiere materia prima Pero requiere distintos tipos de componentes tecnolgicos En tales componentes se puede basar un esfuerzo de estimacin
Estimacin = mtricas + modelo
34
17

Modelos Histricos o Experimentales: Expertos elaboran juicios acerca del esfuerzo de desarrollo requerido Se basan en su propia experiencia en proyectos similares, en su sentido comn, posiblemente en informacin histrica existente acerca de proyectos terminados Utilizado ampliamente en la actualidad Se basan en un anlisis estadstico para determinar parmetros y relaciones entre los parmetros que conforman los modelos Leyes matemticas que se asume sigue el proceso de desarrollo de software Incorporan una combinacin de ecuaciones analticas, ajustes estadsticos de datos y juicios expertos
35
Modelos Estadsticos:
Modelos Tericos:
Modelos Compuestos:

Metodologa de Estimacin:
modelo costo mensual
Estimacin del esfuerzo
Estimacin del costo
Estimacin del tamao
productividad
Estimacin del personal
Analoga Expertos Bottom-up PF
Estimacin del tiempo
Programacin de actividades
36
18

Tcnicas de Descomposicin Bottom-Up. Inicialmente el proyecto se desagrega en pequeas subfunciones, que pueden estimarse individualmente ya sea mediante LOC o PF Al utilizar LOC la descomposicin funcional es absolutamente necesaria Estimacin mediante LOC directa Estimacin mediante PF indirecta mediante la estimacin de: Nmero de entradas al sistema Nmero de salidas del sistema Nmero de archivos de datos internos Nmero de consultas al sistema Nmero de interfaces externas Factores de ajuste de complejidad Generalmente el estimador proporciona un rango de valores de estimacin para cada funcin descompuesta
37
Gestin de Proyectos de Software Estimacin.

Fronteras del Sistema.
SISTEMA
Cada sistema tiene sus propias entradas, salidas y almacenamiento interno. La frontera se define de acuerdo al punto de vista del usuario (stakeholder)
38
19

Puntos de Funcin (PF). www.ifpug.org Tcnica que se centra en la funcionalidad del software Los PF se asocian a los componentes del producto final, tal como los percibe el usuario Elementos considerados: Entradas al sistema Salidas del sistema Consultas al sistema Archivos internos Interfaces con otros productos de software Adems considera una cantidad de factores de ajuste PF Bsicos (PFB): Suma total de los elementos identificados para el software N salidas + N entradas + N consultas + N archivos + N interfaces PF No Ajustados (PFNA): Los valores obtenidos anteriormente se ponderan en base a una tabla de valores empricos segn su complejidad
39

Puntos de Funcin Tabla de Factores segn Complejidad. Componente Entradas Salidas Consultas Archivos Interfaces Simple 3 4 3 7 5 Promedio 4 5 4 10 7 Compleja 6 7 6 15 10 Total PFNA = PFNA
Se deben clasificar los distintos componentes del software segn su complejidad y luego multiplicar la cantidad por el factor indicado en la tabla.
40
20
Gestin de Proyectos de Software Puntos de Funcin

Entradas externas Salidas externas Consultas Archivos internos
Datos (Archivos Relacionados AR)
Transacciones
Interfaces externas Dado que el anlisis de transacciones depende tanto de la informacin contenida en ellas, adems de los archivos referenciados, se recomienda el siguiente orden para la contabilizacin: 1 Estimar los PF relacionados con transacciones (identificar AR) 2 Estimar los PF relacionados con los datos AR
41

Entradas Externas. Ingreso de datos externos a la aplicacin (cruzan la frontera del sistema) Pueden provenir desde una pantalla de ingreso de datos, o desde otra aplicacin. La informacin es utilizada para mantener archivos internos (agregar, modificar, eliminar)
Archivos Referenciados 1 4 Menos de 2 2 Ms de 2 Bajo (3) Bajo (3) Promedio (4)
Elementos de Datos 5 15 Bajo (3) Promedio (4) Alto (6) Ms de 15 Promedio (4) Alto (6) Alto (6)
42
21

Entradas Externas (cont.) Elementos de datos Campo nico no-recursivo: Campos de entrada de datos Valores calculados que se graban en archivos Botones de control (OK, Next, etc.) Sonido, imgenes, cambios de color, video, etc.
43

PF Entradas Externas: Vocabulario Tpico
44
22

Salidas Externas.
Proceso elemental en el cual ocurre un traspaso de datos a travs de la frontera, desde el interior del sistema hacia el exterior. Adicionalmente una salida externa puede actualizar un archivo interno (ILF Internal Logical File). Los datos generan informes o archivos de salida enviados a otros sistemas. Tales informes o archivos son creados a partir de informacin contenida en uno o ms archivos internos.
1 salida externa 2 archivos referenciados

45

Salidas Externas. Datos derivados Son datos que no son obtenidos directamente desde archivos internos o interfaces externas, sino que son producto de un algoritmo o proceso de clculo. Los datos derivados ocurren cuando uno o ms elementos de datos son combinados dentro de una frmula para generar datos adicionales, los cuales no estn contenidos en ningn archivo interno ni interfaz externa.
Archivos Referenciados 1 5 Menos de 2 2 3 Ms de 3 Bajo (4) Bajo (4) Promedio (5) Elementos de Datos 6 19 Bajo (4) Promedio (5) Alto (7) Ms de 19 Promedio (5) Alto (7) Alto (7)
46
23

Salidas Externas (cont.) Elementos de datos: Mensajes de error Mensajes de confirmacin Valores calculados Valores ledos desde archivos internos o interfaces externas Ttulos de columna dinmicos (ledos desde algn archivo)
47

PF Salidas Externas: Vocabulario Tpico
48
24

Consultas. Contiene un componente de entrada y un componente de salida (se deben contabilizar ambos) Captura de datos desde archivos internos y/o interfaces externas El componente de entrada no actualiza ningn archivo interno ni interfaz externa El componente de salida no contiene datos derivados.
Archivos Referenciados 1 5 Menos de 2 2 3 Ms de 3 Bajo (3) Bajo (3) Promedio (4) Elementos de Datos 6 19 Bajo (3) Promedio (4) Alto (6) Ms de 19 Promedio (4) Alto (6) Alto (6)
49

Individualizacin de Consultas:
Una consulta nica se identifica por tener un conjunto de datos distinto o por hacer referencia a archivos distintos. El ordenamiento de los datos no hace nica a una consulta. Se debe cumplir: Conjunto de elementos de datos nico o diferente. Conjunto de archivos referenciados nico o diferente. Procesamiento lgico nico o diferente.
ILF A
ILF B
ILF C
1 consulta 3 archivos referenciados

50
25

PF Consultas: Vocabulario Tpico
51

Archivos Internos. Agrupacin lgica de datos en el entorno del usuario Reside dentro de los lmites de la aplicacin Es mantenido mediante entradas externas Al menos debiera tener una entrada y una salida (o consulta) relacionadas
Tipos de Registros 1 19 1 2 a 5 Ms de 5 Bajo (7) Bajo (7) Promedio (10) Elementos de Datos 20 50 Bajo (7) Promedio (10) Alto (15) Ms de 50 Promedio (10) Alto (15) Alto (15)
52
26

Interfaces Externas. Agrupacin lgica de datos relacionados Slo se utiliza con el propsito de hacer referencia a datos que residen fuera de los lmites del sistema y que son mantenidos por otra aplicacin Se requiere desarrollar una interfaz para obtener los datos externos Una aplicacin puede contabilizar una agrupacin de datos como un archivo interno o como una interfaz externa, pero no ambos
Tipos de Registros 1 19 1 2 a 5 Ms de 5 Bajo (5) Bajo (5) Promedio (7) Elementos de Datos 20 50 Bajo (5) Promedio (7) Alto (10) Ms de 50 Promedio (7) Alto (10) Alto (10)
53

PF Factores de Ajuste por Complejidad Tcnica.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 Comunicacin de datos Funciones distribuidas Objetivos de rendimiento Configuracin ms usada Tasa de transacciones Entrada de datos en lnea Eficiencia usuario final Actualizacin en lnea Procesamiento complejo Reusabilidad Facilidad de instalacin Facilidad de operacin Sitios mltiples Facilidad de mantencin Elementos de comunicacin usados en la transferencia o intercambio de informacin Cmo se manejan los datos distribuidos y funciones de procesamiento Tiempo de respuesta, rendimiento requerido por los usuarios Utilizacin de la plataforma de hardware donde reside la aplicacin Cantidad de transacciones por perodo de tiempo (hora, da, mes, etc.) Porcentaje de informacin capturada en lnea En la interaccin del usuario con la aplicacin Cantidad de archivos que se actualizan por transacciones en lnea Cantidad de procesamiento lgico, matemtico, grfico, etc. Atencin de distintas necesidades de los usuarios Conversin de datos, distribucin del software (deployment) Efectividad y/o nivel de automatizacin de procedimientos (inicio, respaldo, recuperacin, etc.) Uno a varios sitios, una o varias organizaciones, etc. Metodologa, documentacin, etc.
54
27

Grados de Influencia de los Factores de Ajuste. A cada factor de complejidad se le debe asignar un grado de influencia de acuerdo a las caractersticas del software a desarrollar. La asignacin depende de la experiencia del desarrollador. GRADO DE INFLUENCIA PESO Sin influencia Insignificante Moderado Promedio Significativo Influencia fuerte 0 1 2 3 4 5
55

Factores de Ajuste.
Comunicacin de Datos Peso 0 1 Caracterstica Aplicacin puramente batch o PC standalone Aplicacin batch con ingreso remoto de datos o impresin remota Aplicacin batch con ingreso remoto de datos e impresin remota Aplicacin incluye ingreso de datos online o teleprocesamiento Aplicacin front-end, soporta un solo tipo de protocolo de comunicacin Aplicacin front-end, soporta varios tipos de protocolo de comunicacin
56
28

Factores de Ajuste.
Procesamiento Distribuido de Datos Peso 0 1 2 3 4 5 Caracterstica Aplicacin no participa en transferencia de datos o procesamiento entre componentes Aplicacin prepara datos para ser procesados por el usuario final u otro componente (ej: DBMS local) Aplicacin prepara y transfiere datos para ser procesados en otro componente Procesamiento distribuido y transferencia de datos en lnea en una direccin Procesamiento distribuido y transferencia de datos en lnea en ambas direcciones Funciones de procesamiento son distribuidas y ejecutadas en el componente ms apropiado
57

Factores de Ajuste.
Objetivos de Rendimiento Peso 0 1 Caracterstica Usuario no especific restricciones especiales de rendimiento Se especificaron y revisaron restricciones de rendimiento pero no requiere acciones especiales Tiempo de respuesta o rendimiento son crticos en horas peak. No requiere diseo especial para uso de CPU. Plazos de procesamiento para el siguiente da hbil Tiempo de respuesta o rendimiento son crticos en horas peak. No requiere diseo especial para uso de CPU. Plazos de procesamiento limitados Adems, la especificacin de rendimiento requiere tareas de anlisis de rendimiento en la fase de diseo Adems requiere el uso de herramientas de anlisis de rendimiento especiales, durante las fases de diseo e implementacin
58
29

Factores de Ajuste.
Configuracin ms Usada Peso 0 Caracterstica No se incluyen restricciones operacionales implcitas o explcitas Existen restricciones operacionales pero son menos restrictivas que una aplicacin tpica. No requiere esfuerzo especial para cumplir las restricciones Se incluyen algunas consideraciones de seguridad o sincronizacin Incluye requerimientos de un procesador especfico para una parte de la aplicacin Restricciones especificadas requieren restricciones especiales en cuanto al procesador central o procesador dedicado Adems hay restricciones especiales en cuanto a la distribucin de componentes
59
2 3

Factores de Ajuste.
Tasa de Transacciones Peso 0 1 2 3 4 Caracterstica No se anticipan periodos peak en las transacciones Se anticipan periodos peak en las transacciones (mensual, anual, semestral) Se anticipan periodos peak semanales en las transacciones Se anticipan periodos peak diarios en las transacciones Usuario establece altas tasas de transacciones. Requiere efectuar tareas de anlisis de rendimiento durante el diseo Usuario establece altas tasas de transacciones. Adems requiere el uso de herramientas de anlisis de rendimiento durante el diseo e implementacin
60
30

Factores de Ajuste.
Ingreso de Datos en Lnea Peso 0 1 2 3 4 5 Caracterstica Todas las transacciones son procesadas en modo batch 1% a 7% de las transacciones son interactivas 8% a 15% de las transacciones son interactivas 16% a 23% de las transacciones son interactivas 24% a 30% de las transacciones son interactivas Ms del 30% de las transacciones son interactivas
61

Factores de Ajuste.
Ayudas de navegacin (teclas de funcin, etc.) Mens Ayuda y documentacin en lnea Movimiento automtico del cursor Desplazamiento de ventanas Impresin remota Teclas de funcin preasignadas Procesos batch desde transacciones en lnea Seleccin del cursor en pantallas de datos Uso intenso de colores Documentacin impresa de transacciones en lnea Interfaz de mouse o similar Ventanas popup Soporte bilinge Soporte multilinge
Eficiencia del Usuario Final Peso 0 1 2 3 4 5 Caracterstica Ninguna 1 a 3 4 a 5 6 ms, pero sin requerimientos especficos relacionados con la eficiencia 6 ms. Requerimientos adicionales de eficiencia (plantillas, valores por defecto, etc.) 6 mas. Requiere el uso de herramientas especiales para medir eficiencia
62
31

Factores de Ajuste.
Actualizacin en Lnea Peso 0 1 Caracterstica Ninguna Actualizacin en lnea de 1 a 3 archivos. Bajo volumen de actualizacin. Recuperacin es fcil Actualizacin en lnea de 4 o ms archivos. Bajo volumen de actualizacin. Recuperacin es fcil Actualizacin en lnea de la mayora de los archivos Adems requiere programacin especial para proteccin contra prdida de datos Adems considera altos costos por proceso de recuperacin, mxima automatizacin, mnima intervencin del operador
63
2 3 4

Factores de Ajuste.
Control sensitivo (auditoria), procesamiento especfico de seguridad Procesamiento lgico extenso Procesamiento matemtico extenso Mucho procesamiento de excepciones debido a alta probabilidad de transacciones incompletas Procesamiento complejo de entrada/salida (multimedia, dispositivos de hardware, etc.)
Procesamiento Complejo Peso 0 1 2 3 4 5 Caracterstica Ninguna de las anteriores Una de las anteriores (cualquiera) Dos de las anteriores (cualquiera) Tres de las anteriores (cualquiera) Cuatro de las anteriores (cualquiera) Todas las anteriores
64
32

Factores de Ajuste.
Reusabilidad Peso 0 1 2 3 4 Caracterstica No requiere cdigo reusable Cdigo reusable dentro de la aplicacin Menos del 10% de la aplicacin se considera para necesidades de otros usuarios 10% o ms de la aplicacin se considera para necesidades de otros usuarios Aplicacin debe ser empaquetada y documentada para fcil reutilizacin. Reconfiguracin a nivel de cdigo Aplicacin debe ser empaquetada y documentada para fcil reutilizacin. Reconfiguracin por parametrizacin
65

Factores de Ajuste.
Facilidad de Instalacin Peso 0 1 Caracterstica Usuario no establece consideraciones especiales. No requiere ajustes especiales para la instalacin Usuario no establece consideraciones especiales. Requiere ajustes especiales para la instalacin Usuario establece requerimientos de conversin e instalacin. Se proveen y verifican guas de instalacin. El impacto de la conversin no se considera importante Usuario establece requerimientos de conversin e instalacin. Se proveen y verifican guas de instalacin. El impacto de la conversin se considera importante En adicin al punto 2, se requieren herramientas automatizadas de conversin e instalacin En adicin al punto 3, se requieren herramientas automatizadas de conversin e instalacin
66
4 5
33

Factores de Ajuste.
Se requieren procesos efectivos de inicio, recuperacin y respaldo, con intervencin del operador Se requieren procesos efectivos de inicio, recuperacin y respaldo, sin intervencin del operador (vale por 2) La aplicacin minimiza el montaje de cintas La aplicacin minimiza la carga de papel
Facilidad de Operacin Peso 0 1 - 4 5 Caracterstica No hay consideraciones especiales de operacin, aparte de los procesos normales de respaldo Uno o ms de los tems anteriores, c/u vale 1 punto (excepto indicacin expresa) La aplicacin se disea para operacin desatendida. Requiere recuperacin automtica de errores
67

Factores de Ajuste.
Sitios Mltiples Peso 0 1 2 3 Caracterstica Se requiere un nico sitio de instalacin Diseo debe considerar mltiples sitios con entornos de hardware y software idnticos Diseo debe considerar mltiples sitios con entornos de hardware y software similares Diseo debe considerar mltiples sitios con entornos de hardware y software diferentes Adems de los requerimientos descritos en 1 y 2, se debe proveer documentacin, planificacin y pruebas de la aplicacin en mltiples sitios Adems de los requerimientos descritos en 3, se debe proveer documentacin, planificacin y pruebas de la aplicacin en mltiples sitios
68
34

Factores de Ajuste.
Requiere proveer facilidades de consultas simples. Por ej: and/or sobre un mismo archivo (1) Requiere proveer facilidades de consultas promedio. Por ej: and/or sobre ms de un archivo (2) Requiere proveer facilidades de consultas complejas. Por ej: and/or sobre ms de un archivo (3) Datos del negocio se guardan en tablas mantenidas por los usuarios mediante procesos interactivos en lnea, los cambios se realizan el siguiente da hbil (1) Datos del negocio se mantienen en tablas mantenidas por los usuarios mediante procesos interactivos en lnea, los cambios se realizan inmediatamente (2)
Facilidad de Cambio Peso 0 1 2 3 4 5 Caracterstica Ninguno de los anteriores Uno de los anteriores Dos de los anteriores Tres de los anteriores Cuatro de los anteriores Todos los anteriores
69

Clculo Final.
PF = PFNA * FCT FCT = 0,65 + 0,01 * ci
(FCT = Factor de Complejidad Tcnica) i = [1..14]
Productividad de los desarrolladores = PF x HM (Hombre-Mes) Esfuerzo de desarrollo = PF / Productividad

Lenguaje 1032/AF 1 generacin 2 generacin 3 generacin 4 generacin Nivel 20.00 1.00 3.00 4.00 16.00
http://www.spr.com/
Promedio LOC por PF 16 320 107 80 20

70
35

PF Ejemplo Numrico.
Componente Entradas Salidas Consultas Archivos Interfaces 1 2 Simple Factor 3 4 3 7 5 Promedio 8 2 5 10 1 Factor 4 5 4 10 7 Complejo 12 1 5 7 Factor 6 7 6 15 10 Tot PFNA PFNA 104 17 53 219 7 400
71

Ejemplo (cont.)
FACTOR C1 C2 C3 C4 C5 C6 C7 C8 C9 C10 C11 C12 C13 C14 DESCRIPCION Comunicacin de datos Funciones distribuidas Objetivos de rendimiento Configuracin ms usada Tasa de transacciones Entrada de datos en lnea Eficiencia usuario final Actualizacin en lnea Procesamiento complejo Reusabilidad Facilidad de instalacin Facilidad de operacin Sitios mltiples Facilidad de mantencin TOTAL VALOR 5 3 4 3 4 5 3 5 3 1 5 3 5 5 54
72
Factor de Complejidad: FCT = 0,65 + 0,01 * 54 = 1,19 PF Ajustados = 400 * 1,19 = 476
36
73

Ejercicio:
En base a la especificacin de requerimientos para un sistema, utilizar puntos de funcin para estimar el esfuerzo, tiempo y costo de desarrollo. Basarse en el lenguaje que estime ms apropiado y utilizar la tabla de conversin LOC de la diapositiva anterior para determinar las estimaciones Realizar estimacin y entregar informe de resultados
74
37

Objetivos de las Mediciones de Software.
Qu sucede durante el desarrollo y la mantencin Hacer proceso y producto visible Evaluar estado actual, comparar con baselines
Comprender
Mtricas
Controlar
Proyecto Predecir a partir de baselines y objetivos, hacer cambios
Mejorar
Procesos y productos Cambios basados en mediciones y predicciones
75

Mediciones de Software: Cmo usar las mediciones de software?
Importante: Antes de hacer mediciones, definir el propsito y uso de los resultados de la medicin Ejemplo Recolectar nmero de defectos:

Clasificacin: informados interna o externamente, niveles de severidad, dificultad de reparacin, dnde se introdujeron, etc. Uso: Medidas de calidad, decisiones de liberacin de productos, comprobacin de productividad, base para un cambio de proceso, etc.
76
38

Determinando qu medir . . . GQM
Paradigma Goal Question Metric: enfoque para seleccionar e implementar mtricas. Involucra tres pasos:

Listar los objetivos principales Derivar de cada objetivo las preguntas que deben responderse para determinar si el objetivo se satisface Decidir qu medir para ser capaz de responder las preguntas de manera adecuada
77

GQM Ejemplo 1

Goal: Mejorar el proceso de revisiones de diseo Questions:

Cmo se hacen las revisiones de diseo actualmente? Cunto tiempo toman las revisiones de diseo? Cunto cuestan las revisiones de diseo? Qu mtodos de revisiones de diseo se usan? Qu tan efectivo es el proceso de revisiones de diseo?
78
39

GQM Ejemplo 1 (cont.)
Metrics:

Nmero de revisiones de diseo por mdulo Tiempo utilizado en revisiones por mdulo Costo de las revisiones Costo por error encontrado % de errores de especificacin encontrados % de errores de diseo encontrados en test de integracin
79

GQM Ejemplo 2

Goal: Evaluar la efectividad del estndar de codificacin Questions:

Quin est usando el estndar? Cul es la productividad de los codificadores? Cul es la calidad del cdigo producido?
Metrics:

Proporcin de codificadores (usando un estndar, ej: un lenguaje) Experiencia de codificadores (estndar, lenguaje, ambiente, etc.) Tamao del cdigo (LOC, PF, etc.) Esfuerzo Errores
80
40

Comentarios
Sin mediciones. . .

No podemos compararnos con estndares aceptados comnmente No sabemos si estamos mejor o peor que antes Mayor incertidumbre en la asignacin de recursos Mayor incertidumbre en la identificacin de problemas Se dificulta la deteccin de riesgos No se tiene visibilidad del proceso de desarrollo Etc.
81

Modelos de Estimacin:

Histricos Estadsticos Tericos Compuestos:

Combinacin de ecuaciones analticas, ajustes estadsticos de datos y juicios expertos Se basan en mtricas comunes para producir estimaciones al inicio de un proyecto (LOC, PF) Incluyen factores de ajuste de acuerdo a las caractersticas de cada proyecto COCOMO COCOMO II MACOS
82
41

COCOMO (COnstructive COst MOdel). Desarrollado en 1981 por Barry Boehm Usado para estimacin de esfuerzo de desarrollo y mantencin de software Permite estimar: Tiempos de desarrollo Esfuerzo de desarrollo Esfuerzo de mantencin anual Considera tres categoras de modelo segn la exactitud requerida: COCOMO bsico COCOMO intermedio COCOMO avanzado Hace diferencia entre tres tipos de proyectos: Proyectos orgnicos Proyectos semi-conectados Proyectos integrados
83

COCOMO Tipos de Proyectos Proyectos Orgnicos: Equipos de desarrollo pequeo y experimentado. Ambiente familiar con aplicaciones conocidas. Proyectos de no ms de 50 kloc Proyectos Semiconectados: Equipo de desarrollo mezcla de personal experimentado y novato con alguna experiencia en la tecnologa y la aplicacin. Suelen tener interaccin con otros sistemas, tamao de no ms de 300 kloc Proyectos Integrados: Grandes equipos de desarrollo, poco experimentado en el rea de la aplicacin (proyectos nicos). Proyectos presentan fuerte acoplamiento entre el hardware, software y procesos operacionales. Escasa modificacin de requerimientos iniciales. Altos costos de validacin
84
42
Gestin de Proyectos de Software Estimacin

COCOMO Jerarqua de Modelos. Modelo Bsico: Permite estimar el esfuerzo y tiempo de desarrollo de software en funcin del tamao expresado en LOC (estimadas). Apropiado para hacer estimaciones rpidamente sin mucha precisin. Modelo Intermedio: Permite estimar el esfuerzo de desarrollo de software en base al tamao estimado en LOC, ms un conjunto de parmetros de ajuste que incluyen una evaluacin subjetiva del producto, del hardware, del personal y de los atributos del proyecto (juicio de expertos) Modelo Avanzado: Incorpora todas las caractersticas del modelo intermedio, efectuando una evaluacin de los parmetros de ajuste en cada fase del proyecto (anlisis, diseo, etc.) Las estimaciones de esfuerzo se expresan en persona-mes, considerando un valor estndar de 152 horas al mes por persona.
85

COCOMO Definiciones y Supuestos. KDSI (Kilo Deliveded Source Instruction): Miles de instrucciones fuentes entregadas. Excluye explcitamente el cdigo no entregado, no se contabilizan los comentarios ni el cdigo reusado sin modificaciones. Incluye las declaraciones de datos, instrucciones JCL, formateos, etc. Las ecuaciones de esfuerzo y tiempo abarcan desde diseo a test de integracin Las estimaciones slo cubren las actividades relacionadas directamente con el desarrollo del proyecto (excluye entrenamientos, instalacin, conversin, etc.) Las estimaciones cubren los cargos directos del proyecto, excluyendo operadores de centro de procesamiento de datos, secretarias, etc. Una persona-mes equivale a 19 das hbiles 152 horas mensuales de trabajo Se asume que el proyecto es bien administrado La especificacin de requerimientos no va a cambiar sustancialmente El modelo de desarrollo sigue el paradigma clsico (cascada)
86
43

Modelo COCOMO Bsico
Orgnico Esfuerzo estimado [PM] Ed Tiempo estimado (meses) Td Productividad N medio personas Esfuerzo de Mantencin [PM] Semiconectado Integrado
2,4 * (KDSI)1,05 3,0 * (KDSI)1,12 3,6 * (KDSI)1,20 2,5 * (Ed)0,38 2,5 * (Ed)0,35
Pr = DSI / Ed P = Ed / Td
ACT (Annual Change Traffic): porcin de instrucciones fuente que sufren algn cambio durante un ao
2,5 * (Ed)0,32
Em = ACT * Ed Pm = Em / 12
Pm: N medio de personas a tiempo completo dedicadas a mantencin durante 12 meses
87

Modelo COCOMO Bsico Ejemplo. El tamao de un proyecto se estima en 32000 DSI, el cul ser desarrollado por un equipo local de desarrolladores con experiencia en proyectos similares. Se puede considerar como un proyecto orgnico. Estimaciones: Esfuerzo Tiempo Productividad Dotacin promedio = 2,4 (32)1,05 = 2,5 (91)0,38 = 32000 / 91 = 91 / 14 = 91 persona-mes = 14 meses = 352 DSI/PM = 6,5 FSP
FSP = Full-time equivalent Software Personnel
88
44

Modelo COCOMO Bsico Ejemplo (cont.) Si se cuenta con datos histricos de distribucin de esfuerzo y tiempo, se pueden realizar estimaciones para una fase en particular. Por ejemplo: Esfuerzo: Diseo = 16%, Codificacin = 62%, Pruebas = 22% Tiempo: Diseo = 19%, Codificacin = 55%, Pruebas = 26% Estimaciones para la fase de codificacin: Esfuerzo = 0,62 * 91 Tiempo = 0,55 * 14 Dotacin promedio = 56 / 7,7 = 56 persona-mes = 7,7 meses = 7,3 FSP
89

Modelo COCOMO Bsico Estimacin de Esfuerzo de Mantencin (Em) Se efecta en base al concepto ACT (Annual Change Traffic) que corresponde a la fraccin de instrucciones fuente del producto, que son sometidas a cambios durante un ao tpico (modificacin o agregacin): Ejemplo: Para el mismo proyecto anterior (32000 DSI) se determina que en un ao se agregarn 4000 DSI y se modificarn 2400 DSI: ACT = 4000 + 2400 = 6400 DSI 6400 / 32000 = 0,2 Em = 0,2 * 91 = 18 PM Dotacin promedio = 18 / 12 = 1,5 FSP
90
45

Caracterstica
Entendimiento organizacional de los objetivos del producto Experiencia necesaria en sistemas similares Cumplimiento con requerimientos preestablecidos Cumplimiento con especificaciones de interfaces externas Desarrollo concurrente con nuevo hardware y procedimientos operac. Innovacin en procesamiento, arquitectura, algoritmos Premios por entregas a tiempo Rango en tamao
Orgnico Preciso Extensiva Bsico Bsico Alguno Mnima Bajo 50 KDSI
Semiconectado Considerable Considerable Considerable Considerable Moderado Alguna Medio < 300 KDSI
Integrado General Moderada Total Total Extensivo Extensiva Alto
91

Caracterstica Orgnico Ejemplos Semiconectado Integrado Sistema transaccional complejo SO main-frame Aeronutica
Proceso batch Sistema transaccional Mdulos cientficos Control de produccin Modelos de negocio Inventario estricto Inventario simple
Tamaos Estndares S: Pequeo I: Intermedio M: Medio L: Grande VL: Muy grande 2 KDSI 8 KDSI 32 KDSI 128 KDSI 512 KDSI
92
46

Sistema Tamao
F-22 Windows 98 Microsoft Word Windows XP Linux Proyecto ms caro de la historia

Costo sistemas grandes (> 100.000 PF)
1,6 millones de LOC 87.000 LOC 5.000 PF > 100.000 PF 50.000 PF (app) Y2K (36 millones de sistemas afectados)
Similar a un estadio techado o 50 rascacielos
Mass-Updates and Software Project Management Caper Jones 30/01/99
93

Modelo COCOMO Intermedio Versin ampliada del modelo bsico Presenta mayor precisin en las estimaciones, en base a la incorporacin de 15 factores que reflejan la influencia de ciertos elementos en el costo del software Estos factores se agrupan en cuatro categoras: Atributos del producto Atributos del hardware Atributos del personal Atributos del proyecto Cada uno de estos atributos tiene asociado un factor multiplicador que refleja su influencia sobre el esfuerzo
94
47

Modelo COCOMO Intermedio: Orgnico Semiconectado Integrado
Esfuerzo nominal En=3,2 * (KLOC)1,05 En=3,0 * (KLOC)1,12 En=2,8 * (KLOC)1,20 PM
Esfuerzo Total:
ED = EN * FI
95

Tabla Factores de Ajuste COCOMO Intermedio.
96
48

Modelo COCOMO Intermedio Atributos del Producto: Confiabilidad: Debe reflejar las posibles consecuencias para el usuario, en caso que aparezcan errores en el producto entregado:
Bajo = sin mayores consecuencias para los usuarios Muy Alto = prdida de vidas humanas
Tamao BD: Se mide en bytes y se estima en relacin a la cantidad de LOC

Bajo = tamao < 10 * LOC Nominal = 10 * LOC < tamao < 100 * LOC Muy Alto = tamao > 1000 * LOC
Complejidad: Se estima en base al uso de operaciones de E/S, caractersticas de las estructuras de datos, caractersticas de codificacin
Bajo = E/S y estructuras de datos simples, codificacin fcil Nominal = E/S frecuente, mltiples archivos, comunicacin inter mdulos remotos Muy Alto = cdigo recursivo, procesamiento paralelo, estructuras de datos complejas
97

Modelo COCOMO Intermedio Atributos del Hardware: Restricciones tiempo de ejecucin: Codificacin es ms exigente cuando los programas tienen restricciones en su tiempo de ejecucin
Nominal = 50% tiempo de ejecucin disponible Extra Alto = 95% tiempo de ejecucin disponible
Restricciones memoria virtual: Porcentaje de memoria principal utilizado por el programa

Nominal = Reduccin del 50% en almacenamiento principal Muy Alto = Reduccin del 95% en almacenamiento principal
Volatilidad mquina virtual: Tasa de cambios de la mquina virtual (Hw+Sw) Tiempo de respuesta:
A menor tiempo de respuesta, mayor esfuerzo de desarrollo
98
49

Modelo COCOMO Intermedio Atributos del Personal: Capacidad anlisis: Habilidad, eficiencia y capacidad de cooperar
Un grupo con mayor capacidad requiere menor esfuerzo
Experiencia aplicacin: Experiencia del grupo en el desarrollo de aplicaciones similares

Muy bajo Bajo Nominal Alto Muy alto Menos de 4 meses de experiencia media 1 ao de experiencia media 3 aos de experiencia media 6 aos de experiencia media Ms de 12 aos de experiencia media
Capacidad programacin: Similar a la capacidad de anlisis pero aplicado al grupo de programadores
99

Modelo COCOMO Intermedio Atributos del Personal (cont): Experiencia mquina virtual: Cuanto mayor sea la experiencia del grupo en la programacin del procesador, menor ser el esfuerzo
Muy bajo Bajo Nominal Alto Muy alto Menos de 1 mes de experiencia media 4 meses de experiencia media 1 ao de experiencia media Ms de 3 aos de experiencia media Ms de 12 aos de experiencia media
Experiencia Lenguaje: Un grupo con mayor experiencia genera programas ms seguros y con menos cantidad de defectos
Muy bajo Bajo Nominal Alto Menos de 1 mes de experiencia media 4 meses de experiencia media 1 ao de experiencia media Ms de 3 aos de experiencia media
100
50

Modelo COCOMO Intermedio Atributos del Proyecto: Tcnicas de programacin: Se considera de acuerdo a la tabla adjunta
Muy bajo Bajo Nominal Alto Muy alto No se utilizan prcticas modernas de programacin Se usan algunas prcticas de modo experimental Experiencia razonable en el uso de algunas prcticas Experiencia razonable en gran parte de las prcticas Uso habitual de prcticas modernas de programacin
Utilizacin herramientas de software: El uso adecuado de herramientas de software es un multiplicador de la productividad. La puntuacin vara desde Muy bajo cuando slo se utilizan herramientas bsicas, a Muy alto cuando se utilizan herramientas especficas Restricciones tiempo de desarrollo: Se refiere al plazo de entrega. Muy alto demanda ms esfuerzo por parte del equipo
101

Modelo COCOMO Avanzado Presenta una mejora con respecto al modelo intermedio: Los factores de ajuste se aplican a cada fase y sobre cada una de ellas se realizan las estimaciones. El modelo considera las siguientes fases: Anlisis de requerimientos Diseo del producto Programacin Testing Verificacin y validacin Funciones de oficina (administracin) CM & QA - Gestin de la configuracin y aseguramiento de la calidad Documentacin (manuales)
En general el esfuerzo extra requerido en el modelo COCOMO avanzado no se justifica, dada la similitud con los resultados del modelo COCOMO intermedio.
102
51

Ejemplo de Estimacin de Esfuerzo (COCOMO intermedio) Se va a desarrollar un proyecto en modo semiconectado, cuyo tamao estimado es 32 KLOC, con los sgtes. factores de ajuste:
103

Ejemplo de Estimacin de Esfuerzo (cont.) Resultado factores de ajuste:
FI = 0,72
Esfuerzo nominal: En = 3,0 * (32)1,12 = 146 [P/M]
Esfuerzo total: Ed = 146 * 0,72 = 105 [P/M]
ED = EN * FI
Tiempo de desarrollo: Td = 2,5 * (Ed)0,35 = 2,5 * (105)0,35 = 13 [meses]
Personal estimado: P = Ed / Td = 105/13 = 8 [personas]
104
52

Resumen Modelo COCOMO Avanzado Modelo Avanzado requiere mayor esfuerzo de estimacin Resultados obtenidos similares al modelo intermedio Muchos factores no incluidos Importancia de calibracin Desarrollo de COCOMO II Cambios en tecnologa de software Nuevos modelos de ciclos de vida Nuevas herramientas de desarrollo Reingeniera Generadores de aplicaciones Enfoques orientados a objetos Etc.
105

Ejemplo COCOMO Intermedio Proyecto de 10 KDSI modo integrado
106
53

Ejemplo COCOMO Intermedio (cont.) Aplicar frmula de esfuerzo:
2,8 (10)1,20 = 44 PM
Aplicando el factor de ajuste queda:
44 * 1,17 = 51 PM
Asumiendo un costo promedio de US$ 6000 por PM, se obtiene un costo total de US$ 306.000 Es posible asumir que los costos se podran alterar contratando a personal menos preparado y ms barato. Otra posibilidad es modificar el hardware utilizado Este modelo permite analizar si las alteraciones tienen un impacto positivo o negativo en los costos
107

Ejemplo COCOMO Intermedio (cont.) Alteracin 1:
Se contrata a personal menos capacitado a un costo de US$ 5000 por mes. Los factores ACAP y PCAP bajan de alto a nominal, Esto altera el valor del factor de ajuste a 1,58 (en lugar de 1,17) Esfuerzo = 44 * 1,58 = 70 PM Costo = 70 * 5000 = US$ 350.000 impacto negativo en el costo
Alteracin 2:
Se aumenta la memoria principal de 6,4 GB a 9,6 GB, con un costo adicional de US$ 10000. Esto modifica el valor del factor STOR desde 70% a 47% cambiando de alto a nominal El nuevo factor de ajuste es 1,10 Esfuerzo = 44 * 1,10 = 48 PM Costo = 48 * 6000 = US$ 280.000 + US$ 10000 = US$ 290.000 Esta alteracin implica un impacto positivo en el costo total del sistema
108
54

Productividad por Puntos de Funcin. Global EEUU Canad Chile = 92,5 PF/PA = 7,70 PF/PM
= 88,17 PF/PA = 7,35 PF/PM = 111 PF/PA = 9,25 PF/PM = 5,00 PF/PM (*)
(*) Encuesta jefes de proyectos 2004
109

Modelo COCOMO II Adaptado a los ciclos de vida de los modelos de desarrollo de software actuales Mtodos giles Reutilizacin del software Programacin orientada al objeto Se puede basar en puntos de funcin o en puntos de objeto Considera tres modelos distintos: Modelo de composicin de aplicacin: Utilizado en proyectos construidos en base a herramientas de construccin GUI modernas Modelo de pre-arquitectura: Permite establecer estimaciones robustas de costo y duracin del proyecto, antes de determinar completamente su arquitectura Modelo de post-arquitectura: Corresponde al esfuerzo de desarrollo estimado despus de haber fijado la arquitectura del sistema. Puede ajustarse para:
Estimaciones tempranas. Corresponde al modelo de pre-arquitectura Mantenimiento Estimacin de cantidad de defectos esperados
110
55

COCOMO II Modelo de Composicin de Aplicacin Normalmente se conoce poco acerca del tamao probable del producto final Se trabaja con prototipos para resolver aspectos de alto riesgo El tamao se estima en puntos de objeto, los cuales capturan el tamao del producto en trminos de generadores de esfuerzo de alto nivel: Cantidad de tablas de datos de clientes y servidores % de pantallas, informes y mdulos 3GL reusados de proyectos anteriores COCOMO II Modelo de Pre-arquitectura Se decide continuar con el desarrollo, pero deben explorarse arquitecturas y conceptos de operacin alternativos Se conoce ms que en la etapa anterior, pero no lo suficiente como para estimar con precisin Se utilizan puntos de funcin como estimador de tamao, pues ofrecen una mejor descripcin que los puntos de objeto para estimar la funcionalidad capturada en los requerimientos del sistema
111

COCOMO II Modelo de Post-arquitectura Ha comenzado el desarrollo y se cuenta con mucha ms informacin Se estima el tamao en trminos de LOC Se utilizan los factores de costo de manera similar al modelo original Incorpora modelos de reuso, nuevos factores de costo y nuevos valores de parmetros Considera la mantencin y la degradacin del producto (breakage o cambios en los requerimientos a travs del tiempo)
112
56

Puntos de Objeto: Considera pantallas, reportes y mdulos en lenguajes de 3 generacin Los puntos de objeto no estn necesariamente relacionados con los objetos en un lenguaje POO Se estima la cantidad de objetos, la complejidad de cada objeto, el % de reuso y la productividad Cada objeto se clasifica segn su complejidad: simple, promedio o difcil, segn la tabla adjunta
srv = N de tablas de datos de servidores usados en conjunto con las pantallas y reportes clnt = N de tablas de datos cliente (PCs) usados en conjunto con las pantallas y reportes
113

Puntos de Objeto (cont): Los valores de cada celda de la tabla anterior se debe multiplicar con los valores de la tabla siguiente:
El resultado final se suma, obtenindose la cantidad de puntos de objeto (OP) Luego se puede estimar: Esfuerzo = NOP / PROD NOP = OP * (100 - % reuso)/100 PROD se obtiene de la tabla siguiente:
114
57

Puntos de Objeto (cont): Black-Box Cdigo reusado directamente sin modificaciones White-Box Cdigo que se debe mantener antes de reutilizar Cdigo White-Box Reusado (en LOCs): % del cdigo que debe ser rediseado (A) % del cdigo que debe ser modificado (B) % del cdigo que debe ser probado nuevamente (C) LOC Equivalente Representa la cantidad de cdigo nuevo que podra generarse con el mismo esfuerzo necesario para modificar cdigo existente LOC Equivalente = Cdigo Existente * (%A + %B + %C)/3 Ejemplo: Se requiere reutilizar parte de un sistema de 10.000 LOC 40% del cdigo se debe redisear 50% del cdigo se deben rehacer 60% del cdigo se debe probar nuevamente LOC Equivalente = 10.000 * (40% + 50% + 60%)/3 = 5.000
115

Modelo COCOMO II Post-Arquitectura Pasos a seguir: 1. Estimacin de puntos de funcin no ajustados - PFNA: 2. Conversin de puntos de funcin a KLOC 3. Aplicacin de las frmulas bsicas de esfuerzo, tiempo y personal requerido
Esfuerzo = 2,94 * EAF * (KLOC)E

EAF = Productoria de los factores de ajuste segn tabla 1 E = Exponente calculado segn: E = 0,91 + 0,01 * Fi Fi = Parmetros de costo (segn tablas adjuntas): PREC: Desarrollos similares previos FLEX: Flexibilidad del desarrollo RESL: Manejo de riesgos y arquitectura TEAM: Cohesin del equipo de desarrollo EPML: Nivel de madurez, en relacin al modelo de madurez de Sw.
116
58

Modelo COCOMO II Tabla 1: Factores de ajuste de costo
RELY DATA CPLX RUSE DOCU TIME STOR PVOL ACAP APEX PCAP LTEX PLEX PCON SITE TOOL SCED
117

Modelo COCOMO II Tablas parmetros de costo (Fi):
Desarrollos Previos Similares
Flexibilidad del Desarrollo

118
59

Manejo de Riesgos y Arquitectura
119

Cohesin del Equipo de Desarrollo
120
60

Nivel de madurez, en relacin al modelo de madurez de Sw.
Capability Maturity Model

121

Modelo COCOMO II Post-Arquitectura Frmulas de Estimacin:
Esfuerzo = 2,94 * EAF * (KLOC)E
[persona-mes]
Tiempo = 3,67 x Esfuerzo(0,28 + 0,002 x Fi)
[meses]
Personal = Esfuerzo / Tiempo
[FSP]
122
61

COCOMO II Estimacin Pre-Arquitectura COCOMO II sugiere que muchos de los 17 multiplicadores de esfuerzo no pueden estimarse en el diseo temprano, por lo que los reduce a 7 multiplicadores.
123

COCOMO II Estimacin Pre-Arquitectura (cont.)
124
62

125

126
63

COCOMO II Estimacin Pre-Arquitectura (cont.) Ajustes por Mantenimiento: La reusabilidad del software se estima en base a un modelo no lineal Estimacin de la cantidad de software a ser adaptado (ASLOC), ms tres parmetros segn el grado de modificacin:
Esfuerzo de comprensin del software a ser modificado (SU) Esfuerzo en la evaluacin y asimilacin de mdulos a ser reutilizados (AA)
127

COCOMO II Estimacin Pre-Arquitectura (cont.) El incremento que supone la comprensin del software (SU) se expresa en porcentaje y se obtiene de la tabla siguiente:
128
64

COCOMO II Estimacin Reusabilidad Pre-Arquitectura (cont.) El otro incremento no lineal sobre la reusabilidad est relacionado con el grado de valoracin y asimilacin (AA) necesarias para determinar si un cierto mdulo de software completamente reutilizable es apropiado para la aplicacin, e integrar su descripcin dentro de la descripcin global del producto. La tabla siguiente proporciona una escala para este porcentaje
Finalmente la ecuacin para determinar la reusabilidad es:
ESLOC = ASLOC x (AA + SU + 0,4 x DM + 0,3 x CM + 0,3 x IM) 100

129

Ejercicio:

En base a la misma especificacin de requerimientos utilizada en el ejercicio de puntos de funcin, realizar un ejercicio de estimacin de esfuerzo, tiempo y costo de desarrollo, mediante el modelo COCOMO (evaluar qu modelo COCOMO utilizar). Basarse en el lenguaje que estime ms apropiado y utilizar la tabla de conversin LOC para determinar las estimaciones Realizar estimacin y entregar informe de resultados
130
65

Modelo Algortmico de Costos de Software MACOS Se basa en puntos de funcin ms un conjunto de factores de ajuste asociados a las caractersticas del producto y del ambiente de desarrollo Estimaciones: Esfuerzo Ajustado Estimado EAE [horas-hombre] Tiempo de Desarrollo Estimado TDESE [horas] El factor de ajuste del modelo MACOS considera la incidencia de 32 factores asociados a aspectos tcnicos del diseo y construccin del producto de software, as como al entorno en el que se desarrolla el proyecto. Estos factores se clasifican en: Difciles de cuantificar Cuantificables
131

Factores de Ajuste modelo MACOS
132
66

Factores de Ajuste Modelo MACOS
133

Valoracin de los Factores de Ajuste Modelo MACOS. A cada factor se le asigna un valor denominado grado de influencia (GI), que vara entre -5 y +5, el cual indica la incidencia del factor en el costo del proyecto. El signo ms (+) significa aumento del esfuerzo El signo menos (-) significa disminucin del esfuerzo
134
67

Pasos del Modelo MACOS. Paso 1: Calcular los puntos de funcin no ajustados (PFNA). Contabilizar por categoras las entradas, salidas, consultas, archivos internos e interfaces con otros sistemas. Asignar las ponderaciones: simple, promedio, compleja. Paso 2: Calcular los factores de ajuste MACOS (FA)
SGI = GIi i = 1,..,32 FA = 1 + (SGI / 400)

Calcular el esfuerzo ajustado estimado (EAE):
EAE = 1,04 * (PFNA)1,22 * FA [horas-hombre]

Calcular el tiempo de desarrollo estimado (TDESE):
TDESE = EAE / NPTC [horas]

NPTC = cantidad de personas de tiempo completo disponible para el desarrollo
135

Ejemplo de Estimacin con LOC / PF / MACOS.
136
68

Ejemplo Estimacin por LOC
Esp = Opt + 4*Pro + Pes 6 Productividad = 35 LOC/da Esfuerzo = 8157/35 = 233,06 [HD] OBS: LOC y productividad se obtienen de datos histricos
137

Ejemplo Estimacin por PF
138
69

Ejemplo Estimacin por PF (cont.)
139

Ejemplo Estimacin por PF (cont.)
140
70

Ejemplo Estimacin por PF (cont.) Factor de Complejidad Tcnica (FCT) = 0,65 + 0,01 * 52 = 1,17 PF ajustados = PFNA * FCT = 400 * 1,17 = 468 Clculo de tamao y esfuerzo: Equivalencia PF v/s 4GL = 20 [LOC/PF] 468 [PF] * 20 [LOC/PF] = 9360 [LOC] Productividad promedio = 35 [LOC/HD] Esfuerzo = 9360 / 35 = 267,4 [HD] valor histrico
141

Ejemplo Estimacin por MACOS
142
71

Ejemplo Estimacin por MACOS (cont.) FA = 1 + (SGI / 400) = 1 + (17/400) = 1,04 EAE = 1,04 * (PFNA)1,22 * FA = 1,04 * (400)1,22 * 1,04 = 1616,52 HH = 202,07 HD TDESE = EAE / NPTC Productividad = 35 LOC/HD Tamao = EAE * Productividad = 202,07 * 35 = 7072 LOC
143

Comentarios. Calculadora on-line COCOMO 81:
http://sunset.usc.edu/research/COCOMOII/cocomo81_pgm/cocomo81.html
Calculadora on-line Puntos de Funcin:

http://www.engin.umd.umich.edu/CIS/course.des/cis525/js/f00/harvey/FP_Calc.html
COCOMO II:
http://sunset.usc.edu/csse/research/COCOMOII/cocomo_main.html
144
72

Calibracin modelo COCOMO II.

Un modelo calibrado implica estimaciones ms precisas Necesidad de considerar caractersticas de la organizacin Frmula general: Esfuerzo = A * EAF * (KLOC)E (A = 2,94)
Constante A se puede calibrar en base a datos histricos Requiere datos de al menos 5 proyectos anteriores Determinar estimacin sin la constante A Utiliza logaritmo natural
145

Calibracin modelo COCOMO II (cont.)

A = anti-ln e0,97 Frmula original: Frmula calibrada:
= 2,63 Esfuerzo = 2,94 * EAF * (KLOC)E Esfuerzo = 2,63 * EAF * (KLOC)E

146
73

Ejercicio:

En base a la misma especificacin de requerimientos utilizada en el ejercicio de puntos de funcin, realizar un ejercicio de estimacin de esfuerzo, tiempo y costo de desarrollo, mediante el modelo MACOS. Basarse en el lenguaje que estime ms apropiado y utilizar la tabla de conversin LOC para determinar las estimaciones Realizar estimacin y entregar informe de resultados
147
FIN
148
74

Iet Isw Unidad2

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Iet Isw Unidad2

Transféré par

Droits d'auteur :

Formats disponibles

Ingeniera de Software Unidad 2

Gestin de Proyectos de Software

Gestin de Proyectos de Software

Gestin de Proyectos de Software

MEDICIONES EN PRODUCTOS Y PROCESOS DE SOFTWARE

Gestin de Proyectos de Software - Medicin

Gestin de Proyectos de Software - Medicin

Gestin de Proyectos de Software - Medicin

Gestin de Proyectos de Software - Medicin

Confiabilidad, usabilidad, mantenibilidad

Gestin de Proyectos de Software - Medicin

Calidad, costo, estabilidad

Costo, costo-eficacia, estabilidad Nodo, componente, dependencia, localizacin

Gestin de Proyectos de Software - Medicin

Equipos Software Hardware Oficinas

Gestin de Proyectos de Software - Medicin

Gestin de Proyectos de Software - Medicin

Gestin de Proyectos de Software - Medicin

Gestin de Proyectos de Software - Medicin

Gestin de Proyectos de Software - Medicin

Gestin de Proyectos de Software - Medicin

Gestin de Proyectos de Software - Medicin

Gestin de Proyectos de Software - Medicin

Gestin de Proyectos de Software - Medicin

Gestin de Proyectos de Software - Medicin

Gestin de Proyectos de Software - Medicin

Gestin de Proyectos de Software - Medicin

Gestin de Proyectos de Software

ESTIMACION EN PROYECTOS DE SOFTWARE

Gestin de Proyectos de Software - Estimacin

Tamao de proyectos Dificultad

Gestin de Proyectos de Software - Estimacin

Gestin de Proyectos de Software - Estimacin

Gestin de Proyectos de Software - Estimacin

Gestin de Proyectos de Software - Estimacin

+20 +8 +13 +50

Gestin de Proyectos de Software - Estimacin

Gestin de Proyectos de Software - Estimacin

de clculo de modelos de estimacin de costos de software existentes de literatura al respecto

Gestin de Proyectos de Software - Estimacin

Gestin de Proyectos de Software - Estimacin

Gestin de Proyectos de Software - Estimacin

Horas por Punto de Funcin

Tamao en Puntos de Funcin

Gestin de Proyectos de Software - Estimacin

Gestin de Proyectos de Software - Estimacin

Estimacin = mtricas + modelo

Gestin de Proyectos de Software - Estimacin

Gestin de Proyectos de Software - Estimacin

Estimacin del esfuerzo

Estimacin del costo

Estimacin del tamao

Estimacin del personal

Analoga Expertos Bottom-up PF

Estimacin del tiempo

Gestin de Proyectos de Software - Estimacin

Gestin de Proyectos de Software Estimacin.

Gestin de Proyectos de Software - Estimacin

Gestin de Proyectos de Software - Estimacin

Gestin de Proyectos de Software Puntos de Funcin

Gestin de Proyectos de Software Puntos de Funcin

Gestin de Proyectos de Software Puntos de Funcin

Gestin de Proyectos de Software - Estimacin

Gestin de Proyectos de Software Puntos de Funcin