Repblica Bolivariana de Venezuela Ministerio popular para la Educacin Superior Universidad Nacional Experimental Simn Rodrguez Ncleo Palo

Verde Materia: Administracin de Centro de Procesamiento de Datos

Caracas, Febrero, 2011.

NDICE Introduccin..1 Mtricas del Modelo de Anlisis4 La Mtrica Bang...7 Mtricas de la Calidad9 Factores de Calidad..10 El Modelo de Mc Call12 Mtricas del Modelo de Diseo...19 Mtricas del Cdigo Fuente.21 Mtricas de Pruebas del Software..23 La Importancia de la Deteccin Oportuna.27 Tipos de Mantenimiento28 Proceso de Mantenimiento..29 Conclusin.30 Bibliografa. 31 Anexos.32

INTRODUCCION. A travs del presente trabajo de investigacin estudiaremos el tema de las mtricas del producto para el software superficialmente sabemos que las mtricas son aquellos paradigmas que nos ayudaran no solo a desarrollar un software, sino a garantizar su funcionamiento y calidad. Las mtricas se aplican a los sistemas o software para valorar la calidad de los productos de ingeniera o los sistemas que se construyen, estas nos proporcionan una manera sistemtica y ordenada de valorar la calidad basndose en un conjunto de reglas claramente definidas y establecidas, por estas nos regiremos al ser aplicadas por el codificador nos permite descubrir y corregir problemas potenciales que puedan existir o que bien podran presentarse en la medida en que se desarrolle el sistema.

Es necesario medir un atributo interno del software (como el tamao) y suponer que existe una relacin entre lo que se puede medir y lo que se quiere saber, de forma ideal, existe una relacin clara vlida entre los atributos de software internos y externos. A continuacin definiremos estas mtricas y la manera en la que debemos utilizarlas para aplicarlas correctamente. Mtricas del modelo de anlisis En esta fase se obtendrn los requisitos y se establecer el fundamento para el diseo. Y es por eso que se desea una visin interna a la calidad del modelo de anlisis. Sin embargo hay pocas mtricas de anlisis y especificacin, se sabe que es posible adaptar mtricas obtenidas para la aplicacin de un proyecto, en donde

las mtricas examinan el modelo de anlisis con el fin de predecir el tamao del sistema resultante, en donde resulte probable que el tamao y la complejidad del diseo estn directamente relacionados. Es por eso que se vern en las siguientes secciones las mtricas orientadas a la funcin, la mtrica bang y las mtricas de la calidad de especificacin. Mtricas basadas en la funcin La mtrica de punto de funcin (PF) se puede usar como medio para predecir el tamao de un sistema que se va a obtener de un modelo de anlisis. Para instruir el empleo de la mtrica PF, se considerar una sencilla representacin del modelo de anlisis mostrada por Pressman [98] En donde se representa un diagrama de flujo de datos, de una funcin de una aplicacin de software llamada Hogar Seguro. La funcin administra la interaccin con el usurario, aceptando una contrasea de usuario para activar/ desactivar el sistema y permitiendo consultas sobre el estado de las zonas de seguridad y varios censores de seguridad. La funcin muestra una serie de mensajes de peticin y enva seales apropiadas de control a varios componentes del sistema de seguridad. El diagrama de flujo de datos se evala para determinar las medidas clave necesarias para el clculo de la mtrica de PF.: - nmero de entradas de usuario - nmero de salidas de usuario - nmero de consultas del usuario - nmero de archivos - nmero de interfaces externas

Hay tres entradas del usuario: contrasea, interruptor de emergencias y activar/desactivar aparecen en la figura con dos consultas: consulta de zona y consulta de sensor. Se muestra un archivo (archivo de configuracin del sistema) Tambin estn presentes dos salidas de usuarios (mensajes y estado de del sensor) y cuatro interfaces externas (sensor de prueba, configuracin de zona, activar/desactivar y alerta de alarma).

La cuenta total mostrada en la figura 4.1 debe ajustarse usando la ecuacin:

