3. DOCUMENTACIÓN 3.1. DOCUMENTACIÓN DE APLICACIONES. OBJETIVOS PARA MODIFICAR HACE FALTA COMPRENDER/ESTUDIAR:



Documentos relacionados
Instructivo para la elaboración de un Manual de Usuario

Ingeniería de Requerimientos. requiere de un Sistema de Software.

NÚMERO DE HORAS: 160H PROGRAMACIÓN WEB EN EL ENTORNO CLIENTE OBJETIVO

Control del Documento

recomendaciones acerca de la memoria de un PFC

Especificación de requisitos de software

Departamento de Informática Universidad de Valladolid Campus de Segovia TEMA 7, SECCIÓN 1: REQUISITOS SOFTWARE

Published on Marco de Desarrollo de la Junta de Andalucía (

COPIA NO CONTROLADA. ININ No: P.SI-4 Rev.: 1 Fecha de Emisión: Junio de 2010 Hoja: 1 de: 15. Area: Departamento de Sistemas Informáticos

PAUTAS PARA ELABORAR EL INFORME DE PRÁCTICAS

Proyecto: Versión x.x

TEST (2 0 puntos, 0 20 puntos por pregunta correcta, puntos por error) [Marcar sólo una opción]

Matriz de Competencias THEME Mecatrónica con Competencias Parciales/ Unidades de Resultados de Aprendizaje

IEEE Objetivo:

Guía de Estilo para la Documentación del Proyecto

La ingeniería del software es una disciplina de ingeniería que comprende todos los aspectos de la producción de software.

Método de aprendizaje para diplomados tutoriales

LABORATORIO DE INTERACCION HUMANO COMPUTADORA MANUAL DE PRÁCTICAS. Practica #1. Identificación del proyecto a Desarrollar

Tipos Abstractos de Datos (TAD) Lección 1

INTRODUCCIÓN A LA METODOLOGÍA DE LA INVESTIGACIÓN

Elaboración del Descriptor de Procesos. Establecer el proceso a seguir para la elaboración del documento descriptor de procesos.

1. Propósito. Establecer los puntos que debe cubrir como referencia documental mínima un documento de Diseño de sistemas automatizados.

Sistema de Administración de Farmacias Descripción de la Arquitectura Versión 1.1. Historia de revisiones

Caso de Uso. Herramienta de relevamiento. domingo, 28 de octubre de 12

Diagramas De Casos De Uso

Guía para la documentación de proyectos de software

Programación Orientada a Objetos. Conceptos Básicos

CIDE, SA. RIF: J NIT: MODELO FUNCIONAL

Requerimientos de Software

Elaboración de la propuesta de solución. afelipelc

Criterios de Evaluación

Instrucción 1 Criterios, Convenciones y recomendaciones para utilizar este instructivo

DOCUMENTACIÓN TÉCNICA

PONTIFICIA UNIVERSIDAD CATÓLICA DEL PERÚ

ENTRAR. Material ACTIVIDAD DE APRENDIZAJE 3 Guía para la elaboración del informe técnico.

GLOSARIO DE TÉRMINOS

I N T R O D U C C I Ó N

Objetivos. Plan. Cambios de grupos Prof. sustituto: Alicia Villanueva

Comercio en Tiendas de Autoservicio

Programación Orientada a Objetos

DEFINICION DEL PROYECTO SOLICITUD DE LA PROPUESTA

Guía de instalación del navegador Mozilla Firefox

PROPUESTA PROYECTO DE EMPRENDIMIENTO (IDEA DE NEGOCIO)

Proyecto Integrador III Sesión 5 Requerimientos de Software

es en lugar de constituye decidir en lugar de determinar usar en lugar de emplear ahora en lugar de en este momento

Instrucción 1. Criterios, Convenciones y recomendaciones para utilizar este instructivo

ISO 10013:1995 CÓDIGO ISO 10013:1995. Lineamientos para el desarrollo de manuales de calidad

ANEXO PROGRAMACIÓN CIENCIAS SOCIALES, HISTORIA BILINGÜE-FRANCÉS. 4º E.S.O. CURSO

Unidad I. Introducción

ANÁLISIS ESTRUCTURADO

Seminario 1: Documento de Especificación de Requisitos. Laboratorio de Programación Curso 2006/2007 Impartido por: Fran Ruiz

Partes de un informe técnico

Recomendaciones para la presentación en papel

TITULACIÓN POR SEMINARIO EN ÁREAS BÁSICAS REPORTE ACADÉMICO

I N S T I T U T O N A C I O N A L D E I N V E S T I G A C I O N E S N U C L E A R E S

UNIDAD FUNCIONAL: DIRECCIÓN NACIONAL DE TECNOLOGÍA

Lineamientos para la elaboración de manuales de la calidad

Pontificia Universidad Javeriana. USO DE XML EN EL MERCADO DE DIVISAS Plan de Pruebas. Versión 1.0

GUÍA DE APRENDIZAJE. PROCESO DE DISCIPLINA OPERATIVA Calidad. Aprendizaje sin fronteras

RECURSOS DIGITALES EXPERIENCIAS DEL USUARIO (UX) Maestro: Carlos Alberto Rodríguez. Alumno: Ana Cristina Maldonado Rodríguez Matricula:

IVAN CANO. Escritura de artículos

MANUAL DE TALLERES INGENIERÍA DE SOFTWARE

Planes de Contingencia Ambiental. Contenidos mínimos

UNIVERSIDAD SALESIANA DE BOLIVIA ESCUDO DE LA UNIVERSIDAD NOMBRE DEL PROYECTO DE SOFTWARE

ANÁLISIS DE SISTEMAS. Por: Ing. Tanya Recalde Ch.

UNIVERSIDAD MEXIQUENSE DEL BICENTENARIO CAMPUS ACAMBAY LICENCIATURA EN INFORMÁTICA DESARROLLO DE APLICACIÓN PARA AMBIENTES DISTRIBUIDOS

[Escriba texto] CÓMO ESCRIBIR UN TFG

Proyectos Informáticos. Luis Alvarez León

DOCUMENTACIÓN. Documentación de usuario Aspectos de uso del producto

Diseño eléctrico de una tienda departamental OBJETIVOS

Monedero de Cambio. Documentación técnica. Guía breve de referencia para poner en marcha el sistema spider Schn/DVs/Roe Versión 1.0 KA.

Especificación de requisitos de software. Proyecto: [Nombre del proyecto] Revisión [99.99] [Mes de año]

Ingeniería del Software Herramientas CASE Que es CASE? Ingeniería de sistemas asistida por computadoras (Computer-aised system engineering, o CASE)

Grado en Ingeniería Informática. Plan de proyecto. Desarrollo de Sistemas de Información Corporativos. Departamento de Informática

CURSO MONOGRAFÍA Y TESIS FEBRERO 2018 TAREA 2

Especificación de Requisitos (ERS)

Especificación de Requerimientos <Nombre del Proyecto> Nombre del Grupo de Desarrollo o Asignatura Nombre del Autor

CAPÍTULO 1. Se sabe (o conoce) que algunas de las actividades de desarrollo del

Metodología para la solución de problemas programables

Modelo y Análisis 179

ORGANISMO COORDINADOR DEL SISTEMA ELÉCTRICO NACIONAL INTERCONECTADO DE LA REPÚBLICA DOMINICANA

UNIVERSIDAD AUTÓNOMA CHAPINGO. Ingeniería en Restauración Forestal e Ingeniero Forestal Industrial

Laboratorio de Mecánica de Suelos. Pautas del Laboratorio.

Lenguaje Unificado de Modelado

DESCRIPCIÓN DE LA INVENCIÓN Q.F.B. ALMA S. ALVAREZ Y DELUCIO

Programación Orientada a Objetos

Introducción. Propósito. Ámbito del Sistema. Ingeniería del Software I

Planos de Estructuras de Acero. Profesor Sr: Fernando Sepúlveda Elizondo Especialidad Construcciones Metálicas 2009

Ingeniería de Software: Y eso qué es?


Capítulo 11 Líder del equipo

Pontificia Universidad Católica del Perú Especialidad de Ingeniería Informática

PRÁCTICAS EXTERNAS GRADO DE PSICOLOGÍA Evaluación del tutor académico

IEEE-std Práctica Recomendada para la Especificación de Requerimientos de Software

Diplomado Análisis de negocio, preparación para Certificación

Ingeniería de Software II. SETEPROS Plan de pruebas. Versión 1.0

ORGANISMO COORDINADOR DEL SISTEMA ELÉCTRICO NACIONAL INTERCONECTADO DE LA REPÚBLICA DOMINICANA

RUBRICAS DE EVALUACIÓN

Transcripción:

3. DOCUMENTACIÓN 3.1. DOCUMENTACIÓN DE APLICACIONES. OBJETIVOS UN SISTEMA SOFTWARE QUE SEA: + DIFÍCIL DE COMPRENDER + SÓLO UTILIZABLE POR SUS REALIZADORES + DIFÍCIL DE MODIFICAR NO ES VÁLIDO PARA EVITAR ESTOS PROBLEMAS: DOCUMENTACIÓN CARACTERÍSTICAS DEL PROCESO DE DOCUMENTACIÓN ES UN TRABAJO TEDIOSO (MENOS CREATIVO) ES NECESARIO PARA EL MANTENIMIENTO PARA MODIFICAR HACE FALTA COMPRENDER/ESTUDIAR: DESCRIBIRÁ: EL CÓDIGO LA DOCUMENTACIÓN ASOCIADA + LA MANERA DE USAR EL PROGRAMA + LA RAZÓN POR LA QUE SE ESCRIBIÓ + LAS TÉCNICAS USADAS EN SU CONSTRUCCIÓN + LOS ASPECTOS OSCUROS 3.2. CLASIFICACIÓN DE LA DOCUMENTACIÓN DOCUMENTACIÓN DE LA APLICACIÓN: DOCUMENTACIÓN EXTERNA : + DOCUMENTACIÓN DEL USUARIO + DOCUMENTACIÓN DEL SISTEMA DOCUMENTACIÓN INTERNA 3.2.1. DOCUMENTACIÓN EXTERNA DOCUMENTACIÓN LOCALIZADA APARTE DEL PROGRAMA (EN EL SENTIDO DE QUE NO FORMA PARTE DEL CÓDIGO)

CARACTERÍSTICAS DESCRIBIRÁ: + CÓMO USAR EL SISTEMA (SIN ESTO AÚN EL SISTEMA MÁS SIMPLE RESULTARÍA INÚTIL) + CÓMO INSTALAR Y OPERAR CON EL SISTEMA + LOS REQUISITOS Y EL DISEÑO DE TODO EL SISTEMA + LA FUNCIÓN DEL SISTEMA Y LOS PROCEDIMIENTOS DE PRUEBA, PARA PODERLES DAR EL MANTENIMIENTO LA DOCUMENTACIÓN HABRA DE SER ÚTIL DURANTE TODO EL TIEMPO DE VIDA DEL SISTEMA NO TIENE POR QUÉ PRODUCIRSE EN EL MISMO ORDEN QUE EL SISTEMA (PUEDEN ADELANTARSE TROZOS, AUNQUE NO ES CONVENIENTE ATRASARLOS) NECESITA ÍNDICES EFECTIVOS, PARA PODER ENCONTRAR LA INFORMACIÓN PUEDE VENIR DADA EN DISTINTOS FORMATOS: + ESCRITO + INFORMATICO (BASE DE DATOS, TEXTO,...) 3.2.1.1. DOCUMENTACIÓN DE USUARIO CONJUNTO DE DOCUMENTACIÓN REFERIDA A LAS FUNCIÓNES DEL SISTEMA SIN HACER REFERENCIA AL MECANISMO DE APLICACIÓN (CONSTRUCCIÓN) ESTÁ ORIENTADA A LAS PERSONAS QUE USARÁN EL SISTEMA (NO A QUIEN HA DE MANTENERLO) CARACTERÍSTICAS PUEDE (Y SUELE) SER EL PRIMER CONTACTO DE LOS USUARIOS CON LA APLICACIÓN HA DE PROPORCIONAR UNA VISIÓN INICIAL PRECISA DEL SISTEMA HA DE SER UNA INFORMACIÓN REALISTA, NO PROPAGANDA EJ: NO DEBE SEÑALAR SOLO LAS NUEVAS VENTAJAS, SINO EL CONJUNTO ESTARÁ ESTRUCTURADA SEGÚN VARIOS GRADOS DE DETALLE, APROPIADOS AL ESTADO DE CADA USUARIO. DE ESTA FORMA, SE PODRÁ HACER UN USO SENCILLO DE ELLA SIN NECESIDAD DE LEERLA TODA DOCUMENTOS (DESTINADOS AL USUARIO) 1. UNA DESCRIPCIÓN FUNCIÓNAL SOBRE LO QUE PUEDE HACER EL SISTEMA

2. UN DOCUMENTO QUE EXPLIQUE CÓMO INSTALAR EL SISTEMA Y ADECUARLO A CONFIGURACIONES PARTICULARES DE HARDWARE 3. UN MANUAL INTRODUCTORIO QUE EXPLIQUE EN TÉRMINOS SENCILLOS CÓMO INICIARSE EN EL SISTEMA 4. UN MANUAL DE REFERENCIA QUE DESCRIBA CON DETALLE LAS VENTAJAS DEL SISTEMA DISPONIBLES PARA EL USUARIO Y CÓMO SE PUEDEN USAR 5. UNA GUÍA DEL OPERADOR (SI HA DE HABERLO), QUE EXPLIQUE CÓMO HA DE REACCIONAR ANTE SITUACIONES SURGIDAS MIENTRAS EL SISTEMA SE ENCUENTRA EN USO CONTENIDO DE LA DOCUMENTACIÓN DE USUARIO 1. DESCRIPCIÓN FUNCIÓNAL: + DEBE SEÑALAR LOS REQUISITOS + DEBE DESCRIBIR DE FORMA SIMPLE LOS PROPOSITOS DE LOS IMPLEMENTADORES + DEBE DESCRIBIR LO QUE EL SISTEMA PUEDE HACER Y LO QUE NO + SIEMPRE QUE SEA POSIBLE, DEBE INCLUIR PEQUEÑOS EJEMPLOS EVIDENTES + DEBE DAR UNA VIS ION GENERAL, NO ENTRAR EN DETALLES NI CUBRIR TODAS LASCARACTERÍSTICAS DEL SISTEMA + DEBE PERMITIR DECIDIR AL USUARIO SI EL SISTEMA ES APROPIADO A SUS NECESIDADES O NO 2. MANUAL DE INSTALACIÓN: + DEBE DAR TODOS LOS DETALLES ACERCA DE COMO INSTALAR EL SISTEMA.EN UN ENTORNO PARTICULAR + DEBE DESCRIBIR LA FORMA EN QUE SE SUMINISTRA EL CÓDIGO, FORMATO, CONJUNTO DE CARACTERES USADO, ARCHIVOS Y MODO DE INFORMACIÓN + DEBE INCLUIR LA CONFIGURACIÓN MÍNIMA DE HARDWARE REQUERIDA POR EL SISTEMA + DEBE CONTENER LA LISTA DE ARCHIVOS PERMANENTES QUE SE HAN DE ESTABLECER (PARA EL SOFTWARE) + DEBE INDICAR COMO INICIALIZAR EL SISTEMA, INDICANDO LOS CAMBIOS A EJECUTAR EN ARCHIVOS DEPENDIENTES DE LA CONFIGURACIÓN 3. MANUAL DE INTRODUCCIÓN: + DEBE SER UN PROLOGO INFORMAL QUE DESCRIBA EL USO "NORMAL" DEL SISTEMA + DEBE EXPLICAR COMO INICIAR EL TRABAJO EN EL SISTEMA + DEBE EXPLICAR SUS UTILIDADES MÁS COMUNES + DEBE DESCRIBIR A MENUDO EJEMPLOS

+ DEBE SEÑALAR LA FORMA DE SALIR DE LOS PROBLEMAS MÁS USUALES (PARA NOVATOS) 4. MANUAL DE REFERENCIA: + DOCUMENTO DEFINITIVO SOBRE EL USO DEL SISTEMA + DEBE SER COMPLETO + A SER POSIBLE, DEBE USAR TECNICAS DESCRIPTIVAS FORMALES + SE SUPONDRA QUE EL USUARIO ESTARA FAMILIARIZADO CON EL SISTEMA Y CON EL MANUAL INTRODUCTORIO. COMPRENDERA LOS CONCEPTOS Y TERMINOLOGIA DEL SISTEMA + DEBE PRESENTAR LAS SITUACIONES DE ERROR Y LOS INFORMES GENERADOS 5. GUÍA DE OPERACIÓN O GUÍA DEL OPERADOR: + DEBE ELABORARSE SOLO SI SE REQUIERE OPERADOR + DEBE EXPLICAR LOS MENSAJES QUE SE PRESENTAN EN LA CONSOLA DEL OPERADOR + DEBE PRESENTAR LA RESPUESTA QUE SE HA DE DAR A LOS DISTINTOS MENSAJES + DEBE EXPLICAR EL MANTENIMIENTO DEL HARDWARE QUE HA DE LLEVAR A CABO EL OPERADOR (SI HA LUGAR) CONSIDERACIONES SOBRE LA DOCUMENTACIÓN DE USUARIO MANUALES: + SEPARADOS + UNIDOS (AUNQUE MARCANDO CADA PARTE SEGÚN EL VOLUMEN) COMPLEMENTOS: + TARJETA DE REFERENCIA RAPIDA + AYUDA EN LINEA (BREVE) EVITAN QUE LOS USUARIOS EXPERIMENTADOS TENGAN QUE CONSULTAR MANUALES LA DOCUMENTACIÓN DEBE SER ELABORADA: + POR EL INGENIERO DE SOFTWARE + POR EL DOCUMENTALISTA LIBERA AL INGENIERO DE SOFTWARE (+) OBLIGA A UNA MAYOR COMUNICACION INTERNA ( )

3.2.1.2. DOCUMENTACIÓN DEL SISTEMA DE INFORMACIÓN DESCRIBE TODOS LOS ASPECTOS DEL ANÁLISIS, DISEÑO, IMPLEMENTACIÓN Y PRUEBA DEL SOFTWARE (EN GENERAL, DEL SISTEMA) CARACTERÍSTICAS HA DE INCLUIR TODOS LOS DOCUMENTOS DE LA APLICACIÓN: DESDE LA ESPECIFICACIÓN DEL SISTEMA (Y DE REQUISITOS) HASTA EL ÚLTIMO PLAN DE PRUEBAS ES ESENCIAL PARA EL MANTENIMIENTO (ES NECESARIO CONOCER EL DISEÑO, LA FUNCIÓN Y LAS PRUEBAS) HA DE TENER UNA ORGANIZACIÓN ESTRUCTURADA: HA DE PASAR DE LO MÁS GENERAL A LO MÁS DETALLADO, SEGÚN UN ESQUEMA FORMAL HA DE MARCAR RELACIONES Y DEPENDENCIAS CONTENIDO HA DE ESTAR INCLUIDA LA DOCUMENTACIÓN REFERENTE A CADA UNO DE LOS PASOS DEL DESARROLLO DEL SOFTWARE SE PUEDE ORGANIZAR EN: + ESPECIFICACION DEL SISTEMA + PLAN DE VIABILIDAD + PLAN DE DESARROLLO DEL SOFTWARE + ESPECIFICACION DE REQUISITOS + ESPECIFICACION DEL DISEÑO + PLAN DE PRUEBAS + PLAN DE MANTENIMIENTO 3.2.2. DOCUMENTACIÓN INTERNA ES LA DOCUMENTACIÓN QUE VA INCLUIDA CON EL CODIGO PUEDE SER DE DOS TIPOS: + COMPLEMENTARIA SOBRE EL CODIGO ES UTIL AL ESTUDIAR EL CODIGO PERMITE COMPRENDER MEJOR SU FUNCIÓNAMIENTO + AYUDAS INTERACTIVAS NORMALMENTE DESTINADAS AL USUARIO SE PUEDE CONSIDERAR TAMBIEN DE USUARIO

LAS AYUDAS INTERACTIVAS SOFISTICADAS SE PUEDEN CONSIDERAR COMO UNA FUNCIÓN MÁS DEL SOFTWARE (INTERFAZ HOMBRE MÁQUINA) 3.3. CALIDAD DE LA DOCUMENTACIÓN LOS PROBLEMAS USUALES DE LA DOCUMENTACIÓN SON: + MALA REDACCIÓN + DIFÍCIL DE ENTENDER + NO ACTUALIZADA + INCOMPLETA CONSECUENCIAS: + UTILIDAD MERMADA + NO SE SABE USAR + NO SE COMPRENDE PROCEDIMIENTOS ESTÁNDAR: + MECANISMO DE CONTROL DE CALIDAD + DESCRIPCIÓN DE CONTENIDOS + DESCRIPCIÓN DE NOTACION + MÉTODOS DE REFERENCIA (INTERNOS Y EXTERNOS) + NUMERACIÓN (TÍTULOS Y SUBTÍTULOS) NECESARIO EN LOS DISTINTOS DOCUMENTOS 3.4. RECOMENDACIONES PARA LA REDACCIÓN DE LA DOCUMENTACIÓN OBJETIVO: TEXTOS CLAROS, COMPLETOS Y CONCISOS METODOLOGÍA: RECOMENDACIONES REDACTAR LEER CRITICAR DOCUMENTO SATISFACTORIO UTILIZAR FORMAS GRAMATICALES ACTIVAS EN LUGAR DE PASIVAS

NO EMPLEAR FRASES LARGAS QUE PRESENTEN VARIOS HECHOS DISTINTOS HAY MEJOR RETENTIVA Y COMPRENSION CON FRASES CORTAS NO HACER REFERENCIA A UNA INFORMACIÓN SÓLO CON SU NÚMERO DE REFERENCIA DEBE HACERSE ADEMÁS UN COMENTARIO DE LO QUE SE TRATA DETALLAR (EN FORMA DE LISTA) LOS HECHOS SIEMPRE QUE SEA POSIBLE MAYOR FACILIDAD PARA HALLARLOS, DIFERENCIARLOS Y RETENERLOS SI UNA CIERTA DESCRIPCIÓN ES COMPLEJA, REPETIRLA DEBEN USARSE DISTINTAS DESCRIPCIÓNES SER CONCRETO VALE MÁS CALIDAD QUE CANTIDAD SER PRECISO Y DEFINIR LOS TERMINOS UTILIZADOS LOS TERMINOS CON VARIOS SENTIDOS: + EVITARLOS + DEFINIRLOS CON UN UNICO SENTIDO CONSTRUIR UN GLOSARIO DE TERMINOS UTILIZAR PARRAFOS CORTOS NO MAS DE SIETE FRASES MEJOR RETENTIVA CON LA MEMORIA TEMPORAL UTILIZAR TÍTULOS Y SUBTÍTULOS CONVENIO DE NUMERACIÓN CONSTANTE UTILIZAR CONSTRUCCIONES GRAMATICALES Y ORTOGRÁFICAS CORRECTAS EN CASO CONTRARIO SE REDUCE LA CREDIBILIDAD DEL REDACTOR