6.

Inspecciones
6.1 Introduccin
La finalidad de la inspeccin es detectar e identificar anomalas de producto de software. Este es un examen sistemtico entre iguales que: a) verifica que el producto de software cumple con sus especificaciones b) verifica que el producto de software satisface especificaciones y atributos de calidad c) verifica que el producto de software se ajusta a los procedimientos, normas, directrices, planes y reglamentos aplicables d) identifica las desviaciones de las normas y especificaciones e) recopila los datos de ingeniera del software (por ejemplo, datos de anomala y esfuerzo) (opcionales) f) utiliza los datos recopilados ingeniera de software para mejorar el propio proceso de inspeccin y su documentacin de apoyo (por ejemplo, listas de comprobacin) (opcional) Las Inspecciones consisten de tres a seis participantes. Una inspeccin es dirigida por un mediador imparcial que est entrenado en tcnicas de inspeccin. La determinacin de acciones correctivas o investigacin para una anomala es un elemento obligatorio de una inspeccin de software, aunque la resolucin no debe ocurrir en la reunin de la inspeccin. La recopilacin de datos con fines de anlisis y mejora de procedimientos de ingeniera del software (incluyendo todos los procedimientos de revisin) se recomienda pero no es un elemento obligatorio de las inspecciones de software. Ejemplos incluidos sujetos a inspeccin de productos de software, pero no se limitan a: a) b) c) d) e) f) g) h) i) especificacin de requisitos software Descripcin del diseo de software cdigo fuente documentacin de prueba de software documentacin para el usuario de software manual de mantenimiento procedimientos de construccin del sistema procedimientos de instalacin Notas de la versin

6.2 Responsabilidades
Para la inspeccin, se establecern las siguientes funciones: a) b) c) d) lder de inspeccin Documentador Lector inspector

Todos los participantes en la revisin son los inspectores. El autor no actuar como lder de la inspeccin y no debe actuar como lector o documentador. Otras funciones pueden ser compartidas entre los miembros del equipo. Los participantes pueden actuar en ms de una funcin. Personas que ocupan puestos de gestin sobre cualquier miembro del equipo de inspeccin no podrn participar en la inspeccin.

6.2.1 Lder de inspeccin

El lder de inspeccin se encargar de las tareas administrativas relativas a la inspeccin, ser responsable de planificacin y preparacin, como se describe en 6.5.2 y 6.5.4, velar por que la inspeccin se lleva a cabo de manera ordenada y cumpla sus objetivos, debe ser responsable de la recopilacin de datos de inspeccin (si procede) y expedir la inspeccin de salida como se describe en 6.7.

6.2.2 Documentador
El documentador deber documentar anomalas, elementos de accin, las decisiones y recomendaciones formuladas por el equipo de inspeccin. El documentador debe registrar datos de inspeccin requeridas para el anlisis de procesos. El lder de inspeccin puede ser el documentador.

6.2.3 Lector
El lector dar lugar el equipo de inspeccin a travs del producto de software de manera completa y lgica, interpretacin de las secciones de la obra (por ejemplo, generalmente parafraseando a grupos de lneas de 1-3) y destacando aspectos importantes.

6.2.4 Autor
El autor deber ser responsable que el producto de software cumpla sus criterios de ingreso de inspeccin, para contribuir a la inspeccin basada en una comprensin especial del producto de software y para llevar a cabo cualquier reanudacin requerida para hacer el producto de software cumplen su inspeccin salir criterios.

6.2.5 Inspector
Los inspectores debern identificar y describir anomalas en el producto de software. Los inspectores sern elegidos para representar a diferentes puntos de vista en la sesin (por ejemplo, patrocinador, requisitos, diseo, cdigo, seguridad, prueba, prueba independiente, gestin de proyectos, gestin de la calidad e Ingeniera de hardware). Slo los puntos pertinentes a la inspeccin del producto deben estar presentes. Algunos inspectores deberan asignarse temas de revisin especfica para garantizar la cobertura efectiva. Por ejemplo, un inspector puede centrarse en conformidad con una norma especfica o normas, otra sintaxis, otra para la coherencia global. Estas funciones deberan ser asignadas por el jefe de inspeccin cuando planificacin de la inspeccin, como se estipula en 6.5.2 (b).