PF = cuenta-total * (0.65 + 0.01 * Fi) Donde cuenta-total es la suma de todas las entradas PF obtenidas de la figura 4.1 y Fi ( i=1 a 14) son valores de ajuste de complejidad. Para el propsito de este ejemplo, asumimos que Fi es 46 (un producto moderadamente complejo) Por lo tanto: PF = 50* [0.65+(0.01*46)]=56 Basndose en el valor previsto de PF obtenido del modelo de anlisis, el equipo del proyecto puede estimar el tamao global de implementacin de las funciones de Hogar Seguro. Asuma que los datos de los que se disponen indican que un PF supone 60 lneas de cdigo (si se usa un lenguaje orientado a objetos) y que en un esfuerzo de un mes- persona se producen 12 PF. Estos datos histricos proporciona al administrador del proyecto una importante informacin de planificacin basada en el modelo de anlisis en lugar de en estimaciones preliminares. La mtrica Bang Puede emplearse para desarrollar una indicacin del tamao del software a implementar como consecuencia del modelo de anlisis. Desarrollada por Tom DeMarco , la mtrica bang es una indicacin, independiente de la implementacin, del tamao del sistema. Para calcular la mtrica bang, el desarrollador de software debe evaluar primero un conjunto de primitivas (elementos del modelo de anlisis que no se subdividen ms en el nivel de anlisis) Las primitivas se determinan evaluando el modelo de anlisis y desarrollando cuentas para los siguientes elementos:

- Primitivas funcionales (Pfu) Transformaciones (burbujas) que aparecen en el nivel inferior de un diagrama de flujo de datos. - Elementos de datos (ED) Los atributos de un objeto de datos, los elementos de datos no compuestos y aparecen en el diccionario de datos. - Objetos (OB) Objetos de datos. - Relaciones (RE) Las conexiones entre objetos de datos. - Transiciones (TR) El nmero de transacciones de estado en el diagrama de transicin de estado. Adems de las seis primitivas nombradas arriba, se determinan medidas adicionales para: - Primitivas modificadas de funcin manual (PMFu) Funciones que caen fuera del lmite del sistema y que deben modificarse para acomodarse al nuevo sistema. - Elementos de datos de entrada (EDE) Aquellos elementos de datos que se introducen en el sistema. - Elementos de datos de salida (EDS) Aquellos elementos de datos que se sacan en el sistema. - Elementos de datos retenidos (EDR) Aquellos elementos de datos que son retenidos (almacenados) por el sistema. - Muestras (tokens) de datos (TCi) Las muestras de datos (elementos de datos que no se subdividen dentro de una primitiva funcional) que existen en el limite de la i-sima primitiva funcional (evaluada para cada primitiva). - Conexiones de relacin (Rei) Las relaciones que conectan el i-simo objeto en el modelo de datos con otros objetos. DeMarco sugiere que la mayora del software se puede asignar a uno de los dos dominios siguientes, dominio de funcin o dominio de datos, dependiendo de la relacin RE/PFu. Las aplicaciones de dominio de funcin (encontrados comnmente en aplicaciones de ingeniera y cientficas) hacen hincapi en la transformacin de datos y no poseen generalmente estructuras de datos complejas. Las aplicaciones de dominio de datos (encontradas comnmente en

aplicaciones de sistemas de informacin) tienden a tener modelos de datos complejos. Si RE / Pfu < 0,7 implica una aplicacin de dominio de funcin Si 0,8 < RE / Pfu < 1,4 implica una aplicacin hbrida Si RE / Pfu > 1,5 implica una aplicacin de dominio de datos. Como diferentes modelos de anlisis harn una participacin del modelo con mayor o menor grado de refinamiento, DeMarco sugiere que se emplee una cuenta medida de muestras (token) por primitiva para controlar la uniformidad de la participacin a travs de muchos diferentes modelos dentro del dominio de una aplicacin. TCavg = _ TCi/Pfu Una vez que se ha calculado la mtrica Bang, se puede empelar el historial anterior para asociarla con el esfuerzo y el tamao. DeMarco sugiere que las organizaciones se construyan sus propias versiones de tablas IPFuC y IOBC para calibrar la informacin de proyectos completos de software. Mtricas de la Calidad de Especificacin Existe una lista de caractersticas para poder valorar la calidad del modelo de anlisis y la correspondiente especificacin de requisitos: Especificidad, correccin, complecin, comprensin, capacidad de verificacin, consistencia externa e interna, capacidad de logro, concisin, traza habilidad, capacidad de modificacin, exactitud y capacidad de reutilizacin. Aunque muchas de las caractersticas anteriores pueden ser de naturaleza cuantitativa, Davis sugiere que

