IEEE Std 1012™-2004(Revisión del

Estándar IEEE 1012-1998)

1012TM

IEEE Estándares para SoftwareV e r i f i c a c i ó n y V a l i d a c i ó n

IEEE Sociedad de Computación

Patrocinado porComité de Estándares en Ingeniería de Software (Software Engineering Standards Committee)

8 de Junio de 2005Impresión: SH95308

PDF: SS953083 Park Avenue, New York, NY10016-5997, USA

Reconocida como un Instituto Nacional Americano de Estándares (ANSI) IEEE Std 1012™-2004

(Revisión delEstándar IEEE 1012-1998)

IEEE Estándar para Software

Verificación y Validación

Patrocinado por

Comité de Estándares de Ingeniería de Software (Software Engineering StandardsCommittee)

de la

Sociedad de Cómputo de la IEEE Aprobada el 12 de Abril de 2005Instituto Nacional Americano de Estándares (American National Standards Institute)Aprobado el 8 de Diciembre de 2004IEEE-SA Standards Borrad

Resumen:

El proceso de verificación y validación de software determina si el desarrollo de productos de determinada actividad conforman a los requerimientos de esa actividad y si el software satisface los usos previstos y las necesidades del usuario. Los requerimientos del proceso del ciclo de vida de la V&V del software son especificados por diferentes niveles de integridad del software. El alcance de los procesos de V&V se encuentra alrededor de sistemas basados den software, software de computadora, hardware, e interfaces. Este estándar está desarrollado para aplicaciones de software, mantenimiento, o reuso (heredados, comerciales de- estante (COTS), artículos no desarrollados). El término software incluye también firmware (programa oficial del fabricante), microcódigo, y documentación. Los procesos de V&V del software incluyen análisis, evaluación, revisión, inspección, valoración, y pruebas de productos de software.Palabras clave:Niveles de integridad del software, ciclo de vida del software, V&V, validación, verificación.

The Institute of Electrical and Electronics Engineers, Inc.3 Park Avenue, New York, NY 10016-5997, USACopyright © 2005 by the Institute of Electrical and Electronics Engineers, Inc.All rights reserved. Published 8 June 2005. Printed in the United States of America.IEEE is a registered trademark in the U.S. Patent & Trademark Office, owned by the Institute of Electrical and ElectronicsEngineers, Incorporated.Print: ISBN 0-7381-4641-2 SH95308PDF: ISBN 0-7381-4642-0 SS95308No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the priorwritten permission of the publisher.

Los documentos de los Estándares IEEE son desarrollados dentro de las Sociedades IEEE y los Comités Coordinadotes de Estándares de la Asociación de Estándares IEEE (IEEE-SA) Consejo de Estándares. La IEEE desarrolla estos estándares a través del consenso de desarrollo de procesos, aprobado por el ANSI, el cual brinda conjuntos de voluntarios representando variedad de puntos de vista e intereses para alcanzar el producto final. Los voluntarios no son necesariamente miembros del instituto y lo hacen sin pago alguno. Mientras la IEEE administra los procesos y establece reglas para promover la justicia en el proceso de desarrollo del consenso, la IEEE no evalúa independientemente, prueba, o verifica la exactitud de ninguna de las informaciones contenidas en estos estándares.El uso de un Estándar IEEE es completamente voluntario. La IEEE renuncia a la responsabilidad por cualquier falta personal, propiedad u otro daño, de ninguna naturaleza en absoluto, ya sea especial, indirecta, consecuencial, o compensatoria, resultante directa o indirecta de la publicación, uso de, o confianza sobre este, o algún otro documento de los Estándares de la IEEE.La IEEE no garantiza o representa la exactitud del contenido o del material contenido aquí, y renuncia expresamente a cualquier a garantía tácita o explícita, incluyendo cualquier garantía explícita de comerciabilidad o idoneidad de un

propósito específico, o que el uso del material contenido aquí esté libre de violación de patentes. Los documentos de los Estándares IEEE son suministrados “COMO ESTE”.La existencia de un estándar IEEE no implica que no hay otras formas de producir, probar, medir, comprar, comerciar o proveer bienes y servicios relacionados con el campo del estándar IEEE. Más aun, el punto de vista expresado en el momento en que el estándar es aprobado y clasificado es sujeto de cambio a través de los últimos desarrollos y de comentarios recibidos por parte de los usuarios del estándar. Cada estándar IEEE esta sujeto a revisión o confirmación por lo menos cada 5 anos. Cuando un documento es más Viejo que este periodo y no ha sido confirmado es de suponer que su contenido, aunque tenga algún valor, no refleja completamente los últimos avances. Los usuarios son prevenidos para que revisen si es que tienen la última actualización de cualquier estándar IEEE.Al publicar y hacer disponible este documento, el IEEE no sugiere ni aplica servicios profesionales o de otro tipo para, o de parte de, cualquier persona o entidad. El IEEE tampoco esta obligado a hacerlo por ninguna persona o entidad. Cualquier persona que utilice este u otro documento del IEEE debe basarse en las recomendaciones de un profesional competente con la finalidad de llevar a cabo un cuidado razonable bajo cualquier circunstancia. Interpretaciones: Ocasionalmente algunas preguntas pueden surgir con respecto del significado de porciones de los estándares ya que relacionan aplicaciones específicas. Cuando esto ocurre y se requiere al IEEE, el instituto actuará para preparar respuestas apropiadas. Dado que el IEEE representa un consenso de intereses relacionados, es importante asegurar que cualquier interpretación también sea consensuada por los interesados. Por esta razón, el IEEE, los miembros de sus sociedades y los Comités de Coordinación de Estándares, no son capaces de proporcionar una respuesta inmediata cuando un pedimento de interpretación es interpuesto, excepto en aquellos casos en los que el asunto ha recibido consideración formal. En conferencias, simposio, seminarios o cursos educativos, el individuo que presente información sobre el IEEE deberá dejar claro que su punto de vista es individual y no una posición, explicación o interpretación formal del IEEE.Los comentarios para las revisiones de los estándares del IEEE son bienvenidos por parte de cualquier interesado, independientemente de su afiliación con el IEEE. Las sugerencias para los cambios en documentos deberán estar en la forma de cambio de texto propuesto, junto con los comentarios que lo apoyan. Los comentarios a los estándares deberán ser dirigidos a:Secretary, IEEE-SA Standards Board445 Hoes LanePiscataway, NJ 08854USANOTA: Se debe prestar atención a la posibilidad de que la implementación de este estándar puede ser sujeto de asuntos relacionados con derechos de patente. La publicación de este estándar no implica posición alguna con respecto de la existencia o validez de cualquier derecho de patente relacionados. El IEEE no será responsable por la identificación de patentes cuya licencia pueda ser requerida por un estándar IEEE, o por llevar a cabo investigaciones de validez o materia legal para aquellas patentes requeridas por el instituto.

Para fotocopiar porciones de cualquier estándar individual para uso interno o personal se otorgara siempre y cuando el Instituto de Ingenieros Eléctricos y Electrónicos, Inc. demuestren que el cargo apropiado ha sido cubierto en el Centro de Permisos de Derecho de Autor. Para programar el pago de cuota de licencia, por favor contacte al Centro de Permisos de Derecho de Autor, Servicios al Cliente, 222 Rosewood Drive, Danvers, Maryland 01923 USA… Permisos para fotocopiar estándares individuales para uso educativo también pueden ser obtenidos en el mismo Centro.Introducción

Esta introducción no es parte de los estándares 1012-2004, Estándares IEEE para Verificación y Validación de SW. La verificación y validación (V&V) de software es una disciplina técnica de los sistemas de ingeniería. El propósito del software de verificación y validación es ayudar a la organización desarrolladora a construir calidad dentro del software durante el ciclo de vida del software. El proceso de V&V provee un objetivo de valoración de productos y procesos de software a través del ciclo de vida del software. Esta valoración demuestra si los requerimientos del software y del sistema son correctos, completos, consistentes, precisos, y testeable.Los procesos de V&V del software determinan si los productos desarrollados de una actividad dada conforman los requerimientos de dicha actividad y si el software satisface su objetivo y las necesidades del usuario. La resolución incluye valoración, análisis, evaluación, revisión, inspección y pruebas del los productos y procesos de software. La V&V de software se efectúa paralelamente con el desarrollo de software, no al concluir el esfuerzo de desarrollo. La V&V del software es una extensión de la gestión del programa y los sistemas de ingeniería que emplean una metodología rigurosa para identificar los datos del objetivo y conclusiones para proveer una retroalimentación acerca de la calidad del software, rendimiento, y el itinerario a la organización del desarrollo. Esta retroalimentación consiste

en la resolución de anomalías, mejoras al desempeño, y mejoras a la calidad no solo para las condiciones de operación esperadas, sino también a través del espectro completo del sistema y de sus interfaces. Los prontos resultados de la retroalimentación permiten a la organización de desarrollo modificar sus productos de software de una manera oportuna y de tal modo reducir los impactos totales del proyecto y los itinerarios previstos. Sin un acercamiento proactivo, las anomalías y los cambios de sistema de software asociados típicamente se retrasan en el itinerario programado, dando por resultado mayores costos del programa e itinerarios retrasados. IEEE Std 1012-2004 es un estándar de proceso que define los procesos de V&V en términos de actividades específicas y tareas relacionadas. El estándar también define el contenido del plan de V&V de software (SVVP), incluyendo un formato del ejemplo.

Esta versión del estándar contiene cambios de menor importancia al Estándar IEEE 1012-1998. Lo que sigue es un resumen:

a) Se revisó la cláusula 1 para adecuarla con el estilo de IEEE y1) Se movió la descripción de proceso de V&V del 1.3 al 1.12) Se expandió 1.2 para discutir la importancia del rendimiento del software de V&V desde una perspectiva del sistema--software y su interacción con el sistema del cual es parte.b) Se movió la figura 3 en la definición de esfuerzo de V&V (ver 3.1.37) sin figura de referencia.c) Se aclaró al concepto de integridad de software y selección de niveles de integridad del software de la cláusula 4.d) Se revisó que la cláusula 6 contuviera toda la documentación normativa de requerimientos (ver 6.1) que estaban en la cláusula 7.e) Se revisó la cláusula 7 para consolidar IEEE 1012A.-1998 [B6] en la revisión de este estándarf) Se revisó la tabla uno de la siguiente manera:1) Se añadió “análisis de seguridad” a las tareas de V&V que lo requirieran.2) Se reformateó tareas de pruebas para únicamente identificar los requerimientos para cada tipo de prueba – no fueron hechos cambios normativos a las tareas de pruebas.3) Se añadió una subtarea al alcance de la V&V en el apoyo a la adquisición V&V para determinar la extensión de la V&V en software de reuso. 4) Se corrigieron errores editoriales previos.g) Se añadieron mapas de las tareas del IEEE 1012 a los Grupos de Procesos de Ingeniería CMMI en el Anexo A.h) Se añadió una definición de V&V integrada independiente al Anexo Ci) Se aclaró el tratamiento de software de reuso en el Anexo Dj) Se añadieron medidas de ejemplo al Anexo Ek) Se borró el Anexo I y se movieron las definiciones al 3.1

Los siguientes conceptos clave son enfatizados en este estándar:

— Niveles de Integridad del Software.Define 4 niveles de integridad del software que describen la importancia del software, variando de la alta integridad a la integridad baja, para el usuario— Tareas mínimas de V&V para cada nivel de la integridad de software.Define el mínimo de tareas de V&V requeridas para cada uno de los 4 niveles de integridad. Incluye una tabla de tareas de V&V opcionales para adaptar el esfuerzo de V&V a las de necesidades del proyecto y a las características de la aplicación específicas.

— Intensidad y rigor aplicados a las tareas de V&V.

Introduce la noción de que la intensidad y el rigor aplicados a las tareas de V&V varían de acuerdo a los niveles de integridad del software. Los niveles más altos de integridad del software requieres la aplicación de gran intensidad y rigor para las tareas de V&V. La intensidad incluye los más grandes alcances del análisis a través de todos los sistemas normales o anormales en condiciones de operación. El rigor incluye técnicas más formales y procedimientos de registro.

— Criterios detallados para las tareas de V&V.

Define criterios especiales para cada tarea de V&V, incluyendo criterios mínimos para corrección, consistencia, completitud, exactitud, legibilidad, y pruebas. Las descripciones de las tareas de V&V incluyen una lista de tareas de entradas y salidas requeridas.— Puntos de vista del Sistema.

Incluye tareas mínimas de V&V a los temas para las direcciones del sistema. Estas tareas incluyen análisis de riesgos, análisis de seguridad, análisis de peligros, valoración de migración, y valoración de jubilación.Las ediciones específicas del sistema están contenidas individualmente en los criterios la tarea de V&V. — Conformidad a los estándares internacionales de la IEEE .Define los procesos de V&V que conformarn los estándares del proceso de ciclo de vida tal como el estándar ISO/IEC 12207:1995 [B13], Estándar IEEE 1074 -1997 [B10], y el Estándar IEEE/EIA 12207.0 -1996 [B12], como también la familia entera de los Estándares IEEE de Ingeniería de Software.Este estándar direcciona completamente los procesos del ciclo de vida del software, incluyendo adquisición, abastecimiento, desarrollo, operación, y mantenimiento. Este estándar es compatible con todos los modelos del ciclo de vida; sin embargo, no todos los modelos de los procesos del ciclo de vida están descritos en este estándar.

Aviso a los usuarios.

ErrataPara Erratas de este o de cualquier otro estándar pude acceder a la siguiente URL: http://standards.ieee.org/reading/ieee/updates/errata/index.html. Se anima a los usuarios a que prueben este URL para saber si hay erratas periódicamente.

Interpretaciones Las interpretaciones actuales se pueden alcanzar en el URL siguiente:http://standards.ieee.org/reading/ieee/interp/index.html.

PatentesAtención: Existe la posibilidad de que para la posible implementación de este estándar pude requerirse el uso de temas cubiertos por derechos de patente. Por la publicación de este estándar, no se toma ninguna posición con respecto a la existencia o validez de ningún derecho de patente en conexión con eso. La IEEE no será la responsable de identificar las patentes o los usos de patente para los cuales una licencia será requerida para implementar un estándar de IEEE o para investigaciones que conducen en la validez legal o al alcance de esas patentes que hayan traído hasta esta advertencia.

ParticipantesPara el momento en que este estándar fue terminado, el Grupo de Trabajo de la Verificación y Validación del Software tenía a los siguientes miembros:

Roger U. Fujii, PresidenteDolores R. Wallace, Vicepresidente

David H. Daniel, SecretarioJohn W. BradburyPaul R. CrollH. Taz DaughtreyHarpal S. DhamaMichael EdwardsUma D. Ferrell

Eva FreundRon K. GreenthalerLisa A. JensenRex KiddNorm LeblancKevin B. Morgan

Steven M. RaqueSubrato SensharmaNancy E. SunderlandRichard J. StevensonGina B. ToMichael E. Waterman

Los siguientes miembros del comité de la votación individual que votaron sobre este estándar. Los votantes pudieron haber votado por la aprobación, la desaprobación, o la abstención.

Satish K. AggarwalMichael BaldwinBakul BanerjeeMario BarbacciEdward BartlettJuris BorzovsWesley BowersJohn W. Bradbury

Daniel BrosnanNissen BursteinJoseph ButchkoGarry ChapmanKeith ChowAntonio M. CicuTodd CooperPaul R. Croll

Surin DurejaDavid DanielH. Taz DaughtreyHarpal S. DhamaDr. Guru Dutt DhingraScott DuncanDr. Sourav DuttaClint Early, Jr.

Christof EbertMichael EdwardsAmir El-SheikhGary EngmannCaroline EvansWilliam EventoffJohn FendrichYaacov FensterUma D. FerrellRonald FlueggeRabiz FodaEva FreundSamuel FryerRoger FujiiJuan Garbajosa SopeñaJean-Denis GorinLewis GrayRon K. GreenthalerBritton GrimMichael GrimleyRandall Groves

Jon HagarPeter HungMark HeinrichJohn HorchDavid HorvathPeeya IwagoshiJoseph JancauskasWilliam JunkPiotr KarockiDwayne KnirkSubrahmanyam KommuRobert KonnikThomas M. KuriharaSusan LandCarol LongYuhai MaG MichelJames MooreDennis NickleCraig NoahRoger Parker

Charles RoslundJames RuggieriHelmut SandmayrRobert J. SchaafHans SchaeferDavid SchultzJames SivakMike SmithLuca SpotornoRichard J. StevensonGraeme StewartBooker ThomasGina B. ToT.H. TseJohn WacloRichard WalkerMichael E. WatermanOren YuenJanusz ZalewskiLi Zhang

Cuando el conjunto de Estándares IEEE-SA aprobó este estándar el 8 de Diciembre del 2004, se tenían a los siguientes miembros:

Don Wright, PresidenteSteve M. Mills, Vicepresidente

Judith Gorman, SecretariaChuck AdamsStephen BergerMark D. BowmanJoseph A. BruderBob DavisRoberto de Marca BoissonJulian Forster*Arnold M. GreenspanMark S. Halpin

Raymond HapemanRichard J. HollemanRichard H. HulettLowell G. JohnsonJoseph L. Koepfinger*Hermann KochThomas J. McGeanDaleep C. MohlaPaul Nikolich

T. W. OlsenRonald C. PetersenGary S. RobinsonFrank StoneMalcolm V. ThadenDoug ToppingJoe D. Watson

*Miembros Emeritos

También se incluyen los siguientes no – votantes del conjunto de estándares IEEE-SA:

Satish K. Aggarwal, Representante NRCRichard DeBlasio, Representante DOE

Alan Cookson, Representante NIST

Michael D. Fisher.Editor de Proyectos de los Estándares

Contenido1. Visión General……….....................................................................................................................11.1Alcance..........................................................................................................................................11.2 Propósito.......................................................................................................................................21.3 Campo de Aplicación ...................................................................................................................2

1.4 Objetivos de V&V .........................................................................................................................31.5 Organización del estándar........................................................................................................ ...41.6 Audiencia .....................................................................................................................................41.7 Conformidad..................................................................................................................................51.8 Renuncia de Responsabilidades….............................................................................................. 51.9 Limitaciones ................................................................................................................................ 52. Referencias.................................................................................................................................... 53. Definiciones, abreviaturas, y acrónimos........................................................................................ 53.1 Definiciones..................................................................................................................................53.2 Abreviaturas y acrónimos…..................................................................................................... ..104. Niveles de Integridad del Software........................................................................................... ... 115. Procesos de V&V del Software................................................................................................. ... 125.1 Proceso: Gestión ........................................................................................................................ 135.2 Proceso: Adquisición .................................................................................................................. 145.3 Proceso: Suministro.......................... .......................................................................................... 145.4 Proceso: Desarrollo….................................................................................................................. 155.5 Proceso: Operación ..................................................................................................................... 185.6 Proceso: Mantenimiento............................................................................................................... 186. Requisitos de la divulgación del software V&V, administrativos, y de la documentación ……...... 196.1 Requerimientos de la divulgación de la V&V del software........................................................... 196.2 Requerimientos de la administración de la V&V........................................................................... 206.3 Requerimientos de la documentación de la V&V ……………....................................................... 217. Plan fuera de línea de la V&V del Software V&V .......................................................................... 217.1 SVVP sección 1: Propósito ........... .............................................................................................. 237.2 SVVP sección 2: Documentos Referenciados .......................... .................................................. 237.3 SVVP sección 3: Definiciones...................................................................................................... 237.4 SVVP sección 4: Visión General de la V&V ............................................................................... 237.5 SVVP sección 5: Procesos de la V&V .............................. .......................................................... 247.6 SVVP sección 6: Reportando Requerimientos de la V&V .......................................................... 257.7 SVVP sección 7: Requerimientos Administrativos de la V&V ….................................................. 257.8 SVVP sección 8: Requerimientos de la Documentación de Prueba de la V&V.. ......................... 26

Anexo A (informativo) Mapeando las tareas y actividades de V&V del estándar IEEE 1012......................................... 71Anexo B (informativo) Un riesgo basado en el esquema de los niveles de seguirar del software ……………………… 88Anexo C (informativo) Definición independiente de V&V (IV&V).................................................................................... 90Anexo D (informativo) V&V de software de reuso…………............................................................................................ 93Anexo E (informativo) Medidas de V&V ...................................................................................................................... 100Anexo F (informativo) Ejemplo de V&V organizacional que relaciona a otras responsabilidades de proyectos……...103Anexo G (informativo) Tareas opcionales de V&V…………………………………......................................................... 104Anexo H (informativo) Bibliografía………………........................................................................................................... 110

Estándar IEEE para la Verificación y Validación de Software.

Descripción

Este estándar de verificación y validación (V&V) es un proceso estándar que dirige todos los procesos del ciclo de vida del software incluyendo la adquisición, abastecimiento, desarrollo, operación y mantenimiento. Este estándar es compatible con todos los modelos de ciclo de vida, sin embargo, no todos los modelos de ciclo de vida usan todos los procesos descritos en este estándar.

El proceso de verificación y validación de software define si el desarrollo de un producto dada una actividad cumple con los requerimientos de esa actividad y si el software satisface el uso previsto y las necesidades del usuario. Esta definición debe incluir análisis, evaluación, revisión, inspección, gravamen y pruebas al software y a los procesos.

AlcanceEste estándar aplica para el software que esta siendo adquirido, desarrollado, mantenido o reutilizado. Los términos del software también incluyen firmware, código y documentación.

El proceso de V&V de software consiste en el proceso de verificación y en el proceso de validación. El proceso de verificación provee evidencia objetiva sobre el software y sus productos y procesos asociados.

a) Conforma los requerimientos (p.e. corrección, finalización, consistencia o exactitud) para todas las actividades del ciclo de vida durante cada proceso del ciclo (adquisición, entrevistas, desarrollo, operación y mantenimiento).

b) Satisface estándares, prácticas y convenios durante el ciclo de vida de los procesos.c) Completa exitosamente cada actividad del ciclo de vida y satisface todos los criterios para iniciar

satisfactoriamente las actividades del ciclo de vida.

El proceso de validación acredita al software, sus productos y procesos asociados si:

1. Satisface los requerimientos del sistema asignados al final de cada actividad del ciclo de vida.

2. Resuelve el problema específico (p.e. las reglas correctas del modelo físico, implementa las reglas del negocio, usa las suposiciones propias del sistema.)

3. Satisface los usos previstos y las necesidades del usuario.

Los procesos de verificación y validación, son procesos interrelacionados y complementarios que usan los resultados del otro para llegar a un mejor fin en el establecimiento de criterios y análisis, evaluación, revisión, inspección valoración y tareas de la prueba V&V para cada actividad del ciclo de vida del Software.

Los criterios de las tareas del test v y v descritos en la tabla 1 únicamente definen el ajuste de los requerimientos del proceso V&V.

El desarrollo de un razonable cuerpo de evidencia requiere un termino medio entre la cantidad del tiempo invertido y una serie finita de condiciones del sistema y suposiciones en contra de lo que realizan las tareas del V&V. Cada proyecto debe definir criterios para un razonable cuerpo de evidencia (p.e. Seleccionar un nivel integral de software establece uno de los parámetros básicos), tiempo programado y el alcance de análisis del V&V y las tareas de prueba (p.e el rango de condiciones y suposiciones del sistema).Este estándar no asigna la responsabilidad para el cumplimiento de las tareas del V&VPara alguna organización en específico.

El análisis, evaluación y actividades de la prueba pueden ser llevados a cabo por múltiples organizaciones; de cualquier manera, los métodos y propósitos diferirán de organización a organización dependiendo de sus objetivos funcionales.

ISO/IEC 12207:1995 [B13] or IEEE/EIA 12207.0-1996 [B12], requiere que el promotor cumpla con varias pruebas y tareas de evaluación como parte integral en el proceso de desarrollo. Aun cuando las pruebas y las evaluaciones no sean parte del proceso V y V, las técnicas descritas en este estándar pueden ser útiles en su cumplimiento. Por lo tanto cada vez que este estándar menciona el cumplimiento de la actividad de validación y verificación del promotor, debe entenderse que se hace referencia a la prueba integral y tareas de evaluación del proceso de desarrollo.

1.2 propósitos

El propósito de este estándar es:

Establecer una estructura común para el proceso V&V, actividades y tarea en apoyo de todos los procesos del ciclo de vida del software, incluyendo adquisición, abastecimiento, desarrollo, operación y mantenimiento del proceso.

Definir las tareas del V&V, entradas y salidas requeridas

Identificar el mínimo de pruebas V&V correspondientes a un esquema integral de un software de nivel 4.

Definir el contenido de un plan de software V&V

1.3 Campo de aplicación

Este estándar se aplica a todas las aplicaciones del software. Cuando se aplica el proceso del V y V es importante examinar las interacciones del software con el sistema del cual es parte.

Este estándar identifica las importantes consideraciones del sistema que el proceso de V&V del software y dirigen las tareas para la determinación de la corrección y otros atributos del software yV(p.e precisión, exactitud, verificabilidad)

La versatilidad del software y la multitud de diferentes rutas lógicas disponibles dentro del software en respuesta a las variaciones de los estímulos y condiciones del sistema, demanda que el esfuerzo del software V y V examine que el código sea lo mas correcto, para cada posible variación el las condiciones del sistema. La capacidad de modelar condiciones complejas del mundo real estarán limitadas y por tanto el esfuerzo del software V y V examinara si los limites de modelado son reales y razonables para la solución deseada.

La combinación ilimitada de las condiciones del sistema presenta al esfuerzo del software V y V con el único reto de usar un conjunto finito de técnicas analíticas, de prueba, simulación y demostración para establecer un cuerpo razonable de evidencia de que el software esta en lo correcto.

Un sistema de software provee una capacidad para satisfacer una necesidad establecida u objetivo para combinar uno o mas de los siguiente: procesos, hardware, software facilidades y gente. Esta relación entre el software y el sistema requiere que el proceso de software V&V considera interacciones de software con todos los componentes del sistema dado que el software se liga junto con todos los componentes de un sistema digital, el procesador del software V&V examina las interacciones con cada uno de los componentes del sistema clave para determinar la amplitud a la cual cada componente influencia al software y esta inversamente influenciado por el software. El procesador V&V dirige las siguientes interacciones con el software:

Entorno: Determina que la solución representada en el software considere correctamente todas las condiciones, fenómenos naturales, leyes físicas de la naturaleza, propiedades físicas, reglas financieras y el rango total del entorno del sistema operativo.

Operador/usuario: Determina que el software comunique apropiadamente el status/condición del software del sistema al operador/usuario y corrija los procesos de todas las entradas del operador/usuario para producir los resultados requeridos. Para entradas incorrectas del usuario asegurarse de que el software proteja al sistema para que no entere en un estado peligroso e incontrolable.Validar las políticas y procedimientos del operador/usuario (p.e seguridad, protocolos de interfase, suposiciones del sistema) sean aplicadas consistentemente y a lo largo de cada componente de la interfase

Hardware: Determina que el software interactué correctamente con cada una de las interfaces del hardware y de una respuesta controlada al sistema.(p.e una elegante degradación) para las fallas del sistema.

Otro software: Determina una correcta interfase entre el software y sus componentes en el sistema de acuerdo a requerimientos y a que los errores no se propaguen entre los componentes del software del sistema.

Desde que el software afecta directamente al comportamiento y al desarrollo del sistema, el ámbito del proceso V&V es el sistema Software incluyendo el entorno operacional, usuarios y operadores, hardware y la interfase del software usuario de este estándar debe considerar al V&V como parte del proceso del ciclo de vida del software definido por estándares industriales tales como ISO/IEC 12207:1995 [B13] o IEEE/EIA 12207.0-1996 [B12]Para establecer la perspectiva del sistema el software V&V debe proveer un análisis integrado en donde las tareas del V&V estén interrelacionados, dando entradas y penetración a otras tareas V&V Resultados de un proceso de de ciclo de vida completado provee entradas necesarias a las tareas del V&V a procesos del ciclo de vida mas adelante.Resultados y hallazgos de las tareas del V&V puede causar que alguna tarea del V&V previamente completada sean analizadas con nuevos datos. Esta relación entre las tareas del V&V (incluyendo retroalimentación al proceso de desarrollo) empleando rigurosos sistemas de ingeniería es la clave para llegar a un sistema integrado de software V&V. Los resultados del software V&V proveen al proceso de desarrollo de detecciones tempranas de anormalidades y tendencias potenciales que pueden ser usadas para el mejoramiento del proceso del desarrollo.

El Proceso de software V y V y las tareas descritas en este estándar son consistentes con la ingeniería de los sistemas y los modelos de mejoramiento del proceso, tales como: el modelo Integrado de capacidad y madurez (CMMI).

1.4 objetivos de la V&V

Los procesos de V&V proporcionan un objetivo impuesto de los productos y de los procesos de software a través del ciclo de vida del software. Este impuesto demuestra si los requisitos del software y los requisitos del sistema (es decir, ésos asignados al software) son correctos, completos, exactos, constantes, y probables. Los procesos de la V&V determinan si los productos del desarrollo de una actividad dada se conforman con los requisitos de esa actividad y si el software satisface sus necesidades previstas. del uso y del usuario. La determinación incluye el gravamen, el análisis, la evaluación, la revisión, la inspección, y la prueba de los productos y de los procesos de software. La V&V se debe realizar en paralelo con el desarrollo del software, no en la conclusión del desarrollo. Los procesos de V&V proporcionan un objetivo de los productos y de los procesos de software a través del ciclo de vida del software.

Los resultados de la V&V crean las ventajas siguientes al programa: Facilite la detección temprana y la corrección de las anomalías del software. Realza la penetración de la gerencia dentro del proceso y riesgo del producto. Apoya los procesos del ciclo de vida para asegurar la conformidad del funcionamiento, horario, y

presupuesto del programa. Proporciona un acercamiento temprano del funcionamiento del software y del sistema. Proporciona la evidencia objetiva de la conformidad del software y del sistema para apoyar un

proceso formal de certificación. Mejora los procesos del desarrollo y del mantenimiento del software. Apoya la mejora de proceso para un modelo integrado del análisis del sistema.

1.5 Organización del estándar

Este estándar se organiza en las cláusulas (cláusulas 1 a 7), tablas (tabla 1, tabla 2, y tabla 3), figuras (cuadro 1 y cuadro 2), y anexos (anexos A con H). Las cláusulas 2 a 7 y tabla 1 y tabla 2 proporcionan los requisitos obligatorios de V&V para este estándar. La tabla 1 y la tabla 2 son el punto focal de este estándar, conteniendo proceso de V&V, actividad, y requisitos detallados de la tarea. La cláusula 2 es reservada para las referencias normativas; sin embargo, este estándar no prescribe ninguna referencias normativa. La cláusula 3 proporciona una definición de términos, de abreviaturas, y de convenciones. La cláusula 4 describe el uso de los niveles de la integridad de software de determinar el alcance y el rigor de los procesos de V&V. La cláusula 5 describe procesos primarios del ciclo vital del software y enumera las actividades de V&V asociadas al proceso del ciclo vital. La cláusula 6 describe requisitos de la divulgación de V&V, administrativos, y de la documentación. La cláusula 7 describe el contenido de un plan del software V&V. La cláusula 1, el cuadro 1, el cuadro 2, y la tabla 3 contienen el material informativo que proporciona ejemplos de los procesos de V&V y proporcionan la dirección para usar este estándar. Todos los anexos son informativos

La tabla 1 proporciona descripciones, entradas, y las salidas de la tarea de V&V para cada proceso del ciclo vital. La tabla 2 enumera las tareas mínimas de V&V requeridas para diversos niveles de la integridad de software. La tabla 3 proporciona una lista de las tareas opcionales de V&V y de sus usos sugeridos en el ciclo vital del sistema de software. Estas tareas opcionales de V&V se pueden agregar a las tareas del mínimo V&V, como necesario, de adaptar el esfuerzo de V&V de proyectar necesidades.

