UNIVERSIDAD PERUANA LOS ANDES

FACULTAD DE INGENIERIA

CATEDRA: DESARROLLO DE SISTEMAS

CATEDRATICO: ING. JORGE ALBERTO VEGA FLORES

ALUMNOS: PORRAS CASAS EMERSON

SINCHE SOTO FRANCO

SOTO MEDINA JOSE LUIS

ESPECIALIDAD: INGENIERIA DE SISTEMAS Y COMPUTACION

CICLO: VIII

HUANCAYO - 2012

METRICAS Y COSTEO DE SOFTWARE

PRESENTACION

El objetivo primordial de la ingeniería del software es producir un sistema,

aplicación o producto de alta calidad. Para lograr este objetivo, los ingenieros

de sistemas deben emplear métodos efectivos junto con herramientas

modernas dentro del contexto de un proceso maduro de desarrollo del

software. Al mismo tiempo, un buen ingeniero de sistemas y buenos

administradores de la ingeniería del software deben medir si la alta calidad se

va a llevar a cabo. A continuación se verá un conjunto de métricas del software

que pueden emplearse a la valoración cuantitativa de la calidad de software.

INTRODUCCION

Cuando se piensa en modelar se reduce la cantidad de datos a comprender sin

descartar su esencia (retiramos los excesos de la realidad); por eso partimos y

comprendemos el problema, centrándonos cada vez en una sola parte del

mismo.

Es el viejo dicho de: Divide y Vencerás, aplicada al desarrollo de software.

Un buen ingeniero de sistemas debería emplear mediciones que evalúan la

calidad del análisis y los modelos de diseño, así como el código fuente y los

casos de prueba que se han establecido al aplicar la ingeniería del software.

Para obtener esta evaluación de calidad, el ingeniero debe utilizar medidas

técnicas, que evalúan la calidad con objetividad, no con subjetividad. Asimismo,

un buen administrador de proyectos debe evaluar la calidad objetivamente y no

subjetivamente. A medida que el proyecto progresa el administrador del

proyecto siempre debe valorar la calidad. Aunque se pueden recopilar muchas

medidas de calidad, el primer objetivo en el proyecto es medir errores y

defectos. Las métricas que provienen de estas medidas proporcionan una

indicación de la efectividad de las actividades de control y de la garantía de

calidad en grupos o en particulares.

CONTENIDO

DEDICATORIA

CAPITULO I - METRICAS DE SOFTWARE

1.1. CONCEPTOS GENERALES

1.1.1. Medida:

Proporciona una indicación cuantitativa de la cantidad, dimensiones o

tamaño de algunos atributos de un producto.

1.1.2. Medición:

Acto de determinar una medida.

1.1.3. Preguntas comunes durante el proceso de medición:

Frecuentemente la medición con lleva una gran controversia y discusión.

¿Cuáles son las métricas apropiadas para el proceso y para el

producto?

¿Cómo se deben utilizar los datos que se recopilan?

¿Es bueno usar medidas para comparar gente, procesos o

productos?

1.1.4. Razones para medir un producto:

Hay varias razones para medir un producto.

Para indicar la calidad del producto.

Para evaluar la productividad de la gente que desarrolla el producto.

Par evaluar los beneficios en términos de productividad y de calidad,

derivados del uso de nuevos métodos y herramientas de la ingeniería

de software.

Para establecer una línea de base para la estimación

Para ayudar a justificar el uso de nuevas herramientas o de formación

adicional.

1.1.5. Categorías de mediciones:

Las mediciones del mundo físico pueden englobarse en dos categorías:

medidas directas y medidas indirectas.

• Medidas Directas: En el proceso de ingeniería se encuentran:

o Costo

o Esfuerzo aplicado

o Líneas de código producidas

o Velocidades de ejecución

o Tamaño de la memoria

o Numero de errores o defectos

• Medidas Indirectas: En el proceso de ingeniería se encuentran:

o Funcionalidades

o Calidad o Cualidades

o Complejidad

o Eficiencia

o Confiabilidad o fiabilidad

o Facilidad de mantenibilidad

1.2. ANTECEDENTES

Métricas de software realmente comenzó a principios de los años ochenta con el

trabajo realizado por dos académicos de la Universidad de LOWA, Kafura

Dennis(1) y Sally Henry(2). Ellos trataron de investigar el diseño del sistema

métrico que podría ser extraído de un diseño de sistema, y que podría ser

utilizado para predecir factores tales como la facilidad de mantenimiento.

1.3. METRICA

Métricas de software son un intento de cuantificar todos los aspectos de los

productos de software incluidos en el código del programa, la especificación

funcional, diseño de sistemas y diseño detallado.

El concepto de métricas es el término que describe mucho y muy variados casos

de medición. Siendo una métrica una medida estadística (no cuantitativa como

en otras disciplinas ejemplo la física) que se aplica a todos los aspectos de

calidad de software los cuales deben ser medidos desde diferentes puntos de

vista como el análisis, construcción, funcional, documentación, métodos,

proceso, usuario entre otros.

Cuando se planifica un proyecto se tiene que obtener estimaciones de costos y

esfuerzo humano por medio de las mediciones de software que se utilizan para

recolectar software y sus procesos para aumentar su calidad.

Cabe resaltar que en la mayoría de desafíos técnicos, las métricas nos ayudan a

entender el proceso tanto el proceso técnico que se utiliza para desarrollar el

producto, como el propio producto. El proceso para intentar mejorarlo,

consecuentemente se utiliza una métrica para intentar aumentar su calidad.

(1) Kafura, Dennis F. Licenciado en matemáticas(2)

1.4. USO DE LAS METRICAS

Capacidad para ser entendido:

Capacidad del software que le permite al usuario entender si el software es

adecuado y como puede ser usado para unas tareas o condiciones

particulares.

Capacidad para ser aprendido:

Capacidad del software que le permite al usuario aprender sobre su

aplicación.

Capacidad para ser operado:

Capacidad del software que le permite al usuario ser operado y controlado.

Capacidad de atracción:

Capacidad del software para ser atractivo al usuario.

Capacidad de usabilidad:

Capacidad del software para adherirse a normas, convenciones, guías de

estilo o regulaciones relacionadas con la usabilidad

1.5. UTILIDADES DE LAS METRICAS

Estimar casos de prueba.

Ayudar a entender rangos de productividad amplios.

Ayudar a entender el crecimiento del proyecto.

Ayudar a calcular el costo real del software.

Estimar el costo del proyecto, la programación y esfuerzo.

Ayudar a entender los costos de mantenimiento.

Ayudar con las negociaciones del contrato.

1.6. ARGUMENTOS PARA LAS MÉTRICAS DEL SOFTWARE

¿Por qué es tan importante medir el proceso de ingeniería del software y el

producto (software) que produce? La respuesta es relativamente obvia. Si no

se mide, no hay una forma real de determinar si se está mejorando. Y si no se

está mejorando, se está perdido.

La gestión de alto nivel puede establecer objetivos significativos de mejora del

proceso de ingeniería del software solicitando y evaluando las medidas de

productividad y de calidad. Se señaló que el software es un aspecto de gestión

estratégico para muchas compañías. Si el proceso por el que se desarrolla

puede ser mejorado, se producirá un impacto directo en lo sustancial. Pero para

establecer objetivos de mejora, se debe comprender el estado actual de

desarrollo del software. Por lo tanto la medición se utiliza para establecer una

línea base del proceso desde donde se pueden evaluar las mejoras.

Los rigores del trabajo diario de un proyecto del software no dejan mucho tiempo

para pensar en estrategias. Los gestores de proyecto de software están más

preocupados por aspectos mundanos (aunque igualmente importantes):