todas puedan representarse usando una o ms mtricas. Por ejemplo asumimos que hay ni requisitos en una especificacin, tal como ni = nf + nnf Donde nf es el nmero de requisitos funcionales y nnf es el nmero de requisitos no funcionales ( por ejemplo, rendimiento). Para determinar la especificidad de los requisitos, Davis sugiere una mtrica basada en la consistencia de la interpretacin de los revisores para cada requisito: Q1 = nui / nr Donde nui es el nmero de requisitos para los que todos los revisores tuvieron interpretaciones idnticas. Cuanto ms cerca de uno este el valor de Q1 menor ser la ambigedad de la especificacin. La complecin de los requisitos funcionales pueden terminarse calculando la relacin Q2 = nu / (ni * ns) Donde nu es el nmero de requisitos de funcin nicos, ni es el nmero de entradas (estmulos) definidos o implicados por la especificacin y ns es el nmero de estados especificados. La relacin Q2 mide porcentaje de funciones necesarias que se han especificado para un sistema, sin embargo, no trata los requisitos no funcinales. Para incorporarlos a una mtrica global completa, debemos considerar el grado de validacin de los requisitos: Q3 = nc / (nc + nnv) Donde nc es el nmero de requisitos que se han validados como correctos y nnv el nmero de requisitos que no se han validado todava.

Factores de calidad: La ISO (Organizacin Internacional para la Estandarizacin) trata de concluir sobre los modelos existentes y se puede decir que establece ciertas bases slidas para hablar de la calidad de un producto de software. En este apartado no se quiere profundizar en el tema, sin embargo existe mucho material escrito al cual se podran referir en caso necesario (Ver bibliografa), por ahora nos limitaremos a describir que es lo nuevo que incorpora este modelo. 1. La ISO-9126 establece las caractersticas de un modelo de calidad: Un modelo de calidad debera proveer una gua sistemtica para incluir la calidad en el software. Un modelo de calidad debera proveer una forma de identificar/clasificar sistemticamente caractersticas del software y defectos de calidad. Un modelo de calidad debera proveer una estructura que sea entendible hasta cierto nmero de niveles, refinable y adaptable. 2. Establece concretamente que la calidad est compuesta por un conjunto de caractersticas que se pueden dividir en dos grupos: las caractersticas de alto nivel y las caractersticas de bajo nivel que sostienen, o que hacen posible la calidad. Esto se corresponde exactamente con lo que hasta este punto se entenda por factores y mtricas. Por ejemplo, una caracterstica de alto nivel es la mantenibilidad, que a su vez est compuesto por un conjunto de atributos subordinados o de bajo nivel que son:

Analizabilidad. (o Entendibilidad) Estabilidad. Testeabilidad. (o Evaluabilidad) Modificabilidad.

3. Se establece que aunque a priori las caractersticas de alto nivel son mutuamente excluyentes (confiabilidad, eficiencia, mantenibilidad, etc.) en realidad se sobreponen cuando vemos las caractersticas de bajo nivel que comparten. 4. La ISO-9126 establece claramente que un software de calidad no es aquel que tiene todas las caractersticas de calidad imaginables, si no es aquel que cumple con aquellas caractersticas de alto nivel que han sido estratgicamente elegidas, acorde a las necesidades mas importantes que se tenan para el software. 5. Este modelo de calidad hace mayor nfasis que otros en la reusabilidad, ponindola como una caracterstica de alto nivel. Adems define las siguientes caractersticas de alto niveles deseables en todo software. Funcionalidad. Mantenibilidad. Confiabilidad. Portabilidad. Usabilidad. Eficiencia. Reusabilidad.

Casi todas estas caractersticas se definen por s mismas, sin embargo destacaremos la definicin que se da de reusabilidad o software reusable : es aquel que usa caractersticas estndar de un lenguaje, no depende del hardware,

y su implementacin es simple, bien definida, encapsulada y cumple con una funcin especfica, no usa variables globales o provoca efectos colaterales. 6. Se establece una clasificacin para las caractersticas de bajo nivel que sostienen o hacen posible la calidad, en cuatro categoras bsicas: Caractersticas de correccin. (Ej. Precisin) Caractersticas de descripcin. (Ej. Legibilidad) Caractersticas estructurales (Ej. Concisin) Caractersticas de modularidad(Ej. Expandibilidad).

8. El modelo de McCall. El modelo de McCall organiza los factores en tres ejes o puntos de vista desde los cuales el usuario puede contemplar la calidad de un producto, basndose en once factores de calidad organizados en torno a los tres ejes y a su vez cada factor se desglosa en otros criterios: Puntos De Factor Criterios