6.3 Entrada
Entrada a la inspeccin incluir lo siguiente: a) una declaracin de objetivos para la inspeccin b) el producto de software para ser inspeccionado procedimiento de inspeccin c) documentadas d) formas de presentacin de informes de inspeccin lista de anomalas o problemas de e) corriente de entrada a la inspeccin tambin puede incluir lo siguiente: f) listas de inspeccin g) cualquier reglamento, normas, directrices, planes y procedimientos contra el cual el producto de software es para ser inspeccionado h) Especificaciones del producto hardware i) datos de rendimiento de hardware j) categoras de anomala (vase IEEE Std 1044-1993 [B7]) Material de referencia adicional se podr a disposicin de los responsables del producto de software cuando sean solicitados por el jefe de inspeccin

6.4 Criterios de ingreso 6.4.1 Autorizacin

Las inspecciones debern planificarse y documentarse con el correspondiente proyecto planificacin de documentos (por ejemplo, el general del proyecto, o verificacin y plan de validacin de software). Inspecciones adicionales pueden llevarse a cabo durante la adquisicin, suministro, desarrollo, operacin y mantenimiento del producto software a peticin de la administracin de proyectos, gestin de la calidad o el autor, segn los procedimientos locales. .

6.4.2 Condiciones previas

Se efectuar una inspeccin slo cuando se cumplan dos condiciones siguientes: a) se establece una declaracin de objetivos para la inspeccin. b) las entradas de la inspeccin requeridos estn disponibles. 6.4.3 Criterios de ingreso mnimo de una inspeccin no se realiz hasta que todos los eventos siguientes se han producido, a menos que exista una justificacin documentada, aceptada por la administracin, a excepcin de estas disposiciones: a) el producto de software que debe comprobarse es completado y conforme a las normas de proyecto para el contenido y formato. b) cualquier deteccin de errores herramientas automatizadas (como correctores ortogrficos y compiladores) necesarios para la inspeccin estn disponibles. c) previos hitos estn satisfechos como se indica en los documentos de planificacin correspondientes. d) requiere documentacin de apoyo est disponible. e) para una Re inspeccin, se resuelven todos los elementos indicados en la lista de anomalas que afectan el producto de software bajo inspeccin.

6.5 Procedimientos 6.5.1 Preparacin de gestin

Los administradores velarn por que la inspeccin se realice como requiere por las normas aplicables, los procedimientos y requisitos impuestos por ley, un contrato u otra poltica. Con este fin, los administradores debern: a) plan de tiempo y recursos necesarios para la inspeccin, incluyendo las funciones de apoyo, como en el estndar IEEE 1058 de 1987 u otras normas apropiadas b) proporcionar financiacin y facilidades necesarias para planificar, definir, ejecutar y administrar la inspeccin c) proporcionar capacitacin y orientacin sobre los procedimientos de inspeccin aplicables a un determinado proyecto d) asegurarse de que los miembros del equipo de revisin poseen niveles adecuados de experiencia y conocimientos suficientes para comprender el producto de software bajo inspeccin e) asegurar que se llevan a cabo inspecciones planificadas f) Ley sobre recomendaciones de equipo de inspeccin de manera oportuna

6.5.2 Planificacin la inspeccin

El autor deber montar los materiales de inspeccin para el lder de la inspeccin. El lder de la inspeccin ser responsable de las siguientes actividades: a) identificacin, con el apoyo de una gestin adecuada, de el equipo de inspeccin b) asignar responsabilidades especficas a los miembros del equipo de inspeccin c) programacin de la reunin y seleccionar el lugar de reunin d) distribuir materiales de inspeccin a los participantes y permitir suficiente tiempo para su preparacin e) establecer un calendario para la distribucin de material de inspeccin y el retorno de comentarios y envo de comentarios al autor para su disposicin Como parte del procedimiento de planificacin, el equipo de inspeccin deber determinar si las alternativas se discutirn en la reunin de la inspeccin. Las alternativas pueden ser discutidas en la reunin de la inspeccin, despus de una reunin por separado, o de izquierda a los autores del producto de software para resolver.

6.5.3 Resumen de los procedimientos de inspeccin

