Calidad en el Software Dentro del contexto de Ingeniera de Software, se tomar la definicin de calidad en el software propuesta por la organizacin internacional

de estndares (ISO/IEC DEC 9126) que dice la calidad del software es el cumplimiento de la totalidad de caractersticas de un producto de software que tienen como habilidad, satisfacer necesidades explcitas o implcitas. Otra definicin bastante completa de calidad en el software es la que se presenta a continuacin: Se puede decir que el software tiene calidad si cumple o excede las expectativas del usuario en cuanto a: 1. Funcionalidad (que sirva un propsito), 2. Ejecucin (que sea prctico), 3. Confiabilidad (que haga lo que debe), 4. Disponibilidad (que funcione bajo cualquier circunstancia) y 5. Apoyo, a un costo menor o igual al que el usuario est dispuesto a pagar. Resumiendo podemos decir, que la calidad de software se refiere a: Los factores de un producto de software que contribuyen a la satisfaccin completa y total de las necesidades de un usuario u organizacin. Aseguramiento de Calidad de Software (SQA) La funcin de aseguramiento de la calidad tiene como finalidad primaria el determinar si las necesidades de los usuarios estn siendo satisfechas adecuadamente. Otra de sus funciones, es la de determinar los costos que puede causar el aadir ciertas caractersticas al producto, ya que tarde o temprano, la economa resulta ser un factor decisivo para obtener un producto de calidad. Para determinar si las necesidades de los usuarios estn siendo satisfechas, se deben de evaluar tres reas: Objetivos: Los objetivos de la organizacin son primero, luego vienen los requerimientos del usuario. Los objetivos de cualquier usuario deben de estar en armona con los objetivos de la organizacin. Mtodos: Deben de utilizarse mtodos que contengan u observen las polticas, procedimientos y estndares de la organizacin.

Ejecucin: Optimizacin del uso de hardware y software al implementar los productos de software. Para evaluar las reas expuestas con anterioridad, es necesario que se cuente con un programa de aseguramiento de calidad que sea efectivo y que tenga un impacto dentro del desarrollo y prueba del producto de software final. Necesidad de la Calidad y de sus Procesos de Aseguramiento. La calidad en el software es imprescindible. Las organizaciones de la actualidad se encuentran en una situacin donde deben idear estrategias que las pongan en ventaja con sus competidores y las tecnologas de informacin son herramientas usualmente escogidas con este propsito. Las razones, que sustentan lo anteriormente escrito, son: La naturaleza crtica de algunas tareas realizadas por las computadoras . En la actualidad se est dando una creciente dependencia de los sistemas computacionales, donde alguna falla puede resultar en catstrofes personales (sistemas de control areo, en los aeropuertos) y econmicas (sistemas transaccionales en los bancos). El crecimiento de los costos de desarrollo de productos de software. Los costos causados por mantenimiento de software son cada vez mayores, por lo que se vuelve indispensable evitar errores desde la definicin de requerimientos. La competencia entre los desarrolladores de productos de software . Para producir software de alta calidad, como un medio para ganar mercado. Sin embargo, pese a que se conoce la necesidad de producir software de calidad, la cultura actual de la calidad ensea que en las organizaciones los administradores empiezan a involucrarse en los procesos de desarrollo de tecnologa de informacin una vez que se han incurrido en costos de mantenimiento, ya sean ocasionados por un mal diseo, o por no satisfacer los requerimientos correctamente. Beneficios de los procesos de Aseguramiento de la Calidad en el Software. Los beneficios que se pueden obtener como resultado de aplicar los procesos de aseguramiento de calidad son muchos y variados, algunos que se pueden citar con brevedad son: 1. Se detectan problemas rpidamente, Es posible identificar problemas en tempranas etapas del desarrollo de productos de software, ayudando al desarrollador a corregirlos inmediatamente y poder avanzar con ms rapidez.