Vista O Ejes OPERACIN Facilidad de uso - Facilidad de operacin: Atributos del software que DEL PRODUCTO - Facilidad de comunicacin: Atributos del software que proporcionan entradas y salidas fcilmente asimilables. - Facilidad de aprendizaje: Atributos del software que facilitan la familiarizacin inicial del usuario con el software y la transicin del modo actual de determinan la facilidad de operacin del software.

operacin. - Formacin: El grado en que el software ayuda para permitir que nuevos usuarios apliquen el sistema. Integridad - Control de accesos. Atributos del software que proporcionan control de acceso al software y los datos que maneja. - Facilidad de auditora: Atributos del software que facilitan la auditora de los accesos al software. - Seguridad: La disponibilidad de mecanismos que controlen o protejan los programas o los datos. Correccin Completitud: Atributos del software que proporcionan la implementacin completa de todas las funciones requeridas. Consistencia: Atributos del en software las que y

proporcionan

uniformidad

tcnicas

notaciones de diseo e implementacin. - Trazabilidad o rastreabilidad: Atributos del software que proporcionan una traza desde los requisitos a la implementacin con respecto a un entorno operativo concreto. OPERACIN Fiabilidad DEL PRODUCTO Precisin: Atributos del software que proporcionan el grado de precisin requerido en los clculos y los resultados.

- Consistencia. - Tolerancia a fallos: Atributos del software que posibilitan la continuidad del funcionamiento bajo condiciones no usuales. Modularidad: Atributos del software que

proporcionan una estructura de mdulos altamente independientes. - Simplicidad: Atributos del software que posibilitan la implementacin de funciones de la forma ms comprensible posible. - Exactitud: La precisin de los clculos y del control. Eficiencia - Eficiencia en ejecucin: Atributos del software que minimizan el tiempo de procesamiento. - Eficiencia en almacenamiento: Atributos del software REVISION DEL PRODUCTO Facilidad que minimizan el espacio de almacenamiento necesario. de - Modularidad. - Simplicidad. - Consistencia. - Concisin: Atributos del software que posibilitan la implementacin de una funcin con la menor cantidad de cdigos posible. mantenimiento

- Auto descripcin: Atributos del software que proporcionan Facilidad prueba - Simplicidad. - Auto descripcin. - Instrumentacin: Atributos del software que posibilitan la observacin del comportamiento del software durante su ejecucin para facilitar las mediciones del uso o la identificacin de errores. Flexibilidad - Auto descripcin. - Capacidad de expansin: Atributos del software que posibilitan la expansin del software en cuanto a capacidades funcionales y datos. Generalidad: Atributos amplitud del a software las que de - Modularidad. explicaciones sobre la implementacin de las funciones.

proporcionan implementadas. - Modularidad. Reusabilidad

funciones

- Auto descripcin. - Generalidad. - Modularidad. -Independencia entre sistema y software: Atributos del software que determinan su dependencia del

entorno operativo. - Independencia del hardware: Atributos del software que determinan su dependencia del hardware. Interoperabilidad - Modularidad. - Compatibilidad de comunicaciones: Atributos del software que posibilitan el uso de protocolos de comunicacin e interfaces estndar. - Compatibilidad de datos: Atributos del software que posibilitan el uso representaciones de datos estndar. - Estandarizacion en los datos: El uso de estructuras de datos y de tipos estndar a lo largo de todo el programa. Portabilidad - Auto descripcin. - Modularidad. -Independencia entre sistema y software. - Independencia del hardware. 9. Cmo emplear el modelo de mccall. Antes de comenzar a utilizar el modelo de McCall hay que seguir las siguientes pautas: 1. Se aceptan los factores, criterios y mtricas que propone el modelo.

2. Se aceptan las relaciones entre factores y criterios, y entre criterios y mtricas. 3. Se selecciona un subconjunto de factores de calidad sobre los que aplicar los requisitos de calidad establecidos para el proyecto. Al comienzo del proyecto habr que especificar los requisitos de calidad del producto software, para lo cual se seleccionarn los aspectos inherentes a la calidad deseada del producto, teniendo que considerarse para ello:

Las caractersticas particulares del propio producto que se est diseando: por ejemplo, su ciclo de vida que si se espera que sea largo implicar un mayor nfasis en la facilidad de mantenimiento y la flexibilidad, o bien si el sistema en desarrollo est destinado a un entorno donde el hardware evoluciona rpidamente implicar como requisito su portabilidad.