El autor debe presentar una visin general del producto de software para ser inspeccionado. Este resumen puede usarse para introducir a los inspectores al producto de software. El resumen podr asistir a otro personal de proyecto que podra beneficiarse de la presentacin. Las Funciones sern asignadas por el lder de la inspeccin. El lder de la inspeccin deber contestar preguntas acerca de las listas y las asignaciones de rol y debe presentar datos de la inspeccin, tales como la preparacin mnima y el nmero tpico de las anomalas encontradas en productos similares anteriores.

6.5.4 Preparacin
Cada miembro del equipo de inspeccin deber examinar el producto de software y otros insumos de revisin antes de la reunin de revisin. Anomalas detectadas durante este examen debern ser documentados y enviarse al responsable de la inspeccin. El lder de inspeccin debe clasificar anomalas para asegurarse de que encontr. El lder de inspeccin debe renviar las anomalas al autor del producto de software para la disposicin. El lder de la inspeccin o el lector deber especificar un orden adecuado en el que se examinarn el producto de software (como el flujo de datos secuenciales, jerrquicos, control de flujo, de abajo hacia arriba o de arriba hacia abajo). El lector se asegurar de que l o ella es capaz de presentar el producto de software en la reunin de la inspeccin.

6.5.5 Examinacin
La reunin de la inspeccin deber seguir esta agenda:

6.5.5.1 Introduccin de la reunin

El lder de la inspeccin deber introducir a los participantes y describir sus funciones. El lder de inspeccin deber indicar el propsito de la inspeccin y debe recordar a los inspectores a enfocar sus esfuerzos hacia la deteccin de anomalas, no la resolucin. El lder de inspeccin debe recordar a los inspectores para dirigir sus observaciones al lector y a comentar slo sobre el producto de software, no su autor. Los inspectores pueden plantear preguntas al autor en relacin con el producto de software. El lder de la inspeccin deber resolver preguntas procesales especiales planteadas por los inspectores.

6.5.5.2 Establecer preparacin

El lder de la inspeccin deber verificar que los inspectores se preparan para la inspeccin. El lder de la inspeccin deber reprogramar la reunin si los inspectores no estn preparados adecuadamente. El lder de inspeccin debe reunir los tiempos de preparacin individual y anote el total en la documentacin de inspeccin.

6.5.5.3 Revisar artculos en general

Anomalas refirindose al producto de software en general (y por lo tanto no atribuible a una instancia especfica o ubicacin) sern presentadas a los inspectores y grabados.

6.5.5.4 Revisar anomalas de producto y registro de software

El lector deber presentar el producto de software para el equipo de inspeccin. El equipo de inspeccin examinar el producto de software objetivamente y a fondo, y el lder de la inspeccin deber centrarse en esta parte de la reunin sobre la creacin de la lista de la anomala. En la grabadora entrar cada anomala, ubicacin, descripcin y clasificacin en la lista de la anomala. IEEE Estndar 1044-1993 [B7] puede utilizarse para clasificar anomalas. Durante este tiempo, el autor deber contestar preguntas especficas y contribuir a la deteccin de anomalas del autor especial comprensin del producto de software. Si hay desacuerdo acerca de una anomala, la anomala potencial deber registrarse y marcada para la resolucin final de la reunin.

6.5.5.5 Revise la lista de la anomala

Al final de la reunin de la inspeccin, el lder de inspeccin debe tener la lista de anomala revisada con el equipo para asegurar su integridad y exactitud. El lder de inspeccin debera dejar tiempo discutir cada anomala donde ocurri el desacuerdo. El lder de la inspeccin no debe permitir la discusin para centrarse en resolver la anomala, sino de aclarar lo que constituye la anomala.

6.5.5.6 Hacer salir la decisin

El propsito de la decisin de salir es traer un cierre sin ambigedades a la reunin de la inspeccin. La decisin de salida determinar si el producto de software cumple con los criterios de salida de la inspeccin y dispondrn cualquier reanudacin apropiado y verificacin. El equipo de inspeccin deber identificar

