Aplicaciones de Ingeniera de SoftwareAdministracin de la Calidad del Producto de Software

Qu es la gestin de la calidad?

Es una actividad protectora o de sombrilla que se aplica a lo largo del proceso de software. Con frecuencia es llamada garanta de la calidad de software

La gestin de la calidad abarcaUn proceso de garanta de la calidad del software (Software Quality Assurer/Advisor) Tareas especficas de aseguramiento y control de la calidad (revisiones tcnicas formales y una estrategia de pruebas) Prcticas efectivas de ingeniera de software (mtodos y herramientas)

La gestin de la calidad abarcaControl de todos los productos de trabajo del software y los cambios que generan Un procedimiento para garantizar la concordancia con los estndares de desarrollo del software Mecanismos de medicin e informe

Control de calidadInvolucra la serie de inspecciones, revisiones y pruebas empleadas a lo largo del proceso de software para garantizar que cada producto de trabajo satisfaga los requisitos que se le han asignado.

Garanta de la calidad del software (SQA)Concordancia con los requisitos funcionales y de desempeo explcitamente establecidos, estndares de desarrollo explcitamente documentados y caractersticas implcitas que se esperan de cualquier software desarrollado profesionalmente.

La gente olvida cun rpido hiciste un trabajo, pero siempre recuerdan cun bien lo hiciste. Howard Newton

Actividades de SQAPreparar un plan de SQA para un proyecto. Identifica las evaluaciones que se harn, las auditoras y revisiones a llevar a cabo, los estndares aplicables al proyecto, los procedimientos para el informe y el seguimiento de errores, los documentos que debe producir el grupo SQA y la cantidad de retroalimentacin proporcionada al equipo de proyecto.

Actividades de SQAParticipar en el desarrollo de la descripcin del proceso de software del proyecto. El equipo de software selecciona un proceso para el trabajo que habr de realizarse. El grupo de SQA revisa la descripcin del proceso para que concuerde con las polticas organizacionales, los estndares internos de software, los estndares impuestos de manera externa (ISO 9000) y otras partes del plan de proyecto de software.

Actividades de SQARevisar las actividades de ingeniera del software para verificar que se ajustan al proceso de software definido. El grupo de SQA identifica, documenta y sigue las desviaciones del proceso y verifica que se hayan hecho las correcciones.

Actividades de SQAAudita productos de trabajo de software seleccionados para verificar que se ajusten con los definidos como parte del proceso del software. El grupo de SQA revisa los productos de trabajo seleccionados, identifica, documenta y sigue las desviaciones; verifica que se hayan hecho las correcciones; y peridicamente informa de los resultados de su trabajo al gerente del proyecto.

Actividades de SQAGarantiza que las desviaciones en el trabajo del software y en los productos de trabajo estn documentadas y se manejen de acuerdo con el procedimiento establecido. Las desviaciones se pueden encontrar en el plan del proyecto, en la descripcin del proceso, en los estndares aplicables o en los productos de trabajo tcnicos.

Actividades de SQARegistra cualquier falta de ajuste y lo informa al gestor ejecutivo. A los seguimientos que no se ajustan se les da seguimiento hasta resolverlos.

ValidacinLa validacin se refiere al proceso de evaluacin del software al final de su desarrollo para asegurar que est libre de fallas y cumple con los requisitos. La validacin se lleva a cabo mediante la utilizacin de diversos enfoques de prueba. Tambin se pueden validar productos intermedios como la descripcin de requisitos, esto se hace mediante la utilizacin de un prototipo.

VerificacinSe refiere al proceso de determinar si los productos de una determinada fase del proceso de desarrollo de software cumplen con los requerimientos establecidos durante la fase previa. Trata de identificar defectos o errores que generen fallas. Una de las tcnicas ms comunes para la verificacin es la revisin tcnica. Por ejemplo, una revisin de especificaciones intenta verificar el modelo del anlisis contra la Especificacin de Requisitos