La relacin calidad-precio, que puede evaluarse a travs del coste de cada factor de calidad frente al beneficio que proporciona. La siguiente tabla muestra la relacin calidad-precio para cada factor considerado:

Factor Correccin Fiabilidad Eficiencia Integridad Facilidad de uso Facilidad de mantenimiento Facilidad de prueba Flexibilidad Portabilidad

Beneficio / coste Alto Alto Bajo Bajo Medio Alto Alto Medio Medio

Reusabilidad Interoperabilidad

Medio Bajo

La determinacin de las etapas del ciclo de vida donde es necesario evaluar cada factor de calidad para conocer en cuales se dejan sentir ms los efectos de una calidad pobre con respecto a cada uno de los factores.

Las propias interrelaciones entre los factores debido a que algunos factores pueden entrar en conflicto entre s: por ejemplo, la eficiencia plantea conflictos prcticamente con todos los dems factores de calidad. La interaccin entre los diversos factores a evaluar queda reflejada en la tabla I que indica la dependencia entre los factores de McCall. Tambin habr que establecer valores deseables para los criterios, para lo cual se emplearn datos histricos, el promedio en la industria, y con ellos se concretarn los valores finales y otros intermedios o predictivos en cada perodo de medicin durante el desarrollo, as como unos valores mnimos aceptables. La explicacin para cualquier seleccin o decisin deber ser adecuadamente documentada. En la fase de desarrollo ser necesario implementar las mtricas elegidas, analizar sus resultados y tomar medidas correctivas cuando los valores obtenidos estn por debajo de los mnimos aceptables. Una vez finalizado el proyecto ser necesario contrastar las medidas predictivas utilizadas y comprobar si, en efecto, se pueden tomar como indicadores de los valores finales. METRICAS DEL MODELO DE DISEO En este se genera la definicin de la arquitectura del sistema y del entorno tecnolgico que le va a dar soporte, junto con la especificacin detallada de los componentes del Sistema.

La gran irona de las mtricas de diseo para el software es que las mismas estn disponibles, pero la gran mayora de los desarrolladores de software continan sin saber que existen. Sin embargo el diseo sin medicin es una alternativa inaceptable.

METRICAS DE ALTO NIVEL: Las mtricas de alto nivel nos ayudan a localizar los mdulos mas complejos y, por lo tanto, aquellos en los que debemos poner especial atencin. Tambin es utilizada para saber el nmero de mdulos asignados a cada trabajador. Se concentran en las caractersticas de la arquitectura del programa, con nfasis en la estructura arquitectnica y en la eficiencia de los mdulos. Estas mtricas son de caja negra en el sentido que no requieren ningn conocimiento del trabajo interno de un mdulo en particular del sistema. METRICAS DE BAJO NIVEL: Las mtricas de bajo nivel tambin llamadas mtricas de caja blanca son las que nos ayudan a conocer las interioridades del sistema. Hay tres tipos de mtricas: De complejidad Mtricas, De acoplamiento De cohesin bajo nivel. Card y Glass definen las siguientes tres medidas de complejidad: La complejidad estructural, S(i), de un mdulo i se define de la siguiente manera: S(i)=f2out(i). Donde fout(i) es la expansin del mdulo i.La expansin indica el nmero de mdulos que son invocados directamente por el mdulo i. La complejidad de datos, D(i), proporciona una indicacin de la complejidad en la interfaz interna de un mdulo i y se define como: D(i)=v(i)/[fout(i) + 1]. Donde v(i) es el nmero de variables de entrada y salida que entran y salen del mdulo i.

 La complejidad del sistema, C(i), se define como la suma de las complejidades estructural y de datos : C(i)= S(i) + D(i) A medida que crecen los valores de complejidad, la complejidad arquitectnica o global del sistema tambin aumenta. Esto lleva a una mayor probabilidad de que aumente el esfuerzo necesario para la integracin y las pruebas. Fenton sugiere varias mtricas de morfologa simples que permiten comparar diferentes arquitecturas mediante un conjunto de dimensiones directas. Mtricas a aplicar: Tamao= n + a . Donde n es el nmero de nodos (mdulos) y a es el nmero de arcos (lneas de control). Para la arquitectura mostrada se tiene tamao= 17+18=35. Profundidad= camino ms largo desde el nodo raz a un nodo hoja. Para el ejemplo Profundidad= 4 Amplitud=nmero mximo de nodos de cualquier nivel de la arquitectura. Para el ejemplo amplitud= 6 Relacin arco a nodo, r=a/n, mide la densidad de conectividad de la arquitectura y proporciona una indicacin sencilla de acoplamiento de la arquitectura. Para el ejemplo r=18/17= 1.06