2. Se crean y se siguen estndares de trabajo, Con apoyo del proceso de aseguramiento de calidad, se pueden establecer estndares tan diversos como son los de codificacin o de documentacin, los cuales apoyan a uniformizar y consolidar el proceso de desarrollo. 3. Se verifica que los objetivos individuales vayan acordes con los objetivos de la organizacin, Se busca y se recomienda que los requerimientos expuestos por usuarios finales estn alineados con los objetivos globales de la empresa, facilitando as el logro de los mismos y la integracin total de los usuarios a la organizacin. 4. Se recomiendan mtodos para realizar el trabajo, Las prcticas de aseguramiento de calidad, como son muy robustas ya que aplican tcnicas muy completas de medicin, pueden proponer en un momento dado qu mtodos se ajustan ms a la naturaleza del producto a ser desarrollado, teniendo como efecto final que el producto tenga ms posibilidades de ser un producto con calidad. 5. Se evita incurrir en costos innecesarios, Como un efecto generalizado de algunos de los puntos mencionados con anterioridad, la prctica de procesos de aseguramiento de calidad lleva a las organizaciones a evitar costos no deseados como pueden ser todos aquellos ocasionados por mantenimiento correctivo. 6. Se planea la calidad, Est claro que el concepto de calidad no es algo que se da de una manera automtica e impredeciblemente. Es algo que se busca. Por lo mismo, se debe de planear, construir e implantar en el producto. Mtricas de Software Definicin: Una mtrica de software se refiere a aquella aplicacin continua de tcnicas basadas en la medida de los procesos de desarrollo del software, para producir una informacin de gestin significativa al mismo tiempo que se mejoran aquellos procesos y sus productos. Otra de las definiciones dice que una mtrica es: Un Mtodo y una escala cuantitativos que pueden ser usados para determinar el valor que toma cierta caracterstica en un producto de software concreto. Tambin puede ser definida como: Una funcin que toma como entrada cierta informacin del software que se est midiendo, y que devuelve como salida un valor numrico sencillo, el cual es interpretada, como el grado en que el producto de software posee un atributo dado que afecta a su calidad.

Caractersticas: Se afirma que para que las mtricas sean tiles ests deben tener las siguientes cuatro caractersticas: 1. Cuantificables, deben basarse en hechos, no en opiniones. 2. Independientes, los recursos no deben poder ser alterados por los miembros que las apliquen o utilicen. 3. Explicable, debe documentarse informacin acerca de la mtrica y de su uso. 4. Precisas, debe de conocerse un nivel de tolerancia permitido cuando se mide. Mtricas del producto Para justificar la existencia de este tipo de mtrica, se argumenta que stas deben ser enunciadas y utilizadas para administrar el proceso de desarrollo y debe ser conforme al producto de software particular. El proveedor de productos de software debe de recopilar y actuar sobre las medidas cuantitativas de la calidad de esos productos de software. Estas medidas deben ser utilizadas para los siguientes propsitos: 1. Para recopilar informacin y reportar valores de mtricas sobre bases regulares. 2. Para identificar el actual nivel de desempeo por cada mtrica. 3. Para tomar la accin remedial si los niveles de las mtricas crecen peor o exceden los niveles objetivos establecidos. 4. Para establecer metas de mejoras especificas en trminos de las mismas mtricas. Mtricas de proceso El proveedor debe tener mtricas cuantitativas de la calidad del proceso de desarrollo y de liberacin. Estas mtricas deben de reflejar: a) Qu tan bien el proceso de desarrollo est siendo llevado a cabo en trminos de puntos de revisin y en objetivos de calidad en el proceso, siendo cumplidos en tiempo de calendario. b) Qu tan efectivo es el proceso de desarrollo, al reducir la probabilidad que se introduzcan fallas o que cualquier falla introducida sea detectada. Aqu como las partes de las mtricas del producto, lo importante es que los niveles sean conocidos y utilizados, para el control del proceso y de las mejoras, y no

sean utilizadas mtricas fijas. Las mtricas seleccionadas deben de ajustarse al proceso utilizado y si es posible, tener un impacto directo sobre la calidad de software liberado. Las mtricas tambin pueden ser categorizadas como mtricas de resultado o mtricas de prediccin. Una medicin de prediccin es normalmente una mtrica de producto que puede ser utilizada para predecir el valor de otra mtrica. La mtrica es predicha, una mtrica de proceso, es conocida como una mtrica de resultado. Uso de Mtricas Las mtricas deben ser implantadas paso a paso en correspondientes al nivel de madurez del proceso de desarrollo. cinco niveles,

Proceso Inicial (Nivel 1): Su objetivo es formar una base de comparacin con la forma en que las mejoras se realicen y se incremente la madurez, estos incluyen: a) El tamao del producto, b) El esfuerzo del personal (Utilidades para determinar una tasa de productividad) Proceso Repetible (Nivel 2): Las mtricas a este segundo nivel incluyen como objetivos de medicin los siguientes: 1. La cantidad de esfuerzo necesaria para desarrollar un sistema, 2. La duracin del proyecto, 3. El tamao y la volatilidad de los requerimientos, 4. El costo global del proyecto (Por lo que el tipo de mtrica que se recomiendan incluye a las siguientes): a) Tamao del software (Lneas de codillo fuente no comentadas). b) Puntos de Funcin. c) Cuenta de objetos y mtodos. 5. Esfuerzo del trabajo de personal: a) Esfuerzo real medido en unidades persona/mes. b) Esfuerzo reportado en unidades persona/mes. 6. Volatilidad de los requerimientos (Cambios de los requerimientos).

