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

IEEE 730

No description
by

SUSANA RIVERA ZAPATA

on 22 February 2016

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of IEEE 730

IEEE 730
el Institute Of Electrical And Electronics Engineers (
Instituto de Ingenieros Eléctricos y Electrónicos) se formó en 1963.

Es un plan de aseguramiento de calidad que busca establecer los responsables , fases, herramientas, técnicas, indicadores y documentación que se utilizarán para asegurar la buena calidad del proyecto.



El estándar IEEE 730 es una recomendación para elaborar un plan de aseguramiento de la calidad del software (SQAP, softare Quality Assurance Plan) para los proyectos de desarrollo de software. Proporciona los requisitos mínimos aceptables para la preparación y el contenido de los planes de aseguramiento de la calidad de software. Fue escrito para ser utilizado en las fases de desarrollo y mantenimiento del software.

Este estándar puede aplicar a tres grupos:

a.) El usuario, que puede ser otro elemento de la misma organización que desarrolla el software, que necesita el producto con un grado razonable de confianza.
b.) El proveedor, que necesita establecer un estándar para planificar y medir.
c.) El público, que puede verse afectado por el uso del producto.


En este plan, se debe incluir los siguientes pasos y/o puntos:
1.) Propósito:

• Delinea el propósito específico y el alcance del plan
• Lista los nombres de los elementos software cubiertos por el plan y el uso de dichos elementos.
Especificar el propósito del plan, con cada uno de los estándares a trabajar.

2.) Documentos de referencia
• Proporciona una lista completa de los documentos referenciados en el plano o utilizados en su elaboración.

3.) Gestión :
• Está muy ligado al plan del proyecto del software
• Idealmente redactado en formato IEEE

3.1. Organización :
• Describe la estructura organizativa que influye y controla la calidad del software.
• Identifica roles y responsabilidades dentro del plan SQA
• Identifica a los responsables de preparar y mantener el plan SQA

3.2. Tareas:
• Describe:
- La porción del ciclo de vida cubierta por el plan SQA
- Las tareas a desarrollar
- Los criterios de entrada y salida para cada tarea
- Las relaciones entre esas tareas y los principales puntos de control planeados.

3.3. Roles y responsabilidades:

• Identifica los elementos organizativos específicos responsables de llevar a cabo cada tarea.

3.4. Recursos estimados de garantías de calidad:

• Proporciona la estimación de recursos y costes gastados en garantía de calidad y en las tareas de control de calidad.

4.) Documentación:

• Describe toda la documentación que se va a generar durante el proceso de desarrollo.


4.1. Propósito:

• Identifica la documentación que dirige el desarrollo, verificación y validación, uso y mantenimiento del software.
• Lista los documentos que serán revisados o auditados, así como los criterios de revisión.

4.2. Requisitos mínimos de documentación
Para asegurar que la implementación del software satisface los requisitos técnicos, se requiere como mínimo la siguiente documentación:
- Descripción de requisitos software
- Descripción de diseño del software
- Planes de verificación y validación


- Informe de resultados de verificación e informe de resultados de validación
- Documentación de usuario
- Plan de gestión de la configuración software

4.2.1. Documentación del usuario
• La documentación guía al usuario en la instalación, operación, gestión y mantenimiento de los productos software.
• Debería describir las entradas y salidas, así como los mensajes de error.

Gracias
IEEE 730
ANGIE SUSANA RIVERA ZAPATA
5.) Estándares, practicas, convenciones y métricas
• Propósito:
- identifica:
- estándares
- prácticas
- convenciones
- técnicas estadísticas
- métricas aplicables al proyecto

5.2. contenido
• debe incluir cómo mínimo:
- estándares de documentación
- estándares de diseño
- estándares de codificación
- estándares de comentarios
- práctica y estándares de prueba
- métricas del producto y proceso de garantía de calidad seleccionada.


6.) Revisiones del software
• Determina las revisiones del software

6.1. Requisitos mínimos
- Revisión de las especificaciones software
- Revisión del diseño arquitectónico
- Revisión del diseño detallado
- Revisión del plan de verificación y validación
- Auditoría de la funcionalidad
- Auditoría física (consistencia y fecha entrega)
- Auditoría durante el proceso (consistencia del diseño)
- Revisiones de gestión
- Revisión del plan de gestión de la configuración software
- Revisión post-implementación

7.) Prueba


8.) Informe de problemas y acción correctiva
• Describe las prácticas y procedimientos de informe, seguimiento y resolución de problemas, tanto a nivel producto cómo proceso.

9.) Herramientas, técnicas y metodologías utilizadas

10.) Control de medios
• Identificar el medio físico de cada producto software
• Protegerlo de daños durante el proceso

11.) Control de proveedores
• Determina las técnicas para garantizar que el software proporcionado por proveedores externos cumplen sus requisitos
• También es aplicable a código heredado

12.) Colección de registros, mantenimiento y conservación

13.) Gestión del riesgo
• Especifica el plan de gestión del riesgo
• Idealmente redactado

14.) Glosario
• Términos específicos del plan SQA
Full transcript