Universidad de Mo rn - Facultad de Informtic a, Ci encias De la Com unicacin y Tcnicas Especiales Herr am en tas de Software i

CALIDAD DE SOFTWARE

Defi nicin de Calidad:

Concordancia con los requisitos funcionales debidamente establecidos, con los estndares de desarrollo explcitamente documentados y con las caractersticas implcitas que se espera que todo software desarrollado profesionalmente. Los requisitos de software son la base de la medida de calidad. Si no se cumple con los requisitos establecidos, no ser un software de calidad. Los estndar es especificados definen un conjunto de criterios de desarrollo que guan la forma en que se aplica la ingeniera de software. Existe un conjunto de requisitos implcitos que no se mencionan, pero que estn presentes en todos desarrollo profesional, como el buen mantenimiento o la facilidad de uso.

Factores que Determinan la Calidad

Existen dos tipos de factores: Fact ores que pueden ser medidos directamente (errores/KLDC/unidad de tiempo). Fact ores que solo pueden ser medidos indirectamente (la facilidad de uso o de mantenimiento). En ambos casos se puede medir la calidad, debemos comparar el software (documentos, programas, etc.) con alguna referencia y llegar a una indicacin de calidad.

Factores de Calidad segn McCall Loa factores desarrollados segn el modelo de McCall, se centra en tres aspectos importantes de un productos de software: Sus caractersticas operativas. Su capacidad para soportar los cambios. Su adaptabilidad a nuevos entornos.

Lista de factores: Correccin: mide el grado en que un programa satisface sus especificaciones y consigue los objetivos del usuario. Fiabilidad: mide el grado en que se puede esper ar que un programa lleve a cabo sus funciones esper ada con la precisin requerida. Eficienc ia: mide la cantidad de recursos de computadora y de cdigo requerido por un programa para que lleve a cabo las funciones especificadas. Integri dad: es el grado en que puede controlarse el acceso al softwa re o a los datos por personal no autorizado. Facili dad de Uso: es el esfuerzo requerido para apre nder un programa e interpretar la informacin de entrada y de salida. Facili dad de Mantenimiento: es el esfuerzo requerido para localizar y arreglar programas.

Pg. N 1

Universidad de Mo rn - Facultad de Informtic a, Ci encias De la Com unicacin y Tcnicas Especiales Herr am en tas de Software i

Facili dad de Prueba: es el esfuerzo requerido para probar un programa. Flex ibilidad: es el esfuerzo requerido para modificar un sistema operativo. Portabili dad: es el esfuerzo requerido para transferir un software de un hardwa re o un entorno de sistemas a otro. Reus abili dad: es el grado en que un progra ma (o par tes de un programa) se puede reutilizar en otro. Facili dad de Interoperacin: es el esfuerzo requerido para asociar un programa a otro.

Factores de Calidad segn Boehm El modelo que presenta Boehm presenta una jerarqua de caractersticas donde cada una de ellas contribuye a la calidad global. Se centra en: Sus caractersticas operativas. Su capacidad para soportar los cambios. Su adaptabilidad a nuevos entornos. La evaluacin del desempeo del hardware. El modelo comienza con la utilidad general del software, afirmando que el software es til, evitando prdida de tiempo y dinero. La utilidad puede considerarse en correspondencia a los tipos de usuarios que quedan involucrados. El primer tipo de usuarios queda satisfecha si el sistema hace lo que el pretende que haga; el segundo tipo es aquel que utiliza el sistema luego de una actualizacin y el tercer o, es el programador que mantiene el sistema. Factores segn McCall

Utilidad General Utilidad Percibida

Portabilidad Confiabilidad Eficiencia Ingeniera Humana Facilidad de Mantenimiento Facilidad de Prueba Facilidad de Comprensin Facilidad de Modificacin

Factores de Calidad segn ISO 912 6 Es un modelo jerrquico con seis atributos especiales. La diferencia con McCall y Boehm es que la jerarqua es estricta, es decir, que cada caracterstica de la derecha solo est relacionada con un solo atributo del modelo. Las caractersticas de la der echa se relacionan con la visin del usuario. Funcion al idad ............................... Adaptacin, Exactitud, Interoperacin, Seguridad. Conf iabilidad ................................ Madurez, Tolerancia a Defectos, Facilidad de Recuperacin. Eficienc ia ...................................... Comportamiento en el Tiempo, de los Recursos. Facili dad de Uso ........................... Facilidad de Comprensin, de Aprendizaje, de Operacin. Facili dad de Mantenimiento ......... Facilidad de Anlisis, de Cambios, de Pruebas, Estabilidad.
Pg. N 2

 Portabili dad .................................. Adaptabilidad, Facilidad de Instalacin, de Reemplazo.