especficamente, la disposicin del producto de software como uno de los siguientes: a) aceptar con no o menor la reanudacion. El producto de software se acepta tal cual o con la reanudacin slo menor (por ejemplo, que no requerira ninguna verificacin adicional). b) aceptar con reanudacin. El producto de software es para ser aceptado despus el lder de la inspeccin o un miembro designado del equipo de inspeccin (distinto del autor) comprueba la reanudacin. c) re-inspeccin. Programar una nueva inspeccin para verificar la reanudacin. Como mnimo, una re-inspeccin examinar las reas de producto de software modificadas para resolver las anomalas identificadas en la ltima inspeccin, as como los efectos secundarios de esos cambios.

6.5.6 Reanudacin/para seguimiento

El lder de la inspeccin deber verificar que los elementos de accin asignados en la reunin estn cerrados.

6.6 Criterios de salida

Una inspeccin se considerar completa cuando se han realizado las actividades enumeradas en 6.5.5 y existe la salida descrita en 6,7.

6.7 Salida
La salida de la inspeccin deber ser documentada las evidencias que se identifiquen a) el proyecto inspeccionado b) los miembros del equipo de inspeccin c) la duracin de la inspeccin d) el producto de software inspeccionado e) el tamao de los materiales examinados (por ejemplo, el nmero de pginas de texto) f) entradas especficas para la inspeccin g) inspeccin de objetivos si se encontraron h) la lista de anomala que contiene cada ubicacin de la anomala, la descripcin y clasificacin i) el resumen de las anomalas de inspeccin, listando el nmero de anomalas identificadas por cada categora de anomala j) la disposicin del producto de software k) una estimacin del esfuerzo de reanudacin y fecha de finalizacin de esta.

El resultado de la inspeccin debe incluir la siguiente documentacin: l) el tiempo de preparacin total del equipo de inspeccin Aunque esta norma establece los requisitos mnimos para el contenido de las pruebas documentadas, se deja a los procedimientos locales para prescribir medios, requisitos de formato y contenido adicional.

6.8 Recomendaciones de coleccin de datos de

Las inspecciones deben proporcionar datos para el anlisis de la calidad del producto de software, la eficacia de la adquisicin, suministro, desarrollo, procesos de operacin, mantenimiento y la eficiencia de la inspeccin de s mismo. Con el fin de mantener la eficacia de las inspecciones, los datos no deben utilizarse para evaluar el desempeo de las personas. Para habilitar estos anlisis, anomalas que se identifican en una reunin de inspeccin deben clasificarse segn 6.8.1 mediante 6.8.3. Los datos de inspeccin debern contener la identificacin del producto de software, la fecha y hora de la inspeccin, el lder de la inspeccin, los tiempos de preparacin y de inspeccin, el volumen de los materiales inspeccionados y la disposicin del producto inspeccionado. La captura de esta informacin puede utilizarse para optimizar la orientacin local para las inspecciones. La gestin de datos de inspeccin requiere una capacidad para almacenar, entrar, acceder, actualizar, resumir y reportar anomalas categorizadas. La frecuencia y tipos de los informes de anlisis de inspeccin y su distribucin, quedan a procedimientos y normas locales.

6.8.1 Clasificacin de anomala

Las anomalas pueden ser clasificadas por tipo de tcnica, por ejemplo, IEEE Std 1044-1993 [B7].

6.8.2 Clases de anomala

Las clases de anomala proporcionan evidencia de inconformidad y pueden calificarse, por ejemplo, a) falta b) extra (superfluo)

c) ambiguo d) inconsistente e) mejora deseable f) no se ajusta a las normas g) propensa a riesgos, es decir, los hallazgos de revisin que, a pesar de que un elemento no fue mostrado a equivocarse "," el enfoque adoptado implica riesgos (y hay conocidos mtodos alternativos ms seguros). h) objetivamente incorrecto i) no aplicable (por ejemplo, a causa de las limitaciones del sistema o las limitaciones de tiempo) j) editorial

6.8.3 Rango de anomala

Las anomalas pueden ordenarse por el impacto potencial sobre el producto de software, por ejemplo, como: a) mayor. Anomalas que resultaran en fallos del producto de software o una salida observable de especificacin. b) menor. Anomalas que difiera de las especificaciones pertinentes pero no causar la falla del producto de software o una salida observable en el rendimiento.

