Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Plantilla 730 y 830
Plantilla 730 y 830
Tabla de contenido
INTRODUCCIN ................................................................................................... 4 1. 2. 3. 4. 1. 2. 3. 5. 1.1. 1.2. a) b) c) d) e) f) g) h) i) j) k) l) m) n) o) p) q) r) s) t) 6. 7. INTRODUCCIN ............................................................................................. 4 PROPOSITO, OBJETIVOS Y ALCANCE ................................................................ 4 REFERENCIAS ................................................................................................ 4 GESTIN ...................................................................................................... 5 Organizacin ............................................................................................. 5 Tareas ..................................................................................................... 5 Responsabilidades ..................................................................................... 6 DOCUMENTACIN ........................................................................................... 6 Parte Legal ............................................................................................ 7 Especificacin De Requisitos De Software (ERS)(IEEE 830) .......................... 7 Introduccin ............................................................................................. 7 Propsito de ERS ....................................................................................... 7 mbito del Sistema.................................................................................... 7 Definiciones, Acrnimos y Abreviaturas ........................................................ 7 Referencias............................................................................................... 7 Visin General del documento .................................................................... 8 Descripcin General ................................................................................... 8 Perspectiva del Producto ............................................................................ 8 Funciones del Producto .............................................................................. 8 Caractersticas de los usuarios .................................................................... 8 Condicionantes y Restricciones .................................................................... 9 Suposiciones y Dependencias ..................................................................... 9 Requisitos Futuros .................................................................................. 9 Requerimientos ......................................................................................... 9 Interfaces Externas ................................................................................. 10 Funciones ............................................................................................... 10 Requisitos de Rendimiento ........................................................................ 11 Restricciones de Diseo ............................................................................ 11 Atributos del Sistema ............................................................................... 12 Otros Requisitos ...................................................................................... 12
Revisiones (calidad) ................................................................................................................... 12 Propsito ................................................................................................................................... 12 Requerimientos Mnimos .......................................................................................................... 12 Agenda ...................................................................................................................................... 13 Revisar cada producto ............................................................................................................... 13 Revisar el apego al proceso ....................................................................................................... 13 Realizar Revisin Tcnica Formal .............................................................................................. 13
3. Referencias
Identificar propiedades de Plan de SQA Calidad Evaluacin de la calidad de los Informe de revisin de SQA productos
Revisar el ajuste al proceso Informe de revisin de SQA Realizar Formal Revisin Tcnica Informe de Tcnica Formal Revisin
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 sern realizadas estas actividades. Por ejemplo, al marcar las revisiones para la Fase de Elaboracin Iteracin I (correspondiente a semanas 5 y 6), la revisin del documento Descripcin de la Arquitectura se debe indicar en semana 5 o en semana 6 y se debe realizar sobre la versin entregada en semana 4, que corresponde a la Fase Inicial. Como al mismo tiempo se sigue trabajando sobre ese documento, la siguiente versin deber incluir tambin las observaciones realizadas por el Responsable de SQA en la revisin. 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. 5. Documentacin se debe identificar la documentacin que asegura que la implementacin del software satisface los requerimientos planteados, la cual est compuesta segn el std. 730-1 como mnimo por la siguiente: Especificacin de Requerimientos (SRS) se utilizara la 830 Descripcin del Diseo (Arquitectura) Plan de Verificacin y Validacin (SVVP) Reportes de Verificacin Documentacin de Usuario Plan de Gestin de Configuracin (SCMP) Plan del Proyecto Estimacin del proyecto Costos
a) Introduccin
En esta seccin se proporcionara una introduccin a todo el documento de Especificacin de Requisitos Software (ERS). Consta de varias sub secciones: Propsito, mbito del sistema, denticiones, referencias y visin general del documento. b) Propsito 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 evaluacin de calidad. c) mbito del Sistema En esta sub seccin: Se podr dar un nombre al futuro sistema (p.ej. Mi Sistema) Se explicara lo que el sistema hara y lo que no hara. Se describirn los beneficios, objetivos y metas que se espera alcanzar con el futuro sistema. Se referenciaran todos aquellos documentos de nivel superior d) Definiciones, Acrnimos y Abreviaturas
En esta sub seccin se definirn todos los trminos, acrnimos y abreviaturas Utilizadas en la ERS. e) Referencias Norma IEEE 830.
Esta su seccin debe relacionar el futuro sistema (producto software) con otros productos. Si el producto es totalmente independiente de otros productos, tambin debe especificarse aqu. Si la ERS define un producto que es parte de un sistema mayor, esta su seccin relacionara 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 seccin 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 seccin mostrara que el sistema soportara el mantenimiento de cuentas, mostrara el estado de las cuentas y facilitara la facturacin, sin mencionar el enorme detalle que cada una de estas funciones requiere. Las funciones deberan mostrarse de forma organizada, y pueden utilizarse grficos, siempre y cuando dichos grficos reflejen las relaciones entre funciones y no el diseo del sistema. j) Caractersticas de los usuarios
Esta su seccin de la ERS describira aquellos factores que, si cambian, pueden afectar a los requisitos. Por ejemplo, los requisitos pueden presuponer una cierta organizacin de ciertas unidades de la empresa, o pueden presuponer que el sistema correria sobre cierto sistema operativo. Si cambian dichos detalles en la organizacin de la empresa, o si cambian ciertos detalles tcnicos, como el sistema operativo, puede ser necesario revisar y cambiar los requisitos. m) Requisitos Futuros
Esta su seccin esbozara futuras mejoras al sistema, que podrn analizarse e implementarse en un futuro. n) Requerimientos
Esta seccin contiene los requisitos a un nivel de detalle suficiente como para permitir a los diseadores, disear 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 describira comportamientos externos del sistema, perceptibles
Todo requisito debera ser unvocamente identificable mediante algn cdigo o sistema de numeracin adecuado.
Lo ideal, aunque en la prctica no siempre realizable, es que los requisitos posean las siguientes caractersticas: o) Interfaces Externas
Se describiran los requisitos que afecten a la interfaz de usuario, interfaz con otros sistemas (hardware y software) e interfaces de comunicaciones. p) Funciones Esta su seccin (quiz la ms larga del documento) debera especificar todas aquellas acciones (funciones) que debera llevar a cabo el software. Normalmente (aunque no siempre), son aquellas acciones expresables como \el sistema debera. . . ". Si se considera necesario, podran utilizarse notaciones graficas y tablas, pero siempre supeditadas al lenguaje natural, y no al revesa. Es importante tener en cuenta que, en 1983, el Estndar de IEEE 830 estableca que las funciones deberan expresarse como una jerarqua funcional (en paralelo con los DFDs propuestos por el anlisis estructurado). Pero el Estndar de IEEE 830, en sus _ltimas versiones, ya permite organizar esta sub seccin de mltiples 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 organizacin, se especificaran los requisitos funcionales que le afecten o tengan mayor relacin con sus tareas. Por objetos: Los objetos son entidades del mundo real que serian reejadas en el sistema. Para cada objeto, se detallaran sus atributos y sus funciones. Los objetos pueden agruparse en clases. Esta organizacin de la ERS no quiere decir que el diseo del sistema siga el paradigma de Orientacin a Objetos.
10
q) Requisitos de Rendimiento
Se detallaran los requisitos relacionados con la carga que se espera tenga que soportar el sistema. Por ejemplo, el nmero de terminales, el nmero Esperado de usuarios simultneamente conectados, numero de transacciones Por segundo que deberla soportar el sistema, etc. Tambin, si es necesario, se especificaran lo requisitos de datos, es decir, Aquellos requisitos que afecten a la informacin que se guardara 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).
r) Restricciones de Diseo
Todo aquello que restrinja las decisiones relativas al diseo de la aplicacin con: Restricciones de otros estndares, limitaciones del hardware, etc.
11
Se detallaran los atributos de calidad (las \ilities") del sistema: Fiabilidad, mantenibilidad, portabilidad, y, muy importante, la seguridad. Debera especiarse que tipos de usuario estn autorizados, o no, a realizar ciertas tareas, y como se implementaran los mecanismos de seguridad (por ejemplo, por medio de un login y una password).
t) Otros Requisitos
12
se consideran de importancia las revisiones de los siguientes productos: Fase de elaboracin: Documento de Requerimientos, Descripcin de la Arquitectura, Estimaciones y mediciones del Proyecto, Reportes de verificacin de documentos. Fase de construccin: Reportes de revisin por pares, Inspecciones de cdigo, Reportes de pruebas.
13
Se describen las prcticas y procedimientos que sern 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. Tambin deben especificarse las responsabilidades en la implementacin de estos mecanismos. 10. Herramientas, tcnicas y metodologas Se indican las herramientas especiales de software, tcnicas y metodologas que apoyarn la gestin del Responsable de SQA. 11. Control de cdigo Se indican los mtodos que se utilizarn 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 informacin o referenciar ese documento. 12. Control de medios Se indican los mtodos que se utilizarn para proteger el almacenamiento adecuado de los programas, documentacin, etc., as como tambin la prevencin de acceso sin autorizacin, dao, 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 informacin o referenciar ese documento.
13.
Recopilacin retencin
de
registros,
mantenimiento
Se describen los tipos de registros que sern generados, mantenidos y almacenados por el Responsable de SQA y el objetivo de los mismos, adjuntando el formato que tendrn dichos documentos.
14
Capacitacin Capacitar usuario (desarrollo de software para los miembros de la empresa), indicar que cosa Debe saber, jerarqua de los puestos para indicarle que es lo que deben aprender
15. 16.
Conclusiones
17.
IEEE Std. 730-1 1989 Standard for Software Quality Assurance Plans
Documento de Actividades de Gestin de Calidad Taller V A. Delgado & B. Prez 2000.
15