Tipos de Productos para V&VRequisitos Diseo Implementacin Administracin de la Configuracin y Cambios

Objetivo de la V&VAsegurar que el producto satisface las necesidades del usuario. Aspectos considerados por la V&V:Funcionalidad Portabilidad Desempeo Mantenibilidad Seguridad Usabilidad

Clasificacin de la aplicabilidad de las tcnicas y enfoques de V&VCorrectudEl grado en el que el producto est libre de defectos.

ConsistenciaEl grado en el que el producto es consistente consigo mismo y con otros productos.

NecesidadEl grado en que lo contenido en el producto es necesario.

Suficiencia (Completud)El grado en el que el producto est completo.

DesempeoEl grado en el que el producto satisface sus requisitos de desempeo.

Enfoques y tcnicas de V&VRevisiones Tcnicas del Software (Recorridos e Inspecciones) Prueba de Software Simulacin y Prototipos Rastreabilidad de Requisitos

Revisin Tcnica Formal (RTF)Actividad del control de calidad del software Objetivos:Descubrir errores en la funcin, lgica o implementacin en cualquier representacin del software. Verificar que el software en revisin satisface sus requisitos Garantizar que el software se ha representado de acuerdo con los estndares predefinidos.

Revisin Tcnica Formal (RTF)Lograr software desarrollado en una manera uniforme. Hacer proyectos ms manejables.

Revisin Tcnica Formal (RTF)Sirve como un proceso de entrenamiento pues permite que los ingenieros menos experimentados observen diferentes enfoques respecto al anlisis, el diseo y la construccin de software. Promueve el soporte y la continuidad, pues varias personas se familiarizan con partes del software que de otra forma nunca veran. Cada RTF se realiza en una junta y tendr xito si se planifica, controla y atendiende apropiadamente.