6.9 Mejora
Los datos de la inspeccin deben ser analizadas peridicamente con el fin de mejorar la inspeccin propia, y las actividades de software usado para producir productos de software. Con frecuencia pueden incluir anomalas que ocurren en la inspeccin de las listas de comprobacin o asignaciones de funciones. Las listas de verificacin propios deben inspeccionarse regularmente para preguntas superfluas o engaosas. Los tiempos de preparacin, tiempos de reunin y nmero de participantes deben ser analizadas para determinar las conexiones entre tasa de preparacin, tipo de reunin, nmero y gravedad de anomalas encontradas. Debe existir un papel de "jefe inspector". El inspector jefe acta como el dueo de la inspeccin y se encarga de recoger y alimentar datos acerca de la inspeccin. Este inspector jefe debe ser responsable para el seguimiento de propuestas sobre la inspeccin de s mismo.

7. Manual 7.1 Introduccin

El propsito de un recorrido sistemtico es evaluar un producto de software. Un manual podr celebrarse con el propsito de educar a una audiencia sobre un producto de software. Los objetivos principales son: a) encontrar anomalas b) mejorar el producto de software c) considerar implementaciones alternativas d) evaluar la conformidad con las normas y especificaciones Otros objetivos importantes de la funcin de recorrido incluyen intercambio de tcnicas, variaciones de estilo y la capacitacin de los participantes. Un manual puede sealar varias deficiencias (por ejemplo, eficiencia, legibilidad, problemas en el producto de software, problemas de modularidad en el diseo o cdigo o especificaciones no comprobables). Ejemplos de productos de software sujeto a manuales incluyen, pero no se limitan a: a) especificacin de requisitos software b) Descripcin del diseo de software c) cdigo fuente d) documentacin de prueba de software e) documentacin para el usuario software f) manual de mantenimiento g) procedimientos de construccin de del sistema h) procedimientos de instalacin i) Notas de la versin

7.2 Responsabilidades
Para el manual, se establecern las siguientes funciones: a) lder de tutorial b) grabadora c) autor d) miembro del equipo

Una revisin es considerada un recorrido sistemtico, deber montarse un equipo de al menos dos miembros. Los roles pueden ser compartidas entre los miembros del equipo. El lder del manual o el autor puede servir como la grabadora. El lder de recorrido puede ser el autor. Personas que ocupan puestos de gestin sobre cualquier miembro del equipo de tutorial no participarn en el recorrido.

7.2.1 Lder de tutorial

El lder del manual realizar el recorrido, deber manejar las tareas administrativas relacionadas con el tutorial (como distribuir documentos y organizar la reunin) y velar por que el manual se lleva a cabo de manera ordenada. El lder del manual preparar la declaracin de objetivos para guiar al equipo a travs de la funcin de recorrido. El lder del manual velarn por que el equipo llega a una decisin o identificados de accin para cada elemento de discusin y expedir el tutorial de salida como se describe en 7.7.

7.2.2 Registrador
El registrador anotar todas las decisiones e identifica acciones que surjan durante la reunin de tutorial. Adems, el registrador debe tener en cuenta todos los comentarios hechos durante el recorrido que pertenecen a la anomala, cuestiones de estilo, omisiones, contradicciones, sugerencias de mejora o enfoques alternativos.

7.2.3 Autor
El autor debe presentar el producto de software en el manual.

7.3 Entrada
Entrada para el recorrido debe incluir lo siguiente: a) una declaracin de objetivos para el manual b) el producto de software est examinando c) normas que estn en vigor para la adquisicin, suministro, desarrollo, operacin y/o mantenimiento del producto software de entrada para el manual tambin pueden incluir lo siguiente: d) cualquiera de los reglamentos, normas, directrices, planes y procedimientos contra el cual el producto de software debe ser inspeccionado e) categoras de anomala

7.4 Criterios de ingreso 7.4.1 Autorizacin

La necesidad de realizar manuales se establecer documentacin adecuada de planificacin en el proyecto. Los manuales adicionales pueden llevarse a cabo durante la adquisicin, suministro, desarrollo, operacin y mantenimiento del producto software a peticin de la administracin de proyectos, gestin de la calidad o el autor, segn los procedimientos locales.

7.4.2 Condiciones previas

Se efectuar un recorrido slo cuando se cumplan dos condiciones siguientes: a) se establece una declaracin de objetivos para la revisin por el personal de administracin para quienes la lleven acabo la revisin. b) la revisin de entradas deben estar disponibles.

