A
INDICE de Metodología Metodolo gía IEEE IEEE 730
1.
INDICE de Metodología IEEE 730
Tabla de contenido INTRODUCCIÓN.......................................................................................................4 1. INTRODUCCIÓN.................................................................................................4 2. PROPOSITO, OBJETIVOS Y ALCANCE.....................................................................4 3. R EFERENCIAS...................................................................................................4 4. GESTIÓN........................................................................................................5 1. Organización.............................................................................................5 2. Tareas......................................................................................................5 3. Responsabilidades......................................................................................6 5. DOCUMENTACIÓN...............................................................................................6 1.1. Parte Legal.............................................................................................7 1.2. Especificación De Requisitos De Software (ERS)(IEEE 830)..........................7 a) Introducción..............................................................................................7 b) Propósito de ERS.......................................................................................7 c) Ámbito del Sistema....................................................................................7 d) Definiciones, Acrónimos y Abreviaturas.........................................................7 e) Referencias...............................................................................................7 f) Visión General del documento....................................................................8 g) Descripción General...................................................................................8 h) Perspectiva del Producto.............................................................................8 i) Funciones del Producto...............................................................................8 j) Características de los usuarios.....................................................................8 k) Condicionantes y Restricciones....................................................................9 l) Suposiciones y Dependencias.....................................................................9 m) Requisitos Futuros..................................................................................9 n) Requerimientos.........................................................................................9 o) Interfaces Externas..................................................................................10 p) Funciones................................................................................................10 q) Requisitos de Rendimiento........................................................................11 r) Restricciones de Diseño............................................................................11 s) Atributos del Sistema...............................................................................12 t) Otros Requisitos.......................................................................................12 6. ESTIMACIÓN DEL PROYECTO.................................................................................12 7. ESTÁNDARES, PRÁCTICAS Y CONVENCIONES (COMUNICACIÓN)...........................................12 Revisiones (calidad)....................................................................................12 Propósito.....................................................................................................12 Requerimientos Mínimos............................................................................12 Agenda.......................................................................................................13 Revisar cada producto................................................................................13 2
INDICE de Metodología IEEE 730 Revisar el apego al proceso........................................................................13 Realizar Revisión Técnica Formal...............................................................13
8. TESTEO (PRUEBAS).........................................................................................14 9. INFORMACIÓN SOBRE PROBLEMAS Y ACCIÓN CORRECTIVA (CORRECCIONES)............................14 10. HERRAMIENTAS, TÉCNICAS Y METODOLOGÍAS...........................................................14 11. CONTROL DE CÓDIGO.....................................................................................14 12. CONTROL DE MEDIOS.....................................................................................14 13. R ECOPILACIÓN DE REGISTROS, MANTENIMIENTO Y RETENCIÓN........................................14 14. GESTIÓN DE R IESGOS....................................................................................15 15. CAPACITACIÓN............................................................................................15 16. CONCLUSIONES............................................................................................15 17. R EFERENCIAS DE ESTA GUÍA.............................................................................15
Referencias de esta Guía
3
INDICE de Metodología IEEE 730 Introducción Definición, Origen (Un poco de Historia), para que sirve, ventajas, desventajas, cuando se la puede usar, casos específicos, además en cuánto a: )(IEEE 730-1) En este documento se brinda una guía sobre el contenido de las secciones que determina el IEEE Std. 730-1 para el Plan de Gestión de Calidad. En cada seccion se indica entre <> una descripcion de lo que establece el IEEE Std. 828 ,830(REQUISITOS) 1.
Introducción En este documento se brinda una guía sobre el contenido de las secciones que determina el IEEE Std. 730-1(1995) para el Plan de Gestión de Calidad. Se debe proveer una introducción al contenido del plan de SQA para utilización tanto por el resto de los integrantes del grupo como por el Director del Proyecto. Aquí se habla del proyeto
2.
PROPOSITO, objetivos y alcance (PROPOSITO DEL PROYETCTO Y DE LA NORMA IEEE 730)
3. Referencias IEEE Std 730-1998 IEEE Std 828-1998 IEEE Std 830-1998
Incluye la lista de documentos que son referenciados en este estándar. IEEE 730-1 Y TAMBIEN 830
4
INDICE de Metodología IEEE 730 4. Gestión
El tema de esta sección es relacionar los elementos de la Gestión de Calidad con las actividades específicas del proyecto, especificando organización, tareas y responsabilidades. 1. Organización Se describe la ubicación del área de calidad en la estructura de la organización, incluyendo dependencias o independencias del Responsable de Calidad respecto a los responsables del desarrollo y uso del software. Para este curso existe además un área de calidad anexa a los proyectos en la cual participan los Responsables de Calidad de cada grupo de proyecto conjuntamente con docentes del curso. 2. Tareas
Se describen las tareas de SQA que serán realizadas en el proyecto y la documentación que produce cada una, y sus relaciones con los puntos clave definidos en el proceso de desarrollo, así como otras tareas que estén relacionadas con la calidad de los productos. Para este curso las actividades de SQA definidas en el modelo de proceso son: Actividad
Entregable Asociado
Elaboración del Plan de SQA
Plan de SQA
Identificar propiedades de Plan de SQA Calidad Evaluación de la calidad de los Informe de revisión de SQA productos
Revisar el ajuste al proceso Informe de revisión de SQA Realizar Revisión Técnica Informe de Formal Técnica Formal
Revisión
Evaluar y ajustar el Plan de Documento de Evaluación y SQA Ajustes al Plan de SQA Evaluación final de SQA
Informe final de SQA
Revisar la entrega semanal
Entrega semanal de SQA
5
INDICE de Metodología IEEE 730 Se deben identificar las actividades del proceso que son previas a las actividades de SQA, indicando la secuencia de las mismas y los puntos clave en el proceso en los que serán realizadas estas actividades. Por ejemplo, al marcar las revisiones para la Fase de Elaboración Iteración I (correspondiente a semanas 5 y 6), la revisión del documento Descripción de la Arquitectura se debe indicar en semana 5 o en semana 6 y se debe realizar sobre la versión entregada en semana 4, que corresponde a la Fase Inicial. Como al mismo tiempo se sigue trabajando sobre ese documento, la siguiente versión deberá incluir también las observaciones realizadas por el Responsable de SQA en la revisión. 3. Responsabilidades Se identifican las responsabilidades asignadas para cada actividad en el proyecto Se deben identificar los roles y personas de referencia por cada producto que será revisado de forma de enviarle los Informes de SQA para que se incluyan en las nuevas versiones las observaciones realizadas a los productos por parte del Responsable de SQA.
1. Documentación se debe identificar la documentación que asegura que la implementación del software satisface los requerimientos planteados, la cual está compuesta según el std. 730-1 como mínimo por la siguiente: se utilizara la 830 ➢ Especificación de Requerimientos (SRS) ➢ Descripción del Diseño (Arquitectura) ➢ Plan de Verificación y Validación (SVVP) ➢ Reportes de Verificación ➢ Documentación de Usuario ➢ Plan de Gestión de Configuración (SCMP) ➢ Plan del Proyecto ➢ Estimación del proyecto ➢ Costos Agregando toda la que se considere que aporta a la calidad del proyecto.
6
INDICE de Metodología IEEE 730 Para cada documento debe indicarse cual es su objetivo, que norma debe seguir y que información mínima debe contener para cumplir con las definiciones del documento. 1.1.Parte Legal 1.2.Especificación De Requisitos De Software (ERS)(IEEE 830)
a) Introducción En esta sección se proporcionara una introducción a todo el documento de Especificación de Requisitos Software (ERS). Consta de varias sub secciones: Propósito, ámbito del sistema, denticiones, referencias y visión general del documento.
b) Propósito de ERS Mediante este documento pretendemos establecer el SRS aplicando en la medida de lo posible la norma IEEE 830. El proyecto sobre el cual se va aplicar la norma será el proyecto sistema de evaluación de calidad.
c) Ámbito del Sistema En esta sub sección: Se podrá dar un nombre al futuro sistema (p.ej. Mi Sistema) Se explicara lo que el sistema haría y lo que no haría. Se describirán los beneficios, objetivos y metas que se espera alcanzar con el futuro sistema. Se referenciaran todos aquellos documentos de nivel superior
d) Definiciones, Acrónimos y Abreviaturas En esta sub sección se definirán todos los términos, acrónimos y abreviaturas Utilizadas en la ERS.
e) Referencias Norma IEEE 830.
f) Visión General del documento Esta su sección describe brevemente los contenidos y la organización del Resto de la ERS.
7
INDICE de Metodología IEEE 730 g) Descripción General En esta sección se describen todos aquellos factores que afectan al producto y a sus requisitos. No se describen los requisitos, sino su contexto. Esto permitiría definir con detalle los requisitos en la sección 3, haciendo que sean mas faciles de entender. Normalmente, esta sección consta de las siguientes sub secciones: Perspectiva del producto, funciones del producto, características de los usuarios, Restricciones, factores que se asumen y futuros requisitos.
h) Perspectiva del Producto Esta su sección debe relacionar el futuro sistema (producto software) con otros productos. Si el producto es totalmente independiente de otros productos, también debe especificarse aquí. Si la ERS define un producto que es parte de un sistema mayor, esta su sección relacionaría los requisitos del sistema mayor con la funcionalidad del producto descrito en la ERS, y se identificaran las interfaces entre el producto mayor y el producto aquí descrito. Se recomienda utilizar diagramas de bloques .
i) Funciones del Producto En esta sub sección de la ERS se mostrara un resumen, a grandes rasgos, de las funciones del futuro sistema. Por ejemplo, en una ERS para un programa de contabilidad, esta su sección mostraría que el sistema soportaría el mantenimiento de cuentas, mostraría el estado de las cuentas y facilitaría la facturación, sin mencionar el enorme detalle que cada una de estas funciones requiere. Las funciones deberían mostrarse de forma organizada, y pueden utilizarse gráficos, siempre y cuando dichos gráficos reflejen las relaciones entre funciones y no el diseño del sistema.
j) Características de los usuarios
Esta su sección describiría las características generales de los usuarios del producto, incluyendo nivel educacional, experiencia y experiencia técnica.
k) Condicionantes y Restricciones Esta su sección describirá aquellas limitaciones que se imponen sobre los Desarrolladores del producto 8
INDICE de Metodología IEEE 730 Políticas de la empresa Limitaciones del hardware Interfaces con otras aplicaciones Operaciones paralelas Funciones de auditoria Funciones de control Lenguaje(s) de programación Protocolos de comunicación Requisitos de habilidad Criticalidad de la aplicacion Consideraciones acerca de la seguridad
l) Suposiciones y Dependencias Esta su sección de la ERS describiría aquellos factores que, si cambian, pueden afectar a los requisitos. Por ejemplo, los requisitos pueden presuponer una cierta organización de ciertas unidades de la empresa, o pueden presuponer que el sistema correria sobre cierto sistema operativo. Si cambian dichos detalles en la organización de la empresa, o si cambian ciertos detalles técnicos, como el sistema operativo, puede ser necesario revisar y cambiar los requisitos.
m)Requisitos Futuros Esta su sección esbozara futuras mejoras al sistema, que podrán analizarse e implementarse en un futuro.
n) Requerimientos Esta sección contiene los requisitos a un nivel de detalle suficiente como para permitir a los diseñadores, diseñar un sistema que satisfaga estos requisitos, y que permita al equipo de pruebas planificar y realizar las pruebas que demuestren si el sistema satisface, o no, los requisitos. Todo requisito aquí especificado describiría comportamientos externos del sistema, perceptibles por parte de los usuarios, operadores y otros sistemas. Esta es la sección más larga e importante de la ERS. Deberían aplicarse los siguientes principios: •
•
El documento debería ser perfectamente legible por personas de muy distintas formaciones e intereses. Deberían referenciarse aquellos documentos relevantes que poseen alguna influencia sobre los requisitos. 9
INDICE de Metodología IEEE 730 •
•
Todo requisito debería ser unívocamente identificable mediante algún código o sistema de numeración adecuado. Lo ideal, aunque en la práctica no siempre realizable, es que los requisitos posean las siguientes características:
a) Interfaces Externas Se describirían los requisitos que afecten a la interfaz de usuario, interfaz con otros sistemas (hardware y software) e interfaces de comunicaciones.
b) Funciones Esta su sección (quizá la más larga del documento) debería especificar todas aquellas acciones (funciones) que debería llevar a cabo el software. Normalmente (aunque no siempre), son aquellas acciones expresables como \el sistema debería. . . ". Si se considera necesario, podrían utilizarse notaciones graficas y tablas, pero siempre supeditadas al lenguaje natural, y no al revesa. Es importante tener en cuenta que, en 1983, el Estándar de IEEE 830 establecía que las funciones deberían expresarse como una jerarquía funcional (en paralelo con los DFDs propuestos por el análisis estructurado). Pero el Estándar de IEEE 830, en sus _últimas versiones, ya permite organizar esta sub sección de múltiples formas, y sugiere, entre otras, las siguientes: Por tipos de usuario: Distintos usuarios poseen distintos requisitos. Para cada clase de usuario que exista en la organización, se especificarían los requisitos funcionales que le afecten o tengan mayor relación con sus tareas. Por objetos: Los objetos son entidades del mundo real que serian reejadas en el sistema. Para cada objeto, se detallarían sus atributos y sus funciones. Los objetos pueden agruparse en clases. Esta organización de la ERS no quiere decir que el diseño del sistema siga el paradigma de Orientación a Objetos. Por objetivos: Un objetivo es un servicio que se desea que ofrezca el sistema y que requiere una determinada entrada para obtener su resultado. Para cada objetivo o sub objetivo que se persiga con el sistema, se detallarían las funciones que permitan llevarlo a cabo. Por estímulos: Se especificarían los posibles estímulos que recibe el sistema y las funciones relacionadas con dicho estimulo. 10
INDICE de Metodología IEEE 730 Por jerarquía funcional: Si ninguna de las anteriores alternativas resulta de ayuda, la funcionalidad del sistema se especificaría como una jerarquía de funciones que comparten entradas, salidas o datos internos. Se detallarían las funciones (entrada, proceso, salida) y las sub funciones del sistema. Esto no implica que el diseño del sistema deba realizarse Según el paradigma de Diseño Estructurado. Para organizar esta sub sección de la ERS se elegiría alguna de las anteriores Alternativas, o incluso alguna otra que se considere más conveniente. Debería, esos justificarse el porqué de tal elección.
c) Requisitos de Rendimiento Se detallarían los requisitos relacionados con la carga que se espera tenga que soportar el sistema. Por ejemplo, el número de terminales, el número Esperado de usuarios simultáneamente conectados, numero de transacciones Por segundo que deberla soportar el sistema, etc. También, si es necesario, se especificarían lo requisitos de datos, es decir, Aquellos requisitos que afecten a la información que se guardaría en la base de datos. Por ejemplo, la frecuencia de uso, las capacidades de acceso y la cantidad de registros que se espera almacenar (decenas, cientos, miles o millones).
d) Restricciones de Diseño Todo aquello que restrinja las decisiones relativas al diseño de la aplicación con: Restricciones de otros estándares, limitaciones del hardware, etc.
e) Atributos del Sistema Se detallarían los atributos de calidad (las \ilities") del sistema: Fiabilidad, mantenibilidad, portabilidad, y, muy importante, la seguridad. Debería especiarse que tipos de usuario están autorizados, o no, a realizar ciertas tareas, y 11
INDICE de Metodología IEEE 730 como se implementarían los mecanismos de seguridad (por ejemplo, por medio de un login y una password). f) Otros Requisitos
Cualquier otro requisito que no encaje en otra sección.(hasta aqui) 1.
Estimación del proyecto
2.
Estándares, prácticas y convenciones (comunicación) Se identifican los estándares definidos para el proyecto, como normas de documentación, de codificación, notación UML, comunicación, normas IEEE que aplican, etc. y de qué forma se asegurará el cumplimiento de los mismos. También el Modelo de Calidad que se aplica al proyecto.
Revisiones (calidad)
Se describen las revisiones que serán realizadas, especificando cómo y cuando se realizarán, que acciones se tomarán a partir de los resultados obtenidos y como serán implementadas estas acciones. Propósito
Se describe el objetivo de cada uno de los tipos de revisiones que serán realizadas y cuál será el mecanismo a seguir al hacerlas. Las revisiones previstas son de 3 tipos: revisión de productos, revisión de proceso y Revisión Técnica Formal. Requerimientos Mínimos
Las revisiones deben cubrir las mínimas definidas en el std. 730-1: del Documento de Requerimientos, del Diseño (Arquitectura), del Plan de Verificación y Validación, de Gestión del Proyecto, de Gestión de Configuración, y las especificadas en la sección 3.6.2.7– In Process Audits sobre: diseño vs. Código, especificación de interfaces (hardware y software), diseño vs. Requerimientos, testeo vs. Requerimientos.
12
INDICE de Metodología IEEE 730 Agenda
Para cada revisión definida en la sección anterior sobre cada producto identificado se detalla en qué momento del proyecto se realizará con indicación de Fase, iteración y semana. Revisar cada producto
Se indica en qué fase, iteración y semana se realizará la revisión de cada producto identificado. Por ejemplo: Revisión del Plan de Verificación (SVVP): Fase Inicial, Iteración II, semanas 3 y 4: se revisa la primera versión del SVVP producida en la Iteración I. Fase de Elaboración, Iteración I, semanas 5 y 6: se revisa la versión final del SVVP generada en la Fase Inicial, Iteración II. Revisar el apego al proceso
Se indica en qué fase, iteración y semana se realizará la revisión de apego al proceso de cada producto clave identificado. Realizar Revisión Técnica Formal
Se indica en qué fase, iteración y semana se realizará la Revisión Técnica Formal de cada producto clave identificado, indicando su objetivo, roles involucrados y productos a revisar.
se consideran de importancia las revisiones de los siguientes productos: Fase de elaboración: Documento de Requerimientos, Descripción de la Arquitectura, Estimaciones y mediciones del Proyecto, Reportes de verificación de documentos. Fase de construcción: Reportes de revisión por pares, Inspecciones de código, Reportes de pruebas.
3.
Testeo (Pruebas)
Se deben detallar, si existieran, las pruebas que se realizarán sobre el software cubierto por el SQAP y que no están incluidas en el Plan de Verificación y Validación (SVVP), por ejemplo de propiedades de calidad identificadas que así lo requieran >
13
INDICE de Metodología IEEE 730 4.
Información sobre problemas y acción correctiva (Correcciones) Se describen las prácticas y procedimientos que serán seguidos para informar de los problemas detectados, hacer el seguimiento y resolverlos. Esto se aplica tanto a desviaciones encontradas en los productos generados como en el proceso seguido. También deben especificarse las responsabilidades en la implementación de estos mecanismos.
5. Herramientas, técnicas y metodologías
Se indican las herramientas especiales de software, técnicas y metodologías que apoyarán la gestión del Responsable de SQA.
6. Control de código
Se indican los métodos que se utilizarán para mantener, almacenar, asegurar y documentar las versiones controladas identificadas en las fases de desarrollo, lo cual será definido en conjunto con el Responsable de SCM Para este curso se utilizará CVS como se indica en el SCMP, por lo que se podrá incluir la información o referenciar ese documento.
7. Control de medios
Se indican los métodos que se utilizarán para proteger el almacenamiento adecuado de los programas, documentación, etc., así como también la prevención de acceso sin autorización, daño, etc., lo cual será definido en conjunto con el Responsable de SCM. Se utilizará CVS como se indica en el SCMP, por lo que se podrá incluir la información o referenciar ese documento.
8. Recopilación de registros, mantenimiento y retención
Se describen los tipos de registros que serán generados, mantenidos y almacenados por el Responsable de SQA y el objetivo de los mismos, adjuntando el formato que tendrán dichos documentos. Para este curso los registros que generan las actividades de SQA están indicados por los entregables asociados: Entrega semanal de SQA, Informe de revisión de SQA, Informe de Revisión Técnica Formal, Documento de Evaluación y Ajustes del Plan de SQA.
14
INDICE de Metodología IEEE 730 9. Gestión de Riesgos
Se indican los métodos y procedimientos que serán utilizados para identificar, monitorear y controlar los riesgos identificados en el proyecto En este curso la gestión de riesgos está incluida como actividad en el área de Gestión del Proyecto y como sección en el Plan del Proyecto, por lo que se podrá incluir la información o referenciar ese documento.
10.Capacitación Capacitar usuario (desarrollo de software para los miembros de la empresa), indicar que cosa Debe saber, jerarquía de los puestos para indicarle que es lo que deben aprender
11.Conclusiones 12.Referencias
de esta Guía
IEEE Std. 730-1 – 1989 Standard for Software Quality Assurance Plans Documento de Actividades de Gestión de Calidad – Taller V – A. Delgado & B. Pérez 2000.
15