Administracin de Calidad
La administracin de calidad definir procedimientos y estndares a utilizar en el desarrollo de software y comprobar que todos los ingenieros de software lo sigan. Los buenos administradores tienen como propsito desarrollar una cultura de calidad, en donde cada integrante del grupo es motivado para que logre un alto nivel de calidad del producto a desarrollar. La administracin de calidad se estructura en tres actividades principales: 1.Aseguramiento de Calidad: es el establecimiento de un marco de trabajo de procedimientos y estndares organizacionales que conduce a desarrollar un software de calidad. Los procedimientos de aseguramiento de calidad se documentan en un manual de calidad que define el proceso de desarrollo. Existen dos tipos de estndares: Estndares del Produ ct o: son estndares del producto, como la estructura del documento de requerimientos, el documento de codificacin que define como utilizar un lenguaje de programacin, estndares de documentos. Estndares del Proceso: son estndares que definen los procesos a seguir durante el desarrollo. Incluyen definicin de los procesos de especificacin, de diseo, y de validacin, y una descripcin de la documentacin a generar. 2.Planificacin de la Calidad: se inicia en las primeras etapas de desarrollo en forma independiente de la planificacin del proyecto general. Define la calidad del producto deseado, define como valorar la calidad (porque p ara los desarrolladores pesan distintos factores de calidad). Estructura del Plan de Calidad: Introducc in del Produ cto: contiene la descripcin del producto a desarrollar, el mercado al cual se dirige y las expectativas de calidad del producto. Planes del Producto: contiene la fecha de terminacin del producto, lo recursos necesarios, las responsabilidades junto con la distribucin y servicio. Descri pcin del Proceso: contiene los procesos de desarrollo y de servicios a utilizar para el desarrollo y la administracin del producto a desarrollar. Metas de Calidad: contiene las metas y planes de calidad para el producto a desarrollar, incluye una identificacin y una justificacin de los atributos de calidad importantes. Riesgos y Administracin de Riesgos: contiene los riesgos claves que pudieran afectar la calidad del producto de desarrollo y el plan de contingencias. 3.Control de Calidad: implica vigilar el procedimiento de desarrollo para asegurar que se sigan los procedimientos de aseguramiento y los estndares de calidad. El proceso de control de calidad tiene su propio conjunto de procedimientos e informes a utilizar durante el desarrollo. Existen varios mtodos de para validar la calidad de un proceso o producto, el ms utilizado son las Revisiones Tcnicas Formales.

Revision es Tcnicas Formal es (RTF) Es una actividad de la garanta de calidad de software. Los objetivos de las revisiones tcnicas formales son:

 Descubrir err ores en la funcin, la lgica o la implementacin de cualquier representacin de software. Verificar que el software bajo su revisin alcanza sus requisitos los funcionales. Garantizar que el software ha sido desarrollado de acuerdo a los estndares predefinidos. Conseguir un software desarrollado uniformemente. Hacer que los proyectos sean ms manejables.

Restricciones de la RTF: Se debe convocar a la RTF normalmente entre 3 y cinco personas. Se debe prep ara por adelantado, pero sin que requiera ms de dos horas de trab ajo previo por persona. La duracin de la RTF debe ser menor a dos horas. Se debe centrar en una parte especifica y pequea del software total.

Directrices de la RTF: Revisar el producto, no al productor. Fijar una agenda y mantenerla (es decir no desviar el tema de la reunin). Limitar el deb ate y las impugnaciones. Enunciar reas del problema, no intentar resolverlo. Tomar notas escritas. Limitar el nmero de participantes, e insistir en la preparacin anticipada. Desarrollar un lista de comprobacin para cada producto a ser revisado. Disponer de rec ursos y una agenda para las RTF (incluir como tarea del proyecto). Llevar a cabo un entrenamiento por parte de los revisores. Repasar las revisiones anteriores.

Bibliografa: Ingeniera de Softwar e. Roger Pressman Ingeniera de Softwar e. Ian Sommerville Ingeniera de Softwar e. Shari Pfleeger

Un ivers idad de Morn - Fa cultad de Informtica, Ci encias De la Comunicacin y Tcnicas Especiales Herr am entas de Software i

Jefe de Lder de

Revisi n

Proyecto

Productor El lder evala si el producto est en condiciones de pasar a una RTF. Distribuye las copias a los revisores. Agenda la RTF.

El lder evala si el producto est en condiciones de pasar a una RTF.

Revisores

El productor le informa al lder que ha terminado su producto.

Proc eso de una Revisin T cnica Formal

Registrador

Los revisores realizan la revisin previa a la reunin.

Toma las anotaciones correspondientes para generar: La lista de sucesos de revisin y el informe sumario de revisin. Le pasa los informes al productor para que realice las correcciones pertinentes. Archiva la documentacin para futuros controles. Se realiza la RTF.
Pg. N 5