ESTÁNDARES DE CALIDAD DE SOFTWARE DE LA IEEE (INSTITUTE OF ELECTRICAL AND ELECTRONIS ENGINEERS) 1. DEFINICIÓN Regla o base de comparación que se utiliza para medir algún aspecto del software.
Calidad
Productividad
Duración
Esfuerzo
Costo
Los estándares de ingeniería del software del IEEE proporcionan el conjunto de requerimientos y guías más importantes para el aseguramiento de la calidad del software. Este conjunto de estándares abarcan todos los aspectos técnicos relacionados con la Ingeniería de Software. Estos estándares buscan el Aseguramiento de la Calidad del Software (SQA) OBJETIVO DEL LOS ESTANDARES DE LA IEEE
2. CLASIFICACIÓN DE LOS ESTANDARES Existen 22 estándares que están orientados al aseguramiento de la calidad de software
15 estándares del proceso
5 estándares del producto
1 glosario de términos
1 taxonomía (clasificación)
2.1ESTANDARES DEL PRODUCTO 2.1.1. ESTANDAR IEEE 830 -
“REQUERIMIENTOS DE SOFTWARE”
El estándar IEEE 830 establece las normas y condiciones para producir un buen documento de especificación de Requerimientos (SRS: Software Requirements Specification). Contiene ocho plantillas diferentes para definir los requerimientos según la naturaleza del sistema, las cuales contemplan: organizar el sistema por modo, por clase de usuario, por objetos, por rasgos, por estímulos o por jerarquía funcional, existe también la posibilidad de tener organizaciones múltiples.
2.1.2. ESTANDAR IEEE 1016 “DESCRIPCIÓN DEL DISEÑO DEL SOFTWARE ”
2.1.3. ESTANDAR IEEE 990 “PRÁCTICAS PARA EL USO”
2.1.4. ESTANDAR IEEE 1063 “DOCUMENTACIÓN DE USUARIO”
2.2 ESTÁNDARES DEL PROCESO 2.2.1. ESTANDARES DEL PROCESO DE CALIDAD 2.2.1.1. ESTANDAR 730: “PLANES DE CALIDAD DE SOFTWARE ”
El estándar IEEE 730 es una recomendación para elaborar un Plan de Aseguramiento de la Calidad del Software SQAP (Software Quality Assurance Plan) para proyectos de desarrollo de software. Cuando en un proyecto de desarrollo de software se incluye un plan de estos, las decisiones relacionadas con la calidad deben ser tomadas con anticipación y por lo tanto, deben ser estudiadas y razonadas suficientemente antes de iniciar el desarrollo. El equipo de desarrollo deberá entonces ajustarse al plan y así mejorar continuamente los procesos de desarrollo en beneficio del proyecto en curso y de los proyectos futuros.
2.2.1.2. ESTANDAR IEEE 1298 “SISTEMAS DE SQA: REQUERIMIENTOS”
2.2.1.3. ESTANDARIEEE 1074 “DESARROLLO DE CICLOS DE VIDA”
2.2.1.4. ESTANDAR IEEE 1058.1 “PLANES PARA ADMINISTRACIÓN DE PROYECTOS”
2.2.1.5. ESTANDAR IEEE 1012 “VERIFICACIÓN Y VALIDACIÓN ”
2.2.1.6. ESTANDAR IEEE 1028 “REVISIONES Y AUDITORÍAS”
2.2.2.PRUEBAS Y MANTENIMIENTOS 2.2.2.1. ESTANDAR IEEE 1219 “MANTENIMIENTO DEL SOFTWARE”
2.2.2.2. ESTANDAR IEEE 828 “PLANES DE CONFIGURACIÓN DEL SOFTWARE ”
2.2.2.3. ESTANDAR IEEE 1042 “GUÍA PARA CONFIGURACIÓN DEL SOFTWARE”
2.2.2.4. ESTANDAR IEEE 1008 “PRUEBAS DE UNIDAD DEL SOFTWARE”
2.2.2.5. ESTANDAR IEEE 829 DOCUMENTACIÓN DE PRUEBAS El estándar IEEE 829 establece una recomendación de la documentación que debe generarse antes y durante el proceso de pruebas del sistema. Los documentos son: plan de pruebas, diseño de prueba, caso de prueba, procedimiento de prueba, reporte de transmisión de modulo, bitácora de pruebas, reporte de incidente de prueba, resumen de pruebas. 2.3. OTROS 2.3.1.
ESTANDAR IEEE 1002 TAXONOMÍA DE ESTÁNDARES
“
”
2.3.2. ESTANDAR IEEE 610 “GLOSARIO ESTÁNDAR DE TÉRMINOS ”
2.3.3. ESTANDAR IEEE 1209 “EVALUACIÓN DE HERRAMIENTAS CASE ”
3. PLAN DE ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE La planificación de la calidad es el proceso en el cual se desarrolla un plan de calidad para un proyecto determinado. El plan de calidad define la calidad del software deseado y describe cómo valorarlo. Por lo tanto, define lo que es software de
“alta
calidad” El plan de calidad selecciona los estándares organizacionales apropiados para un producto y un proceso de desarrollo particular. Si en el proyecto se utilizan nuevos métodos herramientas, se tiene que definir nuevos estándares. El Estándar IEEE 730 es una recomendación para elaborar un Plan de Aseguramiento de la Calidad del Software (SQAP, Software 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. El plan SQActo sirve para guía de las actividades de SQA en el proyecto.
Este estándar describe la preparación y los contenidos de los planes SQA. Las actividades principales del SQA incluyen la gestión, documentación, mediciones, revisions, tsting, informes de problemas y las acciones correctivas, control de medios de comunicación, control de piezas relacionadas con el plan de SQA, el Estándar IEEE 730 nos proporciona una valiosa información sobre cada de estas actividades. En la claúsula 4, se describe el contenido mínimo de un plan de SQA. Dentro de las descripciones se identifican los elementos fundamentales del proceso de SQA. En un plan de SQA se puede aplicar o citar requisitos y directrices establecidas en otros estándares de la IEEE. Cuando en un proyecto se aplica (o puede afectar) a tres grupos, el proveedor y el público. 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. PLAN SQA Un Plan SQA puede incluir los siguientes puntos: 1.Propósito: - Delinea el propósito específico y el alcance del plan SQA. - Lista los nombres de los elementos software cubiertos por el plan SQA y el uso de dichos elementos. - Determina la porción del ciclo de vida cubierta por el plan para cada elemento software. 2.Documentos de referencia -
Proporciona una lista completa de los documentos referenciados en el plan o utilizados en su elaboración.
3.Gestión - Está muy ligado el plan del proyecto del software.
- Idealmente redactado en formato IEEE Std. 1058
3.1. Organización - Describe la estructura organizativa que influye y controla la calidad de software. - Identifica roles y 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 estas tareas y los principales puntos de control planeados. 3.3. Roles y responsabilidades - Identifica los elementos organizativos responsables de llevar a cabo cada tarea. 3.4. Recursos estimados de garantía de calidad - Proporciona la estimación de recursos y costos 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, asi como los criterios de revisión.
4.2. Requisitos mínimos de documentación
Para asegurar 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 del 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 de software
4.2.1.Descripción de los requisitos software
Es la SRS (software requirements specification).
Idealmente redactada según IEEE. Std 830
4.2.2.Descripción del diseño del software.
Describe la estructura del software para cumplir con los requisitos de la SRS.
Debe describir los componentes y subcomponentes del diseño del software.
Redactado según IEEE Std. 1016, IEEE Recommended practice for software design Descriptions.
4.2.3. Planes de validación y verificación.
Estos planes se utiliza para determinar si el producto software desarrollado se ajusta a sus requisitos, y si cumple con las expectativas del usuario.
Idealmente redactado según los estándares: -
IEEE Std.829-1998 for software Test Documentation.
-
IEEE Std. 1008- 1997 IEEE for software Unit Testing.
-
IEEE Std. 1012-1998 for software validation and verification.
4.2.4.Informe de resultados de verificación e informe de resultados de validación.
Describe los resultados de las actividades de verificación y planificación del software llevados a cabo según los planes descritos en el punto anterior.
4.2.5.Documentación de usuario.
La documentación del usuario 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, asi como los
mensajes de error. Idealmente redactado según IEEE Std. 1063-1987 for
software User documentation.
4.2.6.Plan de gestión de la configuración de software.
Describe el proceso de gestión de configuración software.
Idealmente redactado según IEEE Std. 828-1998 for software configuration Management Plans.
4.3. Otra documentación
Identificar otros documentos necesarios durante el proceso de desarrollo, como:
Plan de proceso de desarrollo.
Descripción de estándares de desarrollo de software.
Descripción de métodos/ procedimientos/ herramientas de IS. Plan de gestión del proyecto de software (idealmente según
IEEE Std.1058). Plan de mantenimiento (idealmente según IEEE Std. 1219-
1998). Planes de seguridad del software (idealmente según IEEE
Std. 1228-1994). Plan de integración del software.
5.estándares, prácticas, convenvenciones y métricas
Esta sección es un poco miscelánea en SQA. 5.1. Propósito
Identifica:
Estándares
Practicas
Convenciones
Técnicas estadísticas
Métricas aplicables al proyecto
Las medidas se incluyeran en las métricas utilizadas y podrían
identificarse en un plan de medición independiente (idelamente redactados esgun IEEE Std. 1219-1998 for software Maintenance e IEEE Srd. 1228-1994 for software Safety Plans). También determina como se monitoriza y garantiza la conformidad
con el plan 5.2. contenido
Como mínimo debe incluir
Estándares de documentación
Estándares de diseño
Estándares de codificación
Estándares de comentarios
Prácticas y estándares de prueba
Métricas de producto y proceso de garantía de calidad seleccionada.
6. revisiones del software
Determinan las revisiones del software
6.1. propósito
Fija las revisiones del software
Idealmente redactado según IEEE Std. 1028.
6.2. requisitos mínimos
Revisión de las especificaciones software.
Revisión del diseño arquitectónicos
Revisión del diseño detallado
Revisión del plan de verificación y validación
Auditoria de la funcionalidad (cumplir SRS)
Auditoria física(consistencia y fecha de entrega)
Auditoria durante el proceso (consistencia del diseño)
Revisiones de gestión (garantizar el cumplimiento plan SQA)
Revisión del plan de gestión de la configuración del software
Revisión Post-implementación.
6.3. otras revisiones y auditorias
Por ejemplo, revisión de la documentación de usuario
7. prueba
Identifica todas las pruebas no incluidas en el plan de verificación y validación
8. informe de problemas de acción correctivas
Describe las prácticas y procedimientos de informe, seguimiento y r4esolucion de problemas, tanto a nivel productivo como proceso
Determina las responsabilidades organizativas relativas a su implementación
9. herramientas, técnicas y metodologías
Herramientas, técnicas y metodologías utilizadas para soportar el proceso de SQA 9.1.
control de medios
Determina los métodos para: o
Identificar el medio fisco de cada producto software.
o
Protegerlo de danos durante el proceso
10. control de procesos - determina las técnicas para garantizar que el software proporcionado por proveedores externos cumple sus requisitos. - también es aplicable a código heredado. 11. colección de registros, mantenimiento y conservación. - identifica la documentación SQA que no debe tirara tras acabar el proceso. - determina los métodos y medios para ensamblar, archivar, proteger y mantener la documentación. 12. Formación - identifica las actividades de formación necesarias para satisfacer las necesidades del plan SQA.
13. gestión del riesgo - Especifica el plan de gestión del riesgo. - idealmente redactado según IEEE Std. 1540-2001 for Software Life Cycle Processes – Risk Management 14. Glosario - Términos específicos del plan SQA. 15. Procedimiento de cambio e historia del plan SQA - Procedimientos de modificación del plan SQA. - Procedimientos de mantenimiento del historial de cambios. - Historial de cambios. 4.
APLICACIONES 3.1. AUDITORIAS Y REVISIONES ESTANDAR IEEE 1028-1988 para Revisiones y Auditorías del Software
Define procedimientos para definir y llevar a cabo procesos de revisión y auditoría del software.
Describe cinco tipos de revisiones y auditorías que se pueden utilizar.
Incluye tanto al producto como al proceso de software.
No prescribe el uso de revisiones ni auditorías particulares.
3.1.1. Auditoría
Evaluación independiente (objetiva) de un producto o proceso de software.
Mide el cumplimiento de estándares, guías, especificaciones, y procedimientos.
Utiliza criterios objetivos de medida debidamente documentados. – Formato y contenido del producto. – Descripción del proceso para producirlo. – Cómo chequear el cumplimiento.
3.1.2. Revisión
Evalúa un producto o proceso de software.
Determina status actual contra el plan original.
Reporta resultados y recomendaciones.
Sigue un proceso formal.
Cuatro tipos de revisiones: – Revisión de administración – Revisión técnica – Inspección – Caminata
TIPOS DE REVISIONES Revisión REVISIONS
TIPO DE SEMI – FORMAL
ELEMENTO
USUARIO
PROYECTO
ADMINISTRACION
PROYECTO
EQUIPO
ADMINISTRACION REVISIONES
SEMI – FORMAL
TECNICAS INSPECCIONES
CAMINATAS
DE
DESARROLLO FORMAL
INFORMAL
PRODUCTO
O EQUIPO
PROCESO
DESARROLLO
PRODUCTO
EQUIPO DESARROLLO
DE
DE
•
•
•
CONCLUSIÓN Como estudiantes de ingeniería de sistemas y futuros ingenieros es esencial saber de estos estándares de calidad de software porque en el futuro nos va hacer de muy útil en nuestro de desempeño profesional La organización que los adoptan lo hace para mejorar sus productos o mejora la percepción de sus productos en el mercado. Los estándares pueden mejorar los procesos de negocios permitiendo desarrollar sus productos con costos más apropiados.