desarrollo de estimaciones significativas del proyecto; producción de sistemas de

alta calidad y terminar el producto a tiempo. Mediante el uso de medición para

establecer una línea base del proyecto, cada uno de estos asuntos se hace más

fácil de manejar. Ya hemos apuntado que la línea base sirve como base para la

estimación. Además, la recopilación de métricas de calidad permite a una

organización “sintonizar” su proceso de ingeniería del software para eliminar las

causas “poco vitales” de los defectos que tienen el mayor impacto en el

desarrollo del software.

Técnicamente (en el fondo), las métricas del software, cuando se aplican al

producto, proporcionan beneficios inmediatos. Cuando se ha terminado el diseño

del software, la mayoría de los que desarrollan pueden estar ansiosos por

obtener respuestas a preguntas como:

¿Qué requisitos del usuario son más susceptibles al cambio?

¿Qué módulos del sistema son más propensos a error?

¿Cómo se debe planificar la prueba para cada módulo?

¿Cuántos errores (de tipos concretos) puede esperar cuando comience la

prueba?

Se pueden encontrar respuestas a esas preguntas si se han recopilado métricas

y se han usado como guía técnica.

1.7. Clases de métricas de software:

Las medidas del software pueden organizarse en otras clases:

Métricas orientadas a la productividad: Basado en la salida del

proceso de desarrollo del software con el objetivo de evaluar el propio

proceso.

Métrica de la calidad: que permite indicar el nivel de la respuesta del

software a las demandas explícitas e implícitas del cliente.

Bajo otro las ópticas, es posible definir una nueva clasificación de las medidas:

Métricas guiadas al tamaño: Basado en las medidas directas de la

Ingeniería de Software.

Métricas guiadas a la función: Estas ofrecen las medidas indirectas.

Métricas guiadas a las personas: Que dan las indicaciones en el

formulario como las personas desarrollan los programas de la

computadora.

1.8. Descripción de Métricas

1.8.1. METRICAS DEL MODELO DE ANALISIS

El trabajo técnico en la ingeniería del software empieza con la creación

del modelo de análisis. En esta fase se obtienen los requisitos y se

establece el fundamento para el diseño. Por lo tanto, son deseables las

métricas técnicas que proporcionan una visión interna de la calidad del

modelo de análisis.

1.8.1.1. MÉTRICAS BASADAS EN LA FUNCION

La métrica de punto de función (PF) se puede usar como medio

para predecir el tamaño de un sistema que se va a obtener de

un modelo de análisis. Cinco características de dominios de

información:

o Número de entradas del usuario

o Número de salidas del usuario

o Número de consultas del usuario

o Número de archivos

o Número de interfaces externas.

1.8.1.2. LA METRICA DE BANG

Al igual que la métrica de función, la métrica bang puede

emplearse para desarrollar una indicación del tamaño del

software a implementar como consecuencia del modelo de

análisis. La métrica bang es “una indicación independiente de la

implementación del tamaño del sistema”. Para calcular esta

métrica, el desarrollador debe evaluar primero un conjunto de

primitivas. Las primitivas se determinan evaluando el modelo de

análisis y desarrollando cuentas para los siguientes elementos:

Primitivas Funcionales-PFU: transformaciones que aparecen

en el nivel inferior de un DFD (diagrama de flujo de datos).

Elementos De Datos-ED: los atributos de un objeto de

datos, los elementos de datos no compuestos y aparecen el

diccionario de datos.

Objetos-OB: objetos de datos.

Relaciones-RE: las conexiones entre objetos

Estados-ES: el número de estados observables por el

usuario en el diagrama de transición de estado.

Transiciones-TR: El número de transiciones de estado en el

diagrama de transición de estado.

Además de estás primitivas, se determinan las cuentas

adicionales para:

Primitivas modificadas de función manual: Funciones que

caen fuera del límite del sistema y que deben modificarse para

acomodarse el nuevo sistema.

