platilla IEEE1058.docx

January 29, 2019 | Author: Kevin Jossa | Category: Software Engineering, Software, Engineering, Evaluation, Science And Technology
Share Embed Donate


Short Description

Download platilla IEEE1058.docx...

Description

PLANTILLAS DE DOCUMENTO PARA PROYECTOS ESCOLARES EN INGENIERÍA DE SOFTWARE Declan Brown y Stephen Delaney Departamento de Ciencias de la Computación, Universidad Nacional de Irlanda, Maynooth Fecha: Agosto 2002 Informe Técnico: NUIM-CS-TR2002-05

Resumen Este informe técnico describe el contenido de un conjunto mínimo de desarrollo de software documentos, adaptados para su uso por los estudiantes en proyectos de ingeniería de software, y con firmeza sobre la base de Estándares IEEE. El conjunto de documentos está diseñado para apoyar las actividades de desarrollo de software. Lo proporciona un marco para su uso en proyectos de pregrado de ingeniería de software, tanto individual y en equipo, que ayuda a los estudiantes a aprender las mejores prácticas. p rácticas. Un informe complementario describe la contenido de cada documento con más detalle.

1. Antecedentes. Los proyectos son una parte importante de la educación de los ingenieros de software. Ellos forman una método activo de enseñanza, según lo definido por Piaget, dando lugar a una formación "en la auto-disciplina y esfuerzo voluntario "[1], que es importante para los profesionales de ingeniería de software. Dos propósitos servido por estos proyectos son: la educación en la práctica profesional y los resultados basados en evaluación, como se señala en el Currículo Cur rículo ACM / IEEE Computing 2001 [2]. Una infraestructura debe proporcionar a las estudiantes están bien guiados en su aprendizaje, sin embargo, tienen una oportunidad de mostrar sus logros individuales a efectos de evaluación. Esta corresponde a los "integrational'and 'differential'modes de la educación según lo descrito por Cook en "Medición Educativa" [11]. Proyectos de ingeniería de software, tal como se define por la IEEE /  EIA, consisten en un número de actividades de desarrollo [10]. Cada actividad se caracteriza por un conjunto de productos, normalmente en forma de código o documentación. Proporcionar un modelo estructurado para la documentación de software 2ayuda tanto a la educación y los aspectos de la evaluación de d e un proyecto de ingeniería de software. Estos plantillas p lantillas proporcionan una guía para el formato esperado y el contenido de los entregables de documentación basado en las normas internacionales. También proporcionan un marco para la evaluación de la proyecto de los estudiantes,

con base en los resultados finales. Tenga en cuenta que este informe no específica criterios de evaluación: se describe la documentación de desarrollo. Además, no cubre la documentación del producto (manual, manual de referencia, manual de instalación, o interno documentación) o el informe del alumno proyecto. Según los estándares de la industria de la mayoría de los proyectos de los estudiantes que normalmente no se justifica la elaboración de un documentación completa establecida. Sin embargo, como parte del proceso educativo, es importante que los los estudiantes se les enseña a documentar su trabajo de acuerdo a las mejores prácticas. No es necesario que todos los proyectos de producción de cada documento se describe aquí, pero desde un punto de vista educativo, y teniendo en cuenta que los estudiantes se embarcará en una carrera profesional, no son distintos beneficios de cada estudiante para hacerlo. Revisión de entregas de actividad es una parte fundamental de asegurar calidad de productos de software y el estado del proyecto de seguimiento, y esto requiere una comprensión de lo documentos son necesarios [15]. Otro aspecto importante de las mejores prácticas en la documentación, incluidos en estas plantillas, es la gestión del riesgo. El conjunto de documentos mínimo, y el contenido de cada documento, se ha derivado de la IEEE completo conjunto de documentos de ingeniería de software, basada en la experiencia de los autores en desarrollo de software e ingeniería de software profesional docente. Muchos otros las universidades han elaborado directrices para la documentación final de ingeniería de software años estudiantes (por ejemplo [12] y [13]); las plantillas descritas aquí están basadas en la más reciente Estándares IEEE y los EE.UU. MILSTD-498 [14].

2. Vista general de la documentación. En la tabla siguiente se identifica el conjunto mínimo básico de software, e identifica las actividades que producirlos. Documento Entregables Descripción Actividades (IEEE / EIA 12207.2 hasta 1.997) [10] Proyectos de Software Manejo Plan (PAPS) Descripción del software enfoque y asociado hitos. Sistema de análisis de requerimientos Software análisis de necesidades Software

