Pruebas. El desarrollo de la documentación. INTRODUCCIÓN
los fase de implementación consiste en desarrollar y probar
el software del sistema, documentación y nuevos procedimientos operativos. La gestión del proceso de programación es la principal tarea del analista de sistemas en esta fase. Mientras que los programadores trabajan en la programación, el analista de sistemas diseña una variedad de pruebas para asegurar que el sistema hace para lo que fue diseñado para hacer. Durante esta fase, los analistas de sistemas finalizan la documentación del sistema y desarrollan la documentación del usuario. GESTIÓN DEL PROCESO DE PROGRAMACIÓN
Las tareas del director del proyecto durante el
proceso de programación: - la asignación de tareas de programación, - la coordinación de las actividades, y - la gestión del cronograma de programación. La asignación de tareas de programación
El director del proyecto primero agrupa los módulos que
están relacionados y luego asigna los grupos de módulos a los programadores sobre la base de su experiencia y nivel de habilidad. El director del proyecto debe hacer frente a una falta de correspondencia entre las habilidades de programación disponibles y las habilidades de programación que son necesarias para el proyecto. El mejor tamaño del equipo de programación es el más pequeño posible que puede funcionar lo más independiente posible. coordinar las actividades La coordinación se realiza a través tanto de alta tecnología y de baja tecnología medios. El enfoque más simple es tener una reunión semanal del proyecto. Otro método importante es crear y seguir las normas. Muchos equipos de proyecto establecieron tres “áreas” para los programadores: – Área de Desarrollo (modificar), – Área de pruebas, y – Área de producción (etapa en la que el sistema funciona). (Continuación) Implementar técnicas de cambio de control(backup): - mantener los archivos y programas en diferentes lugares de acuerdo con el estado de finalización, - usando un registro del programa para realizar un seguimiento de los cambios en el programa. Muchas herramientas CASE están configuradas para realizar el seguimiento del estado de los programas y ayudar a gestionar a los programadores. La gestión de la cronograma Las estimaciones de tiempo iniciales deben ser refinadas según como avanza el proyecto durante la construcción. Una de las causas más comunes de problemas de tiempo es la corrupción del alcance. Otra causa común y es desapercibida cambios debido son los retrasos del día a día en el cronograma. Por lo general, un gerente de proyecto creará una evaluación de riesgos en base a los potenciales riesgos que tienen un impacto en el cronograma y los costos. (Continuación)
Los errores de implementación clásicos:
1. El desarrollo orientado a la investigación. 2. Uso de personal “bajo costo”. 3. La falta de control de código. 4. Pruebas inadecuadas, muy ligeras. PRUEBAS
La atención que se presta a las pruebas
se justifica por los altos costos asociados con el tiempo de inactividad y las fallas causadas por errores de software. Planificación de la pruebas Iniciar las prueba con el responsable desarrollando un Plan de pruebas que define una serie de ensayos que se llevaran a cabo. Un plan de pruebas describe un conjunto muy específico de Casos de prueba a examinar y define los resultados esperados. El responsable de las pruebas desarrolla una serie los casos de prueba para asegurar que la calidad de los programas sea valida. Hay cuatro etapas generales de pruebas: las pruebas unitarias, pruebas de integración, pruebas de sistemas y pruebas de aceptación. (Continuación) Plan de prueba (Continuación)
Cada una de las funciones es un módulo separado que tiene que
ser probado (Continuación) Error de detección tarifas para las diferentes etapas de pruebas (Continuación) Tipos de pruebas Las pruebas unitarias Las pruebas unitarias se centran en una sola unidad - un programa o un módulo de programa que realiza una función específica que puede ser probado. Hay dos enfoques para la prueba de la unidad: - Las pruebas de caja negra – El plan de prueba se desarrolla directamente a partir de la especificación del programa. - Pruebas de caja blanca – El responsable de las pruebas revisa el código del programa. Las pruebas de integración Las pruebas de integración evaluar si un conjunto de módulos o programas que deben trabajar juntos lo hacen sin error. Hay cuatro enfoques para las pruebas de integración: - pruebas de la interfaz de usuario, - pruebas de uso de escenario, - pruebas de flujo de datos, y - pruebas de la interfaz del sistema. Pruebas del sistema Las pruebas del sistema por lo general se llevan a cabo por los analistas de sistemas para asegurar que todos los módulos y programas trabajan juntos sin error. Examinan las pruebas del sistema - qué tan bien el sistema cumple con los requisitos de negocio, - facilidad de uso, - la seguridad, - el rendimiento en situaciones de carga, y - la documentación del sistema. Prueba de aceptación Prueba de aceptación se realizan principalmente por los usuarios. El objetivo de las pruebas de aceptación es para confirmar que el sistema es completo, satisface las necesidades del negocio y es aceptable para los usuarios. Las pruebas de aceptación se realiza en dos etapas: - pruebas de alfa - los usuarios probar el sistema a partir de datos confeccionados, - prueba beta - los usuarios comienzan a utilizar el sistema con datos reales y vigilar cuidadosamente el sistema para localizar errores. DESARROLLO DE DOCUMENTACIÓN Hay dos tipos fundamentalmente diferentes de documentación: - documentación del sistema está destinado a ayudar a los programadores y analistas de sistemas a entender el sistema y les permiten construir o realizar su mantenimiento; - documentación del usuario está diseñado para ayudar al usuario operar el sistema. (Continuación)
La documentación del usuario no se
debe dejar hasta el final del proyecto. El tiempo requerido para el desarrollo y la documentación de usuario de prueba debe ser incorporado en el plan del proyecto. La documentación en línea se está convirtiendo en la forma predominante. (Continuación) Hay cuatro puntos fuertes de documentación en línea: - La búsqueda de información es más simple. - La misma información se puede presentar en diferentes formatos. - Se permite al usuario interactuar con la documentación de muchas nuevas maneras. - Es mucho menos costoso que la documentación en papel. Tipos de documentación del usuario Hay tres tipos fundamentalmente diferentes de documentación para el usuario: - Documentos de referencia están diseñados para ser utilizados cuando el usuario necesita para aprender a realizar una función específica. - Manuales de procedimientos describir cómo llevar a cabo tareas de negocios. - Tutoriales enseñar a la gente cómo utilizar los componentes principales del sistema. Estructura de Documentación Proyectos La estructura general que se utiliza en la documentación en línea es el desarrollo de un conjunto de controles de navegación de la documentación que conducen al usuario temas de la documentación. Hay cinco tipos generales de los controles de navegación para los temas: la tabla de contenido, índice de búsqueda de texto, agente inteligente y enlaces web similares. (Continuación) Organización de los documentos de referencia en línea Temas a escribir en la documentación Los temas comienzan con títulos claros, seguido de texto de introducción que define el tema y luego se proporcionan instrucciones detalladas paso a paso. Muchos de los temas incluyen imágenes de la pantalla y “muestran” ejemplos. La mayoría también incluye controles de navegación para permitir el movimiento entre los temas. Algunos también tienen enlaces a temas relacionados. (Continuación) Un tema de Ayuda en Microsoft Word (Continuación) Directrices para la elaboración de documentación Temas Identificar Términos de Navegación Los términos de navegación se utilizan para ayudar a los usuarios a encontrar los temas. Las condiciones para el motor de búsqueda e índice pueden provenir de cuatro fuentes distintas: - El conjunto de los comandos de la interfaz de usuario; - El conjunto de los conceptos principales en el sistema (por ejemplo, entidades de datos); - El conjunto de tareas de negocios que el usuario realice; - El conjunto de sinónimos de los tres conjuntos de elementos mencionados anteriormente. RESUMEN La gestión de la programación - El director del proyecto asigna tareas a los programadores, coordina el desarrollo del programa, gestiona el programa y ajusta el cronograma. Pruebas - Un Plan de pruebas contiene varias pruebas. - Una prueba especifica varios Casos de prueba. - Cuatro tipos de pruebas: las pruebas unitarias, pruebas de integración, pruebas del sistema y prueba de aceptación. Documentación - La documentación del usuario y la documentación del sistema se están volviendo predominantemente documentación en línea. - Hay tres tipos de documentación para el usuario: documentos de referencia, manuales y tutoriales. Copyright 2011 John Wiley & Sons, Inc. Todos los derechos reservados. La reproducción o traducción de este trabajo más allá de lo permitido en la Sección 117 de la Ley de Derechos de Autor de los Estados Unidos de 1976 sin el permiso expreso por escrito del propietario de los derechos de autor es ilegal. La solicitud de información adicional debe dirigirse al Departamento de Permisos, John Wiley & Sons, Inc. El comprador puede hacer copias de respaldo solo para su propio uso y no para la redistribución o reventa. El Editor no asume ninguna responsabilidad por errores, omisiones o daños causados por el uso de estos programas o por el uso de la información contenida en este documento.