INSTITUTO UNIVERSITARIO DE TECNOLOGIA DE ADMINISTRACION INDUSTRIAL I.U.T.

A CARRERA: INFORMATICA SECCION: 204- A3

Diseo de sistemas

Profesor: Naydrubys Trejo

Alumno: Rubn Linares C.I. 24336093

Guarenas, 27 Julio 2012

IMPLEMENTACION DE SITEMAS DE INFORMACION La fase de implementacin de un sistema es la fase ms costosa y que consume ms tiempo de todo el ciclo de vida: Es costosa porque muchas personas, herramientas y recursos, estn involucrados en el proceso. Consume mucho tiempo porque se completa todo el trabajo realizado previamente durante el ciclo de vida. Durante la implementacin las especificaciones del diseo fsico son convertidas cdigo de computadora que trabaje y cumpla con dicho diseo. El cdigo es probado y la mayora de los errores deben ser detectados y corregidos En la fase de implantacin, las especificaciones del diseo del sistema sirven como base para la construccin del nuevo sistema. En este punto, los programadores y los analistas de sistemas asumen diferentes responsabilidades. El analista debe proveer especificaciones claras y correctas al programador. El programador codifica, prueba y documenta los mdulos de programas, mientras que el analista de sistema planifica la integracin de los programas y asegura que trabajen unidos para satisfacer las necesidades de la organizacin Cualquiera que sea el mtodo de implementacin es necesario puntualizar que, asegurar la confiabilidad del sistema, realizar ajustes, correccin de errores, deben ser planeados por lo que es tambin recomendable realizar monitoreos planeados y coordinados para asegurar que la fase sea exitosa. Un nuevo sistema requiere planificacin, construccin y prueba. Los programas y mdulos deben ser diseados, codificados, probados y documentados. Cuando se planifica el sistema, muchas veces se usa un estilo de arriba-hacia-abajo (top-down), que procede de un diseo general a una estructura detallada siguiendo unos pasos lgicos. En el estilo top-down, el analista de sistemas define los objetivos generales, y luego los descompone en subsistemas y mdulos en un proceso llamado partitioning. Este estilo tambin se conoce como diseo modular. Un mdulo es un conjunto de instrucciones de programas que se pueden ejecutar como un grupo. Asignando mdulos a diferentes programadores se agiliza el desarrollo del programa.

Hay tres maneras para realizar la implementacin una de ellas en la de sustitucin directa del sistema viejo por el nuevo. En esta el sistema se trasladar directamente a la realidad, se deben implementar mtodos de monitoreo para verificar el funcionamiento del sistema, en esta fase de prueba se tienen que identificar errores en conjunto con los usuarios para verificar, que la informacin que entra y sale sea correcta y coincida con informacin que genera el sistema anterior. Los usuarios son un factor determinante en la evaluacin del sistema para que sea implementado definitivamente en la organizacin, s en algn caso no llegara a tener xito debe realizarse una reingeniera o bien los ajustes necesarios para que el sistema vuelva a ser evaluado y obtener los resultados deseados. Otra forma de implementacin es la implementacin en paralelo, es este mtodo, tanto el sistema viejo como el nuevo se ejecutarn paralelamente en un tiempo determinado, para evaluar los resultados antes de que sea implementado definitivamente, durante este periodo se corregirn errores, se ajustar el sistema, para asegurar que el nuevo sistema funciona correctamente y sea sustituido el anterior, la desventaja que tiene este mtodo es que hay que hacer doble esfuerzo, debido a que se deben manejar los dos sistemas. La ltima es la implementacin por proyecto piloto, en esta se procesa informacin en el sistema nuevo producida por el sistema anterior para asegurar que los resultados sean los esperados para asegurar su confiabilidad y veracidad, antes de que sea implementado el nuevo sistema.

PRUEBAS DE SISTEMA Las pruebas de sistema buscan discrepancias entre el programa y sus objetivos o requerimientos, enfocndose en los errores hechos durante la transicin del proceso al disear la especificacin funcional. Esto hace a las pruebas de sistema un proceso vital de pruebas, ya que en trminos del producto, nmero de errores hechos, y severidad de esos errores, es un paso en el ciclo de desarrollo generalmente propenso a la mayora de los errores. Las pruebas de sistema no son procesos para probar las funciones del sistema o del programa completo, porque sta sera redundante con el proceso de las pruebas funcionales. Las pruebas del sistema tienen un propsito particular: para comparar el sistema o el programa con sus objetivos originales (Requerimientos funcionales y no funcionales). Dado este propsito, se presentan dos implicaciones: 1. Las pruebas de sistema no se limitan a los sistemas. Si el producto es un programa, la prueba del sistema es el proceso de procurar demostrar cmo el programa, en su totalidad, no resuelve sus objetivos o requerimientos. 2. 3. Las pruebas de sistema, por definicin, son imposibles si no estn los requerimientos por escrito, mensurables para el producto. Las pruebas de sistema tienen como objetivo ejercitar profundamente el sistema comprobando la integracin del sistema de informacin globalmente, verificando el funcionamiento correcto de las interfaces entre los distintos subsistemas que lo componen y con el resto de sistemas de informacin con los que se comunica. Son pruebas de integracin del sistema de informacin completo, y permiten probar el sistema en su conjunto y con otros sistemas con los que se relaciona para verificar que las especificaciones funcionales y tcnicas se cumplen. Dan una visin muy similar a su comportamiento en el entorno de produccin. Se distinguen los siguientes tipos de pruebas:

Pruebas de comunicaciones. Pruebas de rendimiento. Pruebas de recuperacin Pruebas de volumen. Pruebas de sobrecarga.