El cuadro 1 proporciona un ejemplo de una descripción de las entradas de V&V, de las salidas, y de las tareas mínimas de V&V para el nivel 4 de la integridad de software. El cuadro 2 proporciona las pautas para programar el planeamiento de la prueba de V&V, la ejecución, y actividades de la verificación. Un ejemplo de un modelo puesto en fase del ciclo vital fue utilizado en el cuadro 1 y el cuadro 2 para ilustrar traz de los procesos del ciclo vital de ISO/IEC 12207:1995 [ B13 ] a las actividades y a las tareas de V&V descritas en este estándar

1.6 Audiencia

La audiencia de este estándar incluye a distribuidores, compradores, desarrolladores, de mantenimiento, practicantes de V&V, operadores, usuarios y administradores del lado del vendedor o del comprador.

1.7 Conformidad

La palabra identifica requisitos obligatorios para ser seguido terminantemente para conformarse con este estándar. Las palabras deben y pueden indicar las tareas opcionales que no se requieren para demandar conformidad a este estándar.

No todos los esfuerzos de V&V se inician en el comienzo del proceso del ciclo de vida de la adquisición y continuado con el proceso del mantenimiento puede indicar las tareas opcionales que no se requieren para demandar conformidad a este estándar.

Si un proyecto utiliza solamente procesos seleccionados del ciclo de vidal, entonces la conformidad a este estándar se alcanza si las mínimas tareas de V&V se ponen en ejecución para los procesos asociados del ciclo de vida seleccionados para el proyecto.

Cualquier demanda de la conformidad a este estándar identificará los procesos aplicables del ciclo de vida.

Como en todos los casos, las mínimas tareas de V&V son definidas por el nivel de la integridad de software asignado al sistema

Para los procesos del ciclo de vida que no son utilizados por el proyecto, los requisitos y las tareas de V&V para esos procesos del ciclo de vida están las tareas opcionales de V&V invocadas según lo necesitado en la discreción del proyecto. Los métodos y las tecnologías específicos del desarrollo del software (tales como generación automatizada del código del diseño detallado) pueden eliminar pasos del desarrollo o combinar varios pasos del desarrollo en uno. Por lo tanto, una adaptación correspondiente de las tareas mínimas de V&V es la adaptación correspondiente permitida de las tareas mínimas de V&V que se permite.

Cuando este estándar se invoca para el software existente y las entradas requeridas de V&V no están disponibles, después las tareas de V&V pueden utilizar otras fuentes disponibles de la entrada del proyecto o pueden reconstruir las entradas necesarias para alcanzar conformidad a este estándar.

1.8 Negación.

Este estándar establece los criterios mínimos para los procesos, las actividades, y las tareas de V&V. Sin embargo, poner estos criterios en ejecución no asegura automáticamente conformidad a los objetivos del sistema o de la misión, o previene las consecuencias adversas (p. e., pérdida de vida, falta de la misión, pérdida de la seguridad, financiera o social del sistema). La conformidad a este estándar no absuelve ninguna parte de ninguna obligaciones social, moral, financiera, o legal.

1.9 Limitaciones.Ninguna.

2. Referencias.Este estándar no requiere el uso de ninguna referencia normativa. Los estándares útiles para la puesta en práctica y la interpretación de este estándar se enumeran en el anexo H.

3. Definiciones, abreviaturas, y siglas

3.1 DefinicionesLos propósitos de este estándar, los términos y las definiciones siguientes solicitan. “El diccionario autoritario de los términos de los estándares de IEEE, de la séptima edición [ B2 ] y de IEEE Std 610.127 -1990 [ B3 ], debe ser referido para los términos no definidos a esta cláusula.

3.1.1 prueba de aceptación: (a) Prueba formal conducida para determinar un sistema satisface o no sus criterios de la aceptación y permite al cliente determinar acepta el sistema o no. (b) Prueba formal conducida para permitir al usuario, al cliente, o a la otra entidad autorizada determinarse si acepta un sistema o un componente.

3.1.2 anomalía: Cualquier cosa observada en la documentación o la operación del software que se desvía de las expectativas que se basó en productos de software o documentos previamente verificados.3.1.3 activo: Un artículo (p. e., diseño, especificaciones, código de fuente, documentación, habitaciones

de la prueba, procedimientos manuales) que se ha diseñado para el uso en contextos múltiples.

3.1.4 Componente: Una de las piezas que hacen para arriba un sistema. Un componente puede ser hardware o software y se puede subdividir en otros componentes.

3.1.5 Prueba del componente: Prueba de los componentes individuales del hardware o de software o grupos de componentes relacionados.

3.1.6 Criticalidad: El grado de impacto que el requisito, el módulo, el error, la avería, la falta, u otro error tiene en el desarrollo o la operación de un sistema.

3.1.8 análisis del dominio: (a) El análisis de sistemas dentro de un dominio para descubrir concordancias y diferencias entre ellos. (b) El proceso por el cual se identifica la información que se utilizó en sistemas de software para poderla reutilizarla para crear nuevos sistemas, dentro de un dominio. (c) El resultado del proceso en (a) y (b).

3.1.9 ingeniería del dominio: Un acercamiento para reutilizar, basado en definir el alcance (es decir, definición del dominio), especificando la estructura (es decir, arquitectura del dominio), y construyendo los activos (p. e., requisitos, diseños, código del software, documentación) para una clase de sistemas, de subsistemas, o de usos. La ingeniería del dominio puede incluir las actividades siguientes: definición del dominio, análisis del dominio, desarrollando la arquitectura del dominio, y la puesta en práctica del dominio.

3.1.10 soportes lógico inalterable: La combinación de las instrucciones de hardware de un dispositivo de computadora y datos que residen como software inalterable en ese dispositivo.

peligro: (A) Una intrínseca propiedad que es potencial causa de daño o daños. (B) Una fuente de daño potencial o una situación muy peligrosa en términos de lesiones humanas, daño a la salud, propiedad o ambiente, o alguna combinación de esos tres.Identificación del peligro: El proceso de reconocimiento de que un peligro existe y sus características.Verificación y validación independiente (V&VI): V&V realizada por una organización que es técnica, administrativa y financieramente independiente de la organización que desarrolla.Pruebas de integración: Prueban en qué componentes de software, los componentes de hardware, o ambos se combinan y se prueban para evaluar la interacción entre ellos.Nivel de integridad: Un valor que representa las características únicas del proyecto (p.e. complejidad del software, criticalidad, riesgo, nivel de seguridad, nivel de la seguridad, funcionamiento deseado, confiabilidad) que defina la importancia del software para el usuario.Documento del diseño de la interfaz (IDD): Documentación que describe los interfaces de la arquitectura y del diseño entre el sistema y los componentes. Estas descripciones incluyen algoritmos del control, los protocolos, contenido y los formatos de los datos, y funcionamiento.Especificación de requisitos de la interfaz (IRS): Documentación que especifica los requisitos para los interfaces entre los sistemas y los componentes. Estos requisitos incluyen apremios en formatos y la sincronización.Procesos del ciclo de vida: Un conjunto de actividades correlacionadas que dan lugar al desarrollo o al gravamen de los productos de software. Cada actividad consiste en tareas. Los procesos del ciclo de vida pueden traslapar unos a otros. Para los propósitos de V&V, no se concluye ningún proceso hasta que sus productos del desarrollo se verifican y se validan según las tareas definidas en el SVVP.Microcódigo: Una colección de microinstrucciones, abarcan parte de o todo de los microprogramas.

3.1.20 microprograma: Una secuencia de instrucciones, llamada microinstrucciones, especificando las operaciones básicas necesarias para realizar una instrucción de la terminología de la informática.

3.1.21 tareas mínimas: Esas tareas de V&V requeridas para el nivel de la integridad de software asignado al software que se verificará y validadará.

3.1.22 tareas opcionales: Esas tareas de V&V que se pueden agregar a las tareas de la V&V de requisitos específicos del uso.

3.1.23 entradas requeridas: El sistema de artículos necesarios para realizar las tareas de V&V asignadas por mandato dentro de cualquier actividad del ciclo de vida.

3.1.24 salidas requeridas: El sistema de artículos producidos como resultado de realizar las tareas de V&V asignadas por mandato dentro de cualquier actividad del ciclo de vida.

3.1.25 Producto de software reutilizable: Un producto de software se creó para un uso pero puede tener otras aplicaciones, o fue desarrollado específicamente para ser usable en proyectos múltiples o en papeles múltiples en un proyecto. Los ejemplos incluyen, pero no se limitan a, los productos de software de los COTS, los productos de software adquirente-equipados, los productos de software en bibliotecas de la reutilización, y los productos de software de preexistencia del revelador. Cada uso puede incluir el todo o una parte del producto de software y puede implicar su modificación. Este término se puede aplicar a cualquier producto de software (por ejemplo, requisitos, arquitecturas), no apenas al software sí mismo.

3.1.26 Riesgo: (a) La combinación de la probabilidad de la ocurrencia y de las consecuencias de un acontecimiento indeseable futuro. El riesgo se puede asociar a los productos y/o a los proyectos. (b) La combinación de la probabilidad de un acontecimiento o de una falta anormal y el consequence(s) de ese acontecimiento o hace falta a los componentes, a los operadores, a los usuarios, o al ambiente de un sistema.

3.1.27 Seguridad: (a) La protección del hardware o software contra el acceso, el uso, la modificación, la destrucción, o el acceso accidental o malévolo. La seguridad también pertenece al personal, a los datos, a las comunicaciones, y a la protección física de las instalaciones de la computadora. (b) No niegan la protección de la información y los datos de modo que las personas o los sistemas desautorizados no puedan leerlos o modificar y las personas o los sistemas autorizados el acceso a ellos.

3.1.28 Descripción del diseño del software (SDD): Una representación del software creada para facilitar el análisis, el planeamiento, la puesta en práctica, y la toma de decisión. La descripción del diseño del software se utiliza como medio para la información del diseño del software que se comunica y se puede pensar en como modelo o modelo del sistema.

3.1.29 requisitos del software (SRS): Documentación de los requisitos esenciales (funciones, funcionamiento, apremios del diseño, y cualidades) del software y de sus interfaces externos.

3.1.30 Prueba de sistemas: Prueba conducida en un sistema completo, integrado para evaluar la conformidad del sistema con sus requisitos especificados.

3.1.31 Caso de pruebas: (a) Un sistema de entradas de prueba, de condiciones de la ejecución, y de resultados previstos desarrollados para un objetivo particular, por ejemplo para ejercitar una trayectoria particular del programa o para verificar conformidad con un requisito específico. (b) Documentación que especifica entradas, resultados predichos, y un sistema de condiciones de la ejecución para un artículo de la prueba.

3.1.32 Diseño de pruebas: Documentación que especifica los detalles del acercamiento de la prueba para una característica del software o una combinación de las características del software y que identifica las pruebas asociadas.

3.1.33 Plan de prueba: (a) Un documento que describe el alcance, el acercamiento, los recursos, y el horario de las actividades previstas de la prueba. Identifica los artículos de la prueba, las características que se probarán, las tareas de prueba, que harán cada tarea, y cualquier riesgo que requiere la planificación de urgencia. (b) Un documento que describe el acercamiento técnico y de la gerencia que se seguirá para probar un sistema o un componente. El contenido típico identifica los artículos que se probarán, las tareas de ser realizado, las responsabilidades, los horarios, y los recursos requeridos para la actividad de prueba.

3.1.34 Método de prueba: (a) Instrucciones detalladas para la disposición, la ejecución, y la evaluación de los resultados para un caso dado de la prueba. (b) Un documento que contiene un sistema de instrucciones asociadas como en (a). (c) Documentación que especifica una secuencia de las acciones para la ejecución de una prueba.

3.1.35 Validación: (a) El proceso de evaluar un sistema o un componente durante o en el final del proceso del desarrollo para determinarse si satisface requisitos especificados. (b) El proceso de proporcionar evidencia que el software y sus productos asociados satisfacen requisitos del sistema asignó al software en el final de cada actividad del ciclo vital, soluciona el problema derecho (p. e., modelar correctamente las leyes físicas, ponen reglas de negocio en ejecución, utilizan las asunciones apropiadas del sistema), y satisfacer necesidades previstas del uso y del usuario.

3.1.36 Verificación: (a) El proceso de evaluar un sistema o un componente para determinarse si los productos de una fase dada del desarrollo satisfacen las condiciones impuestas en el comienzo de esa fase. (b) El proceso de proporcionar evidencia objetiva que el software y sus productos asociados se conforman con los requisitos (e.g., para la corrección, lo completo, la consistencia, la exactitud) para todas las actividades del ciclo vital durante cada proceso del ciclo vital (adquisición, fuente, desarrollo, operación, y mantenimiento); satisfaga a los estándares, a las prácticas, y a convenciones durante procesos del ciclo vital; y termine con éxito cada actividad del ciclo vital y satisfaga todos los criterios para iniciar actividades del ciclo vital que tienen éxito (e.g., construyendo el software correctamente).

3.1.37 verificación y esfuerzo de la validación (V&V): El trabajo se asoció a realizar los procesos, las actividades, y las tareas de V&V. El marco siguiente ilustra cómo los procesos de V&V se subdividen en las actividades, que alternadamente han asociado tareas:

3.2 Abreviaturas y siglas

Las siglas y las abreviaturas siguientes aparecen en este estándar:

ANSI American National Standards InstituteCOTS disponible comercialIEC International Electrotechnical CommissionIEEE Institute of Electrical and Electronic EngineersIDD Documento del diseño del interfaz.IRS Especificación de requerimientos de la interfaz. ISO International Organization for StandardizationIV&V Verificación y validación independientes.NDI artículo no-de desarrolloRFP pedido la oferta (oferta)SDD descripción del diseño del software.SRS Especificación de los requerimientos del softwareSVVP plan de V&V de software SVVR reporte de la V&V de softwareV&V verificación y validación

4. Niveles de la integridad de software

Los niveles de la integridad de software son una gama de los valores que representan complejidad del software, criticalidad, riesgo, el nivel de seguridad, el nivel de la seguridad, el funcionamiento deseado, la confiabilidad, u otras características proyecto-únicas que definan la importancia del software al usuario y al adquirente. Las características determinaban el nivel de la integridad de software varían dependiendo del uso y del uso previstos del sistema. El software es una parte del sistema, y su nivel de la integridad es ser determinada como parte de ese sistema. Los niveles asignados de la integridad de software pueden cambiar mientras que el software se desarrolla. Las características del diseño, de la codificación, procesales, y de la tecnología puestas en ejecución en el sistema o el software pueden levantar o bajar los niveles asignados de la integridad de software. Los niveles de la integridad de software establecidos para un proyecto deben resultar de acuerdos entre el adquirente, el surtidor, el revelador, y las autoridades independientes del aseguramiento (p.e., un cuerpo regulador o una agencia responsable).

Este estándar utiliza niveles de la integridad de software para determinar las tareas de V&V de ser realizado. El software high-integrity requiere un sistema más grande de procesos de V&V y un uso más riguroso de las tareas de V&V. Los niveles de la integridad se asignan a los requisitos del software, funciones, grupos de funciones, o los componentes o los subsistemas de software. Algunos elementos y componentes del software pueden no requerir la asignación de un nivel de la integridad (es decir, no aplicable) porque su falta no impartiría ninguna consecuencia en las operaciones de sistema previstas. Los procesos de V&V se deben adaptar a los requisitos y a los usos específicos del sistema a través de la selección de un nivel de la integridad de software con sus tareas mínimas correspondientes de V&V y de la adición de las tareas opcionales de V&V. La adición de las tareas opcionales de V&V permite el

esfuerzo de V&V de tratar las características específicas del uso del software. El esfuerzo de V&V puede recomendar los acercamientos técnicos y procesales de la mitigación para reducir el nivel de la integridad.

Como ejemplo, este estándar utiliza el esquema siguiente de la integridad de software del cuatro-nivel. Este esquema del ejemplo se basa sobre los conceptos de consecuencias y del potencial de la mitigación.

Descripción NivelEl elemento del software debe ejecutarse correctamente o 4las consecuencias graves (pérdida de vida, pérdida de pérdida del sistema, económica o social) ocurrirán. No hay mitigación posible.

El elemento del software debe ejecutarse correctamente o el uso previsto (misión) del software del sistema no será observado, 3causando las consecuencias serias (lesión permanente, impacto importante de la degradación del sistema, económico o social). Parcial terminar la mitigación es posible.

El elemento del software debe ejecutarse correctamente o una función prevista no será observada, causando consecuencias de 2menor importancia. Termine la mitigación posible.

El elemento del software debe ejecutarse correctamente o la función prevista no será observada, causando consecuencias 1 insignificantes. Mitigación no requerida.

Otro ejemplo, un esquema basado en riesgo, se describe en el anexo B. Este estándar no requiere el uso de ningún esquema particular del nivel de la integridad de software descrito o referido a este estándar.

Los niveles de la integridad serán asignados a los elementos del software o a los componentes como parte de la tarea del análisis de la criticalidad. El esfuerzo de V&V especificará un esquema del nivel de la integridad de software si uno no se define ya. El nivel de la integridad asignado a los productos de software reutilizados estará de acuerdo con el esquema del nivel de la integridad adoptado para el proyecto (véase el anexo D), y el producto de software reutilizado será evaluado para el uso en el contexto de su uso. Las herramientas que insertan o traducen el código (p. e., recopiladores, generadores óptimos del código automático) serán asignadas el mismo nivel de la integridad que el nivel de la integridad asignado al elemento del software que la herramienta afecta. El sistema de software será asignado el mismo nivel de la integridad que el nivel más alto asignado a cualquier elemento individual. La asignación del nivel de la integridad de software será repasada y puesta al día continuamente conduciendo la tarea del análisis de la criticalidad de V&V a través del proceso del desarrollo del software.La tabla 2 identifica las tareas mínimas de V&V que serán realizadas para cada nivel de la integridad de software. Para identificar las tareas del mínimo V&V que se aplican a un diverso esquema seleccionado del nivel de la integridad de software, el usuario del estándar tras este esquema del nivel de la integridad de software de estándar y las tareas asociadas del mínimo V&V a su nivel seleccionado de la integridad de software proyectan. El esquema del nivel de la integridad de software y de las tareas asociadas del mínimo V&V será documentado en el SVVP. La base para asignar niveles de la integridad de software a los componentes de software será documentada en un informe de la tarea de V&V e informe final de V&V.

La prueba requiere el planeamiento anticipado que atraviesa varias actividades del desarrollo. La documentación de prueba y su generación en los procesos específicos en el ciclo vital se demuestran en el cuadro 1 y el cuadro 2.

El usuario de este estándar documentará los procesos de V&V en el SVVP y definirá la información y las instalaciones necesarias para manejar y para realizar estos procesos, actividades, y tareas, y para coordinar los procesos de V&V con otros aspectos relacionados del proyecto. Los resultados de las actividades y de las tareas de V&V serán documentados en informes de la tarea, informes sumarios de la actividad, informes de la anomalía, los documentos de la prueba de V&V, y el informe final de V&V.

5.1 Proceso: Gerencia

El proceso de la gerencia abarca las actividades y las tareas genéricas siguientes: - Preparación de los planes para la ejecución del proceso - Iniciar la puesta en práctica del plan - Supervisión de la ejecución del plan - Analizando los problemas descubiertos durante la ejecución del plan - Divulgación del progreso de los procesos - Asegurando productos satisfacer los requisitos - Determinación de resultados de la evaluación - Determinándose si una tarea es completa

- Comprobación de los resultados para saber si hay lo completo - Comprobación de los procesos para saber si hay eficacia y eficacia - Repaso de calidad del proyecto - Repaso de riesgos del proyecto - Repaso de medidas del proyecto

5.1.1 Actividad: Gerencia del esfuerzo de V&V

La actividad de la gerencia de V&V supervisa y evalúa todas las salidas de V&V. La gerencia del esfuerzo de V&V se realiza para todos los procesos y actividades del ciclo vital del software. Esta actividad implica el siguiente: - Una revisión continua del esfuerzo de V&V - Revisión del SVVP cuanto sea necesario basado sobre horario del proyecto y estado actualizados del desarrollo - Coordinación de los resultados de V&V con el revelador y otros procesos de soporte, tales como gerencia de la garantía de calidad y de la configuración - Funcionamiento de revisiones y de intervenciones - Identificación de las oportunidades de la mejora de proceso en la conducta de V&V

La gerencia de V&V determina cada cambio propuesto al sistema y el software, identifica el software los requisitos que son afectados por el cambio, y planean tareas de V&V de tratar el cambio. Para cada cambio propuesto, la gerencia determina si algunos nuevos peligros o riesgos están introducidos en el proceso del desarrollo del software o del sistema, e identifica el impacto del cambio en los niveles asignados de la integridad de software. El planeamiento de la tarea de V&V es revisado agregando nuevas tareas de V&V o cambiando el alcance o la intensidad de las tareas existentes de V&V si se cambian los niveles, los peligros, o los riesgos de la integridad de software. Un cambio de la línea de fondo resulta de los cambios asignados a las revisiones del programa en un proceso incremental del desarrollo del software (e.g., versiones previstas de la línea de fondo).

Con el uso de las medidas de V&V y de otras medidas cualitativas y cuantitativas, esta actividad de V&V desarrolla los datos de la tendencia del programa y las ediciones posibles del riesgo, que entonces se proporcionan al revelador y al adquirente a la notificación oportuna y a la resolución del efecto. En los jalones dominantes del programa (e.g., revisión de los requisitos, revisión de diseño, preparación de la prueba), la gerencia de V&V consolida los resultados de V&V para establecer evidencia de soporte de

si proceder al sistema siguiente de actividades del desarrollo del software. Siempre que sea necesario, el V&V la gerencia se determina si una tarea de V&V debe ser reperformed como resultado de cambios en el programa del software.

El esfuerzo de V&V se realizará, según lo especificado en la tabla 2 para el nivel seleccionado de la integridad de software, las tareas siguientes de la gerencia V&V descritas en la tabla 1: 1) Tarea: Generación de SVVP2) Tarea: Gravamen propuesto/de la línea de fondo del cambio 3) Tarea: Revisión de la gerencia del esfuerzo de V&V 4) Tarea: Gerencia y ayuda técnica de la revisión 5) Tarea: Interfaz con procesos de organización y de soportes 6) Tarea: Identificar las oportunidades de la mejora de proceso en la conducta de V&V

5.2 Proceso: Adquisición

El proceso de adquisición comienza con la definición de la necesidad (e.g., declaración de la necesidad) de adquirir un sistema, un producto de software, o un servicio del software. El proceso continúa con la preparación posible y emisión de un pedido la petición de la oferta de la oferta (RFP) (e.g., oferta), selección de un surtidor, y gerencia del proceso de adquisición a través a la aceptación del sistema, del producto de software, o del servicio del software.

El proceso de adquisición se utiliza al alcance el esfuerzo de V&V, los interfaces del plan con el surtidor y adquirente, repasa los requisitos de los sistemas del bosquejo para ser incluido en el RFP, y proporciona los resultados de la tarea de V&V a la aceptación del adquirente de la ayuda del sistema. La aceptación del adquirente del sistema culmina después de probar y de la instalación de aceptación. Las actividades de la ayuda de la aceptación de la adquisición de V&V ocurren a través del ciclo vital del software, conjuntamente con el otro desarrollo correlacionado y las tareas de V&V, las entradas, y las salidas.

5.2.1 Actividad: Ayuda de adquisición V&V

La actividad de la ayuda de adquisición V&V trata la iniciación del proyecto, RFP, preparación del contrato, surtidor que supervisa, y aceptación y terminación.

El esfuerzo de V&V se realizará, según lo especificado en la tabla 2 para el nivel seleccionado de la integridad de software, las tareas siguientes de la ayuda de adquisición V&V descritas en la tabla 1: 1) Tarea: Scoping el esfuerzo de V&V 2) Tarea: Planear el interfaz entre el esfuerzo de V&V y el surtidor 3) Tarea: Revisión de los requisitos del sistema 4) Tarea: Ayuda de la aceptación

5.3 Proceso: Fuente

El proceso de la fuente es iniciado por una decisión para preparar una oferta para contestar a la petición de un adquirente para la oferta o negociando, concluyendo, y entrando en un contrato con el adquirente para proporcionar el sistema, el producto de software, o el servicio del software. El proceso continúa con la determinación de los procedimientos y de los recursos necesitados para manejar el proyecto, incluyendo el desarrollo de los planes del proyecto y la ejecución de los planes con la entrega del sistema, del producto de software, o del servicio del software al adquirente.

El esfuerzo de la fuente V&V utiliza los productos del proceso de la fuente para confirmar que el pedido la oferta los requisitos y los requisitos de contrato son constantes y satisfacen necesidades del usuario antes de que se concluya el contrato. La actividad del planeamiento de V&V utiliza los requisitos de contrato, incluyendo los horario del programa, para revisar y para poner al día el planeamiento del interfaz entre el surtidor y el adquirente.

5.3.1 Actividad: Planeamiento V&V

La actividad del planeamiento V&V trata la iniciación, preparación de la respuesta, contrato, planeamiento, ejecución y control, revisión y evaluación, y las actividades de la entrega y de la terminación.

El esfuerzo de V&V se realizará, según lo especificado en la tabla 2 para el nivel seleccionado de la integridad de software, las tareas siguientes del planeamiento V&V descritas en la tabla 1: 1) Tarea: Planear el interfaz entre el esfuerzo de V&V y el surtidor 2) Tarea: Verificación del contrato

5.4 Proceso: Desarrollo

El proceso del desarrollo contiene las actividades y las tareas del revelador. El proceso contiene las actividades para el análisis de requisitos, diseño, codificación, integración, prueba, e instalación y ayuda a la aceptación de los productos de software.

Las actividades de V&V verifican y validan estos productos de software. Las actividades de V&V se organizan en el concepto V&V, los requisitos V&V, el diseño V&V, la puesta en práctica V&V, la prueba V&V, y la instalación y comprobación V&V.

5.4.1 Actividad: Concepto V&V

La actividad del concepto representa la delineación de una solución específica de la puesta en práctica para solucionar el problema del usuario. Durante la actividad del concepto, se selecciona la arquitectura del sistema y los requisitos del sistema se asignan al hardware, al software, y a los componentes del interfaz utilizador. La actividad del concepto V&V trata análisis de requisitos arquitectónico del diseño del sistema y del sistema. El objetivo del concepto V&V es verificar la asignación de los requisitos del sistema, validar la solución seleccionada, y asegurarse de que no se ha incorporado ningunas asunciones falsas en la solución.

El esfuerzo de V&V se realizará, según lo especificado en la tabla 2 para el nivel seleccionado de la integridad de software, las tareas siguientes del concepto V&V descritas en la tabla 1: 1) Tarea: Evaluación de la documentación del concepto 2) Tarea: Análisis de la criticalidad 3) Tarea: Análisis de la asignación de las exigencias de los equipo y programas de computación/del consumidor 4) Tarea: Análisis de Traceability 5) Tarea: Análisis de peligro 6) Tarea: Análisis de seguridad 7) Tarea: Análisis del riesgo

5.4.2 Actividad: Requisitos V&V

La actividad de los requisitos V&V trata el análisis de requisitos del software del funcional y requisitos, interfaces externos al software, y requisitos de funcionamiento para la calificación, seguridad y seguridad, ingeniería de factores humanos, definiciones de los datos, documentación del usuario para el software, instalación y aceptación, operación y ejecución de usuario, y mantenimiento del usuario. El planeamiento de la prueba de V&V comienza durante la actividad de los requisitos V&V y atraviesa varias actividades de V&V.

El objetivo de los requisitos V&V es asegurar la corrección, lo completo, la exactitud, las pruebas, y la consistencia de los requisitos del software del sistema.

El esfuerzo de V&V se realizará, según lo especificado en la tabla 2 para el nivel seleccionado de la integridad de software, las tareas siguientes de los requisitos V&V descritas en la tabla 1:

1) Tarea: Análisis de Trazabilidad 2) Tarea: Evaluación de los requisitos del software 3) Tarea: Análisis del interfaz 4) Tarea: Análisis de la criticidad 5) Tarea: Generación del plan de prueba del sistema V&V 6) Tarea: Generación del plan de prueba de la aceptación V&V 7) Tarea: Asentar la administración de la configuración8) Tarea: Análisis de peligro 9) Tarea: Análisis de seguridad 10) Tarea: Análisis del riesgo

5.4.3 Actividad: Diseño V&V

En diseño del software, los requisitos del software se transforman en una arquitectura y un diseño detallado para cada componente de software. El diseño incluye las bases de datos y los interfaces de sistema (e.g., hardware, operador/usuario, componentes de software, y subsistemas). La actividad del diseño V&V trata diseño arquitectónico del software y diseño detallado software. El planeamiento de la prueba de V&V continúa durante la actividad del diseño V&V.

El objetivo del diseño V&V es demostrar que el diseño es una transformación correcta, exacta, y completa de los requisitos del software y que no se introduce ningunas características involuntarias.

El esfuerzo de V&V se realizará, según lo especificado en la tabla 2 para el nivel seleccionado de la integridad de software, las tareas siguientes del diseño V&V descritas en la tabla 1:

1) Tarea: Análisis de Traceability 2) Tarea: Evaluación del diseño del software 3) Tarea: Análisis del interfaz 4) Tarea: Análisis de la criticalidad 5) Tarea: Generación componente del plan de prueba de V&V 6) Tarea: Generación del plan de prueba de la integración V&V 7) Tarea: Generación componente del diseño de la prueba de V&V 8) Tarea: Generación del diseño de la prueba de la integración V&V 9) Tarea: Generación del diseño de la prueba del sistema V&V 10) Tarea: Generación del diseño de la prueba de la aceptación V&V 11) Tarea: Análisis de peligro 12) Tarea: Análisis de seguridad 13) Tarea: Análisis del riesgo

5.4.4 Actividad: Puesta en práctica V&V

En la puesta en práctica del software, el diseño del sistema se transforma en código, las estructuras de la base de datos, y las representaciones ejecutables de la máquina relacionada. Las direcciones de la actividad de la puesta en práctica V&V que codifican en software y probando, incluyendo la incorporación de los productos de software reutilizados. El objetivo de la puesta en práctica V&V es verificar y validar que estas transformaciones sean correctas, exactas, y terminen.

El esfuerzo de V&V se realizará, según lo especificado en la tabla 2 para el nivel seleccionado de la integridad de software, las tareas siguientes de la puesta en práctica V&V descritas en la tabla 1:

1) Tarea: Análisis de Traceability 2) Tarea: Evaluación de la documentación del código de fuente y del código de fuente 3) Tarea: Análisis del interfaz 4) Tarea: Análisis de la criticalidad 5) Tarea: Generación componente del caso de la prueba de V&V 6) Tarea: Generación del caso de la prueba de la integración V&V 7) Tarea: Generación del caso de la prueba del sistema V&V 8) Tarea: Generación del caso de la prueba de la aceptación V&V 9) Tarea: Generación componente del método de prueba de V&V 10) Tarea: Generación del método de prueba de la integración V&V 11) Tarea: Generación del método de prueba del sistema V&V 12) Tarea: Ejecución componente de la prueba de V&V 13) Tarea: Análisis de peligro 14) Tarea: Análisis de seguridad 15) Tarea: Análisis del riesgo

5.4.5 Actividad: Probar V&V

La prueba incluye el software que prueba, la integración del software que prueba, la calificación del software que prueba, la integración de sistema que prueba, y prueba de la calificación del sistema. La actividad de la prueba V&V y su relación al ciclo vital del software se demuestran en el cuadro 2. El objetivo de la prueba V&V es asegurarse de que los requisitos del software y los requisitos del sistema asignados al software son validados por la ejecución de la integración, del sistema, y de las pruebas de aceptación.

El esfuerzo de V&V se realizará, según lo especificado en la tabla 2 para el nivel seleccionado de la integridad de software, las tareas siguientes de la prueba V&V descritas en la tabla 1: 1) Tarea: Análisis de Traceability 2) Tarea: Generación del método de prueba de la aceptación V&V 3) Tarea: Ejecución de la prueba de la integración V&V 4) Tarea: Ejecución de la prueba del sistema V&V 5) Tarea: Ejecución de la prueba de la aceptación V&V 6) Tarea: Análisis de peligro 7) Tarea: Análisis de seguridad 8) Tarea: Análisis del riesgo

