Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Presentación Estandar IEEE 1012-2004

Exposición del estandar de verificación y validación de software
by

Carlos Balderas

on 21 January 2014

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Presentación Estandar IEEE 1012-2004

IEEE 1012-2004 Estándar para la
Verificación y Validación de Software

El estándar IEEE 1012-2004 para la verificación y validación de software consiste en un procedimiento organizado y estandarizado basado en normas de calidad el cual es aplicado en algunos modelos del ciclo de vida del software, determina la calidad de un producto conforme a los requisitos y a la satisfacción de los mismos a través de un método que implique la evaluación óptima del software y cada uno de sus componentes fases o etapas.
Qué es ?
Se aplica al software adquirido, desarrollado, mantenido o modificado, se integra al proceso de
ciclo de vida del software en cada una de sus fases y procesos.
Adquisición
Suministro
Desarrollo
Operación
Mantenimiento
En que consiste
el proceso
de V &V ?

1) Cumplir con los requisitos (por ejemplo, de la exactitud, exhaustividad, coherencia, precisión) para todas las actividades del ciclo de vida durante cada proceso del ciclo de vida (adquisición, suministro, desarrollo, operación y mantenimiento).

2) Cumplir con las normas, prácticas y convenciones durante los procesos de ciclo de vida.

3) Completar con éxito cada actividad del ciclo de vida y satisfacer todos los criterios siguientes para iniciar las actividades del ciclo de vida (por ejemplo, construir el software correctamente)
Validación
Verificación
1) satisfacer los requisitos del sistema asignados al software al final de cada ciclo de actividad de la vida.

2) Solucionar con exactitud el problema .

3) Satisfacer uso y necesidades de los usuarios.
Cual es el propósito del
IEEE 1012-2004 ?

Establecer un marco de trabajo organizado para los procesos de V&V, las tareas y actividades apoyando los procesos del ciclo de vida del software
Definir tareas de verificación y validación.
Permite establecer un plan de verificación y validación de software
Cuales son los objetivos del plan de V&V ?
Proporcionar una evaluación objetiva de los productos y procesos del ciclo de vida del software , evidencia si los requisitos del sistema son apropiados, completos, precisos, coherentes y comprobables. Determina si el producto satisface las necesidades del usuario estipuladas inicialmente.
Con base en esto los resultados del plan de verificación y validación son:

1. Facilitar la detección de anomalias en el software.
2. Mejorar la visión de la gestión de riesgos.
3. Apoyar los procesos del ciclo de vida asegurando conformidad con el producto.
4. Proporcionar evidencia objetiva de conformidad con el software.
5. Apoyar la mejora de procesos para generar un modelo de análisis de un sistema integrado.
La verificación y validación son dos procesos complementarios que permiten establecer mejores criterios de análisis, evaluación crítica, inspección, evaluación y prueba de V & V, generando tareas para cada actividad del ciclo de vida del software.
Cuales son los procesos
para la verificación y
validación de software ?

1. Proceso de Gestión
El proceso de gestión se compone de una serie de actividades y tareas especificadas según la norma IEEE 1012-2004 las siguientes:
- Preparación de planes de ejecución
Inicio de ejecución de planes
- Seguimiento a procedimiento de ejecución de planes.
- Análisis de la problemática generada durante la ejecución de determinado plan.
- Informes sobre el progreso de los procesos.
- Asegurar que los productos cumple con los requisitos.
- Evaluar los resultados.
- Determinar cuando una tarea esta terminada.
- Comprobar resultados de integridad.
- Comprobar procesos para eficiencia y eficacia.
- Revisión de proyecto de calidad.
- Revisión de riesgos del proyecto.
- Revisión de métricas del proyecto.
2. Proceso de Adquisición
El segundo proceso a realizar es el de adquisición este proceso inicia con definir una necesidad existente, posteriormente se plantea una solicitud, y finaliza con la adquisición de la propuesta por medio de una aceptación de la misma. Este se compone de una sola actividad:

- Soporte de adquisición de V&V
3. Proceso de Suministro
En este proceso se prepara la propuesta para responder a determinada solicitud de un cliente para proveer un sistema, posteriormente se organizan los recursos necesarios para el desarrollo y gestión del proyecto.

La actividad propuesta acorde con el IEEE 1012-2004 es planificación de V&V la cual a su vez tiene asignadas ciertas tareas establecidas en el estándar.
Proceso de V & V según
IEEE 1012 -2004

Tabla de Tareas con Niveles
de Integridad

4. Proceso de Desarrollo
Este subproceso es uno de los más complejos y largos en el proceso de V&V ya que conforma todas las actividades que realiza el desarrollador, el análisis de requerimientos, el diseño, la codificación de software, integración, pruebas, instalación y aceptación del producto de software.

- Concepto V&V
- Requerimientos V&V
- Diseño V&V
- Implementación V&V
- Pruebas V&V
- Instalación y chequeo V&V
4. Proceso de Operación
Ciclo de vida
El proceso de operación consiste en llevar a cabo la operación y uso del sistema por el usuario final. Se compone de una actividad denominada Operación V&V.
4. Proceso de Operación
Se evidencia cuando se presentan cambios en el software y deben tenerse los recursos y planes necesarios para realizar modificaciones, migraciones y retiros o remplazos en el software. La actividad que soporta este proceso se denomina Mantenimiento V&V.
En este capítulo se enumeran todos los documentos referenciados en el PVVS.
• IEEE Std 1012-1986 - Este es el estándar IEEE para la Verificación de Software y los Planes de validación.
• PACS - El Plan de Aseguramiento de Calidad de Software para Equipo Centaur se encuentra en CVS módulo: docs / PACS
• SCMP - La configuración del software del Plan de Manejo de Centaur en equipo es situado en el CVS módulo: docs / scmp
2. REFERENCIAS
Esta norma no requiere el uso de las referencias normativas.
3. DEFINICIONES
Este capítulo contiene las definiciones de cualquier terminología específica o acrónimos utilizados en este plan.
Consejo de
Administración
BoM
Project Manager
PM
Quality Assurance
QA
Verificación de Software
y el Plan de Validación
SVVP
Verificación de Software
y el Informe de Validación
SVVR
Task Group
TG
Verificación
y
Validación
V & V
Una comprobación de control de calidad que se realiza en cualquier parte del proyecto
V & V tarea
ºº
Son una gama de valores que representan la complejidad del software, la criticidad, riesgo, nivel de seguridad, el rendimiento deseado, la confiabilidad, u otros proyectos singulares, características que definen la importancia del software para el usuario y el comprador.
Este esquema de ejemplo se basa en los conceptos de las consecuencias y potencial de mitigación.
4. Niveles de Integridad de Software
Elemento Software debe ejecutar correctamente o se producirá consecuencias graves (pérdida de la vida, la pérdida de
sistema, pérdida económica o social). No es posible mitigación.
Elemento Software debe ejecutar correctamente o el uso previsto (misión) del sistema / software no sera realizado, que acarrea consecuencias graves (lesiones permanentes, mayor
degradación del sistema, el impacto económico o social). Parcial de mitigación completa es posible.
Elemento Software debe ejecutar correctamente una función o la finalidad no se materialicen,
provocando consecuencias menores. Completar mitigación posible.
Elemento Software debe ejecutar correctamente o función que se pretende no se materialicen, causando
consecuencias insignificantes. La mitigación no es necesario.
Nivel 1
Nivel 2
Nivel 3
Nivel 4
6. Presentación de informes Software V & V, administrativa y requisitos de documentación
6.1 V & V Requisitos de información
Los informes de V & V constituirán el software de V&V Informe (SVVR).
Los informes de V&V se componen de lo siguiente:
a.
b.
c.
d.
e.
V & V informes de tareas.
El esfuerzo de V & V debe documentar los resultados de V & V tareas y el estado. Los informes del comité incluyen 25 criterios
V & V informes de actividad de resumen.
Un informe de resumen de actividades se resumen los resultados de V & V tareas realizadas por las siguientes actividades de V & V del ciclo de vida:
1) Adquisición de apoyo