stas se incluyen como mtricas principales para realizar la medicin. Adems las siguientes pueden aadirse a consideracin de la administracin del proyecto de software. 7. Experiencia (del dominio o aplicacin, de la arquitectura de desarrollo utilizada, de las herramientas y mtodos empleados, aos globales de experiencia en el desarrollo), 8. Rotacin de personal Proceso definido (Nivel 3): En este nivel de madurez, se recomienda evaluar la complejidad de los requerimientos, el diseo, el cdigo y los planes de prueba, y evaluar la calidad de los requerimientos del diseo del cdigo y de las pruebas. En trminos de complejidad, se sugiere que los siguientes puntos se midan a este nivel: 1. Complejidad de los requerimientos (Nmero de distintos objetos y acciones llevadas a cabo en los requerimientos). 2. Complejidad del Diseo (Nmero de mdulos de diseo, Complejidad Ciclomtica, Complejidad de Diseo de McCabe. 3. Complejidad del Cdigo (Nmeros de Mdulos de Cdigo, Complejidad Ciclomtica. 4. Complejidad de las pruebas (Nmero de Caminos a probar, Si el desarrollo es orientado a objetos, debe de considerarse el nmero de interfaces de objetos a probar. Se puede evaluar la minuciosidad de las pruebas. As, por mencionar algunas mtricas recomendadas de calidad, podemos decir las siguientes: a) Defectos descubiertos, b) Defectos descubiertos por unidad de tamao (densidad de defectos), c) Fallas de requerimientos descubiertos, d) Fallas de diseo descubiertas, e) Fallas de Cdigo descubiertas, f) Densidad de fallas por cada producto. Se enfatiza que este conjunto no es representativo del espectro completo de medidas que pueden ser empleadas. Aspectos tales como facilidad de

mantenimientos, grado de utilizacin facilidad de uso y otros atributos de calidad de software que no son considerados por la cuenta de defectos. Proceso Administrado (Nivel 4): En este nivel la retroalimentacin determina cmo son asignados los recursos pues las actividades bsicas por s mismas no cambian. Las mtricas recolectadas son utilizadas para encontrar y estabilizar el proceso, as la productividad y la calidad coinciden con las expectativas. Se recomienda por lo tanto recolectar informacin al respecto de los siguientes aspectos: - Tipo de proceso, se refiere a qu tipo de modelo se utiliza para el desarrollo de software. - Cantidad de reuso del producto, este aspecto se relaciona con que tanto se disea el software para su reuso. - Cantidad de reuso del Consumidor, Este aspecto es establecido en consideracin a cuanto reuso de los componentes de un proyecto y de otros aspectos. - Identificacin de defectos, se relaciona con cmo y cundo se descubren los defectos. - Uso de la densidad de defectos para las pruebas, se relaciona con la extensin del nmero de defectos que determina cundo estn completas las pruebas. - Uso de la administracin de la configuracin, cuestiona acerca de que si la configuracin de la administracin es un esquema impuesto sobre el proceso de desarrollo. - Terminacin de mdulos sobre tiempo, considera en qu porcentaje los mdulos estn siendo debidamente terminados. Optimizacin del Proceso (Nivel 5): A este nivel las mtricas de las actividades son utilizadas para mejorar el proceso. Pruebas de Software La definicin de pruebas en el contexto del software tiene diferentes connotaciones que en algunos casos llevan a malas interpretaciones. La definicin de pruebas de software de Myers es: Las pruebas son el proceso de ejecucin de un programa con la intensin de encontrar errores; adems, sta es una parte fundamental del aseguramiento de la calidad del software (QA, por sus siglas en

ingles), ya que ayuda a asegurar que el producto cumpla con los requisitos; sin embargo las pruebas de software no son QA, tan solo son una parte de ella. La industria del software a travs de su historia ha encontrado la necesidad de refinar aspectos fundamentales vinculados directamente a su proceso productivo: 1. Los costos y el tiempo: la dificultad de planear proyectos de software trae consigo problemas en la estimacin de tiempos y por ende altos costos asociados; la creacin de mtricas de software y procesos de planeacin eficientes han ayudado a amortiguar el peso de stos factores en el desarrollo del software. 2. La calidad: debido a la competitividad del mercado de software la calidad se convierte en un factor determinante a la hora de comercializar los productos. Igualmente, permite disminuir los tiempos de mantenimiento al obtener productos con menor cantidad de errores inyectados y por ende ms confiables. La importancia de las pruebas de software se puede visualizar teniendo como referencia algunos autores: - Las pruebas de software permiten pasar de forma confiable del cmodo ambiente planteado por la ingeniera de software, es decir del controlado ambiente de anlisis, diseo y construccin, al exigente mundo real en el cual los entornos de produccin someten los productos a todo tipo de fatiga. - Las pruebas de software basadas en componentes permite la reutilizacin y por ende la reduccin de los ciclos de pruebas, lo cual se ve reflejado en la disminucin de costos y tiempos. - La necesidad de productos de software de alta calidad ha obligado a identificar y cuantificar factores de calidad como: capacidad de uso, capacidad de prueba, capacidad de mantenimiento, capacidad de ser medible, capacidad de ser confiable y a desarrollar practicas de ingeniera que contribuyen a la obtencin de productos de alta calidad. Taxonoma de las Pruebas en aplicaciones de Software Las pruebas de software se tipifican de acuerdo a los aspectos especficos que se van a probar en el software. En la literatura existen diversos autores que proponen taxonomas caracterizadas por su grado de profundidad o expansin. La clasificacin propuesta por Burnstein se caracteriza por ser una taxonoma generalizada, enfocada en tipos de pruebas tpicos en la industria del software. La clasificacin incluye pruebas de: funcionalidad, de rendimiento, de fatiga, de configuracin, de seguridad y de recuperacin.