5.4.6 Actividad: Instalación y comprobación V&V

En la instalación y la comprobación, el producto de software está instalado y probado en el ambiente de la blanco. La actividad de la instalación y de la comprobación V&V apoya las actividades de la instalación del sistema de software. El objetivo de la instalación y de la comprobación V&V es verificar y validar la corrección de la instalación del software en el ambiente de la blanco.

El esfuerzo de V&V se realizará, según lo especificado en la tabla 2 para el nivel seleccionado de la integridad de software, la instalación siguiente y las tareas de la comprobación V&V descritos en la tabla 1:1) tarea: Intervención de la configuración de la instalación 2) Tarea: Comprobación de la instalación 3) Tarea: Análisis de peligro

4) Tarea: Análisis de seguridad 5) Tarea: Análisis del riesgo 6) Tarea: Generación de informe final de V&V

5.5 Proceso: Operación

El proceso de la operación implica el uso del sistema de software del usuario final en un operacional ambiente.

5.5.1 Actividad: Operación V&V

La actividad de la operación V&V evalúa el impacto de cambios en el ambiente de funcionamiento; determina el efecto sobre el sistema de cualquier cambio propuesto; evalúa los procedimientos de funcionamiento para la adherencia con el uso previsto; y analiza los riesgos que afectan el usuario y el sistema. El objetivo de la operación V&V es evaluar nuevos apremios en el sistema, determinar propuso

cambios de sistema y su impacto en el software, y evalúan los procedimientos de funcionamiento para la corrección y la utilidad.

El esfuerzo de V&V se realizará, según lo especificado en la tabla 2 para el nivel seleccionado de la integridad de software, las tareas siguientes de la operación V&V descritas en la tabla 1: 1) Tarea: Evaluación de nuevos apremios 2) Tarea: Evaluación de los procedimientos de funcionamiento 3) Tarea: Análisis de peligro 4) Tarea: Análisis de seguridad 5) Tarea: Análisis del riesgo

5.6 Proceso: Mantenimiento

Se activa el proceso del mantenimiento cuando el sistema de software o la documentación asociada debe ser cambiado en respuesta a una necesidad del mantenimiento del sistema. La actividad del mantenimiento V&V trata el sistema de software - Cambios de las modificaciones (es decir, correctivo, adaptante, o perfective) - Migración (es decir, el movimiento del software a un nuevo ambiente operacional)- Retiro (es decir, el retiro de la ayuda activa por la organización de operación y del mantenimiento, reemplazo parcial o total por un nuevo sistema, o instalación de un sistema aumentado)

5.6.1 Actividad: Mantenimiento V&V

Las modificaciones del sistema se pueden derivar de los requisitos especificados para corregir errores del software (e.g., correctivo); para adaptarse a un ambiente de funcionamiento cambiante (e.g., adaptante); o para responder a las peticiones de usuario o a los realces adicionales (e.g., perfective). Las modificaciones del sistema de software serán tratadas como procesos del desarrollo y verificadas y validadas según lo descrito en el siguiente: -5.1 Proceso Gerencia -5.4. Proceso: Desarrollo

Las asignaciones del nivel de la integridad de software serán determinadas según lo descrito en la cláusula 4. Las asignaciones del nivel de la integridad de software serán revisadas como apropiado para reflejar los requisitos derivados del proceso del mantenimiento.

Para el software de la migración, el esfuerzo de V&V verificará que el software emigrado resuelve los requisitos de las cláusulas 4 y 5.

Si el software V&V fue realizado de acuerdo con este estándar, el proceso del mantenimiento continuar conformándose con este estándar. Si el software no fue verificado y validado usar esta documentación estándar y apropiada no es disponible o adecuado, el esfuerzo del mantenimiento V&V se determinará si la documentación que falta o incompleta debe ser generada. En la fabricación de esta determinación de si generar la documentación que falta, los requisitos del mínimo V&V del software asignado la integridad llana será tomada en la consideración.

El objetivo del mantenimiento V&V es determinar propuso cambios de sistema de software y su impacto en el software, evalúa las anomalías que se descubren durante la operación, determina requisitos de la migración, determina requisitos del retiro, y tareas del reperform V&V. Los cambios propuestos son determinados por la tarea propuesta del gravamen del cambio de la línea de fondo de la gerencia de la actividad de V&V.

El esfuerzo de V&V se realizará, según lo especificado en la tabla 2 para el nivel seleccionado de la integridad de software, las tareas siguientes del mantenimiento V&V descritas en la tabla 1: 1) Tarea: Revisión de SVVP 2) Tarea: Evaluación de la anomalía 3) Tarea: Análisis de la criticalidad 4) Tarea: Gravamen de la migración 5) Tarea: Gravamen del retiro 6) Tarea: Análisis de peligro 7) Tarea: Análisis de seguridad 8) Tarea: Análisis del riesgo 9) Tarea: Iteración de la tarea

6. Requisitos de la divulgación del software V&V, administrativos, y de la documentación

6.1 Requisitos de divulgación de V&V

La divulgación de V&V ocurre a través del ciclo vital del software. El esfuerzo de V&V producirá las salidas requeridas enumeradas en la tabla 1 para cada tarea de V&V realizada. El formato y el agrupar de los informes de V&V pueden ser definidos por el usario. Los informes de V&V constituirán el informe del software V&V (SVVR).

Los informes de V&V consistirán en el siguiente: a) La tarea de V&V divulga. El esfuerzo de V&V los resultados y estado de la tarea del documento V&V. Informes de la tarea incluir el siguiente:

1) Evaluación de la anomalía 2) Evaluación de la documentación del concepto 3) Gravamen de la gerencia de la configuración 4) Verificación del contrato 5) Análisis de la criticalidad 6) Evaluación de nuevos apremios 7) Análisis de la asignación de las exigencias de los equipo y programas de computación/del consumidor8) Análisis de peligro 9) Comprobación de la instalación 10) Intervención de la configuración de la instalación 11) Análisis del interfaz 12) Gravamen de la migración13) Evaluación de los procedimientos de funcionamiento 14) Gravamen propuesto del cambio 15) Recomendaciones 16) Gravamen del retiro

1) Resolución de la anomalía y política de divulgación 2) Política de la iteración de la tarea 3) Política de la desviación 4) Controlar los procedimientos 5) Estándares, prácticas, y convenciones

Estos requisitos administrativos serán documentados en el SVVP.

6.3 Requisitos de la documentación de V&V

El alcance de la documentación de V&V consiste en la documentación de prueba de V&V y la documentación de SVVP. los requisitos para la documentación se describen en los subclauses siguientes.

6.3.1 Documentación de prueba de V&V

Los requisitos de la documentación de prueba de V&V incluirán los planes de prueba, los diseños, los casos, los procedimientos, y los resultados para el componente, la integración, el sistema, y la prueba de aceptación desarrollada por el esfuerzo de V&V. La prueba de V&V la documentación se conformará con el propósito, el formato, y el contenido proyecto-definidos del documento de la prueba (e.g., ver IEEE Std 829™-1998 [B4]). Si el esfuerzo de V&V utiliza la documentación de prueba o los tipos de la prueba diferentes de ésas en este estándar (es decir, componente, integración, sistema, aceptación), el esfuerzo del software V&V demostrará traz de la documentación de prueba propuesta y la ejecución a los artículos de la prueba definidos en este estándar. Las tareas del planeamiento de prueba definidas en la tabla 1 serán documentadas en el plan de prueba, los diseños de la prueba, los casos de la prueba, y la prueba procedimientos.

6.3.2 Documentación de SVVP

El esfuerzo de V&V generará un SVVP que trate los asuntos descritos en la cláusula 7 de este estándar. Si no hay información pertinente a un asunto, el SVVP contendrá la frase “que este asunto no es aplicable a este plan” y que indicará una razón apropiada de la exclusión. Los asuntos adicionales se pueden agregar al plan. Si el material de algún SVVP aparece en otros documentos, el SVVP puede repetir el material o hacer referencia al material. El SVVP será mantenido a través de la vida del software.

7. Contorno del plan del software V&V

El SVVP contendrá el contenido descrito en esta cláusula. El usuario de este estándar puede adoptar cualquier sistema del formato y de numeración de la sección para el SVVP. Los números de la sección de SVVP enumerados en esta cláusula se proporcionan a la legibilidad de la ayuda. Un contorno del ejemplo SVVP se demuestra en el texto encajonado siguiente.

Contorno de SVVP (ejemplo)

1. Propósito 2. Documentos referidos 3. Definiciones 4. Descripción de V&V 4.1 Organización 4.2 Horario principal 4.3 Esquema del nivel de la integridad de software 4.4 Recursos sumarios 4.5 Responsabilidades 4.6 Herramientas, técnicas, y métodos 5. Procesos de V&V 5.1 Proceso: Gerencia 5.1.1 Actividad: Gerencia de V&V 5.2 Proceso: Adquisición 5.2.1 Actividad: Ayuda de adquisición V&V 5.3 Proceso: Fuente 5.3.1 Actividad: Planeamiento V&V 5.4 Proceso: Desarrollo 5.4.1 Actividad: Concepto V&V 5.4.2 Actividad: Requisitos V&V 5.4.3 Actividad: Diseño V&V 5.4.4 Actividad: Puesta en práctica V&V 5.4.5 Actividad: Probar V&V 5.4.6 Actividad: Proceso de la instalación y de la comprobación V&V 5.5: Operación 5.5.1 Actividad: Operación V&V 5.6 Proceso: Mantenimiento 5.6.1 Actividad: Mantenimiento V&V 6. Requisitos de divulgación de V&V 6.1 Informes de la tarea 6.2 Informes sumarios de la actividad 6.3 Informes de la anomalía 6.4 Informe final de V&V 6.5 Los estudios especiales divulgan (opcional) 6.6 Otros informes (opcionales) 7. Requisitos administrativos de V&V 7.1 Resolución y divulgación de la anomalía 7.2 Política de la iteración de la tarea 7.3 Política de la desviación 7.4 Controlar los procedimientos 7.5 Estándares, prácticas, y convenciones 8. Requisitos de la documentación de prueba de V&V

7.1 SVVP sección 1: Objetivo

El SVVP describirá el propósito, las metas, y el alcance del esfuerzo del software V&V, incluyendo renuncias de este estándar. El SVVP también identificará los procesos y los productos específicos del software cubiertos por esfuerzo del software V&V. La fecha de emisión y estado, la identificación de publicar la organización, y la identificación de la autoridad de la aprobación serán proporcionadas.

7.2 SVVP sección 2: Documentos de Referencia

El SVVP identificará los documentos de la conformidad, los documentos referidos por el SVVP, y cualquier documento de soporte que suple o que pone el SVVP en ejecución.

7.3 SVVP sección 3: Definiciones

El SVVP definirá o se referirá a todos los términos usados en el SVVP, incluyendo los criterios para clasificar una anomalía como anomalía crítica. Todas las abreviaturas y notaciones usadas en el SVVP también serán descritas.

7.4 SVVP sección 4: V&V overview

El SVVP describirá la organización, el horario, el esquema del nivel de la integridad de software, recursos, responsabilidades, las herramientas, las técnicas, y los métodos necesarios para realizar el software V&V.

7.4.1 SVVP sección 4.1: Organización

El SVVP describirá la organización del esfuerzo de V&V, incluyendo el grado de independencia requerido (véase el anexo C). El SVVP describirá la relación de los procesos de V&V a otros procesos, tales como desarrollo, gerencia de proyecto, garantía de calidad, y gerencia de la configuración. El SVVP describirá las líneas de la comunicación dentro del esfuerzo de V&V, de la autoridad para las ediciones de resolución planteadas por tareas de V&V, y de la autoridad para aprobar productos de V&V. El anexo F ilustra una carta de organización de la correlación de la muestra.

7.4.2 SVVP seccion 4.2: Calendario Maestro

El SVVP describirá el ciclo vital y los jalones del proyecto y resumirá el horario de las tareas de V&V y de los resultados de la tarea como regeneración al desarrollo, de organización, y procesos de soporte (gerencia e.g., de calidad de la garantía y de la configuración). Las tareas de V&V se deben programar para ser reperformed según la política de la iteración de la tarea. Si el ciclo vital usado en el SVVP diferencia del modelo del ciclo vital en este estándar, esta sección describirá cómo todos los requisitos del estándar están satisfechos (e.g., haciendo una remisión a este estándar).

7.4.3 SVVP seccion 4.3: Software integrity level scheme

El SVVP describirá el esquema convenido en del nivel de la integridad de software establecido para el sistema y traz del esquema seleccionado al modelo usado en este estándar. El SVVP documentará (por la inclusión o por referencia al análisis de la criticalidad) la asignación de los niveles de la integridad de software a los componentes individuales (e.g., requisitos, funciones detalladas, módulos del software, subsistemas, u otras particiones del software), donde hay niveles de la integridad de software que diferencian asignados dentro del programa.

7.4.4 SVVP section 4.4: Resources summary

El SVVP resumirá los recursos de V&V, incluyendo proveer de personal, las instalaciones, las herramientas, las finanzas, y los requisitos procesales especiales (e.g., seguridad, las derechas de acceso, y control de la documentación).

7.4.5 SVVP section 4.5: Responsibilities

El SVVP identificará una descripción de los elementos y de las responsabilidades de organización de tareas de V&V.

7.4.6 SVVP sección 4.6: Herramientas técnicas y métodos.

El SVVP describirá documentos, herramientas de HW y SW de V & V, técnicas, métodos, y ambiente de operación y prueba a usarse en el proceso de V & V. Adquisición, entrenamiento, apoyo e información de cada herramienta, tecnología y método será incluido.

El SVVP deberá documentar las medidas a usarse por la V & V (ver anexo E) y deberá describir como estas medidas apoyan los objetivos de la V & V.

7.5 SVVP Sección 5: Procesos de V & V.

El SVVP identificará las actividades de V & V y las tareas a realizarse para cada uno de los procesos de V & V descritos en la cláusula 5 de este estándar, y documentará dichas tareas y actividades de V & V. El

SVVP contendrá una visión general de las actividades de V & V y tareas para todos los procesos del ciclo de vida del SW.

7.5.1 Secciones 5.1 a la 5.6: Ciclo de vida del SW

El SVVP incluirá las secciones 5.1 a la 5.6 para actividades de V & V y tareas como se muestra en el boceto de SVVP (caja de texto).

El SVVP direccionará los siguientes ocho temas para cada actividad de V & V:

1) Tareas de V & VEl SVVP identificará las tareas de V & V a ser realizadas. La tabla 1 describe el mínimo de tareas de V & V, criterio de tareas, y entradas y salidas requeridas. La tabla 2 especifica el mínimo de tareas que serán realizadas por cada nivel de integridad de SW.

2) Métodos y procedimientosEl SVVP describirá los métodos y procedimientos para cada tarea, incluyendo acceso en línea, y condiciones para observación/evaluación de los procesos de desarrollo. El SVVP definirá el criterio para la evaluación de los resultados de las tareas.

3) EntradasEl SVVP identificará las entradas requeridas para cada tarea de V & V. El SVVP especificará la fuente y formato para cada entrada. Las entradas requeridas para el mínimo de tareas de V & V están identificadas en la tabla 1. Otras entradas podrán ser usadas. Para cualquier actividad y tarea de V & V, todas las entradas y salidas requeridas de actividades y tareas precedentes podrán ser usadas, pero para concisión, sólo las entradas primarias están listadas en la tabla 1.

4) SalidasEl SVVP identificará las salidas requeridas para cada tarea de V & V. El SVVP especificará el propósito, formato, y recipientes de cada salida. Las salidas requeridas de cada una de las tareas de V & V están identificadas en la tabla 1. Otras salidas podrán ser producidas.

Las salidas del manejo de V & V y de las tareas de V & V se convertirán en entradas de procesos y actividades subsecuentes, según deba (ver cláusula 6)

5) ProgramaciónEl SVVP describirá la programación de las tareas de V & V. El SVVP establecerá hitos específicos para iniciar y completar cada tarea, para la recepción y criterio de cada entrada, y para la entrega de cada salida.

6) Recursos

EL SVVP identificará los recursos para la realización de las tareas de V & V. El SVVP especificará los recursos por categoría (ej., personal, equipo, instalaciones, viajes, y entrenamiento). Los costos de los recursos y actividades de V & V serán entregados o referenciados.

7) Riesgos y suposicionesEl SVVP identificará los riesgos (ej. programación, recursos o aproximación técnica) y suposiciones asociadas a las tareas de V & V. El SVVP proveerá recomendaciones a eliminar, reducir o mitigar riesgos.

8) Papeles y responsabilidades.

El SVVP identificará los elementos o individuos organizacionales responsables de realizar las tareas de V & V.

7.6 SVVP sección 6: Requerimientos de reporte de V & V.

El SVVP especificará el propósito, contenido, formato, recipientes, y tiempo de todos los reportes de V & V. Los requerimientos de reportes de V & V están especificados en la cláusula 6.

7.7 SVVP sección 7: requerimientos administrativos

El SVVP describirá la resolución de anomalías y los reportes, la política de iteración de tareas, la política de desviación, los procedimientos de control, estándares, prácticas y convenciones.

7.7.1 SVVP Sección 7.1: Resolución de anomalías y reportes

El SVVP describirá el método de reportes y de resolución de anomalías, incluyendo el criterio para reportar una anomalía; La lista de distribución de reporte de anomalías; La autoridad y línea de tiempo para resolver anomalías; y los niveles de criticidad de las anomalías. La clasificación de las anomalías de SW pueden ser encontradas en IEEE std 1044- 1993 {B8}

7.7.2 SVVP Sección 7.2: Políticas de iteración de tareas.

El SVVP describirá el criterio usado para determinar qué tareas estarán exentas de ser repetidas cuando su entrada ha cambiado o el procedimiento de la tarea ha cambiado. Este criterio puede incluir asesoramientos de cambio, nivel de integridad de SW, y efectos en el presupuesto, programación y calidad.

7.7.3 SVVP Sección 7.3: Políticas de desviación

El SVVP describirá los procedimientos y criterios usados para desviarse del plan. La información requerida para las desviaciones deberán incluir identificación, racionalidad, y efectos en la calidad de SW. El SVVP identificará a las autoridades responsables para aprobar las desviaciones.

7.7.4 SVVP Sección 7.4: Procedimientos de control.

El SVVP identificará los procedimientos de control aplicados al esfuerzo de la V & V. Estos procedimientos describirán como se deberán configurar, proteger y almacenar los productos de SW y los resultados de V & V.

Estos procedimientos podrían describir el aseguramiento de la calidad, el manejo de la configuración, el manejo de los datos, u otras actividades si éstas no están direccionadas a otros esfuerzos. El SVVP describirá como el esfuerzo de V & V conformará la existencia de provisiones de seguridad y cómo la validez de los resultados de V & V serán protegidos de alteraciones no autorizadas.

7.7.5 SVVP Sección 7.5: Estándares, prácticas y convenciones.

El SVVP identificará los estándares, prácticas, y convenciones que gobiernen la realización de las tareas de V & V incluyendo estándares organizacionales, prácticas y políticas internas.

7.8 SVVP Sección 8: Requerimientos de documentación de pruebas de V & V

El SVVP describirá el propósito, formato, y contenido de los siguientes documentos de pruebas de V & V:1) Plan de prueba2) Diseño de prueba3) Casos de prueba4) Procedimientos de prueba5) Resultados de prueba

El esfuerzo de V & V podría definir el formato para estos documentos. IEEE Std 829-1998 {B4} contiene formatos de muestra para estos documentos de prueba.

Tabla 1- Tareas, entradas y salidas de V & V

5.1.1 Actividad: Manejo del esfuerzo de V & V (Proceso: Gerencia)

Tareas de V&V Entradas requeridas Salidas requeridas

(1) Generación de SVVP

a) Generar un SVVP para todos los procesos de ciclo de vida. El SVVP podría requerir actualización a través del ciclo de vida. Salidas de otras actividades son entradas del SVVP.b) Establecer una línea base anterior a los requerimientos de las actividades de V & V.c) Identificar los hitos de proyecto en el SVVPd) Programar tareas de V & V para apoyar las revisiones del manejo de proyecto y revisiones técnicas.

Ver Cláusula 7 para un ejemplo del contenido de SVVP

SVVP (Previa actualización)ContratoDocumentación de conceptos (ej. Declaración de necesidades, reporte del plan de avances, memo de inicialización del proyecto, requerimientos del sistema, procedimientos, políticas, regulaciones, aceptación por parte del cliente de los criterios y los requerimientos, documentación de adquisición, reglas de negocio, arquitectura del sistema.)Desarrollo de planes y programación del proveedor.

SVVP y actualizaciones

(2)Propuestas/Cambios en los asesoramientos.

a) Evaluar los cambios de SW propuestos (ej. modificaciones, mejoramientos, y añadimientos como resultado de correcciones anómalas o cambios de requerimientos) para efectos en los sistemas y tareas de V & V previamente completadas.b) Iteración de planes de tareas involucradas o inicio de nuevas tareas para direccionar cambios propuestos de SW o cambios de línea de base asociados con un desarrollo de proceso iterativo.c) Verificar y validar que el cambio es consistente con los requerimientos del sistema y no afecte inversamente los requerimientos directa o indirectamente. Un efecto inverso es un cambio que podría crear daños al sistema nuevo o impactar previos daños resueltos y riegos.

SVVP

Cambios propuestos

Reporte de análisis de daños

Riesgos identificados por tareas de V & V

Desarrollo de planes y programación del proveedor.

Productos del fabricante (Producidos hasta la fecha)

Reporte de tareas propuestas/Cambio de asesoramiento

SVVP actualizado

Reportes de anomalías

5.1.1 Actividad: Manejo del esfuerzo de V & V (Proceso: Gerencia) (continuación)

Tareas de V&V Entradas requeridas

Salidas requeridas

(3) Revisión por parte de la gerencia del esfuerzo de V &V

a) Revisar y resumir el esfuerzo de V & V para definir los cambios a las tareas de V & V o redireccionar el esfuerzo de V & V.b) Evaluar cada anomalía por su impacto en el sistema de SW y asesorar si es o no una anomalía crítica (ej. IEEE Std 1044-1993 [B8]). El alcance y aplicación de las actividades de V & V deberán ser revisadas para direccionar las causas de estas anomalías y riesgos.c) Recomendar proceder al siguiente set de V & V y desarrollo de actividades del ciclo de vida, y proveer reportes de tareas, reportes de anomalías, y reporte de resumen de actividades de V & V a las organizaciones identificadas en el SVVP.d) Verificar que todas las tareas de V & V conformen los requerimientos de tareas definidas en el SVVPe) Verificar que los resultados de las tareas de V & V tengan una base de evidencia que apoye los resultados.f) Asesorar todos los resultados de V & V y proveer sugerencias para la aceptación y certificación del programa como entrada del reporte final de V & V.g) Usar los resultados de la revisión para identificar oportunidades de mejora del proceso a través de la V & V.h) Revisar la calidad de los productos y servicios para asegurar que cumplan con los requerimientos del cliente.i) Revisar los riegos del programa e iniciar acciones para mitigar los riesgos cercanos.j) Revisar la medida del programa para asegurar la calidad y los procesos del producto.

Desarrollo de planes y programación del proveedor.

SVVP y actualizaciones

Reportes de anomalías

Resultados de las tareas de V &V (ej. logros técnicos, reportes V & V, utilización de recursos, medidas de V & V (Ver anexo E), planes y riesgos identificados)

Sugerencias del reporte de tareas.

SVVP actualizado

Resumen de actividades de V & V

Sugerencias del reporte final de V & V

(4)Gerencia y apoyo en la revisión técnica.

a) Apoyar las revisiones de la gerencia del proyecto y revisiones técnicas (el. revisión preliminar del diseño, y revisión del diseño crítica) por medio de asesorar los materiales de revisión, checando las revisiones, y proveyendo reporte de tareas y de anomalías.

b) Verificar el tiempo de entrega de acuerdo al horario aprobado de todos los productos y documentos del SW.

Resultados de las tareas de V & V

Materiales para revisión (ej. SRS, IRS, SDD, IDD, documentos de prueba)

Reporte de Tareas

Revisión de resultados

Reporte(s) de anomalías

5.1.1 Actividad: Manejo del esfuerzo de V & V (Proceso: Gerencia) (continuación)

Tareas de V&V Entradas requeridas

Salidas requeridas

(5)Interfaz con los procesos organizacionales y de soporte.

a) Coordinar el esfuerzo de V & V con procesos y soporte organizacionales (ej. gerencia, mejoramiento, aseguramiento de la calidad, revisión de componentes y resolución problemas).b) Identificar la información de V & V a intercambiarse con estos procesosc) Documentar la información de intercambio de requerimientos en el SVVP.

SVVP

Información identificada en el SVVP de procesos organizacionales y de soporte

SVVP actualizado

(6) Identificar la mejora de oportunidades de procesos a través de V & V.

a) Recopilar y analizar las lecciones aprendidasb) recopilar y analizar los riesgos identificadosc) Recopilar y analizar las medidas de V & Vd) Identificar y analizar las deficiencias en los procesos de V & Ve) Determinar e implementar acciones correctivas (ej. repetir tareas de V & V o conducir una nueva tarea de V & V para direccionar la acción correctiva o usar una técnica/método diferente para ejecutar una tarea de V & V).f) Monitorear la eficacia de acciones correctivasg) Documentar elementos encontrados en el reporte final.

SVVP

Resultados de análisis

Final anterior de reportes de actividades

Reporte de tareas

SVVP actualizado

Entrada en el final del reporte de actividad

Entrada en el reporte final

Nueva/actualizada V & V políticas/procedimientos/reportesInfraestructura de V & V actualizada

5.2.1 Actividad : Adquisición de apoyo de V & V (Proceso: Adquisición)

Tareas de V&V Entradas requeridas

Salidas requeridas

(1) Alcance del esfuerzo de la V & V

a) Determinar las características del SW (ej. Complejidad, criticidad, riesgo, nivel de seguridad, desempeño deseado, confiabilidad u otras características únicas de proyecto) que definan la importancia del SW para el usuario.b) Adoptar el esquema de integridad del sistema asignado al proyecto. Si no existe tal esquema, algún esquema es seleccionado.c) Asignar un nivel de integridad de SW al sistema y al SW.d) Establecer el grado de independencia (ver anexo C), si existe alguna que requiera el SWe) Determinar el mínimo de tareas de V & V para la integridad del SW usando la tabla 2 y el esquema de nivel de integridad de SW seleccionado.f) Determinar la medida de V & V en reuso de SW seleccionado para el programa (ver anexo D).g) Determinar la medida de V & V para herramientas que inserten o traduzcan código.h) Aumentar el mínimo de tareas de V & V con tareas de V & V opcionales, como necesarias. i) Proveer un estimado del presupuesto de V & V, incluyendo facilidades de prueba y herramientas como sean requeridas.

Descripción preliminar del sistema

Declaración de necesidad

RFP preliminar

Esquema de niveles de integridad del sistema

SVVP

(2)Planeación de la interfaz entre el esfuerzo y el proveedor. (Preparar la información preliminar y los procesos para la interfaz con un proveedor a seleccionar en el proceso de abastecimiento).

a) Planear la programación de V & V para cada tarea de V & V.

b) Identificar la lista preliminar de los procesos de desarrollo y productos para ser evaluados por los procesos de V & V.

c) Describir los derechos de acceso de V & V al propietario e información clasificada.

d) Incorporar el esquema del proyecto de nivel de integridad del SW al proceso de planeamiento.

SVVP

RFP Preliminar

Contrato

Reporte(s) de tareas sugerencias para el RFP

SVVP actualizado

5.2.1 Actividad : Adquisición de apoyo de V & V (Proceso: Adquisición) (continuación)

Tareas de V&V Entradas requeridas

Salidas requeridas

(3)Revisión de requerimientos del sistema

a) Revisión de los requerimientos del sistema (p.e. especificación de los requerimientos del sistema, descripción de las reglas de negocio) en el RFP.

1) Verificar la consistencia de los requerimientos a las necesidades del usuario

2) Validar si los requerimientos pueden satisfacerse por las tecnologías definidas, métodos, y algoritmos definidos para el proyecto.

3) Verificar si la información objetiva que puede demostrarse por medio de pruebas, es proveída en los requerimientos (pruebas).

b) Revisar otros requerimientos tales como definiciones de entrega, listado o compilación de los estándares y regulaciones, necesidades del usuario, para la corrección, precisión y completitividad.

Descripción preliminar del sistema

Declaración de la necesidad

Necesidades del usuario RFP preliminar

Reporte(s) de tarea.

Revisión de los requerimientos del sistema Reporte(s) de anomalías

(4)Soporte de aprobación

Las siguientes actividades de V & V soportan la aprobación en el proceso de adquisición. Las actividades están descritas en el proceso de desarrollo donde las entradas para las actividades de V & V son generadas para ayudar el entendimiento del flujo de actividades.

a) Aprobación del generación del plan de prueba de V & V (5.4.2, Tarea 6)

b) Aprobación del generación del diseño de prueba de V & V (5.4.3, Tarea 10)

c) Aprobación del generación del caso de prueba de V & V (5.4.4, Tarea 8)

d) Aprobación del generación del plan de procedimiento de V & V (5.4.5, Tarea 2)

e) Aprobación de la ejecución de prueba de V & V (5.4.5, Tarea 5)

Documentación de conceptos

SDD

IDD

SRS

IRS

Código fuente

Código ejecutable

Documentación de usuario

Plan de pruebas, diseño de casos, procedimientos, resultados

Aprobación del plan de pruebaResultados de las tareas de V & V

Reporte de tareas.

Aprobación del plan de prueba de V & V, diseño(s), casos, procedimientos, resultados de prueba.

Reporte(s) de anomalías

5.3.1 Actividad: Planeación de V & V (Proceso: Provisión)

Tareas de V&V Entradas requeridas

Salidas requeridas

(1)Planeación de la interfaz entre el esfuerzo de V & V y el proveedor.(Coordinar y documentar la información de la interfaz y los procesos con el proveedor seleccionado)

a. Revisar el desarrollo de planes y programación del proveedor para coordinar el esfuerzo de V & V con las actividades de desarrollo.

b. Establecer procedimientos para intercambiar información y resultados de V & V con el esfuerzo de desarrollo

c. Coordinar el plan con el proveedor .

SVVP

Contrato

Desarrollo de planes y programación del proveedor

SVVP Actualizado

(2) Verificación del contrato

a) Verificar lo siguiente:

1) Que los requerimientos del sistema (Del RFP, y contrato) satisfagan y sean consistentes con los requerimientos del sistema

2) Que los procedimientos estén documentados para manejar los cambios de los requerimientos y para identificar la jerarquía de la gerencia para direccionar los problemas

3) Que los procedimientos para la interfaz y la cooperación entre los grupos estén documentados, incluyendo posesión, garantía, derechos, y confidencialidad.

4) Que la aprobación de los procedimientos y criterios estén documentados en concordancia con los requerimientos.

SVVP

Requerimientos de RFP

Contrato

Necesidades del usuario

Desarrollo de planes y programación del proveedor

Reporte(s) de tareas.

Verificación del contrato

SVVP actualizado

Reporte(s) de anomalías

5.4.1 Actividad: Concepto V & V (Proceso: Desarrollo)

Tareas de V&V Entradas requeridas

Salidas requeridas

(1) Evaluación de la documentación de conceptos

a) Validar que la documentación de conceptos satisfaga las necesidades del usuario y que sea consistente con las necesidades de adquisición.

b) Validar las restricciones de los sistemas o limitaciones de las aproximaciones propuestas.

c) Analizar los requerimientos del sistema y validar que los siguientes puntos satisfagan las necesidades del usuario:

1) Funciones del sistema2) Desempeño del sistema final3) Pruebas de los requerimientos funcionales4) Diseño de la arquitectura del sistema5) Mantenimiento y operación de los requerimientos y

