TRMINO EMPLEADO DEFINICIN GESTIN DE LA CALIDAD Es un aspecto de la funcin general de la gestin que determina y aplica la poltica de la calidad (objetivos

y directrices generales de calidad) y normalmente se aplica a nivel empresa. (Aenor). ASEGURAMIENTO DE LA CALIDAD Es el conjunto de actividades planificadas y sistemticas necesarias para aportar la confianza de que el producto (software) satisfar los requisitos dados de calidad (Aenor, 1992). El estndar IEEE (1990) dice que se puede referir al conjunto de actividades para evaluar el proceso mediante el cual se desarrolla el producto CONTROL DE LA CALIDAD DEL SOFTWARE Son las tcnicas y actividades de tipo operativo destinadas a controlar un proceso y eliminar las causas de defectos durante las etapas del ciclo de vida. (Aenor, 1992). VERIFICACIN Y VALIDACIN La IEEE (1990) dice que es una actividad ligada al control de la calidad en el mbito del software. La verificacin trata de comprobar si el producto construido en una etapa del ciclo de vida satisface los requisitos establecidos en la etapa anterior, respondiendo a la pregunta: est el producto construido correctamente? La validacin: consiste en comprobar si el software construido satisface los requisitos del usuario, respondiendo a la pregunta. El producto es el correcto?

Boehm (1978) y McCall (1977) descomponen el concepto de calidad en propiedades ms sencillas de medir y de evaluar. El modelo de McCall se basa en la descomposicin del concepto de calidad en tres usos importantes de un producto de software desde el punto de vista del usuario: ! Caractersticas de operacin. ! Capacidad para soportar cambios (ser modificado). ! Adaptabilidad a nuevos entornos. Cada capacidad se descompone en una serie de factores a saber: facilidad de uso, integridad, fiabilidad, correccin, flexibilidad, facilidad de prueba, facilidad de mantenimiento, transportabilidad, reusabilidad y interoperabilidad. Cada factor se descompone en criterios o propiedades internas del software que determinan su calidad: facilidad de operacin, facilidad de comunicacin, facilidad de formacin o aprendizaje, control de accesos, facilidad de auditora, eficiencia de ejecucin, eficiencia de almacenamiento, exactitud o precisin, consistencia, tolerancia a fallas, modularidad, simplicidad, completitud, facilidad de traza, autodescripcin, capacidad de expansin, generalidad, instrumentacin independencia entre sistema y software, independencia del hardware, compatibilidad de comunicaciones y compatibilidad de datos. Mc Call define el factor de calidad como FC, segn: FC = c1 x m1 + c2 x m2 +... + cn x mn Donde los ci son los coeficientes de regresin y los mi son las mtricas que afectan al factor de la calidad. Estos criterios pueden ser evaluados mediante un conjunto de mtricas, las que se

pueden calcular observando directamente el software. Para cada criterio McCall propuso una serie de mtricas, aunque, muchas de ellas slo pueden ser medidas en forma subjetiva. Las mtricas pueden estar en forma de listas de comprobaciones, para obtener el grado de los atributos especficos del software. McCall propuso un esquema de graduacin mediante una escala que va de cero (bajo) a 10 (alto) y utiliza como mtricas los criterios o propiedades internas del software citados anteriormente.

Ya se describi sintticamente el modelo de tres niveles de Mc Call (1977), llamado comnmente FCM (Factor Criteria Metric). Cada factor de calidad est compuesto por un criterio, que es lo que realmente se mide, ya que son ms fciles d entender. En un tercer nivel se describe el grado de pertinencia de las relaciones entre factores, aclarando que ....dividir para conquistar Flexibilidad - Es el esfuerzo requerido para modificar un programa que ya est en funcionamiento. La pregunta asociada es: Puedo cambiarlo? 8. Flexibilidad: El coste de modificacin del producto cuando cambian sus especificaciones. criterios:

expandibilidad: Capacidad de expansin - Es el grado en que se puede ampliar el diseo arquitectnico de datos o procedural. generalidad: Generalidad - Consiste en la amplitud de aplicacin potencial de los componentes del programa. Grado en que las funciones y componentes del sistema pueden ser tiles en otras aplicaciones. Atributos del software que
proporcionan amplitud a las funciones implementadas.

auto-descripcin: - Auto descripcin: Atributos del software que proporcionan explicaciones sobre la implementacin de las funciones. modularidad:

La capacidad de comprender cada parte de un sistema en forma separada ayuda a la modificabilidad del sistema. Modularidad - Consiste en la independencia funcional de

los componentes del programa. Divisin del programa en componentes funcionales.