Por otro lado existen taxonomas que buscan abarcar un conjunto de aspectos ms amplio en las pruebas, lo cual conduce a que stas contengan una expansin notable en la cantidad de tipos, ofreciendo una visin ms detallada del horizonte de pruebas e influyendo positivamente en todo el proceso de pruebas. Myers clasifica los tipos de pruebas en: de locacin, de volumen, de fatiga, de capacidad de uso, de seguridad, de rendimiento, de almacenamiento, de configuracin, de compatibilidad y conversin, de instalacin, de capacidad de ser confiable, de recuperacin, de utilidad, de documentacin, de procedimientos y de aceptacin. Las tcnicas de pruebas de software constituyen un mecanismo conceptual mediante el cual se pueden detectar defectos en el software. En la taxonoma citada por Young y Taylor, se puede observar que se tipifican las tcnicas de pruebas de software teniendo en cuenta el ciclo de desarrollo del mismo y su estado (caracterstica estticas o dinmicas). Existen otras tcnicas no clasificadas segn su estado; es el caso de las citadas por Burnstein as: 1. Pruebas de tipo aleatorio: se generan los valores correspondientes a los casos de pruebas de forma aleatoria teniendo en cuenta la especificacin de las entradas y en algunos casos las salidas. Algunos autores proponen tcnicas de muestreo aleatorio con restricciones que permiten reducir la poblacin objetivo sin afectar los hallazgos de defectos. 2. Pruebas de particin de clases equivalentes: La poblacin de entrada se generan a partir del muestreo de conjuntos de valores llamados clases. Las clases seleccionadas deben cubrir todo el dominio de valores de entrada o salida y no deben traslaparse. Aunque existe una dificultad asociada en el diseo de pruebas usando esta tcnica, la probabilidad de hallar defectos es bastante alta adems elimina la necesidad de realizar pruebas exhaustivas. 3. Pruebas de valores lmite: Partiendo de la prueba de particin de clases equivalentes se puede incorporar en los datos de pruebas, valores limites de las clases particionadas, es decir, valores que se encuentran en el borde de una u otra clase. Cuando se prueban los valores limites, la probabilidad de encontrar defectos aumenta, dado que estos puntos son los ms susceptibles de contener errores. 4. Pruebas de suposicin de error: La forma ms intuitiva de seleccionar valores de prueba es a travs de la suposicin de errores la cual se basa en la experiencia del diseador de pruebas. Esta tcnica pretende revelar defectos cuando se elijen valores del dominio de entrada que producen determinados valores del dominio de

salida. 5. Pruebas de transicin de estados: Esta tcnica se basa en el diagrama de transicin de estados construido para los objetos relevantes del sistema. El diagrama de transicin de estados presenta los diferentes estados de un objeto y los eventos que generan las transiciones. Cuando un diseador de casos de prueba utiliza una tcnica de transicin de estados tabula las combinaciones posibles que deben ocurrir para que un objeto pase de un estado a otro. Esta informacin de secuencia de eventos es utilizada por el probador para buscar falencias en los estados y sus transiciones.