ambientes6) Requerimientos de migración de un sistema existente

donde sea aplicable.

Documentación de conceptos

Desarrollo de los planes y programación del proveedor

Necesidades del usuario

Necesidades de adquisición

Reporte(s) de tareas.

Evaluación de la documentación de conceptos

Reporte(s) de anomalías.

(2) Análisis de criticidad

a) Determinar si los niveles de integridad del SW son establecidos para los requerimientos, funciones detalladas, módulos de SW, subsistemas, u otras particiones de SW

b) Verificar que los niveles de integridad del SW sean correctos. Si los niveles de integridad del SW no están asignados, entonces asignar los niveles de integridad de SW a los requerimientos del sistema

c) Documentar el nivel de integridad del SW asignados a los componentes individuales de SW (p.e. requerimientos, funciones detalladas módulos de SW, subsistemas, u otras particiones de SW. Para propósitos de planeación de V & V, el sistema de SW asignará el mismo nivel de integridad como el nivel más alto asignado a cualquier elemento individual.

d) Verificar si cualquier componente de SW puede influenciar componentes individuales de SW, asignar un nivel de integridad de SW más alto, y si tales condiciones existen, entonces asignar a ese componente de SW el mismo alto nivel de integridad de SW.

.

Documentación de conceptos (requerimientos del sistema)

Nivel de tareas de integridad del desarrollador.

Reporte(s) de tareas. Análisis de criticidad

Reporte(s) de anomalías

5.4.1 Actividad: Concepto V & V (Proceso: Desarrollo)(Continuación)

Tareas de V&V Entradas requeridas

Salidas requeridas

(3)Hardware/SW/Requerimientos del usuario

Verificar la completitud, corrección, y exactitud del alojamiento del concepto de requerimientos al HW, SW e interfaces de usuario contra las necesidades del usuario.

a) Corrección

Verificar que el desempeño de los requerimientos (p.e. tiempo, tiempo de respuesta) alojadas al HW, SW, e interfaces del usuario satisfagan las necesidades del mismo.

b) Exactitud

Verificar que las interfaces internas y externas especifiquen los formatos de información, protocolos de interfaz, frecuencia de intercambio de información en cada interfaz, y otros requerimientos de desempeño claves demuestren la satisfacción de los requerimientos del sistema

c) Completitud

1) Verificar que los requerimientos específicos de aplicación tales como diversidad funcional, detección de faltas, aislamiento de faltas, y recuperación de errores satisfagan las necesidades del usuario2) Verificar que los requerimientos de mantenimiento del usuario para el sistema estén completamente especificados3) Verificar que la migración del sistema existente y el reemplazo del sistema satisfagan las necesidades del usuario.

Necesidades del usuario

Documentación de los conceptos

Reporte(s) de tarea.

Requerimientos del HW/SW/usuario.

Análisis

Reporte(s) de anomalías

(4) Análisis de rastreabilidad

a) Identificar todos los requerimientos del sistema que serán implementados completa o parcialmente por el SWb) Verificar Que estos requerimientos del sistema sean rastreables a las necesidades de adquisiciónC) Iniciar el análisis de rastreabilidad de los requerimientos de SW con los requerimientos del sistema

Entradas requeridas

Documentación de conceptos

Reporte(s) de tareas.

Análisis de rastreabilidad

Reporte(s) de anomalías.

5.4.1 Actividad: Concepto V & V (Proceso: Desarrollo)(Continuación)

Tareas de V&V Entradas requeridas

Salidas requeridas

(5) Análisis de peligros

a) Analizar los peligros potenciales hacia y desde el sistema conceptual.El análisis deberá:

1) Identificar los peligros potenciales del sistema2) Asesorar la severidad de cada peligro3) Asesorar la probabilidad de cada peligro4) Identificar las estrategias de mitigación para cada peligro.

Documentación de los conceptos

Reporte(s) de tarea. Análisis de peligros

Reporte(s) de anomalías

(6) Análisis de seguridad

a) Revisar la definición del dueño del sistema para un nivel aceptable de riesgo de seguridad.

b) Analizar el concepto de sistema desde una perspectiva de seguridad, y asegurar que los riesgos potenciales de seguridad con respecto a la confidencialidad (revelación de información sensible), integridad (alteración de la información), disponibilidad (mostrar información o servicios), y contabilidad (atribuir acciones a un individuo / proceso) hayan sido identificadas. Incluir una asesoría de sensibilidad de la información a ser procesada.

c) Analizar los riesgos de seguridad introducidos por el propio sistema como aquellos asociados con el ambiente con el cual el sistema interactúa.

Documentación de conceptos Amenaza preliminar y asesoría de riesgo (TRA)

Reporte(s) de tareas. -Análisis de seguridad

Reporte(s) de anomalías.

(7) Análisis de riesgos

a) Identificar los riesgos técnicos y de manejo

b) Proveer recomendaciones para eliminar, reducir o mitigar riesgos

Documentación de conceptos Desarrollo de planes y programación del proveedor

Reporte de análisis de peligros

Análisis de seguridad

Resultados de las tareas de V & V.

Reporte(s) de tareas. -Análisis de riesgo

Reporte(s) de anomalías.

5.4.2 Actividad: V&V de requerimientos (Proceso: Desarrollo) Tareas de V&V Entradas

requeridasSalidas requeridas

(1) Análisis de rastreabilidad

Calcar los requerimientos del SW (SRS e IRS) a los requerimientos del sistema (documentación de conceptos) y los requerimientos del sistema a los requerimientos del SW.

Analizar relaciones identificadas para corrección, consistencia, completitud y exactitud. Los criterios de tareas son:

a) Corrección. Validar que las relaciones entre cada requerimiento de SW y los requerimientos del sistema sean correctos

b) Consistencia. Verificar que la relación entre los requerimientos del sistema y del SW estén especificados a grado de detalle.

c) Completitud.1) Verificar que cada requerimiento de SW sea

rastreable a un requerimiento de sistema con suficiente detalle como para mostrar conformidad con el requerimiento del sistema

2) Verificar que todos los requerimientos del sistema emparentados con el SW sean rastreables a requerimientos de SW

d) Exactitud. Validar que el desempeño del sistema y que las características de operación estén bien estén bien especificadas por los requerimientos rastreados de SW

Documentación del concepto(requerimientos del sistema)

SRS

IRS

Reportes de actividadesAnálisis de rastreabilidad

Reporte(s) de anomalías

(2) Evaluación de los requerimientos de SW

Evaluar los requerimientos (p.e. funcionalidad, capacidad, interfaz, calificación, seguridad, factores humanos, definiciones de información, documentación del usuario, instalación y aceptación, operación del usuario y mantenimiento del usuario) de la corrección, consistencia, completitud, exactitud, pruebas y lecturas del SRS e IRS. Los criterios de tarea son:

a) Corrección1) Verificar y validar que los requerimientos de SW satisfagan los requerimientos del sistema, alojados en el SW dentro de las suposiciones, restricciones, y operaciones del ambiente para el sistema2) verificar que los requerimientos del SW cumplan con los estándares, referencias, regulaciones, políticas, leyes físicas y reglas de negocio.3)Validar las secuencias de los estados y los cambios de estado, usando flujos lógicos y de información junto con experiencia de dominio, resultados de prototipo, principios ingenieriles u otras bases.4) Validar que el flujo de la información y control, satisfagan funcionalidad y requerimientos de desempeño5) Validar el uso y formato de la información

Documentación del concepto(requerimientos del sistema)

SRS

IRS

Reportes de tareas. – Evaluación de los requerimientos de SW

Reporte(s) de anomalías

5.4.2 Actividad: V&V de requerimientos (Proceso: Desarrollo) (continuación)

Tareas de V&V Entradas requeridas

Salidas requeridas

(2) Evaluación de los requerimientos de SW (continuación)

b) Consistencia1) Verificar que todos los términos y conceptos estén

documentados consistentemente2) Verificar que las interacciones y suposiciones de

función sean consistentes y satisfagan los requerimientos del sistema y las necesidades de adquisición.

3) Verificar que exista consistencia interna entre los requerimientos de SW y consistencia externa con los requerimientos del sistema

c) Completitud1) Verificar que los siguientes elementos estén en el SRS o en el IRS, dentro de las suposiciones y restricciones del sistema:

i) Funcionalidad (p.e. algoritmos, definiciones de estado/modo, validación de entrada/salida, manejo de excepciones, reporte y loggeo)

ii) Definición y programación de los procesos

iii) Descripciones del hardware, software y de la interfaz del usuario

iv) Criterios de desempeño (p.e. tiempo, cantidad, velocidad, capacidad, exactitud, precisión, seguridad)

v) Configuración crítica de la información.

2) Verificar que el SRS y el IRS satisfagan los procedimientos de manejo de la configuración especificada.

d) Exactitud1) Validar que la precisión lógica, computacional de

la interfaz (p.e. redondeo y truncamiento) satisfagan los requerimientos en el ambiente del sistema

2) Validar que los fenómenos físicos de modelado sean consistentes con los requerimientos de exactitud y leyes físicas del sistema.

e) Legibilidad1) Verificar que la documentación sea legible,

entendible y no ambigua para el público a quien va dirigido

2) Verificar que la documentación defina acrónimos, mnemónicos, abreviaciones, términos y símbolos.

f) Testabilidad ( Pruebas)Verificar que existan criterios de aceptación de objetivos, para validar requerimientos de SRS e IRS.

5.4.2 Actividad: V&V de requerimientos (Proceso: Desarrollo) (continuación)Tareas de V&V Entradas

requeridasSalidas requeridas

(3) Análisis de la interfaz

Verificar y validar que los requerimientos de hardware, usuario, operador y otros sistemas para la interfaz de software son correctos, consistentes, completos, exactos y testeables. Los criterios son:

a) CorrectosValidar los requerimientos internos y externos de la interfaz de software y de sistema.

b) ConsistentesVerificar que las descripciones de la interfaz son consistentes entre los SRS e IRS.

c) CompletosVerificar que cada interfaz esta descrita e incluye criterios para el formato de datos y el desempeño (por ejemplo: tiempos, ancho de banda, exactitud, seguridad).

d) ExactosVerificar que cada interfaz provee de información con la exactitud requerida.

e) TesteablesVerificar que hay un criterio objetivo de aceptación para validar los requerimientos de la interfaz

Documentación del concepto

IRS

Reportes de actividades

Analisis de la interfaz

Reporte(s) de anomalías

(4) Análisis de Criticalidad

a) Revisar y actualizar los resultados existentes del análisis de criticalidad a partir del reporte de actividades de criticalidad anterior usando los SRS e IRS.

b) Los métodos de implementación y las tecnologías para interfaz pueden causar que los niveles de integridad de software previamente asignados suban o bajen para determinado elemento de software (ejemplo: requerimiento, modulo, función, subsistema)Verificar que revisar los niveles de integridad de software no introduzca consecuencias inconsistentes o no deseadas.

Reporte de actividades de criticalidad

SRS

IRS

Reporte(s) de actividades

Análisis de criticalidad

Reporte(s) de anomalías

5.4.2 Actividad: V&V de requerimientos (Proceso: Desarrollo) (continuación)Tareas de V&V Entradas

requeridasSalidas requeridas

(5) Generacion del plan de pruebas V&V del sistema

a) Niveles 3 y 4 de integridad de software1) Planear las pruebas de V&V del sistema para validar

requerimientos de software.2) Planear el trazado de requerimientos del sistema para

diseños casos, procedimientos y resultados de prueba.3) Planear documentación de diseños, casos, procedimientos y

resultados de prueba.4) El plan de pruebas de V&V de sistema debe tener lo

siguiente: i) Conformidad a todos los requisitos del sistema (e.g.,

funcionalidad, desempeño, seguridad, operación, y mantenimiento) como elementos finales de software completos en el ambiente de sistema

ii) Adecuación a la documentación del usuario (ejemplo: training, materiales y cambios del procedimiento)

iii) Funcionamiento en los límites (ejemplo: datos, interfaces) y bajo condiciones de estrés.

5) Verificar que el plan de pruebas de V&V del sistema satisfaga los siguientes criterios:i) Conformidad con el propósito, formato y contenido del

documento de pruebas definido para el proyecto. (ejemplo: ver IEEE Std 829-1998 [B4])

ii) Probar que se cubran los requerimientos del sistema6) Validar que el plan de pruebas de V&V del sistema

satisfaga los siguientes criterios:i) Que los métodos y estándares de pruebas usados sean

apropiadosii) Conformidad con los resultados esperadosiii) Viabilidad de la prueba de calificación del sistemaiv) Viabilidad y testeabilidad para requerimientos de

operación y mantenimientob) Niveles 1 y 2 de integridad de software.

1) Verificar que el plan de pruebas de sistema del desarrollador satisfaga los siguientes criterios:i) Conformidad con el propósito, formato y contenido del

documento de pruebas definido para el proyecto. (ejemplo: ver IEEE Std 829-1998 [B4])

ii) Probar que se cubran los requerimientos del sistema2) Validar que el plan de pruebas de sistema del desarrollador

satisfaga los siguientes criterios: i) Que los métodos y estándares de pruebas usados

sean apropiadosii) Conformidad con los resultados esperadosiii) Viabilidad de la prueba de calificación del sistemaiv) Capacidad de ser operado y mantenido

Documentación del concepto(requerimientos del sistema)

SRS

IRS

Documentación del usuario

Plan de prueba del sistema

Reportes de actividades

Plan de pruebas de V&V del sistema

Reporte(s) de anomalías

5.4.2 Actividad: V&V de requerimientos (Proceso: Desarrollo) (continuación)Tareas de V&V Entradas

requeridasSalidas requeridas

(5) Generacion del plan de pruebas V&V de aceptación

a) Niveles 3 y 4 de integridad de software1) Planear las pruebas de V&V de aceptación para validar que

el software implemente correctamente los requerimientos de software y de sistema en un entorno operacional.

2) Planear el trazado de requerimientos de aceptación para diseños casos, procedimientos y resultados de prueba.

3) Planear documentación de actividades y resultados de prueba.

4) El plan de pruebas de V&V de aceptación debe tener lo siguiente: i) Conformidad a los requisitos de aceptación en el

entorno operacional.ii) Adecuación a la documentación del usuario

5) Verificar que el plan de pruebas de V&V de aceptación satisfaga los siguientes criterios:i) Conformidad con el propósito, formato y contenido del

documento de pruebas definido para el proyecto. (ejemplo: ver IEEE Std 829-1998 [B4])

ii) Probar que se cubran los requerimientos de aceptación6) Validar que el plan de pruebas de V&V de aceptación

satisfaga los siguientes criterios:i) Que los métodos y estándares de pruebas usados sean

apropiadosii) Conformidad con los resultados esperadosiii) Viabilidad para operación y mantenimiento (ejemplo

capacidad de ser operado y mantenido de acuerdo a las necesidades del usuario)

b) Nivel 2 de integridad de software.1) Verificar que el Plan de pruebas de aceptación del

adquisidor sea conforme al propósito, formato y contenido definido para el proyecto (ejemplo: ver IEEE Std 829-1998 [B4]).

2) Validar que el plan de pruebas de aceptación del adquisidor satisfaga los siguientes criterios. i) Probar que se cubran los requerimientos de aceptaciónii) Conformidad con los resultados esperadosiii) Viabilidad de operación y mantenimiento (ejemplo:

Capacidad de ser operado y mantenido de acuerdo a las necesidades del usuario)

c) Nivel 1 de integridad de software,No se requieren pruebas de aceptación

Documentación del concepto(requerimientos del sistema)

SRS

IRS

Documentación del usuario

Plan de prueba de aceptación

Reportes de actividades

Plan de pruebas de V&V de aceptación

Reporte(s) de anomalías

IEEE

Std 1012-2004 ESTANDAR IEEE

5.4.2 Actividad: V&V de requerimientos (Proceso: Desarrollo) (continuación)Tareas de V&V Entradas

requeridasSalidas requeridas

(7) Asignación de la gestión de la configuración

Verificar que el proceso de administración de la configuración sea completo y adecuado, Los criterios son:a) CompletoVerificar que hay un proceso para describir la funcionalidad del software, seguimiento de versiones de programas y administración de cambios.b) AdecuadoVerificar que el proceso de administración de la configuración sea adecuado para la complejidad del desarrollo, tamaño del sistema y del software, nivel de integridad de software, planes de proyectos y necesidades del usuario.

Documentación del proceso de gestión de la configuración del Software

Reportes de actividades

Configurationmanagementassessment

Reporte(s) de anomalías

(8) Análisis de Hazard

a) Determinar las contribuciones del programa a los peligros del sistema. El análisis de hazard deberá:

1. Identificar los requerimientos de software que contribuyan a cada peligro del sistema

2. Validar que el software controla o mitiga cada peligro

SRS

IRS

Reporte de análisis de Hazard

Reporte(s) de actividades

Análisis de Hazard

Reporte(s) de anomalías

(9) Análisis de seguridad

a) Determinar que los requerimientos de seguridad identificados en el SRS e IRS encuentren los riesgos de seguridad introducidos por el concepto del sistema.b) Verificar que los requerimientos de seguridad del sistema mitigarán los riesgos de seguridad identificado en un nivel aceptable.

SRS

IRS

TRA Preliminar

Reporte(s) de actividades

Análisis de seguridad

Reporte(s) de anomalías

(10) Análisis de riesgos.

a) Revisar y actualizar análisis de riesgos usando los reportes anteriores de actividades.

b) Proporcionar recomendaciones para eliminar, reducir o mitigar los riesgos.

Documentación del concepto

SRS

IRS

Planes y horario del proveedor del desarrollo

Reporte de análisis de Hazard

Análisis de seguridad

Resultados de la actividad de V&V

Reporte(s) de actividades

Análisis de riesgos

Reporte(s) de anomalías

60Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

5.4.3 Actividad: Diseño V&V (Proceso: Desarrollo) Tareas de V&V Entradas

requeridasSalidas requeridas

(1) Análisis de trazabilidad

Trazar los elementos de diseño (SDD e IDD) a requerimientos (SRS e IRS), y los requerimientos a elementos de diseño. Analizar que las relaciones sean correctas, consistentes y estén completas. Los criterios son:

a) CorrectasValidar la relación entre cada elemento de deiseño y los requerimientos de software.

b) ConsistentesVerificar que las relaciones entre los elementos de diseño y los requerimientos de software estén especificadas en un nivel de detalle consistente.

c) Completas1. Verificar que todos los elementos de diseño son trazables desde los requerimientos de software.2. Verificar que todos los requerimientos de software son trazables a los elementos de diseño.

SRS

SDD

IRS

IDD

Reporte(s) de actividades

Análisis de trazabilidad

Reporte(s) de anomalías

(2) Evaluación del diseño del software

Evaluar que los elementos del diseño (SDD e IDD) sean correctos, consistentes, completos, exactos, legibles y testeables. Los criterios son:a) Correctos

1) Verificar y validar que el diseño del software satisfaga los requerimientos.

2) Verificar que el diseño de software cumpla con estándares, referencias, regulaciones, políticas, leyes físicas y reglas de negocio.

3) Validar las secuencias de estados y cambios de estado del diseño usando lógica y flujos de datos apoyados en experiencia, principios ingenieriles, resultados de los prototipos u otras bases.

4) Validar que el flujo de datos y el control satisfagan requerimientos de funcionalidad y rendimiento.

5) Validar el formato y uso de datos.6) Determinar la conveniencia de los métodos y de los

estándares de diseñob) Consistentes.

Verificar que todos los términos y conceptos del diseño sean documentados constantemente.

Verificar que haya consistencia interna entre los elementos del diseño y consistencia externa con la arquitectura del diseño.

c) Completos1) Verificar que los siguientes elementos estén en el SDD, con

las suposiciones del sistema i) Funcionalidad (e.g., algoritmos, definiciones, entrada/salida,

validación, manejo de excepciones reportes y autenticación) ii) Definicion y programación del proceso iii) Descripción del hardware, software y de la interfaz de usuario iv) Criterios de rendimiento (e.g., tiempos, tamaño, velocidad,

SRS

IRS

SDD

IDD

Estándares de diseño(ej. estándares,prácticas y convenciones)

Reporte(s) de actividades

Evaluación del diseño del software

Reporte(s) de anomalías

61Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

capacidad, exactitud, precisión, confiabilidad y seguridad) v) Datos críticos de la configuración. vi) Control del sistema, del dispositivo y del software (e.g.,

monitoreo del arranque, las transacciones y el estado) 2) Verificar que SDD e IDD satisfagan los procesos de

configuración de la administración especificadosd) Exactos

1) Validar la presición lógica, computacional y de la interfaz (e.g., truncamiento y redondeo) en el entorno del sistema.

2) Validar que los fenómenos físicos modelados se conforman con los requisitos de la exactitud del sistema y las leyes físicas.

5.4.3 Actividad: Diseño V&V (Proceso: Desarrollo) (continuación)Tareas de V&V Entradas

requeridasSalidas requeridas

(2) Evaluación del diseño del software (continuación)

e) Legibles1) Verificar que la documentación es legible, entendible y no

es ambigua para los usuarios.2) Verificar que la documentación defina todos los acrónimos,

mnemónicos, abreviaciones, términos y símbolos, si hay alguno.

f) Testeables.1) Verificar que hay un criterio de aceptación objetivo para

validar cada elemento del diseño y el diseño del software.2) Verificar que cada elemento del diseño de software es

testeable contra un criterio objetivo de aceptación.

SRS

IRS

SDD

IDD

Estándares de diseño

Reporte(s) de actividades

Evaluación del diseño del software

Reporte(s) de anomalías

(3) Análisis de la interfaz

Verificar y validar que las interfaces de diseño de software con hardware, usuario, operador y otros sistemas son correctos, consistentes, completos, exactos y testeables. Los criterios son:

a) CorrectosValidar las interfces de diseño de software internas y externas en el contexto de requerimientos del sistema.b) ConsistentesVerificar que el diseño de la interfaz sea consistente entre el SDDe IDDc) CompletosVerificar que cada interfaz esta descrita e incluye criterios para el formato de datos y el desempeño (por ejemplo: tiempos, ancho de banda, exactitud, seguridad).d) ExactosVerificar que cada interfaz provee de información con la exactitud requerida.e) TesteablesVerificar que hay un criterio objetivo de aceptación para validar el diseño de la interfaz

Documentación del concepto(requerimientos del sistema)

SRS

IRS

SDD

IDD

Reportes de actividades

Análisis de la interfaz

Reporte(s) de anomalías

(4) Análisis de Criticalidad

a) Revisar y actualizar los resultados existentes del análisis de criticalidad a partir del reporte de actividades de criticalidad anterior usando el SDD e IDD

b) Los métodos de implementación y las tecnologías para interfaz pueden causar que los niveles de integridad de

Reporte de actividades de criticalidad

SDD

IDD

Reporte(s) de actividades

Análisis de criticalidad

Reporte(s) de

62Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

software previamente asignados suban o bajen para determinado elemento de software (ejemplo: requerimiento, modulo, función, subsistema)

Verificar que revisar los niveles de integridad de software no introduzca consecuencias inconsistentes o no deseadas

anomalías

5.4.3 Actividad: V&V de diseño (Proceso: Desarrollo) (continuación)Tareas de V&V Entradas

requeridasSalidas requeridas

(5) Generación del plan de pruebas V&V de componente

a) Niveles 3 y 4 de integridad de software1) Planear las pruebas de V&V de componente para validar

componentes de software.2) Planear el trazado de requerimientos de de diseño para

diseño casos, procedimientos y resultados de prueba.3) Planear documentación de actividades y resultados de

prueba.4) El plan de pruebas de V&V de componente debe tener lo

siguiente: i) Conformidad a los requerimientos de diseño ii) Asignación de tiempos, tamaño y exactitudiii) Funcionamiento en los límites e interfaces y bajo

condiciones de errores y de estrés.iv) Medir si se cubren los requerimientos y de la

mantenibilidad y confiabilidad del software.5) Verificar que el plan de pruebas de V&V de componente se

conforme al proposito, formato y contenido del documento de pruebas definido para el proyecto. (ejemplo: ver IEEE Std 829-1998 [B4])

6) Validar que el plan de pruebas de V&V de componente satisfaga los siguientes criterios:i) Trazable a los requerimientos y diseño de softwareii) Consistencia externa con los requerimientos y diseño de

softwareiii) Consistencia interna entre requerimientos unitariosiv) Probar que se cubran los requerimientos en cada

unidadv) Viabilidad para integrar y probar el softwarevi) Viabilidad de operación y mantenimiento

b) Nivel 2 de integridad de software.1) Verificar que el plan de pruebas de componente del

desarrollador sea conforme con el propósito, formato y contenido del documento de pruebas definido para el proyecto. (ejemplo: ver IEEE Std 829-1998 [B4])

2) Validar que el plan de pruebas de componente del desarrollador satisfaga los siguientes criterios: i) Trazable a los requerimientos y diseño de softwareii) Consistencia externa con los requerimientos y diseño de

softwareiii) Consistencia interna entre requerimientos unitariosiv) Probar que se cubran los requerimientos en cada

unidadv) Viabilidad para integrar y probar el softwarevi) Viabilidad de operación y mantenimiento

c) Nivel 1 de integridad de software. No se requieren pruebas de componente

SRS

SDD

IRS

IDD

Plan de prueba de componente

Plan de pruebas de V&V de componente

Reporte(s) de anomalías

63Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

(6) Generación del plan de pruebas V&V de integración

a) Niveles 3 y 4 de integridad de software1) Planear las pruebas de V&V de integración para validar

que el software implemente correctamente los requerimientos y diseño de software al tiempo que cada componente de software (ejemplo: unidades o modulos) se integra incrementalmente con otro.

2) Planear el trazado de requerimientos de de diseño para diseño casos, procedimientos y resultados de prueba.

3) Planear documentación de actividades y resultados de prueba.

4) El plan de pruebas de componente debe tener lo siguiente: i) Conformidad a un set de requerimientos funcionales

creciente en cada estado de integraciónii) Asignación de tiempos, tamaño y exactitudiii) Desempeño en los límites y bajo condiciones de

estrés.iv) Medir si se cubren los requerimientos y la confiabilidad

del software.

SRS

SDD

IRS

IDD

Plan de prueba de componente

Plan de pruebas de V&V de componente

Reporte(s) de anomalías

5.4.3 Actividad: V&V de diseño (Proceso: Desarrollo) (continuación)Tareas de V&V Entradas

requeridasSalidas requeridas

(6) Generación del plan de pruebas V&V de integración (continuación)

1) Verificar que el plan de pruebas de V&V de integración sea conforme al propósito, formato y contenido del documento de pruebas definido para el proyecto. (ejemplo: ver IEEE Std 829-1998 [B4])

2) Validar que el plan de pruebas de V&V de integración satisfaga los siguientes criterios:i) Trazable a requerimientos del sistemaii) Consistencia externa con los requerimientos del

sistemaiii) Consistencia interna iv) Probar que se cubran los requerimientos de softwarev) Que los estándares y métodos de prueba usados

sean apropiadosvi) Conformidad con los resultados esperadosvii) Viabilidad para probar la calificación del softwareviii) Viabilidad de operación y mantenimiento

b) Niveles 1 y 2 de integridad de software.1) Verificar que el plan de pruebas de integración del

desarrollador sea conforme con el propósito, formato y contenido del documento de pruebas definido para el proyecto. (ejemplo: ver IEEE Std 829-1998 [B4])

2) Validar que el plan de pruebas de integración del desarrollador satisfaga los siguientes criterios: i) Trazable a requerimientos del sistemaii) Consistencia externa con los requerimientos del

sistemaiii) Consistencia interna iv) Probar que se cubran los requerimientos de softwarev) Que los estándares y métodos de prueba usados

sean apropiadosvi) Conformidad con los resultados esperadosvii) Viabilidad para probar la calificación del softwareviii) Viabilidad de operación y mantenimiento

SRS

SDD

IRS

IDD

Plan de prueba de componente

Plan de pruebas de V&V de componente

Reporte(s) de anomalías

64Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

(7) Generación del diseño de pruebas V&V de Componente

a) Niveles 3 y 4 de integridad de Software 1) Diseñar pruebas para probar componentes.2) Continuar el trazo requerido por el plan de pruebas V&V de

componente.3) Verificar que los diseños de pruebas V&V de Componentes

correspondan al formato, contenido y propósito del documento de pruebas definido para el proyecto (ver IEEE Std 829-1998 [B4]).

4) Validar que los diseños de pruebas V&V para de Componente satisfagan los criterios de la actividad 5.4.3, Tarea 5

b) Nivel 2 de integridad de Software1) Verificar que los diseños de pruebas V&V de componente

del desarrollador correspondan al formato, contenido y objetivo del documento de pruebas definido para el proyecto (e.g., ver IEEE Std 829-1998 [B4]).

2) Validar que los diseños de pruebas V&V de componente del desarrollador satisfagan los criterios de la actividad 5.4.3, Tarea 5

c) Nivel 1 de integridad de software No se requiere prueba de componentes

SDD

IDD

Documentación de usuario

Planes de prueba

Diseños de prueba

Diseño(s) de pruebas V&V de componente

Reporte(s) de anomalías

65Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

5.4.3 Actividad: Diseñar V&V (Proceso: Desarrollo) (continuación)Tareas de V&V Entradas

requeridasSalidas requeridas

(8) Generación del diseño de pruebas de V&V para la Integración

a) Niveles 3 y 4 de integridad de Software 1) Diseñar pruebas para evaluar la integración.2) Continuar el trazo requerido por el plan de pruebas V&V de

Integración. Verificar que los diseños de pruebas V&V de Integración correspondan al formato, contenido y propósito del documento de pruebas definido para el proyecto (e.g., ver IEEE Std 829-1998 [B4]).

3) Validar que los diseños de pruebas V&V para la integración satisfagan los criterios de la actividad 5.4.3, Tarea 6

b) Niveles 1 y 2 de integridad de Software1) Verificar que los diseños de pruebas V&V de integración del

desarrollador correspondan al formato, contenido y objetivo del documento de pruebas definido para el proyecto (e.g., ver IEEE Std 829-1998 [B4]).

2) Validar que los diseños de pruebas V&V de integración del desarrollador satisfagan los criterios de la actividad 5.4.3, Tarea 6

SDD

IDD

Usuario

Documentación

Planes de prueba

Diseños de prueba

Diseño(s) de pruebas V&V de la Integración

Reporte(s) de anomalías

(9) Generación del diseño de pruebas de V&V para el sistema

a) Niveles 3 y 4 de integridad de Software 1) Diseñar pruebas para evaluación del sistema.2) Continuar el trazo requerido por el plan de pruebas V&V de

sistema. Verificar que los diseños de pruebas V&V de sistema correspondan al formato, contenido y objetivo del documento de pruebas definido para el proyecto (ver IEEE Std 829-1998 [B4]).

3) Validar que los diseños de pruebas V&V para el sistema satisfagan los criterios de la actividad 5.4.2, Tarea 5

b) Niveles 1 y 2 de integridad de Software1) Verificar que los diseños de pruebas V&V para la evaluación

del sistema del desarrollador correspondan al formato, contenido y objetivo del documento de pruebas definido para el proyecto (e.g., ver IEEE Std 829-1998 [B4]).

2) Validar que los diseños de pruebas V&V de sistema del desarrollador satisfagan los criterios de la actividad 5.4.2, Tarea 5

SDD

IDD

Usuario

Documentación

Planes de prueba

Diseños de prueba

Diseño(s) de pruebas V&V del sistema

Reporte(s) de anomalías

(10) Generación del diseño de pruebas V&V de aceptación

a) Niveles 3 y 4 de integridad de Software 1) Diseñar pruebas para la prueba de aceptación.2) Continuar el trazo requerido por el plan de pruebas V&V de

aceptación. Verificar que los diseños de pruebas V&V de sistema correspondan al formato, contenido y objetivo del documento de pruebas definido para el proyecto (e.g., ver IEEE Std 829-1998 [B4]).