Junta de revisinCualquier junta de revisin debe atenerse a las siguientes restricciones: En la revisin se deben involucrar entre 3 y 5 personas. Se debe preparar con anticipacin, pero sin que requiera ms de 2 horas de trabajo de cada persona. La duracin de la junta de revisin debe ser menor a dos horas. Estas restricciones implican que una RTF se enfoca en una parte especfica y pequea del software total (Porcin de especificacin, diseo detallado de componente, listo de cdigo fuente. Esto tambin se le conoce como un Recorrido

Participantes en la preparacin y realizacin de la junta de revisinEl ProductorEs el ingeniero que ha desarrollado el artefacto.

Jefe del ProyectoEs el responsable del proyecto.

Jefe de RevisinEvala la disponibilidad del producto, genera copias del material necesario y las distribuye a dos o tres revisores para que realicen sus observaciones antes de la junta. Revisa el producto y establece una agenda.

RevisoresSe familiarizan con el producto considerando entre una y dos horas y toman sus notas.

Desarrollo de la ReuninUno de los revisores asume el papel de registrador Presentacin de la agenda por parte del Jefe de Revisores y breve introduccin por parte del Productor. El Productor inicia el recorrido del producto explicando el material. Los Revisores exponen los problemas que descubrieron antes de la junta.

Desarrollo de la ReuninEl Registrador va anotando los problemas o errores encontrados. Al final todos los asistentes deben decidir si:Aceptan el producto sin modificaciones posteriores. Rechazan el artefacto debido a errores severos encontrados. Aceptan el producto provisionalmente.

Desarrollo de la ReuninSe llena documento de finalizacin indicando la participacin y conformidad con los hallazgos del equipo revisor.

Informe de la revisin y conservacin de registrosUn informe resumen de la revisin responde 3 preguntas:Qu se revis? Quin lo revis? Cules fueron los hallazgos y conclusiones?

Directrices de la revisinRevisar el producto, no al productor Establecer una agenda y respetarla Limitar el debate y la impugnacin Enunciar reas de problemas, pero no se intente resolver todos los que se hayan sealado.

Directrices de la revisinTomar notas Limitar el nmero de participantes e insistir en la preparacin anticipada. Desarrollar una lista de verificacin para cada producto que tenga probabilidad de ser revisado.

Directrices de la revisinAsignar recursos y programar las RTF. Realizar un entrenamiento significativo de todos los revisores. Analizar las revisiones previas.

Simulacin y PrototiposSon tcnicas para analizar el comportamiento esperado de un producto. Para los propsitos de la V&V, son normalmente utilizadas para analizar las especificaciones de requisitos asegurarando que reflejan las necesidades de los usuarios. Tambin se utilizan para analizar el desempeo esperado del producto en relacin a los requisitos no funcionales.

Rastreo de RequisitosEs una tcnica para asegurar que el producto, as como la prueba del producto corresponden a cada uno de sus requisitos. El enfoque tradicional para llevarlo a cabo es mediante el uso de matrices.

Garanta de la calidad estadstica del softwareLa informacin acerca de los defectos de software se recopila y clasifica. Se intenta determinar la causa de cada defecto Mediante el principio de Pareto (80% de los defectos se encuentran en 20% de todas las causas posibles) se aisla un 20%

Garanta de la calidad estadstica del softwareUna vez que las causas vitales han sido identificadas, se corrigen los problemas que han provocado los defectos.

Un ejemplo genrico de la aplicacin de mtodos estadsticos Supngase que una organizacin recopila los defectos de un aoEspecificaciones incompletas o errneas (EIE) Mala interpretacin de la comunicacin con el cliente (MCC) Desviacin intencional de las especificaciones (DIE)

Un ejemplo genrico de la aplicacin de mtodos estadsticosViolacin de los estndares de programacin (VEP) Errores en la representacin de los datos (modelos de clases, datos) (ERD) Interfaz de componente inconsistente (ICI) Error en la lgica del diseo (ELD) Prueba incompleta o errnea (PIE)

Un ejemplo genrico de la aplicacin de mtodos estadsticosError en la traduccin del diseo al lenguaje de programacin (TLP) Errores en la representacin de los datos (modelos de clases, datos) (ERD) Interfaz de componente inconsistente (ICI) Error en la lgica del diseo (ELD) Prueba incompleta o errnea (PIE)

Datos estadsticosTotal Error EIE MCC DIE VEP ERD ICI ELD PIE DII TLP Totales Nmero 205 156 48 25 130 58 45 95 36 60 858 % 24 18 6 3 15 7 5 11 4 7 100 Serios Nmero 34 12 1 0 26 9 14 12 2 15 125 % 27 10 1 0 21 7 11 10 2 12 100 Moderados Nmero 68 68 24 15 68 18 12 35 20 19 347 % 20 20 7 4 20 5 3 10 6 5 100 Menores Nmero 103 76 23 10 36 31 19 48 14 26 386 % 27 20 6 3 9 8 5 12 4 7 100

Interpretacin sobre los resultados presentadosLa tabla indica que EIE, MCC y ERD son las causas vitales al representar el 53% de todos los errores. Sin embargo, se debe observar que EIE, ERD, TLP y ELD se seleccionaran como causas vitales si slo se consideran errores serios.

Acciones correctivasPara corregir EIE y MCC implementar tcnicas que faciliciten la recopilacin de requisitos y que a su vez mejoren la comunicacin con el cliente. Para mejorar ERD adquirir herramientas para el modelado de clases y datos y ejecutar revisiones de diseo ms rigurosas

La aplicacin de SQA y el principio de apareto pueden resumirse en una sola oracin:Emplee su tiempo enfocndose en las cosas que realmente importan, !pero primero asegrese de entender qu es lo que realmente importa!

ReferenciasPressman, R. Ingeniera Ed.,McGrawHill, 2006. de software: un enfoque prctico. 6ta