trabajo de metricas ok - presentar
Post on 25-Jul-2015
48 Views
Preview:
TRANSCRIPT
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
top related