MTRICAS DEL CDIGO FUENTE El cdigo fuente de un programa informtico (o software) es un conjunto de lneas de texto que son las instrucciones que debe seguir la computadora para ejecutar

dicho programa. Por tanto, en el cdigo fuente de un programa est descrito por completo su funcionamiento. El cdigo fuente de un programa est escrito por un programador en algn lenguaje de programacin, pero en este primer estado no es directamente ejecutable por la computadora, sino que debe ser traducido a otro lenguaje (el lenguaje mquina o cdigo objeto) que s pueda ser ejecutado por el hardware de la computadora. Para esta traduccin se usan los llamados compiladores, ensambladores, intrpretes y otros sistemas de traduccin. La teora de la ciencia del software propuesta por Halstead es probablemente la medida de complejidad mejor conocida y minuciosamente estudiada. La ciencia del software propuso la primera ley analtica y cuantitativa para el software de computadora. Utiliza un conjunto de medidas primitivas que pueden obtenerse una vez que se han generado o estimado el cdigo despus de completar el diseo. Estas medidas son: n1: nmero de operadores diferentes que aparecen en le programa. n2: nmero de operandos diferentes que aparecen en el programa. N1: nmero total de veces que aparece el operador. N2: nmero total de veces que aparecen el operando. Halstead utiliza medidas primitivas para desarrollar expresiones par la longitud global del programa; volumen mnimo potencial para un algoritmo; el volumen real (nmero de bits requeridos para especificar un programa); el nivel del programa (una medida de la complejidad del software); nivel del lenguaje (una constante para un lenguaje dado); y otras caractersticas tales como el esfuerzo de desarrollo,,tiempo de desarrollo e incluso el nmero esperado de fallos en el software.

Halstead propone las siguientes mtricas: Longitud N se puede estimar como: N = n1log2n1 + n2log2n2. Volumen de programa se define como: V = N n1log2(n1 + n2).

Tomando en cuenta que V variar con el lenguaje de programacin y representa el volumen de informacin (en bits) necesarios para especificar un programa. Mtricas pruebas del software, En ingls testing son los procesos que permiten verificar y revelar la calidad de un producto software. Son utilizadas para identificar posibles fallos de implementacin, calidad, o usabilidad de un programa de ordenador o videojuego. Bsicamente es una fase en el desarrollo de software consistente en probar las aplicaciones construidas. Las pruebas de software se integran dentro de las diferentes fases del ciclo del software dentro de la Ingeniera de software. As se ejecuta un programa y mediante tcnicas experimentales se trata de descubrir que errores tiene. Para determinar el nivel de calidad se deben efectuar unas medidas o pruebas que permitan comprobar el grado de cumplimiento respecto de las especificaciones iniciales del sistema. El testing puede probar la presencia de errores pero no la ausencia de ellos Edsger Dijkstra Hay muchos planteamientos a la hora de abordar el proceso de pruebas de software, pero para verificar productos complejos de forma efectiva requiere de un

proceso de investigacin ms que seguir un procedimiento al pie de la letra. Una definicin de "testing" es: proceso de evaluacin de un producto desde un punto de vista crtico, donde el "tester" (persona que realiza las pruebas) somete el producto a una serie de acciones inquisitivas, y el producto responde con su comportamiento como reaccin. Por supuesto, nunca se debe testear el software en un entorno de produccin. Es necesario testear los nuevos programas en un entorno de pruebas separado fsicamente del de produccin. Para crear un entorno de pruebas en una mquina independiente de la mquina de produccin es necesario crear las mismas condiciones que en la mquina de produccin. Existen a tal efecto varias herramientas vendidas por los mismos fabricantes de hardware (IBM, Sun, HP etc.). Esas utilidades reproducen automticamente las bases de datos para simular un entorno de produccin. En general, los informticos distinguen entre errores de programacin (o "bugs") y defectos de forma. En un defecto de forma, el programa no realiza lo que el usuario espera. Por el contrario, un error de programacin puede describirse como un fallo en la semntica de un programa de ordenador. ste podra presentarse, o no, como un defecto de forma si se llegan a dar ciertas condiciones de clculo. Una prctica comn es que el proceso de pruebas de un programa sea realizado por un grupo independiente de "testers" al finalizar su desarrollo y antes de sacarlo al mercado. Una prctica que viene siendo muy popular es distribuir de forma gratuita una versin no final del producto para que sean los propios consumidores los que la prueben. En ambos casos, a la versin del producto en pruebas y que es anterior a la versin final (o "master") se denomina beta, y a dicha fase de pruebas, beta testing. Puede adems existir una versin anterior en el proceso de desarrollo llamada alpha, en la que el programa, aunque incompleto, dispone de funcionalidad bsica y puede ser testeado.