3) Validar que los diseños de pruebas V&V para la aceptación satisfagan los criterios de la actividad 5.4.2, Tarea 6

b) Nivel 2 de integridad de Software1) Verificar que los diseños de pruebas para evaluar la

aceptación del adquisidor correspondan al formato, contenido y objetivo del documento de pruebas definido para el proyecto (e.g., ver IEEE Std 829-1998 [B4]).

2) Validar que los diseños de pruebas de aceptación del adquisidor satisfagan los criterios de la actividad 5.4.2, Tarea 6

SDD

IDD

Usuario

Documentación

Planes de prueba

Diseños de prueba

Diseño(s) de pruebas V&V de aceptación

Reporte(s) de anomalías

66Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

c) Nivel 2 de integridad de SoftwareNo se requieren pruebas de aceptación

5.4.3 Actividad: Diseñar V&V (Proceso: Desarrollo) (continuación)Tareas de V&V Entradas

requeridasSalidas requeridas

(11) Análisis de Hazard

a) Verificar que el diseño lógico y los datos asociados implementen correctamente los requerimientos críticos y que no introduzcan nuevos peligros.

b) Actualizar el análisis de hazard

SDD

IDD

Reporte del análisis de hazard

Reporte(s) de actividades

Análisis de Hazard

Reporte(s) de anomalías

(12) Análisis de seguridad

a) Verificar que la arquitectura y las salidas detalladas del diseño traten adecuadamente los requisitos de seguridad identificados. Esta verificación incluye que el sistema mismo y riesgos de seguridad se introduzcan como resultado para ser la interfaz con componentes externos.

SDD

IDD

Reporte(s) de actividades

Análisis de Seguridad

Reporte(s) de anomalías

(13) Análisis de riesgos

a) Revisar y actualizar análisis de riesgos usando reportes de actividades.

b) Proporcionar recomendaciones para eliminar, reducir o mitigar los riesgos.

SDD

IDD

Planes y horario del proveedor del desarrollo

Reporte de análisis de Hazard

Análisis de seguridad

Resultados de la actividad de V&V

Reporte(s) de actividades

Análisis de Riesgos

Reporte(s) de anomalías

67Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

5.4.4 Actividad: Implementación de V y V (Proceso: Desarrollo)

Tareas de V y V Entradas Requeridas Salidas Requeridas1. Análisis de Diseño

Diseñar los componentes de código para que correspondan a la especificación de diseño y la especificación de diseño a los componentes de código. Analizar relaciones identificadas para la exactitud, consistencia y totalidad, Los criterios son:

a) Exactitud: Validar la relación entre los componentes del código y los elementos de diseño.

b) Consistencia Verificar que las relaciones entre los componentes de código y los elementos de diseño sean especificadas a un nivel consistente detallado.

c) Totalidad Verificar que todos los componentes de código sean rastreados de elementos de diseño y visceversa.

SSD IDD

Código Fuente

Reportes de Tareas Análisis de Diseño

Reportes de Anomalías

2. - Código fuente y evaluación de la documentación del código fuente. Evaluar los componentes del código fuente (código fuente y documentación del código fuente) para exactitud, consistencia, totalidad, objetividad, legibilidad y pruebas. Los criterios son:

a) Exactitud

1) Verificar y validar que los componentes del código fuente satisfagan el diseño del software.

2) Verificar que los componentes del código fuente cumplan con estándares, referencias, regulaciones, politicas, leyes físicas y reglas de negocios.

3) Validar la secuencia de declaraciones de los componentes del código fuente y declarar cambios usando diagramas de flujo y lógicos coplados con resultados de prototipos, principios de ingeniería u otras bases.

4) Validar que el flujo de datos y control satisfagan la funcionalidad y desempeño de requerimientos.

5) Validar el uso de datos y formatos.

6) Evaluar lo apropiado de escribir métodos y estándares.

Código Fuente SDD IDD

Estándares de código (ejm. estándares, prácticas , restricciones

de projecto y convensiones) Documentación de Usuario

Reportes de Tareas Código Fuente y evaluación del código fuente y documentación.

Reportes de anomalías

68Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

b) Consistencia

1) Verificar que todos los términos y conceptos de código estén documentados consistentemente.

2) Verificar que haya consistencia interna entre los componentes del código fuente.

3)Validar la consistencia externa con el diseño del software y requerimientos.

c) Totalidad

1) Verificar que los siguientes elementos estén en el código fuente junto con las afirmaciones y restricciones del sistema.

i) Funcionalidad (ejm. algoritmos, declaraciones / definiciones, validación de entradas/salidas, manejo de excepciones, repotes y acceso)

ii) Definición de proceso y agenda.

iii) Hardware, Software, y descripciones de las interfaces de usuario.

iv) Criterio de desempeño (ejm. tiempos,tamaños,velocidad,capacidad,exactitud, presición, protección y seguridad).

v) Datos críticos de configuración.

vi) Sistema, dispositivos y control de software(ejm. inicialización, transacción y estado de monitoreo, y auto pruebas)

vii) Verificar que la documentación del código fuente satisfaga la administración de procedimientos especificada.

d) Objetividad

1) Validar la lógica, cómputo y la exactitud de las interfaces (ejm. truncado y redondeo) en el ambiente del sistema.

2) Validar que el fenómeno de modelado físico cumple exactamente con los requerimientos del sistema y leyes físicas.

e) Legibilidad

1) Verificar que la documentación es legible, entendible y no ambigua para el usuario.

2) Verificar que la documentación define todos los acrónimos, mnemónicos, abreviaciones, términos y símbolos.

f) Pruebas

69Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

1) Verificar que haya criterios de aceptación objetiva para validar cada componente del código fuente.

2) Verificar que cada componente del código fuente sea comparable contra criterios objetivos de aceptación.

3.- Análisis de Interfaz

Verificar y validar que el código fuente de las interfaces del software con hardware, usuario, operador, y otros sistemas para exactitud, consistencia, totalidad, puntualidad y comparabilidad. Los criterios son:

a) Exactitud

Validar el código fuente de interfaz tanto interno como externo en el contexto de los requerimientos del sistema.

b) Consistencia

Verificar que el código de la interfaz sea consistente entre componentes del código e interfaces externas (ejm. Hardware, usuario, operador y otro software).

c) Totalidad

Verificar que cada interfaz es descrita e incluye formatos de datos y criterios de desempeño (ejm. Tiempos, ancho de banda, puntualidad, protección y seguridad).

d) Puntualidad

Verificar que cada interfaz provee información con la objetividad requerida.

e) Comparabilidad

Verificar que hay criterios de aceptación objetiva para validar el código de la interfaz.

Documentación de Conceptos (requerimientos del sistema)

SDD

IDD

Código Fuente

Documentación de Usuario

Reportes de Tareas – Análisis de Interfaz

Reportes de anomalias

70Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

4. Análisis Crítico

a) Revisar y actualizar los resultados de análisis crítico desde el último reporte crítico usando el código fuente.

b) Métodos de implementación y tecnologías de interfaces pueden causar que la asignación previa de los niveles de integridad se incrementen o decrementen por un elemento de software dado (ejm. Requerimiento, modulo, función, subsistema, otra parte de software). Verificar que ninguna inconsistencia o consecuencia de integridad de software no deseada sea introducida, revisando los niveles de integridad de software.

Tarea de Reporte crítico.

Código Fuente

Reportes de Tarea --- Análisis Crítico

Reportes de anomalías.

5.- Componente V y V generación de casos de prueba.

a) Integridad de software niveles 3 y 41) Desarrollar V y V casos de prueba

para prueba de componentes.2) Monitoreo continuo requerido por el

componente V y V plan de prueba.3) Verificar que el componente V y V

casos de prueba cumplan el objetivo del documento de prueba definido en el proyecto, el formato y el contenido ( ejm. Ver IEEE Std 829-1998 [B4]).

4) Validar que el componente V & V casos de prueba satisfagan el criterio en V y V actividad 5.4.3 tarea 5.

b) Integridad del Software nivel 21) Verificar que el componente casos

de prueba del desarrollador cumplan el objetivo del docuemnto de pruebas del proyecto, el formato y contenido (ejm. Ver IEEE Std 829 – 1998 [B4])

2) Validar que el componente casos de prueba del desarrollador satsfagan el criterio en V y V actividad 5.4.3 Tarea 5.

c) Integridad del software nivel 1

No hay requerimientos de componentes de prueba

SRS

IRS

SDD

IDD

Documentación de Usuario

Prueba de diseño

Casos de Prueba

Componente VyV casos de prueba

Reportes de anomalías.

6. Integración V y V generación de casos de prueba

a) Integridad del Software niveles 3 y 4

1) Desarrollar V y V casos de prueba para pruebas de

SRS

IRS

SDD

IDD

Integración V y V Casos de prueba

Reportes de anomalías.

71Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

integración.2) Monitoreo continuo requerido

por el V y V plan de integración de pruebas.

3) Verificar que la integración V y V casos de prueba cumplan el objetivo del documento de pruebas del proyecto, el formato y contenido (ejm. Ver IEEE Std 829-1998 [B4]):

4) Validar que la integración V y V casos de prueba satisfagan los criterios en V y V actividad 5.4.3, Tarea 6.

b) Integridad del software niveles 1 y 2

1) Verificar que la integración de los casos del desarrollador cumplan con el objetivo del documento de pruebas, el formato y contenido (ejm. Ver IEEE Std 829-1998 [B4]).

2) Validar que la integración de los casos de prueba satisfagan los criterios en V y V actividad 5.4.3, Tarea 6.

Documentación de Usuario

Diseño de Pruebas

Casos de Pruebas

7. – Sistema V y V generación de caos de pruebaa) Integridad del Software niveles 3 y 4

1) Desarrollar V y V casos de prueba del sistema.

2) Monitoreo continuo por el V y V plan de pruebas del sistema.

3) Verificar que el sistema V y V casos de prueba cumplan el objetivo del documento de pruebas del proyecto, el formato y contenido (ejm. Ver IEEE Std 829-1998 [B4]).

4) Validar que el sistema V y V casos de prueba satisfagan los criterios en V y V actividad 5.4.2, Tarea 5.

b) Integridad del software niveles 1 y 21) Verificar que los casos de prueba

del desarrollador cumplan con el documento de pruebas del proyecto, el formato y contenido (ejm. Ver IEEE Std 829-1998 [B4])

2) Validar que el los casos de prueba del desarrollador satisfagan los criterios en V y V actividad 5.4.2, Tarea 5.

SRS

IRS

SDD

IDD

Documentación de Usuario

Diseño de pruebas

Casos de Prueba

V y V Casos de prueba del sistema.

8. – Aceptación V y V generación de casos de prueba

a) Integridad de Software niveles 3 y 41) Desarrollar V y V casos de

prueba para la aceptación de pruebas.

2) Monitoreo continuo requerido para la aceptación V y V del

SRS

IRS

SDD

IDD

Documentación de Usuario

Aceptación V y V casos de prueba

Reportes de anomalías.

72Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

plan de prueba.3) Verificar que la aceptación V y

V de los casos de prueba cumplan con el objetivo del documento de prueba del proyecto, el formato y el contenido (ejm. Ver IEEE Std 829-1998 [B4]).

4) Validar que la aceptación V y V de los casos de prueba satisfagan los criterios en V y V actividad 5.4.2, Tarea 6.

b) Integridad del Software nivel 21) Verificar que la aceptación de

los alcances de los casos de prueba cumplan con el objetivo del documento de pruebas del proyecto, el formato y contenido (ejm. Ver IEEE Std 829-1998 [B4])

2) Validar que el alcance de la aceptación de los casos de prueba satisfagan los criterios en V y V actividad 5.4.2, Tarea 6.

c) Integridad del Software Nivel 1No hay requerimientos de aceptación del sistema.

Pruebas de Diseño

Casos de Prueba

9 – Componente V y V generación de procedimientos de prueba

a) Integridad del software niveles 3 y 41) Desarrollar V y V

procedimientos de pruebas para la prueba de componentes.

2) Monitoreo continuo requerido por el componente V y V plan de pruebas.

3) Verificar que el componente V y V procedimientos de prueba cumplan con el objetivo del documento de pruebas del proyecto, el formato y contenido (ejm. Ver IEEE Std 829-1998 [B4])

4) Validar que el componente V y V procedimientos de prueba satisfagan los criterios en V y V actividad 5.4.3, Tarea 5.

b) Integridad del software nivel 21) Verificar que los procedimientos

de pruebas del desarrollador cumplan con el objetivo del documento de pruebas del proyecto, el formato y el contenido (ejm. Ver IEEE Std 829-1998 [B4]).

2) Validar que el procedimiento de prueba del desarrollador satisfagan los criterios en V y V

SRS

IRS

SDD

IDD

Documentación de Usuario

Casos de Prueba

Procedimientos de prueba

Componente V y V procedimientos de pruebas

Reportes de anomalías.

73Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

actividad 5.4.3, Tarea 6.c) Integridad de Software nivel 1

No hay componentes de requerimientos de pruebas.

10. – V y V interación y generación de procedimientos de prueba.

a) Integridad de software niveles 3 y 41) Desarrollar V y V

porcedimientos de pruebas para pruebas integrales.

2) Monitoreo continuo requerido por el plan de integración de V y V.

3) Verificar que la integración V y V de las pruebas de procedimientos cumplan el objetivo del documento de prueba del proyecto, el formato y el contenido(ejemplo: ver IEEE Std 829-1998 [B4]).

4) Validar que la integración V y V de los procedimientos de prueba satisfagan el criterio de V y V actividad 5.4.3, tarea 6.

b) Integridad del Software niveles 1 y 21) Verificar que los procedimientos

de prueba del desarrollador cumplan con el objetivo de documento de prueba definido para el proyecto, el formato y el contenido (ejm. Ver IEEE Std 829-1998 [B4]).

2) Validar que los procedimientos de prueba de integración del desarrollador satisfagan en V y V actividad 5.4.3, Tarea 6.

SRS

IRS

SDD

IDD

Documentación de Usuario

Casos de prueba

Procedimientos de prueba

Integración de procedimientos de prueba V y V.

Reportes de anomalías.

11 . Generación del procedimiento de prueba del Sistema

a) Integridad del software niveles 3 y 41) Desarrollar V y V

procedimientos de pruebas para probar el sistema.

2) Monitoreo continuo requerido por el plan V y V de pruebas.

3) Verificar que los V y V procedimientos de prueba cumplan el objetivo del documento de pruebas, el formato y el contenido (ejm. Ver IEEE Std 829-1998 [B4]).

4) Validar que los procedimientos de prueba V y V del sistema, satisfagan los criterios en V y V actividad 5.4.2 Tarea 5.

b) Integridad de software niveles 1 y 21) Verificar que los procedimientos

de prueba del desarrollador cumplan el objetivo del documento de prueba definido en el proyecto, el formato y el

SRS

IRS

SDD

IDD

Documentación de Usuario

Casos de Prueba

Procedimientos de Prueba

Procedimientos de prueba V y V del Sistema

Reportes de anomalías

74Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

contenido. (ejm. Ver IEEE Std 829-1998 [B4]).

2) Validar que los procedimientos de prueba del desarrollador satisfagan los criterios en V y V actividad 5.4.2, Tarea 2.

12. Componente V y V Pruebas de Ejecución

a) Integridad de Software niveles 3 y 41) Implementar Pruebas de

componentes V y V.2) Analizar los resultados de las

pruebas para validar que el software implemente correctamente el diseño.

3) Validar que los resultados de las pruebas

4) Documentar los resultados como se requiere en el plan de pruebas de componentes V y V.

5) Usar los resultados de pruebas V y V para validar que el software satisfaga los criterios de pruebas de aceptación.

6) Documentar discrepancias entre los resultados actuales y los esperados.

b) Integridad de software nivel 21) Usar los resultados de pruebas

de componentes para validar que el software satisface los criterios de aceptación de pruebas.

c) Integridad del software nivel 1No hay requerimientos de pruebas de componentes.

Código Fuente

Código Ejecutable

SDD

IDD

Planes de pruebas de componentes

Procedimientos de pruebas de componentes

Resultados de pruebas de componentes.

Reportes --- Resultados de pruebas

Reportes de anomalías

13. Análisis de Amenazas

a) Verificar que la implementación y elementos asociados de datos implementen correctamente los requerimientos críticos y no introduzcan nuevas amenazas.

b) Actualizar los análisis de amenazas.

Código Fuente

SDD

IDD

Reporte de análisis de amenazas

Reportes ---- Análisis de riesgos

Reportes de anomalías.

14. Análisis de Seguridad

a) Verificar que la implementación es completada en acuerdo con el diseño del sistema, de esa forma se cubren los riesgos de seguridad identificados y que la implementación no presente nuevos riesgos de seguridad a través de códigos erróneos o errores de compilador.

Código Fuente

SDD

IDD

Reportes ----- Análisis de Seguridad

Reportes de anomalías

15. Análisis de Riesgos

a) Revisar y actualizar los análisis de riesgos usando reportes anteriores.Proveer recomendaciones para eliminar, reducir, o mitigar los riesgos.

Código Fuente

Planes y calendarios de desarrollo.

Reporte de análisis de amenazas

Analisis de seguridad

Resultados de tareas V y V.

Reportes --- Análisis de riesgos

Reportes de anomalías

75Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

5.4.5 Actividad: Pruebas de V y V (Proceso: Desarrollo)Tareas V y V Entradas Requeridas Salidas Requeridas

1. Análisis de Diseño

Analizar relaciones en los V y V planes de pruebas, diseños, casos y procedimientos para precisión y totalidad. Los criterios de esta tarea son:

a) PrecisiónVerificar que haya una relación válida entre planes V y V, diseños, casos y procedimientos.

b) TotalidadVerificar que todos los procedimientos de pruebas V y V, se acoplen a los planes de pruebas.

Planes de prueba V y V.

Diseños de pruebas V y V

Procedimientos de pruebas V y V.

Reportes --- Análisis de Diseño

Reporte de Anomalías.

2. Aceptación V y V procedimiento de generación de pruebas.

a) Integridad de software niveles 3 y 41) Desarrollar V y V

procedimientos de pruebas para aceptación del plan de prueba.

2) Monitoreo continuo requerido por el plan de prueba de aceptación V y V.

3) Verificar que la aceptación V y V pruebas de procedimientos cumplen con el objetivo del documento de prueba, el formato, y el contenido (ejm. Ver IEEE Std 829-1998 [B4]).

4) Validar que la aceptación V y V pruebas de procedimientos cumple el criterio en V y V actividad 5.4.2, Tarea 6.

b) Integridad de software nivel 21) Verificar que los

procedimientos de prueba de aceptación del desarrollador, cumplan el objetivo del documento de pruebas definido en el proyecto, formato y contenido(ejm. Ver IEEE Std 829 – 1998 [B4]).

2) Validar que los procedimientos de prueba de aceptación del desarrollador satisfagan los criterios en V y V actividad 5.4.2, Tarea 6.

c) Integridad del software nivel 1No hay requerimientos de aceptación de prueba.

SDD

IDD

Código fuente

Documentación de usuario

Plan de pruebas de aceptación

Procedimientos de aceptación de prueba.

Procedimientos de Aceptación de prueba V y V.

Reportes de Anomalías.

3. Integración V y V prueba de ejecución

a) Integridad del software niveles 3 y 41) Implementar V y V pruebas de

integración2) Analizar resultados de

pruebas para verificar los

Código Fuente

Código ejecutable

Plan de prueba de integración

Procedimientos de integración de

Reportes ---- Resultados de Preubas

Reportes de Anomalías.

76Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

componentes de software sean implementados correctamente

3) Validar que los resultados de las pruebas cubran los criterios de prueba establecidos por los documentos de diseño y plan de pruebas.

4) Documentar los resultados como es requerido en el plan de integración de prueba V y V.

5) Usar los V y V resultados de pruebas para validar que el software satisfaga los criterios de V y V de aceptación.

6) Documentar las discrepancias entre resultados de pruebas actual y esperados

b) Integridad del software niveles 1 y 2Usar los resultados de pruebas del desarrollador para verificar que el software satisface los criterios de prueba de aceptación.

prueba.

Resultados de integración de prueba.

Tabla 1—Tareas, entradas, y salidas de V&V (continuado)5.5.1 Actividad: Operación V&Y (proceso: Operación) (continuado)

Tareas de V&V Entradas requeridas

Salidas requeridas

77Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

(5) Análisis del riesgoa) Revisión y la actualización de riesgos usando análisis de informes anteriores de tarea.b) Proporcione las recomendaciones que eliminan, reducen o atenúanriesgos.

Paquete de la

instalación

Cambios propuestos

Informe del análisis

de riesgo

Análisis de seguridad

Planes y horario de desarrollo del surtidorInformes del problema de la operación

Resultados de la tarea de V&V

Informes de la tarea- Análisis del riesgoInformes de la anomalía

5.6.1 Actividad: Mantenimiento V&V (proceso: Mantenimiento)

Tareas de V&V Entradas requeridas

Salidas requeridas

(1) Revisión de SWPa) Revise el SWP para conformarse con los cambios aprobados.b) Cuando la documentación del desarrollo requerida por este estándar no está disponible, genera un SWP nuevo, consideremétodos en el anexo D para derivar la documentación requerida del desarrollo.

SWP

Cambios aprobados

Paquete de la

instalaciónPlanes y horario de desarrollo del surtidor

SWP actualizado

(2) Evaluación de la anomalíaEvalúe el efecto de las anomalías de la operación del software.

Informes de la anomalía

Informes de la tarea—Anomalíaevaluación

(3) Análisis de la criticalidada) Determínese la integridad del software por niveles para modificaciones propuestas.b) Valide los niveles de la integridad proporcionados por el estándar. Para los propósitos del planeamiento de V&V, el nivel más alto de la integridad de software asignado al software será el nivel de la integridad del sistema de software.

Cambios propuestosPaquete de la instalaciónNiveles de la integridad del sostén

Informes de la tarea—CriticalidadanálisisInformes de la anomalía

(4) Gravamen de la migracióna) Determine si software requisitos y dirección de la puesta en práctica el siguiente:

1) Requisitos específicos de la migración

2) Herramientas de la migración

3) Conversión de los productos y de los datos de

software

4) El archivar del software

5) Ayuda para el ambiente anterior

6) Notificación del usuario

Cambios

aprobados paquete

de la instalación

Informes de la tarea—MigracióngravamenInformes de la anomalía

78Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

Tabla 1—Tareas, entradas, y salidas de V&V (continuado)5.6.1 Actividad: Mantenimiento V&V (proceso: Mantenimiento) (continuado)

Tareas de V&V Entradas requeridas

Salidas requeridas

(5) Gravamen del retiroa) Determine si instalación paquete direcciones el siguiente:

1) Software support

2) Impacto en sistemas y bases de datos

existentes

3) El archivar del software

4) Transición a un producto de software nuevo

5) Notificación del usuario

Cambios

aprobados paquete

de la instalación

Informes de la tarea—RetirogravamenInformes de la anomalía

(6) Análisis de peligroa) Verifique que las modificaciones del software pongan correctamente en ejecuciónlos requisitos críticos y no introducen ningún nuevo peligro.b) Ponga al día el análisis de peligro.

Informe propuesto del

análisis de peligro del

paquete de la

instalación de los

cambios

Informes de la tarea- Análisis de peligroInformes de la anomalía

(7) Análisis de seguridadVerifique que los cambios /las actualizaciones propuestos al software no introduzcan nuevos o crecientes riesgos de la seguridad al sistema total.

Paquete propuesto

de la instalación de

los cambios

Informes de la tarea- Análisis de seguridad

(8) Análisis del riesgoa) La revisión y la actualización arriesgan análisis usando informes anteriores de la tarea.b) Proporcione las recomendaciones de eliminar, de reducir, o de atenuarlos riesgos.

Paquete de la

instalación

Cambios propuestos

Informe del análisis

de peligro

Análisis de seguridadPlanes y horario de desarrollo del surtidorInformes del problema de la operaciónResultados de la tarea de V&V

Informes de la tarea- Análisis del riesgoInformes de la anomalía

(9) Iteración de la tarea

a) Realice las tareas de V&V, según lo necesitado,

asegurar eso

1) Los cambios previstos se ponen en ejecución

correctamente

2) La documentación es completa y corriente3) Los cambios no causan el sistema inaceptable

Paquete aprobado

de la instalación de

los cambios

Informes de la tarea—Anomalíainformes

79Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

o involuntariocomportamientos del temA.

NOTA- Los cambios de software son actividades del mantenimiento (véase 5.6.1).

a Otras entradas pueden ser utilizadas. Para cualquier actividad y tarea de V&V, todas las entradas y salidas requeridas de actividades precedentes y las tareas se pueden utilizar, pero para la concisión, sólo se enumeran las entradas primarias.

80Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

Tabla 2—Tareas mínimas de V&V asignadas a cada nivel de la integridad de softwareProcesos del ciclo vital

Proceso:Adquisición(véase 5.2)

Proceso: Fuente (véase 5.3)

Proceso: Desarrollo(véase 5.4)

Proceso:Operación(véase 5.5)

Proceso: Mantenimiento (véase 5.6)

Actividades de V&V

Actividad:Adquisiciónayuda

V&V (véase 5.2.1)

Actividad: Planeamiento

V&V (véase 5.3.1)

Actividad: Concepto

V&V (véase 5.4.1)

Actividad: Requisitos V&V (véase 5.4.2)

Activida

d: (véase

5.4.3)

Actividad: Puesta en práctica V&V ( véase 5.4.4)

Actividad: Prueba

V&V(véase 5.4.5)

Actividad:Instalación

comprobación

V&V (véase 5.4.6)

Actividad:

Operación

V&V (véase 5.5.1)

Actividad: Mantenimiento

V&V (véase 5.6.1)

Niveles de la integridad de software

Niveles Niveles Niveles Niveles Niveles Niveles Niveles Niveles Niveles Niveles

4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1

Ayuda de la aceptación

X X X X X X X X X X X X

Generación del caso de la prueba de la aceptación V&V

X X X

Generación del diseño de la prueba de la aceptación V&V

X X X

Ejecución de la prueba de la aceptación V&V

X X X

Generación del plan de prueba de la aceptación V&V

X X X

Generación del

X X X

81Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

método de prueba de la aceptación V&VEvaluación de la anomalía

X X X

Generación componente del caso de la prueba de V&V

X X X

Generación componente del diseño de la prueba de V&V

X X X

Ejecución componente de la prueba de V&V

X X X

82Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

Tabla 2—Tareas mínimas de V&V asignadas a cada nivel de la integridad de software (continuado)Procesos del ciclo vital

Proceso:Adquisición(véase 5.2)

Proceso: Fuente (véase 5.3)

Proceso: Desarrollo(véase 5.4)

Proceso:Operación(véase 5.5)

Proceso: Mantenimiento (véase 5.6)

Actividades de V&V

Actividad: Adquisiciónayuda

V&V (véase 5.2.1)

Actividad: Planeamiento

V&V (véase 5.3.1)

Actividad: Concepto

V&V (véase 5.4.1)

Actividad: Requisitos V&V (véase 5.4.2)

Actividad:DiseñoV&V( véase 5.4.3)

Actividad: Puesta en práctica V&V(véase 5.4.4)

Actividad:Prueba

V&V(véase 5.4.5)

Actividad:Instalación

comprobación

V&V (véase 5.4.6)

Actividad:

Operación

V&V (véase 5.5.1)

Actividad: Mantenimiento V&V (véase

5.6.1)

Niveles de la integridad de software

Niveles Niveles Niveles Niveles Niveles Niveles Niveles Niveles Niveles Niveles

4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1

Generación componente del plan de prueba de V&V

X X X

Generación componente del método de prueba de V&V

X X X

Evaluación de la documentación del concepto

X X X

Gravamen de la gerencia de la configuración

X X

Verificación del contrato

X

Análisis de la criticalidad

X X X X X X X X X X X X X X X X X X X X

Análisis de la X

83Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

asignación de las exigencias de los equipo y programas de computación/del consumidorAnálisis de peligro X X X X X X X X X X X X X X X X

Identifique las oportunidades de la mejora en la conducta deV&V

X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X

Comprobación de la instalación

X X

Intervención de la configuración de la instalación

X X

84Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

Tabla 2—Tareas mínimas de V&V asignadas a cada nivel de la integridad de software (continuado)                                                                                                                                                S m

->■ mProcesos del ciclo vital

Proceso:Adquisición(véase 5.2)

Proceso: Fuente (véase 5.3)

Proceso: Desarrollo(véase 5.4)

Proceso:Operación(véase 5.5)

Proceso: Mantenimiento (véase 5.6)

Actividades de V&V

Actividad: Adquisiciónayuda

V&V (véase 5.2.1)

Actividad: Planeamiento

V&V (véase 5.3.1)

Actividad: Concepto

V&V (véase 5.4.1)

Actividad: Requisitos V&V (véase 5.4.2)

Actividad:DiseñoV&V(véase 5.4.3)

Actividad: Puesta en práctica V&V(véase 5.4.4)

Actividad:Prueba

V&V(véase 5.4.5)

Actividad:Instalación

comprobación

V&V (véase 5.4.6)

Actividad:

Operación

V&V (véase 5.5.1)

Actividad: Mantenimiento V&V (véase

5.6.1)

Niveles de la integridad de software

Niveles Niveles Niveles Niveles Niveles Niveles Niveles Niveles Niveles Niveles

4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1

Generación del caso de la prueba de la integración V&V

X X X X

Generación del diseño de la prueba de la integración V&V

X X X X

Ejecución de la prueba de la integración V&V

X X X X

Generación del plan de prueba de la integración V&V

X X X X

Generación del método de prueba de la integración

X X X X

85Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

V&VAnálisis del interfaz X X X X X X X X X

Interfaz con procesos de organización y de soportes

X X X X X X X X X X X X X X X X X X X X

Gerencia y ayuda técnica de la revisión

X X X X X X X X X X X X X X X X X X X X

Revisión de la gerencia del esfuerzo de V&V

X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X

Gravamen de la migración

X X

Nueva evaluación de los apremios

X X X

Evaluación de los procedimientos de funcionamiento

X X

86Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

Tabla 2—Tareas mínimas de V&V asignadas a cada nivel de la integridad de software (continuado)Procesos del ciclo vital

Proceso:Adquisición(véase 5.2)

Proceso: Fuente (véase 5.3)

Proceso: Desarrollo(véase 5.4)

Proceso:Operación(véase 5.5)

Proceso: Mantenimiento (véase 5.6)

Actividades de V&V

Actividad: Adquisiciónayuda

V&V (véase 5.2.1)

Actividad: Planeamiento

V&V (véase 5.3.1)

Actividad: Concepto

V&V (véase 5.4.1)

Actividad: Requisitos V&V (véase 5.4.2)

Actividad:DiseñoV&V( véase 5.4.3)

Actividad: Puesta en práctica V&V(véase 5.4.4)

Actividad:Prueba

V&V(véase 5.4.5)

Actividad:Instalación

comprobación

V&V (véase 5.4.6)

Actividad:

Operación

V&V (véase 5.5.1)

Actividad: Mantenimiento

V&V (véase 5.6.1)

Niveles de la integridad de software

Niveles Niveles Niveles Niveles Niveles Niveles Niveles Niveles Niveles Niveles

4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1

Planear el interfaz entre el esfuerzo de V&V y el surtidor

X X X X X X X X

Gravamen propuesto/de la línea de fondo del cambio

X X X X X X X X X X X X X X X X X X X X X X X X

Gravamen del retiro

X X

Análisis del riesgo

X X X X X X X X X X X X X X X X

Scoping el esfuerzo de V&V

X X X X

Análisis de seguridad

X X X X X X X X X X X X X X X X

Evaluación del diseño del software

X X X X

Evaluación de los requisitos del software

X X X X

87Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

Generación de SVVP

X X X X X X X X X X X X X X X X

Revisión de SVVP

X X X X

Evaluación de la documentación del código de fuente y del código de fuente

X X X

Revisión de los requisitos del sistema

X X X X

Generación del caso de la prueba del sistema V&V

X X X X