- elementos de datos de entrada

- elementos de datos de salida

Elementos de datos retenidos: elementos de datos que son

almacenados por el sistema.

La mayoría del software se puede asignar a uno de los dos

dominios siguientes:

Dominio de función: Las aplicaciones de este dominio

hacen hincapié en la transformación de datos y no poseen

generalmente estructuras de datos complejas.

Dominio de datos: Estas aplicaciones tienden a tener

modelos de datos complejos

1.8.1.3. METRICAS DE LA CALIDAD DE ESPECIFICACION

Lista de características que pueden emplearse para valorar la

calidad del modelo de análisis y la correspondiente

especificación de requisitos:

Especificidad

Compleción

Corrección

Compresión

Capacidad de verificación

Consistencia interna y externa

Capacidad de logro

Concisión

Trazabilidad

Capacidad de modificación

Exactitud

Capacidad de reutización.

Se apunta a que las especificaciones de alta calidad deben estar

almacenadas electrónicamente, ser ejecutables o al menos

interpretables, anotadas por importancia y estabilidad relativas,

con su versión correspondiente, organizadas, con referencias

cruzadas y especificadas al nivel correcto de detalle.

1.8.2. METRICAS DEL MODELO DE DISEÑO

1.8.2.1. METRICAS DE DISEÑO DE ALTO NIVEL

Estás métricas se concentran en las características de la

arquitectura del programa (estructura arquitectónica y eficiencia

de los módulos). Estas métricas son de caja negra en el sentido

que no requieren ningún conocimiento del trabajo interno de un

módulo en particular del sistema.

Tres medidas de la complejidad del diseño del software:

- Complejidad estructural

- Complejidad de datos

- Complejidad del sistema

A medida que crecen los valores de complejidad arquitectónica

o global del sistema también aumenta. Esto lleva a una mayor

probabilidad de que aumente el esfuerzo necesario para la

integración y las pruebas.

1.8.2.2. METRICAS DE DISEÑO EN LOS COMPONENTES

Estás métricas se concentran en las características internas de

los componentes del software e incluyen medidas de la

cohesión, acoplamiento y complejidad del módulo. Estas tres

medidas pueden ayudar al desarrollador del software a juzgar la

calidad de un diseño a nivel de componentes.

Estás métricas son de caja blanca en el sentido que requieren

conocimiento del trabajo interno del módulo. Estás métricas se

pueden aplicar una vez que se ha desarrollado un diseño

procedimental. También se puede retrasar hasta tener

disponible el código fuente.

Métricas de cohesión: Se definen 5 conceptos y medidas:

- Porción de datos: una porción de datos es una marcha

atrás a través de un módulo que busca valores de datos

que afectan a la localización del módulo en el que

empezó la marcha atrás. Se pueden definir tanto

porciones de programas como porciones de datos:

- Símbolos léxicos (tokens) de datos: las variables

definidas para un módulo pueden definirse como señales

de datos para el módulo.

- Señales de unión: el conjunto de señales de datos que

se encuentran en uno o más porciones de datos.

- Señales de súper unión: Las señales de datos

comunes a todas las porciones de datos de un módulo.

- Pegajosidad: la pegajosidad relativa de una señal de

unión es directamente proporcional al número de

porciones de datos que liga.

Métricas de acoplamiento: El acoplamiento del módulo

proporciona una indicación de la “conectividad” de un módulo

con otros módulos, datos globales y el entorno exterior.

Las medidas necesarias para calcular el acoplamiento de

módulo se definen en término de los siguientes tres

acoplamientos:

a) Para el acoplamiento de flujo de datos y de control:

• Número de parámetros de datos de entrada

• Número de parámetros de control de entrada

• Número de parámetros de datos de salida

• Número de parámetros de control de salida

b) Para el acoplamiento global

• Número de variables globales usadas como datos

• Número de variables globales usadas como control

c) Para el acoplamiento de entorno