Requisitos Especificaciones (SRS) Descripción de la esperada características del software, limitaciones, interfaces y otros atributos. Proceso de implementación Software de diseño Descripción (SDD) Descripción de la forma de la software cumpla con la requisitos. También describe la justificación de decisiones de diseño tomadas. Sistema de diseño arquitectónico Software de diseño arquitectónico Software de diseño detallado Software de prueba Documentación (STD) Descripción del plan y especificaciones para verificar y validar el software y el resultados. Pruebas de software calificación Sistema de pruebas de calificación IEEE términos y abreviaturas que se han utilizado a lo largo, lo que proporciona la exposición a la terminología profesional de los estudiantes, y también reduce la ambigüedad. 2.1 Propósito de cada documento Documento Resumen del Propósito SPMP Para documentar los entregables acordados y fechas. SRS Para documentar los requisitos acordados con el supervisor del proyecto, para proporcionan la base para el diseño, proporcionar la base para la prueba del sistema. SDD Para documentar las decisiones de diseño y el diseño con el fin de proporcionar la base para la implementación y prueba unitaria STD

Para documentar cómo el software se pondrá a prueba y registrar los resultados. Página 3

3 3. Secciones comunes para el conjunto de documentación. Cada documento dentro del conjunto recomendado tiene algunas características comunes. El siguiente páginas se incluyen en cada documento: I. Cubierta de página (contenido y diseño) Nombre del Documento Título del proyecto Documento número de versión Fecha de impresión Ubicación de la versión electrónica de los archivos Departamento y la Universidad II. Revisiones página (contenidos) ? Resumen ? Nuestro publico ? Los miembros del equipo del proyecto ? Historia de control de versiones: Versión Autor (s) principal Descripción de la Versión Fecha de terminación Proyecto / final ? Firmas de Aprobación III. Material Adicional (contenidos) CUESTIONES ADICIONALES? DFINITIONS??, SIGLAS Y ABREVIATURAS REFERENCIAS? APÉNDICES? 4. El contenido de la documentación. Los siguientes cuatro páginas de identificar el contenido de cada documento. Una descripción detallada de los contenidos serán proporcionados en un informe técnico en el futuro. El contenido no es un rígido definición, sino una guía en cuanto a las características más relevantes de cada documento. Estos deben estar adaptado para reflejar la importancia de cada proyecto. Documentación producida durante aplicación no está cubierta; estos resultados son por lo general en forma de código ejecutable, el usuario

documentación e implementación de un diario / cuaderno de registro de la ingeniería la ejecución del trabajo del estudiante. Las especificaciones y los resultados de, las pruebas unitarias son también considerado como parte de la aplicación. Page 4

4 Proyecto de Software de Gestión Plan (PAPS) Página de tapa Revisiones de la página Tabla de contenidos 1 INTRODUCCIÓN 1,1 Descripción del proyecto 1,2 Entregables del proyecto 2 ORGANIZACIÓN DEL PROYECTO 2,1 Modelo de Procesos de Software 2,2 Roles y Responsabilidades 2,3 Herramientas y Técnicas 3 PROYECTO DE PLAN DE MANEJO 3,1 Tareas 3.1.n Tarea n 3.1.n.1 Descripción 3.1.n.2 Entregables e hitos 3.1.n.3 Recursos necesarios 3.1.n.4 Las dependencias y restricciones 3.1.n.5 Riesgos y Contingencias 3,2 Asignaciones

3,3 Calendario 4 MATERIAL ADICIONAL Normas pertinentes de la IEEE: IEEE-1058 [8], IEEE-1540 [9] Page 5

5 Requisitos Especificaciones de Software (SRS) Página de tapa Revisiones de la página Tabla de contenidos 1 INTRODUCCIÓN 1,1 Descripción del producto 2 REQUISITOS ESPECÍFICOS 2,1 Requisitos de interfaz externa 2.1.1 Interfaces de usuario 2.1.2 Interfaces de hardware 2.1.3 Interfaces de Software 2.1.4 Protocolos de comunicaciones 2,2 Características del software del producto 2,3 Atributos del sistema de software 2.3.1 Confiabilidad 2.3.2 Disponibilidad 2.3.3 Seguridad 2.3.4 Mantenibilidad 2.3.5 Portabilidad 2.3.6 Rendimiento