2—Tareas mínimas de V&V asignadas a cada nivel de la integridad de software (continuado)Procesos del ciclo vital

Proceso:Adquisición(véase 5.2)

Proceso: Fuente (véase 5.3)

Proceso: Desarrollo(véase 5.4)

Proceso:Operación(véase 5.5)

Procesos: Mantenimiento (véase 5.6)

Actividades de V&V

Actividad: Adquisiciónayuda

V&V (véase 5.2.1)

Actividad: Planeamiento

V&V (véase 5.3.1)

Actividad: Concepto

V&V (véase 5.4.1)

Actividad: Requisitos V&V (véase 5.4.2)

Actividad:Diseño

V&V(véase 5.4.3)

Actividad: Puesta

en práctica

V&V(véase 5.4.4)

Actividad:prueba

V&V(véase 5.4.5)

Actividad:Instalación

comprobación

V&V (véase 5.4.6)

Actividad:

Operación

V&V (véase 5.5.1)

Actividad: Mantenimiento

V&V (véase 5.6.1)

Niveles de la integridad de software

Niveles Niveles Niveles Niveles Niveles Niveles Niveles Niveles Niveles Niveles

4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1

Generación del diseño de la prueba del

X X X X

88Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

sistema V&VEjecución de la prueba del sistema V&V

X X X X

Generación del plan de prueba del sistema V&V

X X X X

Generación del método de prueba del sistema V&V

X X X X

Iteración de la tarea

X X X X

Análisis de Trazabilidad

X X X X X X X X X X X X X X X

Generación de informe final de V&V

X X X X

89Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

Tabla 3—Tareas opcionales de V&V y usos sugeridos en el ciclo vitalActividades del ciclo vital de V&V

Act

ivid

ad:

Ger

enci

a d

e V

&V

(v

éas

e 5.

1.1)

Act

ivid

ad:

Ayu

da

de

ad

qu

isic

ión

V

&V

(vé

ase

5.2.

1)A

ctiv

idad

: P

lan

eam

ien

to

V&

V