7.5 Procedimientos 7.5.1 Preparacin de gestin

Los administradores velarn por que el recorrido se realice como es requerido por las normas aplicables, los procedimientos y requisitos impuestos por ley, un contrato u otra poltica. Con este fin, los administradores debern: a) plan de tiempo y recursos requeridos para tutoriales, incluyendo las funciones de apoyo, como en IEEE Std 1058.1-1987 [B8] u otras normas apropiadas b) proporcionar financiacin y facilidades necesarias para planificar, definir, ejecutar y administrar el manual. c) proporcionar capacitacin y orientacin sobre los procedimientos de tutorial aplicables a un determinado proyecto d) asegurarse de que los miembros del equipo de tutorial poseen niveles adecuados de experiencia y conocimientos suficientes para comprender el producto de software e) asegurar que se llevan a cabo los tutoriales planificadas f) recomendaciones del equipo de manual de manera oportuna

7.5.2 Planificacin el tutorial

El lder del manual ser responsable de las siguientes actividades: a) identificar el equipo del manual b) programacin de la reunin y seleccionar el lugar de reunin

c) distribuir insumos necesarios a los participantes y dar suficiente tiempo para su preparacin

7.5.3 Resumen
Una presentacin del resumen debe hacerse por el autor como parte de la sesin del manual.

7.5.4 Preparacin
El lder del manual deber distribuir el producto de software y convocar una reunin de manual. Los miembros del equipo debern prepararse para la reunin por el producto de software a examinar y preparar una lista de elementos para la discusin en la reunin. Estos elementos deben dividirse en dos categoras: general y especfica. Los artculos generales que se aplican a la totalidad del producto; elementos especficos se aplican a una parte de ella. Cada miembro del equipo del manual examinar el producto de software y otros insumos de revisin antes de la reunin de revisin. Anomalas detectadas durante este examen debern ser documentados y al lder del tutorial. El lder de tutorial debe clasificar anomalas para garantizar que el tiempo de la reunin del manual se utiliza eficazmente. El lder del manual debe renviar las anomalas al autor del producto de software para su disposicin. El lder del manual deber especificar una orden adecuada en el que se examinarn el producto de software (como el flujo de datos secuenciales, jerrquicos, control de flujo, de abajo hacia arriba o de arriba hacia abajo).

7.5.5 Examen
El lder del manual deber introducir a los participantes y describir sus funciones. El lder de manual indicar el propsito del manual y debe recordar a los miembros del equipo a centrar sus esfuerzos hacia la deteccin de anomalas, la resolucin no. El lder del manual debe recordar a los miembros del equipo a comentar slo el producto de software, no su autor. Los miembros del equipo pueden plantear preguntas a la autora en relacin con el producto de software. El lder de manual resolver las cuestiones de procedimiento especiales planteadas por los miembros del equipo. El autor presentar una visin general del producto de software que se examina. Esto es seguido por un debate general durante la cual el equipo de miembros debe plantear sus artculos en general. Despus del debate general, el autor presenta en serie el producto de software en detalle (de ah el "Manual" de nombre). Los miembros del equipo deben levantar sus elementos especficos cuando se lleva acabo la presentacin por parte del autor. Nuevos artculos pueden elevarse durante la reunin.

El lder del manual coordina la discusin y guas de la reunin a una decisin o identificada accin sobre cada tema. El registrador de notas de todas las recomendaciones y acciones requeridas. Durante el encuentro del manual: a) el lder autor del manual debe hacer una presentacin del producto de software bajo examen b) el lder del manual coordinarn una discusin de las anomalas generales de preocupacin c) el lder autor del manual deber presentar el producto de software, describiendo cada parte de ella d) los miembros del equipo levantarn anomalas especficas conforme el autor llega a la parte del producto de software que se refieren. e) el registrador anotar las recomendaciones y acciones que surjan de la discusin sobre cada anomala despus de la reunin del manual, el lder del manual expedir la salida del manual detallando las anomalas, decisiones, acciones y otra informacin de inters. Requisitos de contenido mnimos para la salida del manual se proporcionan en 7.7.

7.5.6 Reanudacin/para seguimiento

El lder del manual deber verificar que los elementos de accin asignados en la reunin estn cercanos