2) Planificación

3) Concepto

4) los requisitos

5) Diseño

6) La aplicación

7) Ensayo

8) Instalación y comprobación

9) Funcionamiento

10) Mantenimiento
1) Anomalía evaluación
2) Concepto de evaluación de documentación
3) evaluación de la gestión de configuración
4) Contrato de verificación
5) La criticidad análisis
6) Evaluación de las nuevas restricciones
7) Hardware / software / análisis de asignación
de necesidades de los usuarios
8) El análisis de riesgos
9) Verificación de la instalación
10) La instalación auditoría de configuración
11) Interfaz de análisis
12) la evaluación de las Migraciones
13) los procedimientos de evaluación de funcionamiento
14) Proyecto de evaluación del cambio
15) Recomendaciones
16) Evaluación de Retiro
17) Revisar los resultados
18) Análisis de riesgos
19) Análisis de seguridad
20) Software evaluación del diseño
21) Software de evaluación los requisitos
22) El código fuente y código fuente
evaluación documentación
23) Requisitos del sistema opinión
24) Resultados del ensayo
25) Análisis de Trazabilidad
V & V informes de anomalías.
El esfuerzo de V & V debe documentar en un informe de cada anomalía que detecta.
V & V informe final.
El informe de V & V definitivo será emitido al final de la actividad de instalación y registro de salida o al final de los esfuerzos de V & V.
Los informes de V & V también puede incluir informes opcionales (por ejemplo, los informes de estudios especiales y otros informes). El esfuerzo de V & V debe documentar en unos estudios especiales reportar cualquier daño especial V&V estudios realizados durante el ciclo de vida del software.

El esfuerzo de V & V debe documentar en un informe los resultados de las tareas realizadas, pero no se define en el PVVS.

El título del informe puede variar de acuerdo con la materia.
Opcional V&V informes
6.2 V&V Requisitos administrativos
Los requisitos administrativos se documentarán en el PVVS.
Los requisitos de V & V administrativos consistirán en lo siguiente:
1) Anomalía de resolución y notificación política

2) La tarea política iteración

3) Desviación política
4) Los procedimientos de control

5) Normas, prácticas y convenciones
6.3 V & V Requisitos de documentación
El alcance de la documentación de V & V está formado por documentación de prueba V & V y documentación PVVS. Los requisitos de documentación, se describen en los siguientes apartados.
Deberá incluir los planes de la prueba, los diseños, los casos, los procedimientos y los resultados del componente, integración, sistema y pruebas de aceptación desarrollado por el esfuerzo de V&V.

La prueba de V&V documentación deberá ajustarse al proyecto definido por el objeto documento de prueba, el formato y contenido (por ejemplo, véase el IEEE
Std. 829 ™ -1998 [B4]).
6.3.1 V & V documentación de pruebas
El esfuerzo de V & V se genera una PVVS que se ocupa de los temas descritos en el numeral 7 de esta norma. Si no hay información pertinente a un tema, el PVVS deberá contener la frase

"Este tema no es aplicable a este plan"

y expondrá una razón apropiada para la exclusión. Temas adicionales pueden ser añadidos al plan. Si algún material SVVP aparece en otros documentos, el PVVS puede repetir el material o hacer referencia al material. El SVVP se mantiene a lo largo de la vida del software
6.3.2 SVVP documentación
El SVVP contendrá el contenido descrito en esta cláusula.

El usuario de esta norma podrá adoptar cualquier formato
y la sección sistema de numeración para el PVVS.