“(vé

ase

Act

ivid

ad:

Co

nce

pto

V

&V

(

véas

e 5.

4.1)

Act

ivid

ad:

Req

uis

ito

s

V&

V

(véa

se

5.4.

2)A

ctiv

idad

: D

iseñ

o

V&

V

(véa

se 5

.4.3

)A

ctiv

idad

: P

ues

ta

en p

ráct

ica

V&

V

( vé

ase

5.4.

4)A

ctiv

idad

: P

rueb

e

V&

V

(véa

se 5

.4.5

)A

ctiv

idad

: In

stal

ació

n/c

om

pr

ob

ació

n

V&

V

Act

ivid

ad:

Op

erac

ión

V

&V

(

véas

e 5.

5.1)

Act

ivid

ad:

Man

ten

imie

nto

V

&V

(vé

ase

5.6.

1)

Análisis del algoritmo X X X X

Funcionamiento de la intervención

X X X X X X

Ayuda de la intervención X X X X X X X

Controle el análisis de flujo X X X X

Análisis de coste X X X X X X X X X X

Análisis de la base de datos X X X X X

Los datos flujo análisis X X X X

Gravamen del plan de recuperación de desastre

X X X X X X X

Gravamen distribuido de la arquitectura

X X X X

Evaluación del estudio de viabilidad

X X X X X X X

Gravamen de riesgo independiente

X X X X X X X X X X X

Inspección

Concepto X X

Requisitos X X

Diseño X X

Código de fuente X X

Plan de prueba X X X X X

Pruebe el diseño X X X X

Pruebe el caso X X X X X

Evaluación operacional X

Supervisión de funcionamiento X X X X X X X X

Validación de la instalación del poste

X X X

Ayuda del descuido de la gerencia de proyecto

X X X X X X X X X X X

Ayuda de la evaluación de la oferta

X

Prueba de la calificación X X X

Análisis y prueba de la regresión X X X X X X

90Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

Tabla 3—Tareas opcionales de V&V y usos sugeridos en el ciclo vital (continuado)Actividades del ciclo vital de V&V

Act

ivid

ad:

Ger

enci

a d

e V

&V

(

véas

e 5.

1.1)

Act

ivid

ad:

Ayu

da

de

adq

uis

ició

n V

&V

(vé

ase

5.2.

1)

Act

ivid

ad:

Pla

nea

mie

nto

V&

V

“(sc

eSA

l)

Act

ivid

ad:

Co

nce

pto

V&

V

(véa

se 5

.4.1

)

Act

ivid

ad:

Req

uis

ito

s V

&V

(

véas

e 5.

4.2)

Act

ivid

ad:

Dis

eño

V&

V (

véas

e

5.4.

3)

Act

ivid

ad:

Pu

esta

en

prá

ctic

a V

&V

(vé

ase

5.4.

4)

Act

ivid

ad:

Pru

ebe

V&

V

( vé

ase

5.4.

5)

Act

ivid

ad:

Inst

alac

ión

/co

mp

rob

ació

n

V&

V (

véas

e 5.

4.6)

Act

ivid

ad:

Op

erac

ión

V&

V

(véa

se 5

.5.1

)

Act

ivid

ad:

Man

ten

imie

nto

V&

V

(véa

se

5.6.

1)

Análisis de la reutilidad X X X X X X X X

Análisis de la reutilización X X X X X X X

Análisis de la simulación X X X X X X X X

Análisis del apresto y de la sincronización

X X X X X

Gravamen del software del sistema

X X X X X X

Pruebe la certificación X X X X

Pruebe la evaluación X X X X X X X

Pruebe atestiguar X X X X

Evaluación del documento del entrenamiento

X X X X X X X

Análisis de la utilidad X X X X X X X X

Evaluación de la documentación del usuario

X X X X X X X X X

Entrenamiento de usuario X X X X X

Generación del plan de la herramienta de V&V

X X X X

Camine-throughs

Diseño X X

Requisitos X X

Código de fuente X X

Prueba X X X

El anexo G contiene una descripción de las tareas opcionales de V&V.

91Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

V6V

Ent

rada

sProceso: Proceso: Proceso: Proceso: Proceso:

Adquisición (5.2) Fuente (5.3) Desarrollo (5.4) Problema de la operación

Mantenimiento

1 Sistema preliminar 1 SVVP 1 Documentación del concepto 1 SRS 1 SRS 1 SRS 1 Planes, preparaciones y 1 Paquete de la instalación 1 SVVP 1 SVVP2 Declaración de la necesidad 2 Contrato 2 Desarrollo del surtidor, planeando  & Horario 2 SDD 2 SDD 2 SDD procedimientos de

prueba2 Documentación del

usuario2 Nuevos apremios 3 Paquete de la instalación

3  Representante del bosquejo u oferta

3 Planes y horario

3 Necesidades del usuario 3 IRS 3 IRS 3 IRS 2 SDD 3 Informe del análisis de Hazain

3 Cambios propuestos

4 Desarrollo del surtidor

4 Nivel de la integridad del sistema

4 RFP 4 Necesidades de la adquisición 4 Informe de la tarea de la criticalidad 4 IDD 4 IDD 3 IDD 4 Desarrollo del surtidor 4 Paquete de la instalación

Planes y horario

Esquema 5 Necesidades del

5 Integridad del revelador 5 Documentación del usuario 5 Estándares del diseño

5 Fuente y ejecutable 4 Fuente y ejecutable 5 Planes y horario 5 Procedimientos de

5 Cambios supuestos

5 SVVP 6 Asignaciones llanas 6 Plan de la prueba del sistema 6 Documentación del concepto

Código Código 6 Seguridad anal \ sis 6 Documentación del usuario

6 Informes de la anomalía

6 Contrato Pezones preliminares y 7 Plan de prueba de aceptación 7 Informe de la tarea de la

6 Codificación Slds 5 Documentación del usuario 7 Resultados de la tarea de V&V

7 Documentación del concepto

7 Integridad del sostén

7 Desarrollo del surtidor Gravamen de riesgo (TRA) 8 Configuración del interruptor 8 Planes de prueba y. Diseños

7 Documentación del usuario 6 Resultados de la prueba Resumen de la actividad de V&V

8 Informe del análisis de

Niveles

Planes y horario 7 Informe del análisis de peligro Proceso de la gerencia 9 Documentación del usuario

8 Documentación del concepto

7 Informe del análisis de peligro

Informes 9 Chlanges ambiental

8 Informe del análisis de peligro

8 Necesidades del usuario 8 Análisis de seguridad Documentación 10

Informe del análisis de

9 Informe de la tarea de la criticalidad

8 Desarrollo del surtidor 10

Análisis de seguridad

9 Análisis de seguridad

9 Concepto 9 Resultados de las tareas de V&V 9 Informe del análisis de peligro 11

Desarrollo del surtidor

10

Prueba Planes y horario 11

Desarrollo del surtidor

10

Desarrollo del surtidor

Documentación 10

TRA preliminar Planes y horario Casos de los diseños de los planes

9 Análisis de seguridad Planes y horario Planes y horario

10

SDD, IDD, SRS, IRS 11

Desarrollo del surtidor 12

Análisis de seguridad

11

Métodos de prueba 10

Resultados de la tarea de V&V

12

Problema operacional

11

Problema de la operación

11

Código de fuente Planes y horario 13

Resultados de la tarea de V&V

12

Resultados de la prueba componentes

Informes Informes

12

Código ejecutable 12

Análisis de seguridad 13

Informe del análisis de peligro

13

Resultados de la tarea de V&V

12

Resultados de la tarea de V&V

13

Planes de prueba. Diseños, 13

Resultados de la tarea de V&V 14

Desarrollo del surtidor

14

Casos, Planes y horario

15

Procedimientos. 15

Análisis de seguridad

16

Resultados de la tarea de V&V

16Actividad: Actividad: Actividad; Actividad: Actividad: Actividad. Actividad: Actividad. Actividad: Actividad.

V&

V T

area

s

Ayuda de adquisición V&V Planeamiento V&V

Concepto V&V Requisitos Diseño V&V Puesta en práctica lista V&V Instalación y Cluck hacia fuera V&V

Operación V&V Mantenimiento

(5.2.1) ( 5.3.1) (5.4.1) (5.4.2) (5.4.3) V&V. (5.4.4 j) (5.4.5) (5.4.1) (5.5.1) (5.6.1)

1 Scoping el V&V 1 Planear el interfaz

1 Evaluación de la documentación del concepto 1 Análisis de Trazabilidad 1 Análisis de Traceability

1 Análisis de Trazabilidad 1 Análisis de Trazabilidad 1 Configuración de la instalación

1 Evaluación de nuevo

1 SVVP 2 Esfuerzo. Entre el

esfuerzo de 2 Análisis de la criticalidad 2 Evaluación de los requisitos del

software 2  Evaluación del

diseño del 2 Código de fuente y 2 Prueba de la aceptación

V&V2 Instalación de la

intervención 2 Evaluación de

los 2 Evaluación de la anomalía de la

región Planear el interfaz Verificación del

3  Software duro/uso de ware/S 3 Análisis del interfaz 3 Análisis del interfaz

Código de fuente  Generación del procedimiento

3 Análisis de peligro de la comprobación

de funcionamiento

3 Análisis de la criticalidad

Entre el esfuerzo de V&V 2 Verificación del

Asignación de los requisitos 4 Análisis de la criticalidad 4 Análisis de la criticalidad

3 Análisis del interfaz 3 Prueba de la integración V&V

4 Análisis de seguridad 3 Análisis de peligro

4 Gravamen de la migración

y surtidor Análisis 5 Plan de prueba del sistema V&V 5 Prueba componente de

4 Análisis de la criticalidad Ejecución 5 Análisis del riesgo 4 Análisis de seguridad

5 Gravamen del retiro

3 Requisitos del sistema 4 Análisis de Trazabilidad Generación Generación de Han

5 Prueba componente de V&V

4 Prueba del sistema V&V 6 Informe final de V&V 5 Análisis del riesgo

6 Análisis de peligro

Revisión 5 Análisis de peligro 6 Prueba de la aceptación V&V 6 Prueba de la integración V&V

Generación del caso Ejecución Generación 7 Análisis de seguridad

6 Análisis de seguridad 7 Generación de Han Generación de Han

6 Prueba de la integración V&V

5 Prueba de la aceptación V&V

8 Análisis del riesgo

4 Ayuda de la aceptación 7 Análisis del riesgo 8 Configuración 7 Prueba componente de

Generación del caso Ejecución 9 Iteración de la tarea

Gerencia Generación del diseño

7 Caso de la prueba del sistema V&V

6 Análisis de peligro

9 Análisis de peligro 8 Prueba de la integración V&V

Generación 7 Análisis de seguridad

10

Análisis de seguridad Dimita la generación

8 Prueba de la aceptación V&V

8 Análisis del riesgo

Análisis del riesgo 9 Prueba del sistema V&V

Generación del caso

Dimita la generación

9 Prueba componente de V&V1

0Prueba de la aceptación V&V

Generación del procedimiento1

1Análisis de peligro de la

10

Prueba de la integración V&V 1

2Análisis de seguridad

Generación del procedimiento 1

3Análisis del riesgo

11

Prueba del sistema V&V Generación del procedimiento1

2 Prueba componente de V&V1

3Análisis de peligro

14

Análisis de seguridad

15

Análisis del riesgo

1 SVVP y actualizaciones 1 SVVP actualizado

1 Informes de la tarea 1 Informes de la tarea 1 Informes de la tarea

1 Informes de la tarea 1 Informes de la tarea 1 Informes de la tarea 1 Informes de la tarea

1 SVVP actualizado

2 Informes de la tarea 2 Informes de la tarea

2 Informes de la anomalía 2 Informes de la anomalía 2 Informes de la anomalía

2 Informes de la anomalía 2 Informes de la anomalía 2 Informes de la anomalía 2 Informes de la anomalía

2 Informes de la tarea

V&

V

3 Informes de la anomalía 3 Informes de la

3 Planes de prueba de V&V 3 Prueba Hans de V&V

3 Casos de la prueba de V&V 3 Métodos de prueba de V&V 3 Informe final de V&V 3 Informes de la anomalía

Sistema  Componente Componente Aceptación

Aceptación  Integración

4 Diseños de la prueba de V&V

Sistema

Componente Aceptación

Sistema 4 Métodos de prueba de V&V

 Aceptación Componente

Integración

Sistema

Actividad: Gerencia de V&V (5.1.1)

Entradas de V&V V&V Tarea V&V Salidas(1) Todas las entradas de V&V

> (1) Generación de SVVP (5) Interfaz con procesos de organización y de soportes > (1) SVVP y actualizaciones (4) Informes sumarios de la actividad de V&V(2) Todas las salidas de V&V

(2) Gravamen propuesto/de la línea de fondo del cambio

(6) Identifique las oportunidades de la mejora en la conducta de V&V

(2) Informes de la tarea (5) Recomendaciones al informe final de V&V

(3) Revisión de la gerencia del esfuerzo de V&V (3) Informes de la anomalía

            (4) Gerencia y ayuda técnica de la revisión                        

92Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

ISO/iec 12207 Requerimientos de V&V IEEE Std 1012 Actividades y TareasVerificación e Implementación de Procesos Clausula 4Niveles de Integridad de Software

Clausula 6 Solicitudes, Documentación, Administración sobre la Verificación y Validación de Software6.2 Solicitudes Administrativas de V&VClausula 7 SVVP 7.7 Sección SVVP y solicitudes administrativas del V&V.

6.4.1.1 Puntos Críticos sobre la Verificación del Software

Clausula 4Niveles de Integridad de SoftwareTabla B.1 Asignación de SoftwareTabla B.2 Definición de ConsecuenciasAnexo D Software de rehusó

6.4.1.2 Proceso de Verificación Clausula 6 V&V de Software, administración y documentación.Clausula 7 SVVP

6.4.1.3 y 6.4.1.4 Extensión y Rigor de la Verificación

Clausula 4Niveles de Integridad de SoftwareTabla 2 Tareas mínimas de la V&V asignadas a cada nivel de integridadAnexo C Definición e Independencia de V&V

6.4.1.5 Plan de Verificación Clausula 6 V&V de Software, administración y documentación.Clausula 7 SVVP

6.4.1.6 Problemas 6.2 Solicitudes Administrativas de V&V7.7 Sección del SVVP y Solicitudes Administrativas de V&V

6.4.2 Verificación Clausula 5 Proceso de la V&V de Software6.4.2.1 Verificación del Contrato 5.3.1 Actividad : Planeamiento de la V&V

Tarea 2 Verificación de Contrato6.4.2.2 Proceso de la Verificación Proceso 5.2 : Adquisición

Proceso 5.3 AbastecimientoProceso 5.4 Desarrollo

6.4.2.3 Solicitudes de la Verificación Actividad 5.2.1: Adquisición y Soporte de la V&VTarea 3 Revisión del sistema de solicitudesActividad 5.4.1 Concepto de la V&VTarea1 Concepto de evaluación de la documentaciónActividad 5.4.2 Solicitudes de la V&VTarea 1 Análisis de la trazabilidadTarea 2 Solicitud de evaluación de softwareTarea 3 Análisis de interferenciaTarea 4 Análisis de criticaTarea 5 Sistema de V&V prueba del plan de generaciónTarea 6 Aceptación de la prueba del plan de V&VTarea 8 Análisis de RiesgoTarea 9 Análisis de seguridad

6.4.2.4 Diseño de Verificación Actividad 5.4.3 Diseño de la V&VTarea 1 Análisis de la trazabilidadTarea 2 Solicitud de evaluación de softwareTarea 3 Análisis de interferenciaTarea 4 Análisis de criticaTarea 5Componentes de la prueba de generación de V&VTarea 6 Integración del plan de generación de V&VTarea 7 Componentes de la prueba de diseño de V&VTarea 8 Integración de la prueba de diseño de V&VTarea 9 Sistema de V&V prueba del plan de generaciónTarea 10 Aceptación de la prueba del plan de V&V

93Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

Tarea 11Análisis de RiesgoTarea 12 Análisis de seguridad

6.4.2.5 Verificación de Código Actividad 5.4.4 Implementación de V&VTarea 1 Análisis de la trazabilidadTarea 2Codigo Fuente y código fuente documentadoTarea 3 Análisis de interferenciaTarea 4 Análisis de criticaTarea 5Componentes de la prueba de generación de V&VTarea 6 Integración del plan de generación de V&VTarea 7 Sistema de la prueba de generación de V&VTarea 8 Aceptación de la prueba de generación de V&VTarea 9 Componentes de la prueba de procedimientos de V&VTarea 10 Integración de la prueba de procedimientos de V&VTarea 11 Sistema de V&V prueba del plan de procedimientosTarea 12 Componentes de la prueba de ejecución de V&VTarea 13Análisis de RiesgoTarea 14 Análisis de seguridad

6.4.2.6 Integración y Verificación Actividad 5.4.5 Prueba V&VTarea 3 Integración de la prueba de ejecución de V&V

6.4.2.7 Documentación Actividad 5.2.1 SoporteTarea 3 Revisión de los sistemas de solicitudActividad 5.3.1 PlaneaciónTarea 2 Verificación de ContratoActividad 5.4.1 ConceptosTarea 2 Concepto de la evaluación de la documentaciónTarea 3 Análisis de InterferenciaActividad 5.4.2 DiseñoTarea 2 Evaluación de Diseño de softwareTarea3 Análisis de InterferenciaActividad 5.4.4 ImplementaciónTarea 2 Código fuente y documentación de códigoTarea 3 Análisis de interferenciaActividad 5.4.6 Instalación de PruebasTarea 1 Instalación y configuraciónActividad 5.5.1 OperaciónTarea 2 Evaluación de procedimientos

6.5.1 Proceso de Validación Clausula 4Niveles de Integridad de SoftwareClausula 6 Solicitudes, Documentación, Administración sobre la Verificación y Validación de Software6.2 Solicitudes Administrativas de V&VClausula 7 SVVP 7.7 Sección SVVP y solicitudes administrativas del V&V.Anexo C Definición e Independencia de V&VAnexo D Rehúso de SoftwareAnexo E Medición

6.5.1.2 Proceso de Validación Clausula 6 V&V de Software, administración y documentación.Clausula 7 SVVP

6.5.1.3 Extensión y Rigor de la Verificación

Tabla 2 Tareas mínimas de la V&V asignadas a cada nivel de integridad

94Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

Anexo C Definición e Independencia de V&V6.5.1.4 Validación del plan Clausula 6 V&V de Software, administración y

documentación.Clausula 7 SVVP

6.5.1.5 Problemas 6.2 Solicitudes Administrativas de V&V7.7 Sección del SVVP y Solicitudes Administrativas de V&V

6.5.2.1 Validación Clausula Proceso de V&V de Software6.5.2.1 Validación y Pruebas Actividad 5.4.2 Requerimientos de V&V

Tarea 5 sistema de las pruebas del plan de generación de V&VTarea 6 Aceptación de las pruebas del plan de generación de V&VActividad 5.4.3 Diseño de V&VTarea 5 ComponentesTarea 6 IntegraciónTarea 7 ComponentesTarea 8 IntegraciónTarea 9 SistemasTarea10 Aceptación Actividad 5.4.4 ImplementaciónTarea 5 ComponentesTarea 6IntegraciónTarea 7 SistemaTarea 8 AceptaciónTarea 9 ComponentesTarea 10 IntegraciónTarea 11 Sistemas de ProcedimientosActividad 5.4.5 PruebasTarea 2 Aceptación de los procedimientos de V&V

6.5.2.2 Validación de Trazabilidad Actividad 5.4.4 Implementación de V&VTarea 12 Componentes de las pruebas de ejecución de V&VActividad 5.4.5 PruebasTarea 3 IntegraciónTarea 4 SistemaTarea 5 Aceptación

6.5.2.3 Validación de las pruebas Actividad 5.4.4 ImplementaciónTarea 12 Componentes de la ejecuciónActividad 5.4.5 Pruebas de V&VTarea 3 IntegraciónTarea 4 SistemaTarea 5 Aceptación

6.5.2.4 Validación del Software Actividad 5.4.1 Conceptos de V&VTarea 1 Concepto de la evaluación de la documentaciónActividad 5.4.2 RequerimientosTarea 2 Requerimientos de SoftwareTarea 3 Análisis de interferenciaActividad 5.4.3 DiseñoTarea 2 Diseño de SoftwareTarea 3 Análisis de InterferenciaActividad 5.4.4 ImplementaciónTarea 2 Código fuente y documentaciónTarea 3 Análisis de interferenciaActividad 5.4.5 PruebasTarea 4SistemaTarea 5 Aceptación

6.5.2.5 Instalación y Pruebas Actividad 5.4.6 Instalación y Pruebas Tarea 1 InstalaciónTarea 2 Instalación y PruebasTarea 3 Riesgos

95Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

Tarea 4 SeguridadTarea 5 Análisis

Anexo A Procesos N/AAnexo B Guía N/AAnexo C Guía de Procesos y Organización N/AAnexo D Bibliografía N/AAnexo E Conceptos Básicos N/AAnexo F Propósitos Cláusula 4 Integridad del Software

Clausula 5 Procesos del SoftwareClausula 6 V&V de Software, administración y documentación.Clausula 7 SVVP

Anexo G N/AAnexo H N/A

Tabla A.2 Estándar 1012 de las actividades de V&V Estándar 1012 IEEE actividades V&V

Proceso Actividad

Actividad 5.2.1 Soporte de Adquisición

Adquisición IniciaciónRFPPreparación de contrato y actualizaciónMonitoreoAceptación

Actividad 5.3.1 Planeación Suministro IniciaciónPreparaciónContratoPlaneaciónEjecución y controlRevisión y evaluaciónLiberación

Actividad 5.4.1 Concepto de V&V

Desarrollo Proceso de ImplementaciónRequerimientos y LicitaciónAnálisis del sistema de requerimientosSistema del diseño arquitectónico

Actividad 5.4.2 requerimientos de V&V

Desarrollo Análisis de requerimientos de software

Actividad 5.4.3 diseño de V&V Desarrollo Diseño arquitectónico de softwareDiseño detallado de software

Actividad 5.4.5 pruebas de V&V

Desarrollo Integración de softwarePruebas de calificación de softwareSistema de integraciónSistema de pruebas de calificación

Actividad 5.4.6 Instalación de V&V

Operación Proceso de implementaciónPruebas operacionalesSistema de operaciónSoporte a usuario

Actividad 5.6.1 Mantenimiento de V&V

Mantenimiento Proceso de implementaciónProblemas y análisis de modificaciónModificación e implementaciónMantenimiento y revisiónMigraciónRetiro de software

Actividad 5.1.1 dirección de V&V

Todos los procesos Todas las actividades

96Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

Requerimientos del Estándar IEEE 1074 Actividades y Tareas correspondientes al estándar 1012 IEEE

A.1 Dirección de proyecto y actividadesA.1.1 Iniciación de actividadesA.1.1.1 Creación del SCLPA.1.1.2 EstimacionesA1.1.3 Recursos del proyectoA1.1.4 Definición de Medición

Actividad 5.2.1 Soporte a la adquisiciónTarea 1 Alcance del proyectoTarea 2 Planeación de la interfaceActividad 5.3.1 Planeación Tarea 1 Planeación de la interfaceActividad 5.1.1 Dirección de V&VTarea 1 Generación SVVPActividad 5.6.1 Mantenimiento de V&VTarea 1 Revisión de SVVP6.1 Reporte de Requerimientos7.6 Sección SVVP 6 Reporte de requerimientos de V&V5.2 Administración de requerimientos de V&V7.7 Sección SVVP 7 Administración de requerimientos V&V6.3.1 Pruebas de documentación de V&V7.8 SVVP sección 8 Pruebas de la documentación de requerimientos de V&V6.3.2 Documentación de SVVPClausula 7 SVVPAnexo E Mediciones de V&V

A.1.2 Actividades del proyecto de planeaciónA1.2.1 Plan de EvaluaciónA1.2.2 Plan de configuraciónA1.2.3 Plan sistema de transiciónA1.2.4 Plan de instalaciónA1.2.5 Plan de documentaciónA1.2.6 Plan de capacitaciónA1.2.7 Plan de administración de proyectoA1.2.8 Plan de integración

Clausula 5 Procesos de software de V&VTodas las tareasClausula 6 Reporte de software de V&V, administración y documentaciónClausula 7 SVVP

A1.3Monitoreo y ControlA1.3.1 Manejo de riesgosA1.3.2 Manejo de proyectoA1.3.3 Identificación de SCLPA1.3.4 Almacenamiento de datos A1.3.5 Análisis de datos recolectados

Actividad 5.1.1 Dirección de V&VTarea 1 Generación SVVPTarea 2 Propósitos del cambio de valoresTarea 3 Revisión Tarea 4Soporte técnicoTarea 5 organización y soporte a procesos

A.2 Actividades de grupos del predesarrolloA 2.1 ConceptoA2.1.1 Identificación de ideasA2.1.2 Uso del potencialA2.1.3 ViabilidadA2.1.4 Finalización de ideasA2.2 Actividades de los sistemasA2.2.1 Análisis de funcionesA2.2.2 Desarrollo de sistemaA2.2.3 Requerimientos de sistemaA2.3 Importancia de las actividades de softwareA2.3.1 Identificación de los requerimientos de softwareA2.3.2 Evaluación de softwareA2.3.3 Definición de métodosA2.3.4 Importación de software

Actividad 5.4.1 Concepto de V&VTarea 1 concepto y documentaciónTarea 2 análisis Tarea 3 TrazabilidadTarea 5 riesgosTarea 6 seguridadActividad 5.4.1 Conceptos de V&VTarea 1 concepto y documentaciónTarea 3 hardware y softwareClausula 5 proceso de software Todas las tareasAnexo D rehúso de software

A.3 Desarrollo de actividadesA 3.1 RequerimientosA3.1.1 Definición y desarrollo

Actividad 5.4.2 Requerimientos de V&VTarea 1 trazabilidadTarea 2 Requerimientos de software

97Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

A3.1.2 Definición de interfacesA3.1.3 Integración de los requerimientos de software

Tarea 3 InterfacesTarea 4 análisis críticosTarea 5 sistema de generación de V&VTarea 6 aceptaciónTarea 7 configuraciónTarea 8 riesgosTarea 9 seguridadTarea 10 análisis de riesgos

A.3 Desarrollo de actividadesA3.2 Diseño de actividadesA3.2.1 DiseñoA3.2.2 Diseño de bases de datosA3.2.3 Diseño de interfacesA3.2.4 Detalles de diseñoA3.3 Implementación de actividadesA3.3.1 Creación de ejecutableA3.3.2 Creación operativaA3.3.3 Integración

Actividad 5.4.3 Diseño de V&VTarea 1 trazabilidadTarea 2 diseño de softwareTarea 3 interfacesTarea 4analisis críticosTarea 5 componentes del plan de generaciónTarea 6 integración del plan de generaciónTarea 7 componentes del plan de diseñoTarea 8 integración del diseñoTarea 9 sistemaTarea 10 AceptaciónTarea 11 riesgosTarea 12 seguridadTarea 13 análisis de riesgosActividad 5.4.3 Implementación de V&VTarea 1 trazabilidadTarea 2 código y código documentadoTarea 3 interfacesTarea 4analisis críticosTarea 5 componentes del plan de generaciónTarea 6 integración del plan de generaciónTarea 7 sistemaTarea 8 aceptación de las pruebas de generaciónTarea 9 componentes de procedimientosTarea 10 Integración de procedimientosTarea 11 sistema de procedimientosTarea 12 componentes de l plan de ejecuciónTarea 13 riesgosTarea 14 seguridadTarea 15 análisis de riesgosActividad 5.4.5 Pruebas de V&VTarea 1 trazabilidadTarea 2 aceptación del plan de procedimientosTarea 3 integración del plan de ejecuciónTarea 4 sistema del plan de ejecuciónTarea 5 aceptación del plan de ejecuciónTarea 6 riesgosTarea 7 seguridadTarea 8 análisis de riesgos

A.4 Actividades del post desarrolloA4.1 InstalaciónA4.1.1 Distribución de softwareA4.1.2 Instalación de softwareA4.1.3 AceptaciónA4.2 Operación y soporte de actividadesA4.2.1 Operación de sistemasA4.2.2 Asistencia TécnicaA4.2.3 MantenimientoA4.3 Actividades de MantenimientoA4.3.1 Identificación de software

Actividad 5.4.6 InstalaciónTarea 1 Instalación y configuraciónTarea 2 instalaciónTarea 3 RiesgosTarea 4 SeguridadTarea 5 Análisis de riesgosTarea 6 Reporte finalActividad 5.5.1 OperaciónTarea 1 Instalación y configuraciónTarea 2 instalaciónTarea 3 Riesgos

98Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

A4.3.2 Implementación del problemaA 4.4 ActividadesA4.4.1 Notificación al usuarioA4.4.2 Operaciones paralelasA.5 Integración de actividadesA5.1 Evaluación de actividadesA5.1.1 RevisiónA5.1.2 Creación de la matriz de trazabilidadA5.1.3auditoriaA5.1.4 DesarrolloA5.1.5 CreaciónA5.1.6 EjecuciónA5.1.7 Reporte de resultados

Tarea 4 SeguridadTarea 5 Análisis de riesgosActividad 5.6.1 MantenimientoTarea 1 SVVPTarea 2 EvaluaciónTarea 3 Análisis criticoTarea 4 migraciónTarea 5 Análisis de riesgos

99Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

Cuadro 2—Un ejemplo del producto de la prueba de V&V y de programar de la tarea de la ejecución de la prueba.

100Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

Anexo A

(informativo)

Mapeo de las actividades y de las tareas de IEEE Std 1012 V&V

Mapeo A.1 de los requisitos de ISO/IEC 12207 V&V a las actividades y a las tareas de IEEE Std 1012 V&V

La tabla A.1 demuestra amapping de todos los requisitos de ISO/IEC 12207:1995 [B13] V&V (es decir, procesos, actividades y tareas) a las actividades de V&V y a las tareas de este estándar.

La primera columna de la tabla A.1 enumera los números de la cláusula de ISO/IEC 12207:1995 [B13] y los títulos de los procesos y de las actividades de V&V. La segunda columna de la tabla A.1 enumera las cláusulas y las tablas de IEEE Std 1012-2004 que tratan los asuntos enumerados en la primera columna.

Tabla A.1—Traz requisitos de ISO/IEC 12207 V&V a las actividades y a las tareas

de IEEE Std 1012 V&VRequisitos de ISO/IEC 12207 V&V Actividades y tareas de IEEE Std 1012 V&V

(véase la cláusula correspondiente/la tabla)

Surtidor de 5.1.4.1 que supervisa V&V 5.2.1 Actividad: Ayuda de adquisición V&VScoping de la tarea 1 el esfuerzo de V&VTarea 2 que planea el interfaz entre el esfuerzo de V&V y el surtidorRevisión de los requisitos del sistema de la tarea 3

5.2.4.5 (h) y 5.2.5.5 que interconecta con V&Va

5.2.1 Actividad: Ayuda de adquisición V&VTarea 2 que planea el interfaz entre el esfuerzo de V&V y el surtidor5.3.1 Actividad: Planeamiento V&VTarea 1 que planea el interfaz entre el esfuerzo de V&V y el surtidorDefinición del anexo C de IV&V

Verificación y validación de 5.2.6.3 " Todas las cláusulas, tablas, figuras del software V&V, y anexos

5.3.2 Análisis de requisitos del sistema 5.2.1 Actividad: Ayuda de adquisición V&VRevisión de los requisitos del sistema de la tarea 35.4.1 Actividad: Concepto V&VAnálisis de Trazabilidad de la tarea 4 de la evaluación de la documentación del concepto de la tarea 1

retiro de la migración 5.5.5 y 5.5.6 y del software

5.1.1 Actividad: Gerencia de V&VLa tarea 2 propuso/gravamen del cambio de la línea de fondo5.6.1 Actividad: Mantenimiento V&V

101Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

Tabla A.4 IEEE Estándar 1012 CMMI Proceso de mapeo de la matriz para los requerimientos

Proceso de Aéreas y Grupos CMMI

IEEE Estándar 1012 Verificación y Validación Tareas y Actividades (ver la clausula correspondiente)

Integraciones del Producto 5.4.2 Actividad: Requerimientos de Verificación y Validación. Tarea 1:Analisis de Trazabilidad Tarea 3:Analisis de la Interfaz Tarea 5:Generacion del plan de pruebas del sistema de

verificación y validación Tarea 6:Generacion del plan de pruebas aceptados de

verificación y validación.5.4.3 Actividad: Diseño de Verificación y Validación

Tarea 1: Análisis de trazabilidad Tarea 3:Analisis de la Interfaz Tarea 5: Generación del plan de pruebas de los componentes

de Verificación y Validación Tarea 6: Generación del plan de pruebas de la integración de

la Verificación y Validación Tarea 7: Generación del diseño de pruebas de los

componentes de Verificación y Validación Tarea 8: Generación del diseño de pruebas de la integración

de Verificación y Validación Tarea 9: Generación del diseño de pruebas del sistema de

Verificación y Validación Tarea 10: Generación del diseño de pruebas aceptados de

Verificación y Validación.5.4.4 Actividad: Implementación de la Verificación y Validación

Tarea 1: Análisis de la trazabilidad Tarea 3: Análisis de la interfaz Tarea 5: Generación de los casos de prueba del componente

de Verificación y Validación Tarea 6: Generación de los casos de prueba de la integración

de Verificación y Validación Tarea 7: Generación de los casos de prueba del sistema de

Verificación y Validación Tarea 8: Generación de los casos de prueba aceptados de

Verificación y Validación Tarea 9: Generación de los procedimientos de prueba de los

componentes de Verificación y Validación Tarea 10: Generación de los procedimientos de prueba de la

integración de Verificación y Validación Tarea 11: Generación de los procedimientos de prueba del

sistema de Verificación y Validación Tarea 12: Ejecución de las pruebas del componente de

Verificación y Validación.5.4.5 Actividad: Pruebas de Verificación y Validación

Tarea 1: Análisis de trazabilidad Tarea 2:Generacion de los procedimientos de prueba de

Verificación y Validación aceptados Tarea 3:Ejcucion de las pruebas de integración de Verificación

y Validación Tarea 4: Ejecución de las pruebas del sistema de Verificación y

Validación Tarea 5: Ejecución de las pruebas aceptadas de Verificación y

Validación.5.4.6 Actividad: Comprobación e Instalación de Verificación y Validación

Auditar las configuración de la instalación Comprobación de la instalación

Verificación Todas las clausulas

102Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

Validación Todas las clausulasSoporte de la Administraciones

de la Configuración5.1.1 Actividad: Administración de la Verificación y Validación

Tarea 2: Proponer una línea base para los cambios Tara 6:Identificar las oportunidades de mejora en la conducta

de verificación y validación5.4.1 Actividad: Concepto de Verificación y Validación

Tarea 4: Análisis de trazabilidad5.4.2 Actividad: Requerimientos de Verificación y Validación

Tarea 1: Análisis de trazabilidad Tarea 7: Administración de la configuración

5.4.3 Actividad: Diseño de Verificación y Validación Tarea 1: Análisis de la trazabilidad

5.4.4 Actividad: Implementación de Verificación y Validación Tarea 1: Análisis de trazabilidad

5.4.5 Actividad: Pruebas de Verificación y Validación Tarea 1: Análisis de trazabilidad

5.4.6 Actividad: Comprobación e instalación de Verificación y Validación

Tarea 1: Auditar la instalación de la configuraciónProceso y Aseguramiento de la

Calidad del Producto5.1.1 Actividad: Administración de Verificación y Validación

Tarea 6: Identificar las oportunidades de mejora en la conducta de verificación y validación

Anexo E de Verificación y ValidaciónAnexo F Relaciones de Verificación y Validación en otros responsabilidades de proyectos.

Ambiente de Organizacion para la Integración

Anexo C Definición de Verificación y Validación IndependienteAnexo F Relaciones de Verificación y Validación en otros responsabilidades de proyectos.

Análisis de Decisión y Resolución

5.1.1 Actividad: Administración de Verificación y Validación Tarea 2: Proponer una base línea para los cambios.

5.4.1 Actividad: Concepto de Verificación y Validación Tarea 7: Análisis de riesgo

5.4.2 Actividad: Requerimientos de Verificación y Validación Tarea 10: Análisis de riesgos

5.4.3 Actividad: Diseño de Verificación y Validación Tarea 13: Análisis de riesgo

5.4.4 Actividad: Implementación de Verificación y Validación Tarea 15: Análisis de riesgo

5.4.5 Actividad: Pruebas de Verificación y Validación Tarea 8: Análisis de riesgo

5.4.6 Actividad: Comprobación e Instalación de Verificación y Validación

Tarea 5: Análisis de riesgo5.5.1 Actividad: Operación de Verificación y Validación

Tarea 5: Análisis de riesgo5.6.1 Actividad : Mantenimiento de Verificación y Validación

Tarea 8: Análisis de riesgo

Análisis Causal y Resolución 5.1.1 Actividad: Mantenimiento de Verificación y Validación Tarea 6: Identificar las oportunidades de mejora en la conducta

de Verificación y ValidaciónAnexo E Verificación y ValidaciónAnexo F Relaciones de Verificación y Validación en otros responsabilidades de proyectos.

Anexo B

(Informativo)

Riesgo basado en el nivel de Esquema de la Integridad del Software

103Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

B.1 Riesgo basado en el nivel de Esquema de la Integridad del Software

La tabla B.1 define cuatro niveles de integridad de software usados como referencia para este estándar. La tabla B.2 las consecuencias de los errores de software para cada uno de los cuatro niveles de integridad de software. Hay traslapes entre los niveles de integridad de software que permiten interpretaciones individuales de riesgos aceptables dependiendo de la aplicación.

Tabla B.1Asigancion de los Niveles de Integridad de Software

Nivel de Integridad de Software Descripción4 Un error de función o característica de sistema causa:

Consecuencias catastróficas al sistema con probabilidad razonable, o una probabilidad ocasional de un estado de funcionamiento del sistema que contribuye al error.

Consecuencias criticas razonable o con una probabilidad de ocurrencia de un estado de funcionamiento que contribuye al error.

3 Un error de función o característica del sistema causa:

Consecuencias catastróficas con una probabilidad ocasional o infrecuente en la ocurrencia de un estado de funcionamiento que contribuye al error.

Consecuencias criticas con una probabilidad razonable u ocasional de la ocurrencia de un estado de funcionamiento que contribuye al error.

Consecuencias marginales con probabilidad ocasional o razonable de la ocurrencia de un estado de funcionamiento que contribuye al error.

2 Un error de función o característica del sistema causa:

Consecuencias criticas con una probabilidad infrecuente de ocurrencia de un estado de funcionamiento que contribuye al error.

Consecuencias marginales con una probabilidad razonable u ocasional de ocurrencia de un estado de funcionamiento que contribuye al error.

Consecuencias insignificantes con una probabilidad razonable o probable de ocurrencia de un estado de funcionamiento que contribuye al error.

1 Un error de función o de una característica del sistema causa:

Consecuencias criticas con una probabilidad infrecuente de ocurrencia de un estado de funcionamiento que contribuye al error.

Consecuencias marginales con una ocurrencia ocasional o infrecuente d un estado de funcionamiento que contribuye al error.

Consecuencias insignificantes con una probabilidad infrecuente, ocasional o probable de ocurrencia de un estado de funcionamiento que contribuye al error.

104Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

Tabla B.2 Definición de las Consecuencias

Consecuencia DefinicionesCatastrófica Perdida de la vida humana, la misión completa falla,

perdida de la seguridad y resguardo del sistema o perdida extensiva social o financiera.

Critica Lesión principal o permanente, pérdida parcial de la misión, daño al sistema principal o una perdida principal social o financiera.

Marginal Lesión o enfermedad severa, degradación de la misión secundaria o algunas pérdidas sociales o financieras.

Insignificante Lesión o enfermedad mínimas, impacto menor en el performance del sistema u operaciones inconvenientes.

La tabla B.3 ilustra los riesgo basados en los esquemas que muestra las tablas B.1 y B.2. Cada celda en la tabla de asignación de los niveles de integridad de software basados sobre la combinación de las consecuencias de un error y la probabilidad de ocurrencia de un estado de funcionamiento que contribuye al error. Algunas celdas de las tablas reflejan más de un nivel de integridad de software, indicando la asignación final del nivel de integridad de software puede ser seleccionado de la dirección de la aplicación del sistema y de las recomendaciones para la mitigación de los riesgos. Para algunas aplicaciones industriales, la definición de probabilidad de las categorías de ocurrencia pueden ser expresadas como figuras de probabilidad derivadas del análisis de requerimientos del sistema.

Tabla B.3 Ilustración Grafica de la Asignación de los Niveles de Integridad de Software

ErrorProbabilidad de ocurrencia de un estado de funcionamiento que contribuye al error (se decrementa en el orden de la probabilidad)

Consecuencia Razonable Probable Ocasional InfrecuenteCatastrófica 4 4 4 o 3 3

Critica 4 4 o 3 3 2 o1Marginal 3 3 o 2 2 o 1 1

Insignificante 2 2 o 1 1 1

Anexo C(Informativo)

Definición de Independencia de Verificación y Validación (IV&V)

IV&V es definido por tres parámetros, independencia técnica, independencia directiva e independencia financiera.

C.1 Independencia Técnica

La independencia técnica requiere el esfuerzo de V&V de utilizar al personal que no está implicado en el desarrollo del software. El esfuerzo de IV&V debe formular su propia comprensión del problema y cómo el sistema propuesto está solucionándolo. La independencia técnica (“punto de vista fresco”) es un método importante para detectar los errores sutiles pasados por alto que también nos acercan a la solución.

Para las herramientas del software, la independencia técnica significa que el esfuerzo de IV&V utiliza o desarrolla su propio sistema de herramientas de prueba y del análisis a parte de las herramientas de desarrollo. El compartir herramientas es permisible para los ambientes de ayuda de la computadora ( ejemplo, recopiladores, ensambladores, utilidades) o para las simulaciones del sistema donde estaría demasiado costosa una versión independiente. Para las herramientas compartidas, IV&V conduce pruebas de calificación en las herramientas para asegurarse de que las herramientas comunes no contienen los errores que pueden enmascarar errores en el software que es analizado y probado. Las herramientas

105Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

disponibles que tienen historia extensa del uso no requieren la prueba de la calificación. El aspecto más importante para el uso de estas herramientas es verificar los datos de entrada usados.

C.2 Independencia Directiva

Esto requiere que la responsabilidad del esfuerzo de IV&V esté concedida en una organización a parte de las organizaciones de administración de desarrollo y de programación. La independencia directiva también significa que el esfuerzo de IV&V selecciona independientemente los segmentos del software y del sistema para analizar las pruebas, elige las técnicas de IV&V, define el horario de las actividades de IV&V, y selecciona las ediciones y los problemas técnicos específicos para actuar. El esfuerzo de IV&V proporciona sus resultados en una manera oportuna simultáneamente a las organizaciones de administración de desarrollo y de programación. El esfuerzo de IV&V se debe someter al programa de administración de los resultados de IV&V , las anomalías, y los resultados sin ninguna restricción (ejemplo. sin requerir la aprobación anterior del grupo del desarrollo) o presiones adversas, directo o indirecto, del grupo del desarrollo.

C.3 Independencia Financiera

Esto requiere que el control del presupuesto de IV&V esté concedido en una organización independiente de la organización de desarrollo. Esta independencia previene las situaciones donde el esfuerzo de IV&V no puede terminar su análisis o prueba o entregar resultados oportunos porque los fondos de han dispersado o se han ejercido las presiones financieras o por influencias adversas.

C.4 Formas de Independencia

El grado en el cual cada uno de esos tres parámetros de independencia (técnica, directiva y financiera) es concedido en una organización de Verificación y Validación que determina el grado de independencia alcanzado.

Muchas formas de independencia pueden ser adoptadas por la organización de verificación y validación. Las cinco más frecuentes son:

1. Clásica2. Modificada3. Integrada4. Interna5. Embebidas

La tabla C.1 muestra el grado de independencia alcanzado por esta cinco formas.

Tabla C.1 Forma de Validación y Verificación

Forma de Verificación y Validación

Técnica Administrativa Financiera

Clásica I I IModificada I i IIntegrada i I I

Interna i i IEmbebida e e eNota: IIndependencia rigurosa, iIndependencia condicional, e Independencia mínima

C.4.1 IV&V Clásica

 IV&V clásica incorpora los tres parámetros de independencia. La responsabilidad de IV&V se concede en organización que está separada de la organización de desarrollo. IV&V utiliza una relación de funcionamiento cercana con la organización de desarrollo para asegurarse de que los resultados y las recomendaciones de IV&V sean integrados rápidamente dentro del proceso de desarrollo. Típicamente, IV&V clásica es realizada por una organización (ejemplo, surtidor) y el desarrollo es realizada por otra

106Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

organización separada (es decir, otro vendedor). IV&V clásica se requiere generalmente para el nivel 4 de la integridad de software (es decir, pérdida de vida, pérdida de misión, pérdida social, o financiera significativa) con las regulaciones y los estándares impuestos ante el desarrollo del sistema.

C.4.2 IV&V Modificada

IV&V modificada se utiliza en muchos programas grandes donde el integrador primo del sistema es seleccionado para manejar el desarrollo entero del sistema incluyendo el IV&V. El integrador primo selecciona organizaciones para asistir al desarrollo del sistema y para realizar el IV&V. En la forma modificada de IV&V, el adquirente reduce su propio tiempo de la adquisición pasando esta responsabilidad al integrador primo. Puesto que el integrador primo realiza todo o algo de desarrollo, la independencia directiva es comprometida teniendo el informe del esfuerzo de IV&V al integrador primo. La independencia técnica se preserva puesto que el esfuerzo de IV&V formula una opinión imparcial de la solución del sistema y utiliza al personal independiente para realizar el IV&V. que se preserva la independencia financiera puesto que un presupuesto separado se pone a un lado para el esfuerzo de IV&V. El esfuerzo modificado de IV&V sería apropiado para los sistemas con el nivel 3 de la integridad de software (es decir, una misión y un propósito importantes).

C.4.3 IV&V IntegradaEsta forma se centra en el abastecimiento de la regeneración rápida de los resultados de V&V en el proceso de desarrollo y es realizada por una organización que esté financieramente y administrativamente independiente de la organización de desarrollo para reducir al mínimo compromisos con respecto a independencia. La regeneración rápida de los resultados de V&V en el proceso de desarrollo es facilitada por la organización integrada de IV&V: trabajo de lado a lado con la organización de desarrollo; repaso de productos de trabajo del interino; y proporcionando la regeneración de V&V durante inspecciones, guías, y las revisiones conducidas por el personal de desarrollo (impacto potencial en independencia técnica). Los impactos a la independencia técnica son contrapesados por las ventajas asociadas a un foco en interdependencia entre la organización integrada de IV&V y la organización del desarrollo.

La interdependencia significa que los éxitos de las organizaciones están estrechamente unidos, asegurándose de que trabajan juntos en una manera cooperativa.

C.4.4 IV&V Interna

IV&V interna existe cuando el desarrollador conduce la IV&V con personal dentro de su propia organización, aunque preferiblemente no el mismo personal implicado directamente en el esfuerzo del desarrollo. Se compromete la independencia técnica, directiva, y financiera. La independencia técnica es comprometida porque el análisis y la prueba de IV&V son vulnerables a los errores que pasan por alto usando las mismas asunciones o ambiente de desarrollo que enmascaró el error de los desarrolladores. La independencia directiva se compromete porque el esfuerzo interno de IV&V utiliza las mismas herramientas comunes y procedimientos corporativos de análisis que el grupo del desarrollo. La presión del paralela del grupo del desarrollo puede influenciar al contrario de cómo el software es analizado y probado agresivamente por el esfuerzo de IV&V. Se compromete la independencia financiera porque el grupo del desarrollo controla el presupuesto de IV&V. Los fondos, los recursos, y los horarios de IV&V se pueden reducir como presiones del desarrollo y las necesidades vuelven a dirigir los fondos de IV&V en solucionar problemas del desarrollo. La ventaja de un esfuerzo interno de IV&V es el acceso al personal que conoce su sistema y su software. Esta forma de IV&V se utiliza cuando el grado de independencia no se indica explícitamente y las ventajas del conocimiento de preexistencia del personal compensan las ventajas de la objetividad.

C.4.5 IV&V Embebida

Esta forma es similar a IV&V interna ya que utiliza al personal de la organización de desarrollo que no se debe implicar directamente en el esfuerzo de desarrollo. V&V se centra en asegurarse de conformidad a los procedimientos y los procesos del desarrollo. La organización de V&V trabaja de lado a lado con la organización de desarrollo y atiende a las mismas inspecciones, guías, y las revisiones con el personal de desarrollo (es decir, el compromiso de la independencia técnica). V&V embebida no es tarea específicamente independientemente de la solución original o de llevar a cabo las pruebas independientes

107Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

(es decir, compromiso de la independencia directiva).La independencia financiera se compromete porque el grupo de recursos asignados de V&V son controlados por el grupo del desarrollo. V&V embebida permite la regeneración rápida de V&V de los resultados en el proceso del desarrollo pero comprometen la independencia técnica, directiva, y financiera de la organización de V&V.

Anexo D

Verificación y Validación de Rehúso de Software

D.1 Propósito

El propósito de este anexo es proporcionar opciones y sugerencias para ayudar al esfuerzo de V&V de rehúso de software y para superar los desafíos asociados a la reutilización de software. La reutilización de software se puede tomar de muchas formas y podría incluir software de bibliotecas, el software desarrollado para otras aplicaciones, los COTS software, los requerimientos de software, los diseños del software, u otros artefactos del software existentes. Este anexo trata ambos:

1. Software de rehúso desarrollado y usado como parte de un proceso de reutilización y2. el software de la reutilización desarrollado y usado fuera de un proceso de la reutilización.

La figura D.1 ilustra actividades y tareas de V&V para el software de rehúso si fue desarrollado bajo un proceso de reutilización o de un proceso exterior de reutilización.

Figura D.1 Verificación y Validación Software de Rehúso

108Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

D.2 Verificación y Validación de Software desarrollado en un proceso de reutilización

Un proceso estructurado de reutilización de software desarrolla los activos (ejemplo, diseño, código, y documentación) previstos para el uso en contextos múltiples. Los procesos de reutilización de software de la IEEE estándar 1517-1999 [B11] proporcionan un marco para ampliar los procesos del ciclo vida del software de IEEE/EIA estándar 12207.0-1996 [B12] para incluir un sistemático, proceso de ingeniería de dominio para la reutilización del software.

El alcance del dominio y el análisis del dominio de un activo proporcionan los requerimientos, el uso previsto, los parámetros de la interfaz, y la información necesaria para V&V del activo, o una comprensión de V&V previamente realizado del activo.

D.2.1 Verificación y Validación de Activos en Desarrollo

El esfuerzo de V&V debe analizar los artefactos (ejemplo, planes, modelos, arquitectura) de la ingeniería de dominio como parte de las tareas requeridas de V&V. El análisis significativo de los productos de la ingeniería del dominio debe ocurrir durante la revisión de los requerimientos del sistema, evaluación de los requerimientos del software, análisis de la interfaz, evaluación del diseño de software, evaluación de la documentación del código fuente y del código de fuente, y todo el planeamiento de pruebas. El esfuerzo de V&V debe incluir la asignación de un nivel de integridad de software al activo, en el contexto del dominio para su uso previsto, de determinar las tareas del mínimo V&V de ser realizado (vea la tabla 2). Al planear el esfuerzo de V&V, el análisis opcional de la reutilización de la tarea (véase el anexo G) debe ser incluido.

D.2.2 Verificación y Validación del Rehúso de Activos

Un proceso de ingeniería de dominio asegura que la información usada en el desarrollo de sistemas de software sea identificada, capturada, y organizada para poderla reutilizar y para crear nuevos sistemas dentro de un dominio. El esfuerzo de V&V debe incluir la asignación de un nivel de la integridad de software al activo, en el contexto de su uso real, de determinar las tareas del mínimo V&V de ser realizados (véase la tabla 2). Al planear el esfuerzo de V&V, el análisis opcional de la reutilización de la tarea (véase el anexo G) debe ser incluido

D.2.3 Verificación y Validación de Software desarrollado y su rehúso exterior de un proceso de reutilización

Algunos sistemas de software son desarrollados, operados y mantenidos usando módulos de software que no fueron diseñados para el uso en contextos múltiples o no fueron convertidos como parte de un proceso estructurado de la reutilización del software (ejemplo, los productos de la ingeniería del dominio no están disponibles). En estos casos el esfuerzo de V&V debe realizar el análisis opcional de la reutilización de la tarea (véase el anexo G) a las entradas del producto para determinar la conveniencia de reutilización del software del candidato. El esfuerzo de V&V debe asignar un nivel de integridad de software al software candidato de reutilización para determinar las tareas del mínimo V&V de ser realizado.

El rehúso de software requiere algunas consideraciones especiales durante el esfuerzo de Verificación y Validación cuando alguna de lo siguiente es aplicable:

Las entradas para una tarea requerida de verificación y validación no están disponibles para el software reutilizado.

El software reutilizado fue desarrollado como parte de un sistema que es diferente en función o aplicación para un sistema donde será reutilizado.

El software reutilizado fue desarrollado para resolver diversas necesidades del usuario del sistema actual.

Las necesidades originales del usuario son desconocidas.

En algunos casos, las entradas para las tareas de V&V pueden no estar disponibles, reduciendo visibilidad en los productos y los procesos de software. Las opciones y las técnicas están disponibles para compensar la carencia de entradas. Cada técnica tiene fuerzas que varían y la consideración de debilidad se debe dar

109Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

a realizar múltiples técnicas para contradecir las debilidades de una técnica con fuerzas de otra técnica cuando se exige la alta confianza. Estas opciones se tratan por orden decreciente de deseabilidad.

Primero, tareas substitutas. La substitución para las tareas de la tabla 1de V&V es permitida si las tareas substitutas equivalentes de V&V se pueden demostrar para satisfacer los mismos criterios que en la tabla 1. Dos técnicas de substitución de tareas se sugieren en la tabla D.1.

Tabla D1.Tareas de Substitución para establecer las entradas de tareas de Verificación y Validación

Tareas de SubstituciónDescripción: Substituir métodos de prueba y análisis alternativos en lugar del requerimiento de actividades del estándar IEEE 1012 para generar conclusiones objetivas acerca de las correcciones, lo completo, la exactitud y la usabilidad del software reutilizado.Técnica 1: Pruebas de la caja negraPrueba de la caja negra y la validación: Ejecutar el software reutilizado contra un espectro de entrada de un caso de prueba y validar que la salida sea correcta.Análisis del manual de usuario: Derivar el sistema y los requerimientos del software del manual de usuario y validar que los resultados de las pruebas de la caja negra satisfagan los requerimientos.Comprobar el límite de interconexión del software: Agregar un límite dentro de todas las interfaces del software sobre toda la información y los datos lógicos recibidos del software de rehúso para asegurarnos que no hay información errónea aceptada.

Pros Los resultados de las pruebas reflejan el

software actual. Limitar los errores catastróficos para que no

se propaguen en el sistema. Tener la capacidad de comprobar las

exigencias del sistema y los requerimientos del usuario derivados del manual de usuario

Análisis independiente.

Cons Inhabilitar todas las pruebas de error si la

presencia de alguno no es observable en la salida de la caja negra (errores latentes.)

EL límite de las comprobaciones dificulta cubrir todos los escenarios de ejecución.

Limitar las minuciosidades del manual de usuario.

Técnica 2: Revisión QA (Aseguramiento de la Calidad) de desarrollo.Resultados de QA de desarrollo: Revisar los resultados de QA y confirmar si la evidencia de datos es similar a los que deberían de generar las tareas de validación y verificación.Resultados de prueba de desarrollo: Revisar si los resultados de las pruebas de desarrollo y confirmar si la evidencia de datos es similar a los que deberían de generar las tareas de validación y verificación.Revisión del cuaderno de desarrollo: Revisar el cuaderno de desarrollo que deriva del análisis y los problemas de software durante los primeros estados de desarrollo.Análisis del manual de usuario: Fragmentar el sistema y los requerimientos de software del manual de usuario y validar que el QA (aseguramiento de calidad) de desarrollo y los resultados de las pruebas satisfagan los requerimientos.

Pros Tener la capacidad de fragmentar a detalle

el diseño del software y el performance de las características internas.

Identificacion de las posibles características de error del programa autorizando análisis adicionales y pruebas con otros métodos.

Observar el performance del sistema usando resultados de prueba que reflejan las características actuales de la ejecución del software.

Cons Limitado el alcance y extendiendo el análisis

de QA y especificar el foco de las pruebas realizadas.

Limitar las minuciosidades del manual de usuario.

No hay análisis totalmente independientes.

110Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

Segundo, usar fuentes alternativas de información para realizar las actividades de validación y verificación de la tabla 1 y la tabla 2 de este estándar. Tres técnicas de fuentes alternativas son sugeridas en la tabla D2.

Fuentes AlternativasDescripción: Usar fuentes alternativas de los datos del programa para derivar conclusiones acerca de lo que debe de ser correcto, completo, exacto y usable del software reutilizado.Técnica 3: Historia OperacionalHistorial del análisis de datos: Examinar y analizar el historial operacional del software reutilizado con la atención particular de cómo el software realizado en un sistema con características similares se propone en un nuevo sistema.Entrevista de usuario: Entrevistas de conducta con los usuarios operacionales. Concentrar los datos recolectados sobre como el performance del sistema en escenarios y condiciones similares son los esperados para el nuevo sistema propuesto.

Pros Datos reales del software reutilizado en el

ambiente operacional. Usar observaciones acerca del performance

del software en el sistema relacionado. Marcar el software establecido y las pistas

de discrepancias registradas. Análisis independiente.

Cons Características diferentes, tecnologías e

interfaces de usuario con un nuevo sistema propuesto podrían causar un error no identificado en el historial del sistema.

No todas las interacciones registradas u observables en el historial del sistema como datos completos u exactos son limitados.

Las observaciones del usuario pueden ser subjetivas basadas en errores posibles, así que la correccion, lo completo y exactitud pueden ser limitados.

Técnica 4: Auditar los resultadosEntrevistas de desarrollo: Llevar a cabo entrevistas con el equipo de desarrollo para adquirir la información pertinente acerca del diseño y las características del performance del software reutilizado.Diseñar guías de análisis de revisión: Analizar el diseño y el código de datos para determinar como el software reutilizado podría interactuar en el nuevo sistema.Análisis estándar aceptable: Revisar los resultados de cualquier estándar aceptado para determinar que fueron seguidos para el desarrollo del nuevo software.

Pros Dependiendo de qué tan minucioso sea el

equipo de desarrollo, se pueden obtener un buen diseño y acercamiento al código de las entrevistas.

Los artefactos históricos de diseño y las guías de código pueden tener la suficiente calidad para actuar como un sustituto de la nueva fuente de código y del detalle del diseño.

Cons Limitar los detalles de la documentación del

equipo de desarrollo y de la información recolectada durante la entrevista.

No hay análisis totalmente independientes. Tabla D.4-Realización de prototipos independiente y comparación para establecer tareas de entrada de V&V

Realización de prototipos independiente y comparación Descripción: Desarrolle un modelo (prototipo) del software propuesto o use partes del sistema precio.Ejecute escenarios de prueba en el prototipo o en el sistema previo, y compare los resultados de las pruebas contra el software reutilizado. Analice los resultados para generar conclusiones objetiva acerca de las correcciones, completitud, precisión y usabilidad del software reutilizado.Técnica 7: Realización de prototiposComparación del código del prototipo: Desarrolle un modelo de réplica (prototipo) de la función o requerimientos en un lenguaje amistoso para usuarios. Ejecute las pruebas de casos representando el rango de los escenarios del sistema tanto en el modelo y en el software reutilizable. Compare los resultados y analice las diferencias para determinar si el software reutilizado tiene el desempeño esperado.

Pros:- Útil para funciones pequeñas y conjuntos de

requerimientos.- Fácil de diagnosticar problemas en software reutilizable

- Capacidad para correr un amplio rango de escenarios del sistema y comparar con el programa de referencia.

Cons:- Los costos y el tiempo de la construcción del modelo.

111Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

- Los errores en el modelo pueden enmascarar errores similares en el software reutilizable (la probabilidad de que dos errores similares sean generados por dos fuentes independientes debe ser pequeña o improbable)

Técnica 8: Resultados del sistema previoComparación con las funciones del sistema previo: Ejecute los casos de prueba representando el rango de los escenarios del sistema en las funciones del sistema previo y del software reutilizable. Compare los resultados y analice las diferencias para determinar si el software reutilizable tiene un desempeño como el esperado.

Pros:- Económico para ejecutar los casos de prueba en el

sistema previo y realizar la comparación.- Registro de pista probado del desempeño de las

funciones del sistema precio, con un desempeño base establecido.

- Diferencias en los resultados de ejecución conduce a otro análisis y pruebas para ser conducido.

- Análisis independiente.

Cons:- Limitado en alcance con funciones más pequeñas.

- Habilidad para instrumentar las funciones del sistema previo para extraer un diagnóstico de información acerca de los pasos internos del programa puede ser difícil y hacer duro el diagnóstico exacto de la localización de un problema.

- Cualquier problema oculto en las funciones del sistema previo puede ser pasado por alto o no probado en las nuevas funciones del sistema propuestas (herencia de errores)

Últimamente, usar una combinación de las evidencia circunstancial, mostrada a continuación que provee visibilidad y penetración dentro del software reutilizable para ejecutar las tareas de V&V en la Tabla 1 y en la Tabla 2 de este estándar:

a) Historia operacionalb) Historia de pruebasc) Revisión de resultadosd) Entrevistas con usuariose) Juicio de ingenieríaf) Documentación del productog) Riesgos previos del análisis de resultadosh) Resultados previos de V&Vi) Cuaderno de desarrollador de softwarej) Documentación del proceso de diseñok) Entrevistas a los desarrolladores originalesl) Análisis de resultados de código estáticom) Evaluación de conformidad con estándares.