2,4 Requisitos de base de datos 3 MATERIAL ADICIONAL Entre las normas IEEE: IEEE-830 [4] Página 6

6 Descripción del software de diseño (SDD) Página de tapa Revisiones de la página Tabla de contenidos 1 INTRODUCCIÓN 1,1 Diseño Web Introducción 1,2 Requisitos Matriz de Trazabilidad 2 SISTEMA DE DISEÑO ARQUITECTÓNICO 2,1 Sistema elegido Arquitectura 2,2 Discusión de los diseños alternativos 2,3 Descripción del sistema de interfaz 3 DESCRIPCIÓN DETALLADA DE LOS COMPONENTES 3. N  Componente-n

4 DISEÑO DE INTERFAZ DE USUARIO 4,1 Descripción de la interfaz de usuario 4.1.1 Imágenes de pantalla 4.1.2 Objetos y Acciones 5 MATERIAL ADICIONAL Normas pertinentes de la IEEE: IEEE-1016 [7] Page 7

7

Documentación del software de prueba (STD) Página de tapa Revisiones de la página Tabla de contenidos 1 INTRODUCCIÓN 1,1 Descripción general del sistema 1,2 Ensayo de aproximación 2 PRUEBA DE PLAN 2,1 Características que debe ser probado 2,2 Características del no a la prueba 2,3 Herramientas de prueba y Medio Ambiente 3 CASOS DE PRUEBA 3. N  Case-n 3. N .1

Propósito 3. N .2 Entradas 3. N .3 Resultados esperados y Pasa / Falla criterios 3. .4 N  Procedimiento de ensayo 4 MATERIAL ADICIONAL (incluyendo el apéndice A) APÉNDICE A. REGISTROS DE PRUEBA Un Inicie sesión para la prueba n An1 Resultados de las pruebas An2 Reporte de Incidentes Normas pertinentes de la IEEE: IEEE-829 [3], IEEE-1008 [5], IEEE-1012 [6] Page 8

8 Referencias

[1] HE Gruber & JJ Vonêche [eds.], The Essential Piaget, Basic Books, 1977 [2] Computing Curricula 2001, La Fuerza de Tarea Conjunta sobre Planes de Estudio Informática, Informe Final, IEEE Computer Society, Association for Computing Machinery, 15 de diciembre 2001 [3] IEEE Std. Norma IEEE 829-1998 de Documentación de pruebas de software

[4] IEEE Std. 830-1998 IEEE Práctica recomendada para los requisitos de software  Especificaciones

[5] IEEE Std. 1008-1997 Norma IEEE para Pruebas de Software Unidad  [6] IEEE Std. 1012-1998 IEEE estándar para la verificación y validación de software

[7] IEEE Std. IEEE 1016-1998 Práctica recomendada para el diseño de software  Descripciones

[8] IEEE Std 1058-1998 Norma IEEE para los Planes de Gestión de Proyectos de Software

[9] IEEE Std 1540-2001 Norma IEEE for Life Cycle Software Procesos Riesgos  Manejo

[10] IEEE 12207.2-1997 implementación en la industria de la Norma  Internacional  ISO / IEC 12207: 1995 (ISO / IEC 12207) Norma para la Tecnología de la  Información Software Procesos del Ciclo de Vida - Consideraciones de implementación [11] EF Lindquist (Ed.), Medidas para la Educación, Consejo Americano de

Educación, 1951 [12] R. McCauley y Jackson U., "Enseñanza de Ingeniería de Software Temprana Experiencias y resultados ", en  Actas de los 1998 Frontiers in Education Conferencia (FIE'98), IEEE, 1998. [13] R. Thomas, G. Semeczko, H. Morarji, G. Mohay, "Núcleo de Ingeniería de Software Temas: Un Estudio de Caso ('86 - '94) ", en Actas de la Educación Software Conferencia de 1994, Páginas: 24-31, IEEE, 1995 [14] MIL-STD-498 estándar militar, Desarrollo de Software y la  Documentación,

EE.UU. Departamento de Defensa, 05 de diciembre 1994 [15] E. Yourdon, Rise y Resurrección del estadounidense, Yourdon Press, 1996

programador 

View more...

Comments

Copyright ©2017 KUPDF Inc.
SUPPORT KUPDF