Análisis y Diseño de Distemas

5ta Edición

Capítulo 12. Transición a la

Implementación

Alan Dennis, Barbara Haley Wixom, and Roberta Roth

© Copyright 2011 John Wiley & Sons, Inc.

 Capítulo 12 Esquema

 La gestión del proceso de programación.

 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.

© Copyright 2011 John Wiley & Sons, Inc.