Finalmente y antes de salir al mercado, es cada vez ms habitual que se realice una fase de RTM testing (Release To Market), dnde se comprueba cada funcionalidad del programa completo en entornos de produccin. Otra prctica es que el proceso de pruebas se realice desde el mismo momento en que empieza el desarrollo y contine hasta que finaliza. La importancia de la deteccin oportuna En la cadena de valor del desarrollo de un software especfico, el proceso de prueba es clave a la hora de detectar errores o fallas. Conceptos como estabilidad, escalabilidad, eficiencia y seguridad se relacionan a la calidad de un producto bien desarrollado. Las aplicaciones de software han crecido en complejidad y tamao, y por consiguiente tambin en costos. Hoy en da es crucial verificar y evaluar la calidad de lo construido de modo de minimizar el costo de su reparacin. Mientras antes se detecte una falla, ms barata es su correccin. El proceso de prueba es un proceso tcnico especializado de investigacin que requiere de profesionales altamente capacitados en lenguajes de desarrollo, mtodos y tcnicas de pruebas y herramientas especializadas. El conocimiento que debe manejar un ingeniero de prueba es muchas veces superior al del desarrollador de software.

Pruebas unitarias Pruebas funcionales Pruebas de Integracin Pruebas de validacin Pruebas de sistema Pruebas de aceptacin Pruebas de regresin Pruebas de carga

Pruebas de prestaciones Pruebas de recorrido Pruebas de mutacin Prueba Unitaria Al desarrollar un nuevo software o sistema de informacin, la primera etapa de pruebas a considerar es la etapa de pruebas unitarias o tambin llamada pruebas de caja blanca (White Box), ests pruebas tambin son llamadas pruebas modulares ya que nos permiten determinar si un modulo del programa esta listo y correctamente terminado, estas pruebas no se deben confundir con las pruebas informales que realiza el programador mientras esta desarrollando el mdulo. Una prueba funcional es una prueba basada en la ejecucin, revisin y retroalimentacin de las funcionalidades previamente diseadas para el software. La pruebas funcionales se hacen mediante el diseo de modelos de prueba que buscan evaluar cada una de las opciones con las que cuenta el paquete informtico.

Pruebas integrales o pruebas de integracin son aquellas que se realizan en el mbito del desarrollo de software una vez que se han aprobado las pruebas unitarias. nicamente se refieren a la prueba o pruebas de todos los elementos unitarios que componen un proceso, hecha en conjunto, de una sola vez.

Consiste en realizar pruebas para verificar que un gran conjunto de partes de software funcionan juntos.

Las pruebas de integracin (algunas veces llamadas integracin y testeo I&t) es la fase del testeo de software en la cual mdulos individuales de

software son combinados y testeados como un grupo. Son las pruebas posteriores a las pruebas unitarias y preceden el testeo de sistema.

Pruebas de validacin El objetivo de estas pruebas es obtener informacin til para la validacin de la implementacin de los algoritmos estudiados. Se asume para esta parte que el software ha cumplido la etapa de verificacin, por lo tanto est libre de errores de tiempo de ejecucin, lo que no significa que est libre de errores lgicos

Las pruebas del sistema son una fase de pruebas de investigacin, en la que se asegura que cada componente unitario o mdulo (identificado en las pruebas unitarias) interactue con otros componentes o mdulos, tal como fue diseado. Se registra la peticin de mantenimiento, y se determina de quin es la responsabilidad de atenderla. Si la peticin no es denegada, si mant. correctivo: se reproduce el problema si mant. evolutivo: se estudia la viabilidad del cambio propuesto por el usuario Se analizan las alternativas de solucin Se realizan las tareas necesarias de los procesos de desarrollo ASI, DSI, CSI o IAS. Se realizan las pruebas de regresin

 Es muy importante registrar los cambios que se realizan en los SI y su documentacin. Mantenimiento del software.