El aporte ms importante que hizo el diseo estructurado fue la idea de que, para resolver un problema complejo de desarrollo de software, conviene separarlo en partes ms pequeas, que se puedan disear, desarrollar, probar y modificar, de manera sencilla y lo ms independientemente posible del resto de la aplicacin. Esas partes, cuando se quiere usar un nombre genrico, habitualmente se denominan mdulos. De all que otro nombre para la programacin estructurada, luego cado en desuso, fue programacin modular. El diseo estructurado, al plantear la separacin del sistema en mdulos, se bas en las propias funciones del sistema. Esto es, los mdulos de la

programacin estructurada seran los procedimientos y funciones. Por lo tanto, al modularizar, lo que hacamos era tomar nuestra solucin del problema, y separarla en partes. Detngase aqu y asegrese de que entiende lo que le digo: en programacin estructurada modularizamos la solucin, el cmo del desarrollo. En el diseo orientado a objetos, en cambio, la modularizacin esencial se da a nivel de clases, que no son funciones del sistema, sino (al menos en una primera aproximacin) entidades del dominio del problema. Por lo tanto (y asegrese de entender tambin esto), en el anlisis y diseo orientados a objetos, no modularizamos la solucin, sino primero el problema (en el anlisis) y luego, partiendo de esas clases conceptuales, del dominio del problema, modularizamos la solucin (diseo)

Testeabilidad: Facilidad de Prueba - Es el esfuerzo requerido para probar un programa de forma que se asegure que realiza su funcin requerida. La pregunta asociada es: Puedo probarlo?

criterios: Modularidad: los modulos permiten la facilidad de prueba y correccin. Permiten detectar mas fcil los defectos del software.

simplicidad: Simplicidad - Es el grado de facilidad con que se puede entender un programa. . Atributos del software que posibilitan la implementacin de funciones de la forma ms comprensible posible. Facilidad de entendimiento del sistema para el usuario estndar. Los diseos complicados nos obligan a un esfuerzo de adaptacin y a la incorporacin de elementos que nos son artificiales y forzados.
1. Proximidad: Los diseos sencillos son ms fciles de entender y favorecen el uso inmediato y la exploracin exhaustiva de los recursos del diseo. 2. Reconocibilidad: Son ms fcilmente reconocibles y asimilables, ya que presentan menos informacin superflua. 3. Inmediatez: Los diseos sencillos tienen un impacto mayor precisamente porque su facilidad de comprensin los hacen inmediatamente reconocibles con un esfuerzo consciente mnimo. 4. Usabilidad: Por todo lo anterior suelen ser tambin los ms fciles de usar.

Instrumentacin: Instrumentacin - Es el grado en que el programa muestra su propio funcionamiento e identifica errores que aparecen. Grado en que el programa funciona correctamente e identifica errores. 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. ISO 9000-3 divide el testeo en cuatro etapas testeo de unidad se testea los componentes individuales, generalmente realizado por los programadores, Las pruebas unitarias tienen como objetivo verificar la

funcionalidad y estructura de cada componente individualmente una vez que ha sido codificado. Las pruebas de unidad es un proceso para probar los subprogramas, las subrutinas, los procedimientos individuales o las clases en un programa. Es decir, es mejor probar primero los bloques desarrollados ms pequeos del programa, que inicialmente probar el software en su totalidad. testeo de integracin se testean los mdulos compuestos por diversos componentes: La prueba de integracin es una tcnica sistemtica para construir la
estructura del programa mientras al mismo tiempo, se lleva a cabo pruebas para detectar errores asociados con la interaccin. El objetivo es tomar los mdulos probados en unidad y estructurar un programa que est deacuerdo con el que dicta el diseo. La integracin puede ser descendente si se integran los mdulos desde el control o programa prinicpal, o bien, asdendente, si la verificacin del diseo empieza desde los mdulos ms bajos y de all al principal. La seleccin de una estrategia de integracin depende de las caractersticas depende de las caractersticas del software y, a veces, del plan del proyecto, en algunos de los casos se puede combinar ambas estrategias. prueba la interaccin entre dos o

ms elementos, que pueden ser clases, mdulos, paquetes, subsistemas, etc incluso la interaccin del sistema con el entorno de produccin. testeo de sistema se testea el sistema completo tal como lo usara un usuario normal, pero sin su presencia. Al final del desarrollo, el software se incorpora a otros elementos del sistema (hardware, personas, informacin). Esta incluidas las pruebas de seguridad (comprueba los mecanismos de proteccin integrados al sistema realmente lo protejan de irrupciones inapropiadas.), pruebas de interfaces grficas. Pruebas de resistencia (ejecuta un sistema de tal manera que requiera una frecuencia o un volumen anormal de recursos. Sobrecargar el programa), pruebas de desempeo en tiempo de ejecucin. testeo de aceptacin el usuario ejecuta el sistema completo para asegurarse que cumpla con los requerimientos. Tambin llamado alpha testing