Si la V&V de software reutilizables no puede cumplir con el nivel apropiado, los artículos pueden ser usados tanto tiempo como sea su riesgo asociado, con este uso es se reconoce y explica la estrategia de mitigación de errores. El esfuerzo de la V&V debe asegurar que los riesgos son profundamente entendidos, debidamente documentados, y correctamente rastreados bajo las tareas de análisis de riesgo.

112Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

Anexo E(informativo)Medidas de V&VE.1 IntroducciónLa administración de la actividad de V&V utiliza medidas para proveer retroalimentación para el continuo perfeccionamiento del proceso de V&V, y evaluar el proceso de desarrollo y los productos de software. Las tendencias pueden ser identificadas y dirigidas por la evaluación de calcular medidas sobre el periodo de tiempo. Los valores del umbral de las medidas deberían ser establecidos, y las tendencias deberían ser evaluadas; para servir como indicadores en cuanto a si un proceso, producto o tarea de V&V, ha sido completado satisfactoriamente. Ningún conjunto estándar de medidas es aplicable para todos los proyectos, así que el uso de medidas puede variar de acuerdo al dominio de la aplicación y el ambiente de desarrollo de software.No existe consenso para las medidas para evaluar la calidad y la cobertura de las tareas de V&V. El IEEE Std 1061-1998 [B9] provee una definición estándar de medidas disponibles de calidad de software. Otros estándares de medidas relacionados y guías son el IEEE Std 982.1-1988 [B5] y el FP-05 Software Measurement [B1].Este estándar considera tres categorías de medidas asociadas con los trabajos de V&V: (1) medidas para evaluar la densidad de anomalías, (2)medidas para valorar la efectividad de la V&V, y (3) medidas para evaluar la eficiencia de la V&V.E.2 Medidas para evaluar la densidad de anomalías.Las medidas de densidad de anomalías pueden proveer información profunda de la calidad del producto de software, la calidad del procesos de desarrollo de software, y la calidad de los trabajos de V&V para descubrir anomalías en el sistema de software y para facilitar la corrección de las anomalías. Las medidas de densidad de anomalías son influenciadas por numerosas variable (por ejemplo, complejidad del software, tipo de dominio, y el tiempo en la fase de aplicación del proceso de V&V); en consecuencia, las medidas deben ser analizadas para ganar penetración en las interdependencias entre el trabajo de desarrollo y el de V&V.Si el valor de la medida de densidad de anomalías es bajo, esto sugiere que la calidad del desarrollo del programa es alta, que el proceso de V&V necesita ser mejorado, o una combinación de ambas. Si el valor de la medida es alto, entonces esto sugiere que la calidad del desarrollo del programa es baja, que el proceso de V&V es efectivo, o una combinación de ambas. Luego de considerar el valor de la medida, el siguiente paso es evaluar medidas de desarrollo de programas de software relacionado para llegar a clarificar y discernir la tendencia de la medida para determinar la necesidad de mejorar el proceso.La medidas de anomalías y las tendencias pueden ser usadas para mejorar la calidad del proyecto en cuestión y puede ser usado para mejorar la planeación y la ejecución del proceso de V&V para proyectos futuros con características similares. Las medidas definidas por la Ecuación(E .1), Ecuación(E.2), Ecuación(E.3), y Ecuación(E.4) son aplicables para cuatros fases del desarrollo de software:Densidad de anomalías en requerimientos= #Anomalías en requerimientos encontradas por la gestión de V&V (E.1) #Requerimientos revisados por la gestión de V&V

Densidad De anomalías en diseño= #Anomalías encontradas en los informes de diseño por la gestión de V&V (E.2) #Informes de diseño revisados por la gestión de V&V

Densidad de anomalías en código= #Anomalías en código encontradas por la gestión de V&V (E.3) #Volumen de código revisado por la gestión de V&V

Densidad de anomalías de prueba= #Anomalías de prueba encontradas por la gestión de V&V (E.4) #Pruebas revisadas por la gestión de V&V

E.3 Medidas para evaluar la efectividad de la V&V

Las medidas efectivas asociadas con los trabajos de V&V proveen indicaciones cuantitativas que se caracterizan por añadir beneficios de V&V para descubrir anomalías en los productos y procesos de

113Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

software. Estas medidas delinean el porcentaje de el total de anomalías encontradas por los trabajos de V&V. Las medidas son influenciadas por numerosas variables (p.e., complejidad del software), y las medidas deben ser analizadas para ganar penetración dentro de las interdependencias entre el trabajo de desarrollo y de V&V.

La efectividad de los valores de medida de V&V son altamente influenciadas por el grado de paralelismo entre el trabajo de desarrollo de software y el trabajo de V&V. Asumiendo que los trabajos son paralelos, entonces una baja efectividad en el valor de medida de V&V sugiere que el trabajo en el desarrollo de software es efectivo, o que el trabajo de de V&V puede requerir mejorarse, o la combinación de ambas. Si la efectividad en la medida de V&V es alta, entonces esto sugiere que el proceso de desarrollo de software puede requerir mejorarse, o que el proceso de V&V es efectivo, o que solamente cambios incrementales al proceso de V&V pueden ser requeridos. Luego de considerar el valor de la medida, el siguiente paso es evaluar medidas de desarrollo de programas de software relacionados para llegar a clarificar y discernir las tendencias de las medidas para determinar la necesidad de mejorar el proceso. Las medidas definidas por Ecuación(E.5), Ecuación(E.6), Ecuación(E.7), Ecuación(E.8) son aplicables para cuatro fases del desarrollo de software:

Efectividad de requerimientos V&V= #Anomalías encontradas en los requerimientos por la gestión de V&V (E.5) #Anomalías encontradas en los requerimientos por todas las fuentes

Efectividad del diseño V&V= #Anomalías encontradas en los informes de diseño por la gestión de V&V (E.6) #Informes de diseño revisados por todas las fuentes

Efectividad en el código V&V= #Anomalías en código encontradas por la gestión de V&V (E.7) #Anomalías en el código encontradas por todas las fuentes

Efectividad en pruebas de ejecución V&V= #Anomalías de prueba encontradas por la gestión de V&V (E.8) #Pruebas revisadas por la gestión de V&V

E.4 Medidas para evaluar la eficiencia dela V&V

Las medidas asociadas con los trabajos de eficiencia de V&V proveen información que caracteriza la capacidad del trabajo de V&V para descubrir anomalías en los productos y procesos de software en la actividad de desarrollo en la cual son inyectados. Los máximos beneficios son alcanzados cuando las anomalías del software son descubiertas tan pronto como sea posible in el ciclo de vida de desarrollo. En consecuencia de esto se minimiza la repetición de trabajo y los costos de desarrollo. El análisis de estas medidas, las anomalías, y los factores casuales que son previamente descubiertos de la anomalía en la fase en la cual fue inyectado puede revelar necesidad de mejorar en métodos, procesos, herramientas, y técnicas para mejorar el trabajo general de V&V.

Una eficiencia baja en el valor de medida de V&V sugiere que el trabajo de V&V de software no descubre anomalías en las posibles actividades más tempranas, o que el desarrollo de productos de software es inmaduro, o una combinación de ambos. Si el valor de la medida de eficiencia de V&V es alto, entonces esto sugiere que el trabajo de V&V esta descubriendo anomalías en las posibles actividades más tempranas, o que el desarrollo de productos de software es maduro, o una combinación de ambos. Luego de tomar en cuenta el valor de medida, el siguiente paso es evaluar medidas de desarrollo de programas de software para llegar a clarificar y discernir las tendencias de las medidas para determinar la necesidad de mejorar el proceso. Las medidas definidas por Ecuación(E.9), Ecuación(E.10), Ecuación(E.11), y Ecuación(E.12) son aplicables para cuatro fases del desarrollo de software:

Eficiencia de requerimientos V&V= #Anomalías encontradas en los requerimientos por V&V en dicha activ (E.9) #Anomalías encontradas en los requerimientos por V&V en todas las actividades

114Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

Eficiencia del diseño V&V= #Anomalías encontradas en los informes de diseño por V&V en dicha actividad (E.10) #Informes de diseño revisados por V&V en todas las actividades

Eficiencia V&V= #Anomalías en código encontradas por V&V en la actividad de implementación (E.11) #Anomalías en el código encontradas por V&V en todas las actividades

Eficiencia V&V= #Anomalías de prueba encontradas por V&V en la actividad de prueba (E.12) #Pruebas revisadas por V&V en todas las actividades

Anexo F(informativo)Ejemplo de relación organizacional de V&V para las responsabilidades del proyecto.F.1 Relaciones organizacionales V&V.La figura 1 muestra un ejemplo de relaciones organizacionales entre el equipo de V&V, el que adquiere y el suministrador, e identifica la información y los flujos de datos a través de los trabajos de V&V. Muchas otras relaciones organizacionales trabajarán bien a lo largo de las responsabilidades del proyecto, flujo de datos, y reportando flujos definidos y documentados.

Figura F.1- Relaciones de V&V para otras responsabilidades del proyectoNOTA- Las líneas en la Figura F.1 representa el flujo de control e información como flujos:A: Presentación de la documentación del programa (p.e., conceptos, requerimientos, diseño, manuales de usuario), código fuente, estado del programa, presupuestos del programa, y planes de desarrollo y planificaciones.B: Aceptación, denegación, y recomendaciones de los elementos de desarrollo lista de entregado en A.

115Copyright © 2005 IEEE. Todos los derechos reservados,

Administración del programa adquirido Usuarios

Comités y tablas de descuidoTrabajo de desarrollo

Trabajo de V&V

Grupo de desarrollo

Grupo de aseguramiento de

calidad

Grupo de V&V

IEEE

Std 1012-2004 ESTANDAR IEEE

C: Presentación de resultados de tareas de SVVP, V&V, reportes de anomalías, y otros reportes especiales.D: Aprobación, denegación, y recomendaciones en cuestiones de V&V y la lista de distribución en C.E: Presentación de V&V resultados de tarea, informes de anomalía, informes de actividad, e informes especiales como dirigido por el programa de adquirentedirección.F: Presentación de documentación de programa (p.ej, concepto, exigencias, diseño, manuales de usuarios, informes especiales, código fuente,y listas de programa).*: El personal de garantía de calidad puede hacer un informe directamente al Director de Garantía de Calidad más bien que por el desarrolloorganización.

Anexo G(informativo)Opcional V&V tareasAnálisis de algoritmo. Verifice la realización correcta de algoritmos, ecuaciones, formulaciones matemáticas, o expresiones. Saque de nuevo cualquier algoritmo significativo y ecuaciones de principios básicos y teorías.Compárese contra referencias establecidas o datos históricos probados pasados. Valide los algoritmos, ecuaciones, formulaciones matemáticas, o expresiones con respecto al sistema y exigencias de software. Asegure esto los algoritmos y las ecuaciones son apropiados para la solución de problema. Valide el exactitud de alguno coacciones o limitaciones, como doblamiento, truncamiento, simplificaciones de expresión, valoraciones mejores adecuadas, y soluciones no lineales impuestas por los algoritmos y ecuaciones.Interpretación de auditoría. Proporcione una evaluación independiente de si un proceso de software y sus productos confórmese a regulaciones aplicables, estándares, proyectos, procedimientos, especificaciones, y pautas. Las auditorías pueden sea aplicado a cualquier proceso de software o producto en cualquier etapa de desarrollo. Las auditorías pueden ser iniciadas por el proveedor, el adquirente, el revelador, u otro partido complicado como una agencia reguladora. El iniciador de el la auditoría selecciona el equipo de auditoría y determina el grado de independencia requerida. El iniciador de la auditoríay el líder de equipo de auditoría establece el objetivo, el alcance, el plan, y el reportaje de exigencias para la auditoría.Los auditores coleccionan pruebas suficientes para decidirse si los procesos de software y los productos se encuentran el criterios de evaluación. Ellos identifican desviaciones principales, tasan el riesgo a calidad,

116Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

lista, y costaban, e informe su conclusiones. Los ejemplos de procesos que podrían ser revisados incluyen prácticas de dirección de configuración, uso deinstrumentos de software, grado de integración de vario software que trama disciplinas en particular en desarrollando una arquitectura, cuestiones de seguridad, formación, y dirección de proyecto.Apoyo de auditoría. Proporcione la maestría técnica a los auditores por la petición. Ellos pueden representar al adquirente en las medidas de auditoría y pueden asistir en el V&V de actividades remediadoras identificadas por la auditoría.Análisis de flujo de control. Tase el exactitud del software haciendo el diagrama del control lógico. Examinar el flujo de la lógica para identificar ausencia, exigencias incompletas, o inexactas. Valide si el flujo del control entre las funciones representa una solución correcta con el problema.Análisis de costes. Evalúes el estado de coste de los procesos de desarrollo. Compárese planeó el presupuesto gastos contra actual gastos. Correlacione gastos de coste con el estado técnico y programe el progreso. Identifique riesgos de programa si los gastos actuales indican detrás de la lista y sobre estimaciones de costos.Análisis de base de datos. La evaluación del diseño de base de datos como la parte de un proceso de revisión de diseño podría incluira) Análisis de limitaciones físico. Identifique las limitaciones físicas de la base de datos, como el máximo el número de archivos, el máximo registra la longitud, el valor numérico más grande, el valor numérico más pequeño, y la longitud de serie máxima en unos datos los estructura y compara a valores diseñados.b) Índice contra análisis de almacenaje. Analice el uso de índices múltiples comparados al volumen de almacenado los datos para determinar si el acercamiento propuesto encuentra las exigencias para la interpretación de extracción de datosy coacciones de tamaño.c) Los datos estructuran el análisis. Algunos sistemas de administración de bases de datos tienen estructuras de datos específicas dentro de a registro, como series, mesas, y formatos de fecha. Examine el uso de estas estructuras para el potencial impacto en exigencias para almacenaje de datos y recuperación.d) Reserva y análisis de recuperación de desastre. Examine los métodos empleados para la reserva contra el las exigencias para recuperación de datos y recuperación de desastre de sistema e identifican carencias.

Análisis de flujo de datos. La evaluación de organigramas de datos como la parte de un proceso de revisión de diseño podría incluir a) Control de consecuencia de Symbology. Varios métodos solían representar el empleo de organigramas de datos muy symbology específico para representar las acciones realizadas. Verifique que cada símbolo es usado consecuentemente.b) Equilibrio de flujo. Compare los datos de salida de cada proceso a las entradas de datos y los datos sacados dentro del proceso para asegurar los datos está disponible cuando requerido. Este proceso no hace expresamente examine consideraciones de secuencia o cronometraje.c) Confirmación de datos sacados. Examine los datos sacados dentro de un proceso para exactitud y formato.Los datos diseñados para ser entrado en un proceso por la acción de operador deberían ser confirmados para asegurar disponibilidad.d) Llaves para poner índice a comparación. Compárese las llaves de datos solían recuperar datos de tiendas de datos dentro de a trate al diseño de índice de base de datos para confirmar que ningunas llaves inválidas han sido usadas y la unicidadlas propiedades son consecuentes.La recuperación de desastre planea la evaluación. Verifique que el plan de recuperación de desastre es adecuado de restaurar crítico operación del sistema en caso de una interrupción de sistema ampliada. El plan de recuperación de desastre debería incluir lo siguiente:a) La identificación de la recuperación de desastre combina y una lista de contactob) Procedimientos de operación de recuperaciónc) Procedimiento para establecer un sitio alternativo incluso voz y comunicaciones de datos, correo, y equipo de apoyod) Proyectos para reemplazo de equipo de computadorae) Establecimiento de una lista de reserva de sistemaf) Procedimientos para almacenaje y recuperación de software, datos, documentación, y archivos vitales fuera de sitiog) Logística de personal móvil, datos, documentación, etc.Evaluación de arquitectura distribuida. Tase la distribución de datos y procesos en el propuestola arquitectura para la viabilidad, calculando conflictos, la disponibilidad de telecomunicaciones, cuesta, reserva y restaura rasgos, tiempo de indisponibilidad, degradación de sistema, y provisiones para instalación de actualizaciones de software.

117Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

Evaluación de estudio de viabilidad. Verifice que el estudio de viabilidad es correcto, exacto, y completo. Valide esto todas las asunciones lógicas y físicas (p.ej, modelos físicos, reglas comerciales, procesos lógicos), coacciones, y las exigencias de usuario están satisfechas.Evaluación de riesgo independiente. Conduzca una evaluación de riesgo independiente en cualquier aspecto del proyecto de software e informe en las conclusiones. Tales evaluaciones de riesgo serán principalmente de una perspectiva de sistema. Ejemplos de la evaluación de riesgo incluye: propiedad de la metodología de desarrollo seleccionada o instrumentos para el proyecto;y los riesgos de calidad se asociaron con alternativas de lista de desarrollo propuestas.Inspección. Inspeccione los productos de software para descubrir defectos en el producto en cada etapa de desarrollo seleccionada asegurar la calidad del software emergente. El proceso de inspección puede consistir en pasos múltiples para el segregación de las funciones de inspección de lo siguiente:a) Planificación de inspecciónb) Descripción de productoc) Preparación de inspecciónd) Reunión de examene) El defecto refundef) Continuación de resoluciónUna inspección es realizada por un pequeño equipo de reveladores de par e incluye, pero no es conducida por el autor. El equipo de inspección por lo general consiste en tres a seis personas, y en algunos casos incluye al personal de la prueba de grupo, garantía de calidad, o V&V. Los participantes asumen que papeles específicos encuentran, clasifican, hacen un informe, yanalice defectos en el producto. Cada tipo de la inspección es expresamente definido por su objetivo intencionado, los criterios de entrada requeridos, la clasificación de defecto, las listas de comprobación, los criterios de salida, designaron a participantes, y su preparación y procedimientos de examen. Las inspecciones no debaten juicios de ingeniería, sugierencorrecciones, o educan a miembros de proyecto; ellos descubren anomalías y problemas y verifican su resolución por el autor.Inspección (concepto). Valide esto la arquitectura de sistema y las exigencias satisfacen necesidades de cliente. Verificar que los requisitos del sistema sean completos y correctos, y esto omisiones, defectos, y ambigüedades en el las exigencias son descubiertas.Inspecciones (diseño). Verifique que el diseño puede ser puesto en práctica, es detectable a las exigencias, y que todos el interfaz y la lógica procesal son completos y correctos, y esto omisiones, defectos, y ambigüedades en el diseño es descubierto.Inspecciones (exigencias). Valide esto las exigencias encuentran necesidades de cliente y pueden ser puestas en práctica.Verifique que ellos son completos, detectables, verificables, y consecuentes de modo que omisiones, defectos, y ambigüedades en las exigencias son descubiertos.Inspección (código fuente). Verifique que la realización de código fuente es detectable al diseño, y que todos los interfaces y la lógica procesal son completos y correctos, y esto omisiones, defectos, y ambigüedades en el código fuente es descubierto.Caso de prueba de inspección (componente, integración, sistema, aceptación). Verifice que el (componente,la integración, el sistema, aceptación) el plan de prueba ha sido seguido exactamente, que el juego de casos de prueba componentes es completo, y que todos los casos de prueba componentes son correctos.Diseño de prueba de inspección (componente, integración, sistema, aceptación). Verifice que el (componente, integración, sistema, aceptación) el diseño de prueba es consecuente con el plan de prueba, y que el diseño de prueba es correcto, completo, y legible.Plan de prueba de inspección (componente, integración, sistema, aceptación). Verifice que el alcance, estrategia, los recursos, y la lista del (componente, integración, sistema, aceptación) probando el proceso han sido completamente y exactamente especificado, que todos los artículos para ser probados y todas las tareas requeridas para ser realizadas tienen sido definido, y asegurar que todo el personal y los recursos necesarios de realizar las pruebas han sidoidentificado.Evaluación operacional. Tase la preparación de despliegue y la preparación operacional del software.La evaluación operacional puede incluir el examen de los resultados de pruebas operacionales, revisiones de auditoría, y anomalía informes. Esta evaluación verifica que el software esa) En un punto conveniente de exactitud para fabricación en serie de aquel softwareb) Válido y correcto para sitio configuraciones específicasEscucha de interpretación. Coleccione la información en la interpretación de software en condiciones operacionales.Determine si el sistema y las exigencias de interpretación de software están satisfechos. La interpretación que supervisa es un proceso continuo y puede incluir la evaluación de los artículos siguientes:

118Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

a) Precios de transacción de base de datos para determinar la necesidad de reorganizar o poner índice de nuevo a la base de datosb) Escucha de interpretación de CPU para equilibrio de cargac) Utilización de almacenaje de acceso directad) Tráfico de red para asegurar amplitud de banda adecuadae) Las salidas críticas de un sistema (p.ej, frecuencia programada, esperó la variedad de valores, sistema programadoinformes, informes de acontecimientos)

Validación de instalación postal. Ejecute una referencia prueba de la prueba patrón o periódica para el software crítico cuando la fiabilidad es crucial o hay una posibilidad de la corrupción de software. Por automáticamente o a mano comparación resultados con los resultados de la prueba patrón establecidos, el sistema puede ser validado antes de cada ejecución de elsoftware. Cuando las pruebas de cota de referencia de preuso son poco prácticas, como para tiempo real, control del proceso de producción, y el software de uso de emergencia, una prueba periódica, conducida en un intervalo predeterminado, puede ser usado para asegurarfiabilidad continuada.Apoyo de descuido de dirección de proyecto. Tase el estado de desarrollo de proyecto para técnico y la dirección cuestiones, riesgos, y problemas. Evaluación de descuido de coordenada con el adquirente y desarrollo organización. Evalúes proyectos de proyecto, listas, procesos de desarrollo, y estado. Coleccione, analice, y informe en medidas de proyecto claves.Apoyo de evaluación de oferta. Participe en el proceso de selección de fuente de organización de desarrollo. Desarrollar factores de evaluación de oferta y criterios de evaluación. Independientemente evalúes la organización de desarrollo ofertas tasar conformidad a la declaración de exigencias de interpretación y trabajo.Pruebas de calificación. Verifique que todas las exigencias de software son probadas según pruebas de calificación exigencias que demuestran la viabilidad del software para operación y mantenimiento. Conducta como necesario cualquier prueba para verificar y validar el exactitud, exactitud, y completo de la calificación pruebas de resultados. Documente los resultados de prueba de calificación juntos con los resultados de prueba de calificación esperados.La planificación para pruebas de calificación puede comenzar durante las Exigencias V&V actividad.Análisis de regresión y pruebas. Determine el grado de V&V análisis y pruebas que deben ser repetidascuando los cambios son hechos a cualquier producto de software antes examinado. Tase la naturaleza del cambio en determine ondulación potencial o efectos secundarios e impactos en otros aspectos del sistema. Casos de prueba dirigidos de nuevo basados en cambios, correcciones de error, y evaluación de impacto, para descubrir errores engendrados por modificaciones de software.Análisis de reutilizabilidad. Verifique que los artefactos (los productos) del proceso de ingeniería de esfera se conforman aobjetivo definido por proyecto, formato, y contenido (p.ej, IEEE Std 1517-1999 [B11]). Verifice que la esfera los modelos y la arquitectura de esfera son correctos, consecuentes, completos, exactos, y se conforman a la esfera ingeniería de plan. Analice el activo (artículo de software querido para la reutilización) para verificar que el activo es consecuente con la esfera modelan y arquitectura de esfera.Análisis de reutilización. Analice la documentación del revelador para verificar que la esfera original del candidato el software de reutilización satisfará la esfera del nuevo sistema (p.ej nivel de integridad de software, necesidades de usuario, funcionando ambiente, seguridad, seguridad, e interfaces). Si el revelador no ha realizado ningún análisis de esfera, funcionar el análisis de esfera (ver IEEE Std 1517-1999 [B11]) comparar la esfera original y la nueva esfera de elsoftware de reutilización de candidato. Verifique que reutilización de revelador que planea disposiciones y documento toda la esferadiferencias.Análisis de simulación. Use una simulación para ejercer el software o partes del software para medir el interpretación del software contra condiciones predefinidas y acontecimientos. La simulación puede tomar la forma de a el paseo manual - por del software contra el programa específico valora y entradas. La simulación también puede ser otro programa de software que proporciona las entradas y la simulación del ambiente al software bajo examen. El análisis de simulación es usado para examinar exigencias de tiempo de respuesta e interpretación críticas ola respuesta del software a acontecimientos anormales y condiciones.El apresto y el cronometraje de análisis. Coleccione y analice datos sobre las funciones de software y utilización de recurso a determine si el sistema y las exigencias de software para velocidad y capacidad están satisfechos. Los tipos de software las funciones y las cuestiones de utilización de recurso incluyen, pero no son limitadas con a) Carga de CPU

119Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

b) Memoria de acceso aleatorio y almacenamiento secundario (p.ej disco, cinta) utilizaciónc) Velocidad de red y capacidadd) Entrada y velocidad de salidaEl apresto y el cronometraje del análisis son comenzados en el diseño de software e iterados por pruebas de aceptación.Evaluación de software de sistema. Tase el software de sistema (p.ej, sistema operativo, la computadora ayudó al software tramando instrumentos, sistema de administración de bases de datos, depósito, software de telecomunicaciones, usuario gráfico interfaz) para la viabilidad, haga impacto con interpretación y exigencias funcionales, madurez, supportability,adhesión a estándares, el conocimiento del revelador de y experiencia con el software de sistema y hardware, y exigencias de interfaz de software.Certificación de prueba. Certifique los resultados de prueba verificando que las pruebas fueron conducidas usando la línea de fondo exigencias, un proceso de control de configuración, y pruebas repetibles, y atestiguando las pruebas. Certificación puede ser llevado a cabo en un nivel de artículo de configuración de software o en un nivel de sistema.Evaluación de prueba. Evalúes las pruebas para la cobertura de exigencias y pruebe el completo. Tase la cobertura por la evaluación del grado del software se entrenó. Tase el completo de prueba determinando si el juego de entradas usado durante la prueba son una muestra representativa justa del juego de todas las entradas posibles al software. Tasar si las entradas de prueba incluyen entradas de condición divisorias, entradas raramente encontradas, y entradas inválidas. Paraalgún software puede ser necesario tener un juego de entradas secuenciales o simultáneas en un o varios procesadores para probar el software suficientemente.Presencia de prueba. Supervise la fidelidad de la ejecución de prueba a los procedimientos de prueba especificados y atestigüe el grabación de resultados de prueba. Cuando un fracaso de prueba ocurre, el proceso de prueb as puede ser seguido por: (1)la realización “de un trabajo alrededor” al fracaso; (2) insertando un remiendo de código temporal; (o 3) parada de las pruebastrate y realización de una reparación de software. En todos los casos, tase el proceso de continuación de prueba para el proceso de prueba rotura (p.ej, algún software no es probado o un remiendo es dejado en el lugar permanentemente), el impacto adverso en otropruebas, y pérdida de control de configuración. El análisis de regresión y las pruebas deberían ser hechos para todo el software afectado por el fracaso de prueba.Formación de evaluación de documentación. Evalúes los materiales de formación y procedimientos para el completo, exactitud, legibilidad, y eficacia.Análisis de utilidad. Verifice que las necesidades de grupo de presión y los intereses son considerados durante el desarrollo, la operación, y el mantenimiento tratan actividades. El análisis asegurará que: diseño centrado por humano las actividades son realizadas; los factores humanos y las consideraciones de ergonomía son incorporados en el diseño, los efectos adversos potenciales en salud humana y seguridad son dirigidos en el diseño; y las necesidades de usuario están satisfechas en una manera que apoya la eficacia de usuario y la eficacia.Evaluación de documentación de usuario. Evalúes la documentación de usuario para su completo, exactitud, y el consecuencia con respecto a exigencias para el interfaz de usuario y para cualquier funcionalidad que puede ser invocada por el usuario. La revisión de la documentación de usuario para su legibilidad y eficacia debería incluir los usuarios finales representativos que son desconocidos con el software. Emplee la documentación de usuario en la planificaciónuna prueba de aceptación que es representativa del ambiente operacional.Formación de usuario. Asegure que la formación de usuario incluye reglas que son específicas al administrativo, operacional y aspectos de aplicación, y estándares de industria para aquel sistema. Esta formación debería estar basada en el documentación de usuario técnica y procedimientos proporcionados por el fabricante del sistema. La organización responsable del uso del sistema debería ser responsable de proporcionar la formación de usuario apropiada.V&V generación de plan de instrumento. Prepare un plan que describe los instrumentos tenía que apoyar el V&V esfuerzo. El plan incluye una descripción de interpretación de cada instrumento, entradas requeridas e instrumentos asociados, salidas generado, la fecha de necesidad, y costado del instrumento compra o desarrollo. El plan de instrumento también debería describir la prueba de instalaciones e integración y laboratorios de ensayos de sistema que apoyan el V&V esfuerzo. El alcance y rigor de el V&V el esfuerzo como definido por el nivel de integridad de software seleccionado debería ser considerado en la definición el interpretación requerida de cada instrumento.Paseo - por. Participe en los procesos de evaluación en cual personal de desarrollo conducen a otros por a examen estructurado de un producto. Asegure que los participantes son calificados para examinar los productos y no son sujetos a la influencia excesiva. Ver descripciones específicas del paseo de exigencia - por, diseñe walkthrough, paseo de código fuente - por, y paseo de prueba - por.

120Copyright © 2005 IEEE. Todos los derechos reservados,

IEEE

Std 1012-2004 ESTANDAR IEEE

Paseo - por (diseño). Participe en un paseo - por del diseño y las actualizaciones del diseño para asegurar completo, exactitud, integridad técnica, y calidad.Paseo - por (exigencias). Participe en un paseo - por de la especificación de exigencias para asegurar esto las exigencias de software son correctas, inequívocas, completas, verificables, consecuentes, modificables, detectables, verificable, y utilizable en todas partes del ciclo de vida.Paseo - por (código fuente). Participe en un paseo - por del código fuente para asegurar que el código es completo, correcto, conservable, libre de errores lógicos, se conforma a la codificación de estándares y convenciones, y funcionará eficazmente.Paseo - por (prueba). Participe en un paseo - por de la documentación de prueba para asegurar que el planeado las pruebas son correctas, completas, y que los resultados de prueba serán correctamente analizados.

Anexo H(informativo)Bibliografía

[B1] FP-05 Software Measurement, IEEE Computer Society Software and Systems Engineering StandardsCommittee Policy.4[B2] IEEE 100, The Authoritative Dictionary of IEEE Standards Terms, Seventh Edition.5,6[B3] IEEE Std 610.12-1990 (Reaff 2002), IEEE Standard Glossary of Software Engineering Terminology.[B4] IEEE Std 829-1998, IEEE Standard for Software Test Documentation.[B5] IEEE Std 982.1-1988, IEEE Standard Dictionary of Measures to Produce Reliable Software.[B6] IEEE Std 1012A™-1998, Supplement to IEEE Standard for Software Verification and Validation: ContentMap to IEEE/EIA 12207.1-1997.[B7] IEEE Std 1028-1997, IEEE Standard for Software Reviews.[B8] IEEE Std 1044-1993, IEEE Standard for Software Anomalies.[B9] IEEE Std 1061-1998, IEEE Standard for a Software Quality Metrics Methodology.[B10] IEEE Std 1074-1997, IEEE Standard for Developing Software Life Cycle Processes.[B11] IEEE Std 1517-1999, IEEE Standard for Information Technology—Software Life Cycle Processes—Reuse Processes.[B12] IEEE/EIA Std 12207.0-1996, IEEE/EIA Standard—Industry Implementation of International StandardISO/IEC 12207:1995 (ISO/IEC 12207) Standard for Information Technology—Software Life CycleProcesses.[B13] ISO/IEC 12207:1995, Information Technology—Software Life Cycle Processes; as amended byAmendment 1:2002.7

121Copyright © 2005 IEEE. Todos los derechos reservados,