En el tema 1 se mencionó que algunos procesos específicos SQM están definidos en el estándar IEEE 12207.0-96: * Procesos de Verificación * Procesos de Validación * Procesos de Revisión * Procesos de Auditoría Con base en (SWEBOK, Guide to the Software Engineering Body of Knowledge, 2004 Version “http://www.swebok.org/pdfform “http://www.swebok.org/pdfformat.html”) at.html”) 1. Coloque Coloque una aportación aportación en el que describa describa la respuesta, respuesta, considerando considerando lo siguiente: siguiente: a. Seleccione Seleccione uno de los dos procesos procesos (Revisión (Revisión y Auditoría) Auditoría) e investigue. investigue. Describa Describa a que se refiere, como se define y sus principales características. b. Integre una respuesta con su investigación y su aportación y conclusión personal y colóquela como su aportación en el foro de discusión. SOLUCION: La garantía de calidad del software es una actividad que se aplica en todo el proceso del desarrollo de software. La SQA comprende procedimientos para p ara la aplicación efectiva de métodos y herramientas, revisiones técnicas formales y estrategias de prueba. PROCESO DE REVISION: El objetivo de una Revisión de un elemento software es evaluar el software o el estado, del proyecto para identificar las discrepancias sobre los resultados planificados y recomendar mejoras cuando sea apropiado. * Su objetivo es evaluar el estado y los productos de una/s actividad/es en un/os proyectos * Se realizan a nivel gerencial y a nivel técnico y durante todo el ciclo de vida * Puede ser realizado por cualquiera de las dos partes Una parte (parte revisora) revisa lo actuado por la otra (parte revisada). Las revisiones sirven para: • Señalar la necesidad de mejoras en el producto de una sola persona o un equipo. • Confirmar las partes de un producto en las que no es necesaria o no es deseable una mejora. • Conseguir un trabajo técnico de una calidad más uniforme, o más predecible, que la que puede ser conseguida sin revisiones, con el fin de hacer más manejable el trabajo técnico. Revisiones técnicas formales • Descubrir errores en la función, la lógica o la implementación de cualquier representación del software. • Verificar que el software bajo revisión alcanza sus requisitos. • Garantizar que el software ha sido representado de acuerdo con ciertos estándares predefinidos. • Conseguir un software desarrollado de forma uniforme.
• Hacer que los proyectos sean más manejables. La reunión de revisión: • Deben convocarse para la revisión entre 3 y 5 personas. • Se debe preparar por adelantado, pero sin que se requiera más de 2 horas de trabajo de cada persona. • La duración de la reunión de revisión debe < 2 horas. Roles: • El productor • Revisor • El jefe de revisión • El registrador Registro e informe de la revisión: Elaborar un resumen de revisión • Qué fue revisado? • Quién lo revisó? • Qué se descubrió y cuáles fueron las conclusiones? • Identificar áreas problemáticas dentro del producto. • Lista de comprobación de puntos de acción para las correcciones. Directrices para una revisión: 1.- Revisar al producto, no al productor. 2.- Fijar una agenda y mantenerla. 3.- Limitar el debate y las impugnaciones. 4.- Enunciar áreas de problemas, pero no intentar resolver cualquier problema que se ponga de manifiesto. 5.- Tomar notas escritas. 6.- Limitar el número de participantes e insistir en la preparación anticipada. 7.- Desarrollar una lista de comprobación para cada producto que haya de ser revisado. 8.- Disponer de recursos y una agenda para las Revisiones Técnicas formales. 9.- Llevar a cabo un buen entrenamiento de todos los revisadores. 10.- Repasar las revisiones anteriores. EL PROCESO DE AUDITORIA DEL SOFTWARE 1. Objetivo. Según se ha indicado es proveer la confirmación de la conformidad de los productos y los procesos para certificar la adherencia con los estándares. Líneas guía, especificaciones y procedimientos. 2. Resumen. La auditoria es realizada de acuerdo con los planes y procedimientos documentados. El plan de auditoría establece un procedimiento para dirigir la auditoria y para las acciones, de seguimiento sobre las recomendaciones de la auditoria. 3. Responsabilidades especiales. Es responsabilidad del líder del equipo de auditoría el organizar y dirigir la auditoria y la coordinación de la preparación de los puntos del informe de auditoría. El líder del equipo deberá asegurar que el equipo de auditoría está
preparado para llevar ésta, y que los procedimientos y los distintos puntos son realizados y reflejados en los informes de acuerdo con su alcance. 4. Entrada. El propósito y alcance de la auditoria. Criterios objetivos de la auditoria, tales como contratos, requerimientos, planes, especificaciones, procedimientos, líneas guía y estándares. Los elementos software y los procesos a auditar y cualquier antecedente pertinente. Información complementaria respecto a la organización responsable de los productos y los procesos a auditar (por ejemplo, organigramas de la organización). 5. Criterio de comienzo. La necesidad para que una auditoria se inicie debe ser por uno de los siguientes sucesos: 6. Procedimientos: 1. Se ha alcanzado un hito especial del proyecto. La auditoria es iniciada por planes previos (por ejemplo, el plan de aseguramiento de calidad, el plan de desarrollo del software). 2. Partes externas (por ejemplo, agencias reguladores o usuarios finales) demandando una auditoria en una fecha específica o en un hito de proyecto. Ésta puede ser por la realización de un requerimiento de un contrato o como prerrequisito a un acuerdo contractual. 3. Un elemento de la organización local (por ejemplo, el director del proyecto, la dirección funcional, ingeniería de sistemas, aseguramiento o control interno de la calidad) ha requerido la auditoria estableciendo una necesidad clara y específica. 4. Un hito especial del proyecto, fecha de calendario, u otro criterio ha sido alcanzado y dentro de la planificación de la organización de auditoría le corresponde la iniciación de una auditoria. * Planificación * Introducción. * Preparación. * Examen. * Informes. * Criterio de terminación * Salidas. * Adaptabilidad OBJETIVOS DE LAS AUDITORÍAS DE CALIDAD * Establecer el estado de un proyecto. * Verificar la capacidad de realizar o continuar un trabajo específico. * Verificar qué elementos aplicables del. programa o Plan de Aseguramiento de la Calidad han sido desarrollados y documentados. * Verificar la adherencia de esos elementos con el programa o Plan de Aseguramiento de la Calidad. PROCESOS DE CALIDAD * Calidad de los productos y servicios. * Plazo de entrega adecuado.
* Coste dentro de los límites fijados. PROCESOS DE CALIDAD Objetivos Principales principios que incluye AUDITORIA DE SISTEMAS DE CALIDAD DE SOFTWARE El propósito de la auditoría de un Sistema de Calidad, o un programa de evaluación de la calidad, es suministrar una valoración independiente sobre la conformidad de un plan de aseguramiento de la Calidad del Software. La auditoria deberá ser dirigida para asegurar que: a) Los productos software codificados (tal como un elemento software) ret1ejarán lo diseñado en la documentación. b) Los requerimientos de la revisión de aceptación y de pruebas prescritos por la documentación son adecuados para la aceptación de los productos software. c) Los datos de prueba cumplen con la especificación. d) Los productos software fueron sucesivamente probados y alcanzaron sus especificaciones. e) Los informes de pruebas son correctos y las discrepancias entre los resultados conseguidos y lo esperado han sido resueltas. f) La documentación del usuario cumple con los estándares tal como se ha especificado. g) Las actividades han sido llevadas de acuerdo con los requerimientos aplicables, los planes y el contrato. h) El coste y. el cronograma se ajustan a los planes establecidos. CONCLUSION: Las revisiones del software es un medio efectivo para descubrir errores y mejorar la calidad del software. El beneficio que traen es el descubrimiento temprano de errores y se verifica que el software satisface los requisitos del sistema. La revisión nos permite: • Detectar defectos en “etapas tempranas” del desarrollo de un producto de software • Reducir costos de corrección en etapas posteriores • Detectar funcionalidades faltantes o mal interpretadas • Bajar la tasa de los defectos que se introducen en el diseño de casos de prueba y en la codificación, por una mala interpretación de las especificaciones de requerimientos Por lo tanto estos procesos están definidos en el SQA y el objetivo del aseguramiento de la calidad es proporcionar a la administración los datos necesarios para tener la certeza de que el producto se está haciendo con calidad. http://www.buenastareas.com/ensayos/Seguridad-En-El-Software-Sqa/213734.html