El mantenimiento del sw. es la modificacin de un producto sw. despus de su entrega al cliente o usuario para corregir defectos, para mejorar el rendimiento u otras propiedades deseables, o para adaptarlo a un cambio de entorno (IEEE 83).

Es

la

parte

ms

costosa

del

ciclo

de

vida

del

sw.:

60-90% del coste total (y coste creciente). El coste relativo de reparar un defecto aumenta en las ltimas etapas del ciclo de vida (de 1 a 100). En algunas empresas coste del 95%

(no se pueden desarrollar nuevos productos sw.)

Tipos de mantenimiento Correctivo Adaptativo Perfectivo Mantenimiento de ampliacin Mantenimiento de eficiencia Preventivo

Mantenimiento para la reutilizacin

Coste de mantenimiento

Preventivo 5%

Correctivo 17% Adaptativo 18%

Perfectivo 60%

El proceso de mantenimiento en el ciclo de vida del sw. Proceso ppal. de mantenimiento en el std. IEEE 12207. Actividades: Implementacin del proceso. Anlisis de problemas y modificaciones. Implementacin de las modificaciones. Revisin y aceptacin del mantenimiento. Migracin. Retirada del sw.

Mtodos de mantenimiento del software Reingeniera: examen y modificacin del sistema para reconstruirlo en una nueva forma. Ingeniera inversa: anlisis de un sistema para identificar sus

componentes y las relaciones entre ellos, as como para crear representaciones del sistema en otra forma o en un nivel de abstraccin ms elevado. Reestructuracin del software: consiste en la modificacin del software para hacerlo ms fcil de entender y cambiar o menos susceptible de incluir errores en cambios posteriores. Transformacin de programas: tcnica formal de transformacin de programas

CONCLUSIN

Al haber analizado las mtricas del producto para el software podemos concluir que es necesario aplicar dichas mtricas ya que es importante que cualquier sistema o software tenga calidad, los requisitos y requerimientos del Software son la base de las medidas de calidad, la falta de concordancia con los requisitos es una falta de calidad. A menudo es imposible medir los atributos de calidad del software en forma directa, los atributos como la complejidad , la mantenibilidad y la comprensin se ven afectados por diversos factores y no existen mtricas directas para ellos. Unos estndares especficos definen un conjunto de criterios de desarrollo que guan la manera en que se hace la ingeniera del Software, si no se siguen los criterios, habr seguramente poca calidad. Existe un conjunto de requisitos implcitos que ha menudo no se nombran. Si el software cumple con sus requisitos explcitos pero falla en los implcitos, la calidad del software no ser fiable. Algunas de las mtricas que podemos mencionar son los factores de calidad MCCALL, FURPS, ISO, estructuras para las mtricas del software, mtricas del modelo de anlisis, mtricas del modelo del diseo, mtricas del cdigo fuente, mtricas para las pruebas y mtricas para el mantenimiento adems de una serie de medidas para evaluar la calidad.

BIBLIOGRAFA http://es.wikipedia.org/wiki/metricas http://metricastecnicasdelsoftware.com http://www.monografias.com/trabajos51/metricas/evolucion-software.shtml www.fi.unju.edu.ar/.../Clase_22-abr-2009/SIII2009_-_ Metricas_de_ Producto.pdf?cidReq=SI2 www.angelfire.com/pokemon2/beer_1/M_tricas_del_Software.doc www.eici.ucm.cl/.../descargas/Ing_Sw2/apuntes/ metricas%20tecnicas% 20del%20software.ppt www.slideshare.net/juic/metricas-tecnicas-del-software-presentation

ANEXOS FACTORES DE CALIDAD MCCALL

Facilidad de mantenimiento Flexibilidad Facilidad de prueba

Revisin del Producto Transicin del producto Operacin del producto Correccin

Portabilidad Reusabilidad Interoperatividad

Fiabilidad Usabilidad Integridad Eficiencia

EJEMPLO DE DISEO DE UN SOFTWARE

TOMA DE DESICIONES ADMINISTRATIVAS

Proceso de Software

Producto de software

Medidas de Control

Medidas de prediccin

Decisiones administrativas

Ambas mtricas influyen en la toma de decisiones administrativas

DISEO CON ESTANDARES