Los números de sección SVVP mencionados en esta cláusula se proporcionan
para ayudar a mejorar la legibilidad. Un esquema SVVP ejemplo se muestra en la caja de texto siguiente.
7. Software V & V esbozo del plan
(A) Las pruebas formales para determinar si un sistema cumple con sus criterios de aceptación y para permitir que el cliente pueda decidir si acepta o no el sistema.
(B) Las pruebas formales a cabo para permitir a un usuario, cliente, u otra entidad autorizada para determinar si debe aceptar un sistema o componente.
3.1.1
pruebas de aceptación:
Cualquier cosa que se observa en la documentación o el funcionamiento del software que se desvía de las expectativas basadas en los productos de software previamente verificados o documentos de referencia.
Un elemento (por ejemplo, el diseño, las especificaciones, código fuente, documentación, conjuntos de pruebas, procedimientos manuales) que ha sido diseñado para su uso en múltiples contextos.
Una de las partes que componen un sistema. Un componente puede ser hardware o software y pueden subdividirse en otros componentes.
Pruebas de hardware o componentes de software individuales o grupos de relacionado componentes.
El grado de impacto que un requisito, módulo, error, error, fallo u otro elemento tiene en el desarrollo o el funcionamiento de un sistema.
Un espacio del problema.
(A) El análisis de los sistemas dentro de un dominio para descubrir puntos en común y diferencias entre ellos.
(B) El proceso por el que la información utilizada en los sistemas de software de desarrollo es identificada, capturada, y organizado de modo que puede ser reutilizado para crear nuevos sistemas, dentro de un dominio.
(C) El resultado del proceso en (A) y (B).
Un enfoque basado en la reutilización de definir el ámbito de aplicación (es decir, el dominio de definición), especificando la estructura (es decir, el dominio de la arquitectura), y la construcción de los activos (por ejemplo, requisitos, diseños, software de código, documentación) para una clase de sistemas, subsistemas, o aplicaciones. Ingeniería de dominio pueden incluir las siguientes actividades: definición, análisis de dominio de dominio, el desarrollo de la arquitectura de dominio, y la implementación de dominio.
La combinación de un dispositivo de hardware e instrucciones de ordenador y los datos que residen como software de sólo lectura en el dispositivo.
3.1.2
Anomalía
3.1.3
De activos:
3.1.4
Componente:
3.1.5
Componente de la prueba:
3.1.6
Importancia:
3.1.7
Dominio:
3.1.8
Análisis del dominio
3.1.9
Dominio de la ingeniería:
3.1.10
Firmware:
ANSI American National Standards Institute

COTS comercial off-the-shelf

IEC Comisión Electrotécnica Internacional

IEEE Instituto de Ingenieros Eléctricos y Electrónicos

Interfaz DDI diseño documento

IRS interfaz de especificación de requisitos

ISO Organización Internacional para la Estandarización

IV y V independiente de verificación y validación

NDI no desarrollado artículo

RFP solicitud de propuesta (oferta)

Software SDD descripción del diseño

SRS especificación de requisitos software

SVVP software V & V Plan

SVVR software V & V Informe

V & V de verificación y validación
3.2 Abreviaturas y acrónimos
Los siguientes acrónimos y abreviaturas aparecen en esta norma:
Rol responsable
Responsable de verificacion
Momento de realización
Fase Inicial
Fase de Elaboración
Actividades de las cuales es salida
Planificar la verificación
Actividades de las cuales es entrada
Planificar la verificación
Ajustar y controlar la verificación
Especificar los casos de prueba
Verificación unitaria
Verificar Documento
Verificar el software
Verificar el sistema
Evaluar la verificación
Realizar el informe final de verificación
Planificar el proyecto
Planificar la implantación
Objetivo
Identificar los componentes de software y documentos que deben ser verificados.
Describir las estrategias de verificación que serán usadas. Identificar los recursos necesarios y proporcionar una estimación de esfuerzo para realizar la verificación
Plantilla
http://www.fing.edu.uy/inco/cursos/ingsoft/pis/proceso/MUM/sal/planver.htm
Full transcript