Pruebas de tensin. Pruebas de disponibilidad de datos. Pruebas de facilidad de uso. Pruebas de operacin. Pruebas de entorno. Pruebas de seguridad. Pruebas de usabilidad. Pruebas de almacenamiento. Pruebas de configuracin. Pruebas de instalacin. Pruebas de la documentacin.

Las pruebas de unidad sirven para comprobar el correcto funcionamiento de un componente concreto de nuestro sistema. Es este tipo de pruebas, el "probador" debe buscar situaciones lmite que expongan las limitaciones de la implementacin del componente, ya sea tratando ste como una caja negra ("pruebas de caja negra") o fijndonos en su estructura interna ("pruebas de caja blanca"). Resulta recomendable que, conforme vamos aadindole nueva funcionalidad a nuestras aplicaciones, vayamos creando nuevos test con los medir nuestro progreso y tambin repitamos los antiguos para comprobar que lo que antes funcionaba sigue funcionando (test de regresin). Una vez "finalizado" el sistema, se realizan pruebas alfa en el seno de la organizacin encargada del desarrollo del sistema. Estas pruebas, realizadas desde el punto de vista de un usuario final, pueden ayudar a pulir aspectos de la interfaz de usuario del sistema Cuando el sistema no es un producto a medida, sino que se vender como un producto en el mercado, tambin se suelen realizar pruebas beta. Estas pruebas las hacen usuarios finales del sistema ajenos al equipo de desarrollo y pueden resultar vitales para que un producto tenga xito en el mercado. En sistemas a medida, se suele realizar un test de aceptacin que, si se supera con xito, marcar oficialmente el final del proceso de desarrollo y el comienzo de la etapa de mantenimiento.

Por ltimo, a lo largo de todo el ciclo de vida del software, se suelen hacer revisiones de todos los productos generados a lo largo del proyecto, desde el documento de especificacin de requerimientos hasta el cdigo de los distintos mdulos de una aplicacin. Estas revisiones, de carcter ms o menos formal, y ayuden a verificar la correccin del producto revisado y tambin a validarlo (comprobar que se ajusta a los requerimientos reales del sistema). Aunque es imposible garantizar la ausencia de errores en el software, una adecuada combinacin de distintas tcnicas de prueba puede ayudar ms del 90% de los errores que se encontrarn a lo largo de toda la vida del sistema. Aunque podamos ser reacios a admitirlo, lo normal es que el 40% de nuestro tiempo lo "perdamos" eliminando errores, mientras que slo empleamos un 20% en la etapa de anlisis, otro 20% en el diseo y el 20% restante en la implementacin del sistema (Robert Glass, Building quality software, 1992). Al realizar cualquiera de los tipos de prueba descritos, es importante recordar que el desarrollo de software es una actividad que se realiza en equipo, por lo que pueden surgir roces personales y disputas polticas entre los miembros del equipo. Las pruebas resultan particularmente delicadas en sentido, ya que su objetivo es, al fin y al cabo, encontrar defectos.

FACES DE IMPLEMENTACION La fase de implementacin se puede dividir en seis (6) procesos: Codificacin. Pruebas Instalacin. Documentacin. Adiestramiento. Soporte.

EL PROCESO DE PRUEBA Un sistema falla porque tiene al menos un defecto. Es por ello que hay que realizar pruebas, con la finalidad de eliminar los defectos. Es una actividad ingrata y debe hacerla un grupo no involucrado con el desarrollo. La actividad de prueba se debe prever desde el inicio del proyecto. Dadas las caractersticas del software, este puede requerir un plan de pruebas muy costoso. Este plan debe delinearse desde el inicio del proyecto para estipular: tiempo, recursos humanos, recursos de HW y SW, posible datos especiales, etc. EL PROCESO DE PRUEBA Un sistema falla porque tiene al menos un defecto. Es por ello que hay que realizar pruebas, con la finalidad de eliminar los defectos. Es una actividad ingrata y debe hacerla un grupo no involucrado con el desarrollo. La actividad de prueba se debe prever desde el inicio del proyecto. Dadas las caractersticas del software, este puede requerir un plan de pruebas muy costoso. Este plan debe delinearse desde el inicio del proyecto para estipular: tiempo, recursos humanos, recursos de HW y SW, posible datos especiales, etc. Las pruebas que en particular se le pueden realizar al cdigo se clasifican en: dinmicas o estticas, automatizadas o manuales. Por esttica se entiende que el cdigo evaluado no es ejecutado; por automtica, que lo conduce la computadora.

Las Inspecciones son vistas como un elemento de aseguramiento de la calidad.

 El Desk Checking es solicitar a un equipo de desarrolladores que corran en fro el cdigo. El Chequeo Sintctico es realizado por excelencia por los compiladores. Las Pruebas de Unidad se conocen como las pruebas de caja blanca y las pruebas de caja negra. Las Pruebas de Integracin pueden ser profundas o anchas. Las Pruebas del Sistema se dividen en alfa y beta. Las Pruebas de Sistemas tipo Alfa ( ) son la que se realizan con una muestra de datos reales. Las Pruebas de Sistemas tipo Beta ( ) son evaluaciones realizadas por un grupo de colaboradores. Durante las pruebas alfa, se debe verificar: o Recuperacin ante fallas del sistema. o Pruebas de seguridad. o Pruebas de estrs. o Pruebas de performance.

BIBLIOGRAFIA http://200.69.103.48/comunidad/grupos/arquisoft/fileadmin/Estudiantes/Prueb as/HTML%20-%20Pruebas%20de%20software/node37.html http://www.angelfire.com/cantina/plan/fase04.htm http://www.tuobra.unam.mx/obrasPDF/publicadas/040911121648.html http://mmalicea.tripod.com/proyecto/implantsist.htm