Presentación de Avance de Auditoria

Adjunto el link de las diapositivas
Presentación

Revisiones e Inspecciones de software

Una inspección es una de las clases mas comunes de prácticas de la revisión encontradas en proyectos del software. La meta de la inspección está para que todos los inspectores alcancen consenso en un producto del trabajo y lo aprueben para el uso en el proyecto. Los productos comúnmente examinados del trabajo incluyen especificaciones de requisitos del software yplanes de prueba. En una inspección, un producto del trabajo se selecciona para la revisión y recolectan a un equipo para una inspección que se reúne para repasar el producto del trabajo. Un asesor se elige para moderar la reunión. Cada inspector se prepara para la reunión leyendo el producto del trabajo y observando cada defecto. La meta de la inspección es identificar defectos. En una inspección, un defecto es cualquier parte del producto del trabajo que guardará a inspector de aprobarla. Por ejemplo, si el equipo está examinando una especificación de requisitos del software, cada defecto será texto en el documento con el cual un inspector discrepa.

El proceso

El proceso de la inspección fue desarrollado por Michael Fagan en los mediados de los años setenta y se ha ampliado y se ha modificado más adelante.

El proceso debe tener criterios de una entrada que se determina si el proceso de la inspección es listo comenzar. Esto evita que los productos inacabados del trabajo incorporen el proceso de la inspección. Deletrear-se han comprobado los criterios de la entrada pudieron ser una lista de comprobación incluyendo artículos tales como “el documento”.

Las etapas en el proceso de las inspecciones son: Reunión del planeamiento, de la descripción, reunión de la preparación, de la inspección, reanudación y carta recordativa. La reunión de la preparación, de la inspección y las etapas de la reanudación pudieron ser iteradas.

• Planeamiento: La inspección es planeada por el asesor.
• Reunión de la descripción: El autor describe el fondo del producto del trabajo.
• Preparación: Cada inspector examina el producto del trabajo para identificar defectos posibles.
• Reunión de la inspección: Durante esta reunión el lector lee a través del producto del trabajo, parte por la parte y los inspectores precisan los defectos para cada partición.
• Reanudación: El autor hace changs al producto del trabajo según los planes de acción de la reunión de la inspección.
• Carta recordativa: Los cambios del autor se comprueban para cerciorarse de que todo esté correcto.

El proceso es terminado por el asesor cuando satisface algunos criterios predefinidos de la salida.

Papeles de la inspección

Durante una inspección se utilizan los papeles siguientes.

• Autor: La persona que creó el producto del trabajo que era examinado.
• Asesor: Éste es el líder de la inspección. El asesor planea la inspección y la coordina.
• Lector: La lectura a través de los documentos, un artículo de la persona a la vez. Los otros inspectores entonces precisan defectos.
• Registrador: La persona que documenta los defectos que se encuentran durante la inspección.

Tipos relacionados de la inspección

Revisión de código

A revisión de código puede ser hecho como clase especial de inspección en la cual el equipo examine una muestra del código y fije cualquier defecto en él. En una revisión de código, un defecto es un bloque del código que no pone correctamente sus requisitos en ejecución, que no funciona como el programador pensó, o que no es incorrecto pero podría ser mejorado (por ejemplo, podría ser hecha más legible o su funcionamiento se podría mejorar). Además de los equipos que ayudan encuentre y fije los insectos, las revisiones de código son útiles para ambos programadores del cruz-entrenamiento en el código que es repasado y para ayudar los reveladores menores aprenden nuevas técnicas de programación.

Revisiones de par

Las revisiones de par se consideran una mejor-práctica de la industria para detectar defectos del software temprano y aprender sobre los artefactos del software. Las revisiones de par se componen de walkthroughs del software y las inspecciones del software y son integrales a las actividades de la ingeniería del producto de software. Una colección de conocimiento, de habilidades, y de comportamientos coordinados facilita la práctica mejor de las revisiones de par. Los elementos de las revisiones de par incluyen el proceso estructurado de la revisión, estándar de las listas de comprobación del producto de la excelencia, el papeles definida de participantes, y las formas y los informes.

Las inspecciones del software son la forma más rigurosa de revisiones de par y utilizan completamente estos elementos en la detección de defectos. Los walkthroughs del software dibujan selectivamente sobre los elementos en asistir al productor para obtener la comprensión más profunda de un artefacto y alcanzar un consenso entre participantes. Los resultados medidos revelan que las revisiones de par producen una vuelta en la inversión atractiva obtenida con aprender acelerado y la detección temprana del defecto. Para los mejores resultados, las revisiones de par se ruedan hacia fuera dentro de una organización a través de un programa definido de elaborar una política y un procedimiento, de médicos de entrenamiento y de encargados, definiendo medidas y poblando una estructura de la base de datos, y sosteniendo la infraestructura del rodillo hacia fuera.

PPT de trazabilidad

A continuación la presentacion realizada el martes 26 de octubre sobre trazabilidad:

Presentacion de trazabilidad

Walkthrough del software

En tecnología de dotación lógica, a walkthrough o caminar-por es una forma de revisión de par del software “en cuál pregunta a preguntas y hace un diseñador o los miembros de los plomos del programador del equipo del desarrollo y de otros partidos interesados a través de un producto de software, y los participantes comentarios sobre errores posibles, la violación de estándares del desarrollo, y otros problemas”^[1].

El “producto de software” refiere normalmente a una cierta clase de documento técnico. Según lo indicado por la definición de IEEE, esto pudo ser un documento o un programa del diseño del software código de fuente, pero utilice los casos, proceso del negocio definiciones, pruebe el caso las especificaciones, y una variedad de la otra documentación técnica se pueden también caminar a través.

Un walkthrough diferencia de revisiones técnicas del software en su franqueza de la estructura y de su objetivo del conocimiento. Diferencia de la inspección del software en su capacidad de sugerir alteraciones directas al producto repasado, su carencia de un foco directo en el entrenamiento y la mejora de proceso, y su omisión del proceso y de la medida del producto.

Contenido 1 Objetivos y participantes 2 Proceso 3 Vea también 4 Referencias

Objetivos y participantes

Un walkthrough tiene generalmente uno o dos objetivos generales: para ganar la regeneración sobre la calidad o el contenido técnica del documento; y/o para familiarizar a las audiencias con el contenido.

Un walkthrough es organizado y dirigido normalmente por el autor del documento técnico. Cualquier combinación del personal interesado o técnico cualificado (de dentro o fuera del proyecto) se puede incluir como se parece apropiado.

IEEE 1028^[1] recomienda tres papeles del especialista en un walkthrough:

• Autor, que presenta el producto de software de la manera paso a paso en caminar-por la reunión, y es probablemente responsable de terminar la mayoría de los artículos de acción;
• Líder de Walkthrough, que conduce el walkthrough, maneja tareas administrativas, y asegura conducta ordenada (y que es a menudo el autor); y
• Registrador, que observa todos anomalías (defectos potenciales), decisiones, y artículos de acción identificados durante la reunión del walkthrough.

Proceso

Un walkthrough puede ser absolutamente informal, o puede seguir el proceso detallado en IEEE 1028 y contorneado en el artículo encendido revisiones del software.