el testeo interactua con otros criterios de calidad, por ejemplo correctitud (Correccin - Es el grado en que un programa satisface sus especificaciones y consigue los objetivos pedidos por el cliente) y eficiencia ( Es la cantidad de recursos de computadoras y de cdigo requeridos por un programa para llevar a cabo sus funciones. Eficiencia. Caractersticas referentes a las relaciones entre el rendimiento y la cantidad de recursos empleados en unas condiciones determinadas. )

debe ser llevado a cabo siguiendo planes pre-definidos, con datos conocidos y cuyos resultados sean predeterminados. No debe ser redundante. Uno de los objetivos de las pruebas es
encontrar el mayor nmero de errores con la menor cantidad de tiempo y esfuerzo posibles, por lo cual no se deben disear casos de prueba que tengan el mismo propsito que otros, sino que se debe tratar de disear el menor nmero de casos de prueba que permitan probar adecuadamente el software y optimizar los recursos.

la testeabilidad puede ser maximizada usando herramientas automticas, buenas estrategias de cohesin y de diseo (diseo estructurado, funcional, orientado a objetos, Incluye la funcionalidad del sistema, el hardware y la plataforma de software del sistema, y el mtodo para su adquisicin o desarrollo. La seleccin de la mejor alternativa del diseo del sistema) (Cohesin: cmo estn relacionados los elementos de un mismo mdulo Para alcanzar estos objetivos los mdulos en los que se divida el sistema deben tener alta cohesin y bajo acoplamiento. Un mdulo tiene alta cohesin si todos sus elementos estn fuertemente relacionados y son agrupados por una razn lgica, esto es todos cooperan para alcanzar un objetivo comn que es la funcin del mdulo. La cohesin es una propiedad interna de cada mdulo, por el contrario el acoplamiento caracteriza las relaciones de un mdulo con otros..), y buenas prcticas de programacin McCall defini originalmente mtricas para testeabilidad consistentes en una matriz de complejidad que involucra nmero y tamao de mdulos, tamao de procedimientos, profundidad de anidamiento, nmero de errores por unidad de tiempo, etc.

Durante el diseo arquitectural es necesario adoptar algunas decisiones: Existe una arquitectura genrica que pueda ser usada? Cmo ser distribuido el sistema? Qu estilos arquitectnicos son apropiados? Qu aproximacin se utilizar para estructurar el sistema? Cmo se descompondr el sistema en mdulos? Qu estrategia de control se utilizar? Cmo se evaluar el diseo arquitectural resultante? Cmo se documentar la arquitectura? segn McCall el factor portabilidad (. Portabilidad (o Transportabilidad): El coste de transportar o migrar un producto de una configuracin hardware o entorno operativo a otro. Habilidad del software para operar en diferentes entornos informticos.) incluye los siguientes criterios: auto-descripcin: Atributos del software que proporcionan explicaciones sobre la implementacin de las funciones. Atributo de software que proporciona una descripcin por si solo, es decir, que el software debe describirse por si solo. Atributo de software que proporciona una descripcin por si solo, es decir, que el software debe describirse por si solo.

modularidad: Como se ha explicado un sistema complejo puede dividirse en piezas ms simples llamadas mdulos. Un mtodo de diseo que merezca ser llamado modular, debera satisfacer adems de los objetivos anteriores los dos siguientes: 1. Continuidad modular: Se satisface si un pequeo cambio en la especificacin de un problema provoca slo cambios en un solo mdulo o en un nmero pequeo de mdulos. 2. Proteccin modular: Si produce arquitecturas en las cuales el efecto de una situacin anormal ocurrida en un mdulo durante la ejecucin, queda confinado a ese mdulo (o se propaga slo a unos pocos vecinos). De los objetivos expuestos para asegurar la modularidad, se derivan cinco reglas: 1. Correspondencia directa: Conexin de un sistema de software con los sistemas externos con que est relacionado. La estructura modular obtenida, debe seguir siendo compatible con cualquier otra estructura modular en el dominio del problema. 2. Pocas interfaces de mdulos: Cada mdulo debe comunicarse con el menor nmero de mdulos posible. 3. Interfaces pequeas (acoplamiento dbil): Si dos mdulos se comunican, deben intercambiar la menor informacin posible. 4. Interfaces explcitas: Siempre que dos mdulos A y B se comuniquen, esto debe ser obvio a partir del texto de A, del de B o de ambos. 5. Ocultar informacin: Mostrar slo lo necesario.

independencia de la mquina: Independencia del Hardware - Es el grado en que el software es independiente del hardware en que opera. independencia del sistema operativo: Independencia del sistema de software - Es el grado de independencia del programa respecto a las caractersticas del lenguaje de programacin no estndar, caractersticas del sistema operativo y otras restricciones del entorno.