• Número de módulos llamados

• Número de módulos que llaman al módulo en cuestión

Métricas decomplejidad: Se pueden calcular una variedad de

métricas del software para determinar la complejidad del flujo de

control del programa. Muchas de éstas se basan en una

representación denominada grafo de flujo.

La métrica de complejidad más usada para el software es la

complejidad ciclomática: puede emplearse para proporcionar

una indicación cuantitativa del tamaño máximo del módulo.

1.8.2.3. METRICAS DE DISEÑO DE INTERFAZ

Se sugiere la CR (conveniencia de la representación) como una

valiosa métrica de diseño para interfaces hombre–máquina. Una

GUI (interfaz Gráfica del Usuario) típica usa entidades de

representación – iconos, gráficos, ventanas, etc. para ayudar al

usuario a completar tareas. Para realizar una tarea usando una

GUI, el usuario debe moverse de una entidad de representación

a otra. Las posiciones absolutas y relativas a cada entidad de

representación, la frecuencia con que se utilizan y el coste de la

transición de una entidad de representación a la siguiente

contribuirán a la conveniencia de la interfaz.

La CR se emplea para valorar diferentes distribuciones

propuestas de GUI y la sensibilidad de una representación en

particular a los cambios en las descripciones de tareas. El

diseñador de interfaces puede emplear el cambio en la

conveniencia de la representación, como guía en la elección de

la mejor representación de GUI para una aplicación en

particular.

La selección de un diseño IGU puede guiarse con métricas tales

como CR, pero el árbitro final debería ser la respuesta del

usuario basada en prototipos GUI.

1.8.3. METRICAS DEL CODIGO FUENTE

La ciencia del software usa un conjunto de primitivas que pueden

obtenerse una vez que se ha completado o estimado el código después

de completar el diseño:

- Número de operadores diferentes que aparecen en el programa

- Número de operandos diferentes que aparecen en el programa.

- Número total de veces que aparece el operador

- Número total de veces que aparece el operando.

Se usa las medidas primitivas para desarrollar expresiones para:

- La longitud global del programa

- Volumen mínimo potencial para un algoritmo

- Volumen real

- Nivel del programa

- Nivel del lenguaje

- Esfuerzo de desarrollo

- Tiempo de desarrollo

- Número esperado de fallos.

1.8.4. METRICAS PARA PRUEBAS

Los responsables de la pruebas deben fiarse en las métricas de

análisis, diseño y código para que les guíen en el diseño y ejecución de

los casos de prueba.

Métricas basadas en la función

Métricas bang.

Métricas de diseño de alto nivel

El analista debería invertir un esfuerzo extra para descubrir errores en

el módulo antes de integrarlo en un sistema. A medida que se van

haciendo las prueba, tres medidas proporcionan una indicación de la

compleción de las pruebas.

Amplitud de las pruebas: Indica cuantos requisitos se han probado.

Profundidad de las pruebas: Indica porcentaje de los caminos

básicos probados en relación con el número total de estos caminos en

el programa.

Perfiles de fallos: Categorizar los errores descubiertos. Severidad

del problema

1.8.5. METRICAS DEL MANTENIMIENTO

Todas las métricas del software presentadas en este capítulo pueden

usarse para el desarrollo de nuevo software y para el mantenimiento del

existente. Se han propuesto métricas diseñadas explícitamente para

actividades de mantenimiento. El estándar IEEE 982.1-1988 sugiere un

índice de madurez del software que proporciona una indicación de la

estabilidad de un producto software (basada en los cambios que

ocurren con cada versión del producto). Se determina la siguiente

información:

- Número de módulo en la versión actual.

- Número de módulos en la versión actual que se han cambiado

- Número de módulos en la versión actual que se han añadido.

- Número de módulos en la versión anterior que se han borrado en

la versión actual.

RECOMENDACIONES

CONCLUSIONES

WEBGRAFIA