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

A ESPECIALIDAD: INFORMATICA SECCION: 204 A3 UNIDAD CURRICULAR: DISEO DE SISTEMAS PROF: Naydrubys Trejo

Implementacin de sistemas de informacin

Milla, Osmar C.I. 21.104.146 Hidalgo, Edinson C.I. 17.457.649 Pineda, Keiverson C.I. 19.498.359 Guarenas, Julio 2012

IMPLEMENTACION

Esta fase es la que podra llamarse como " la prueba de fuego" del sistema, pues con ella se proceder a probar su funcionalidad, robustez, amigable al usuario, es donde surgirn posibles errores. Con la implementacin es la parte en la cual el sistema se pondr en funcin para evaluarlo, realizar ajustes necesarios para que el sistema tenga las mejores condiciones de funcionamiento. 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. 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. Al incluir el trmino sistema viejo, no significa en el sentido estricto que existe un sistema de cmputo, si no que puede ser un sistema manual que quiere ser sustituido por uno computarizado, recordemos que aunque sea manual es un sistema que se ha estado llevando y que por mucho tiempo ha operado. Tal vez en algn momento se encuentre renuencias al cambio, pero es trabajo del analista y de los ejecutivos de la organizacin de que su trabajo no ser menos importante al existir procedimientos automatizados, recordemos que dentro de esto el usuario es pieza importante, por lo que es tarea convencerlos de los beneficios que le traer la nueva herramienta de trabajo, no es fcil pero es necesario para facilitar el trabajo de implementacin y esto incluye a los altos ejecutivos. Al evaluar el sistema debemos tomar en cuenta tambin los costos, beneficios, el tiempo que tardarn los procesos en ejecutarse, la satisfaccin de los usuarios, los errores y reas donde hay y haba problemas, adems de evaluar la eficacia y eficiencia del nuevo sistema, todo de esto con el fin de obtener una retroalimentacin del sistema de tanto de sus puntos malos como buenos. Todo esto conforma el estudio de viabilidad del sistema y por ende si todo fue exitoso es porque el anlisis y diseo de sistemas tambin

lo fue, adems de ello examinar errores, determinacin de las causas de estos y su rpida atencin. Y se deben documentar los resultados, recomendaciones para la solucin de problemas.

PRUEBAS DE SISTEMA

Errar es humano y la etapa de pruebas tiene como objetivo detectar los errores que se hayan podido cometer en las etapas anteriores del proyecto (y, eventualmente, corregirlos). Lo suyo, adems, es hacerlo antes de que el usuario final del sistema los tenga que sufrir. De hecho, una prueba es un xito cuando se detecta un error (y no al revs, como nos gustara pensar). La bsqueda de errores que se realiza en la etapa de pruebas puede adaptar distintas formas, en funcin del contexto y de la fase de proyecto en la que nos encontremos:

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). Las pruebas de integracin son las que se realizan cuando vamos juntando los componentes que conforman nuestro sistema y sirven

para detectar errores en sus interfaces. En algunas empresas, como Microsoft, se hace una compilacin diaria utilizando los componentes del sistema tal como estn en ese momento (daily build) y se somete al sistema a una serie de pruebas bsicas (la prueba de humo, smoke test) que garanticen que el proyecto podr seguir avanzando al da siguiente. El causante de que la compilacin diaria falle suele tener que quedarse a hacer horas extra para que sus compaeros puedan seguir trabajando al da siguiente... 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 CODIFICACIN Consiste en traducir las especificaciones fsicas del diseo en lneas de programas.

 Es una actividad intensa y se debe desarrollar en paralelo con la actividad de prueba. Su entrega gerencial por excelencia es el cdigo mismo. El cdigo se debe caracterizar por ser: o Claro. o Legible. o Limpio. o Documentado. o Modular. o Otros. 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:

Recuperacin ante fallas del sistema.

o Pruebas de seguridad. o Pruebas de estrs. o Pruebas de performance.

EL PROCESO DE INSTALACIN Es el proceso de sustituir el viejo Sistema de Informacin por el nuevo. Existen cuatro (4) tipos de procesos de instalacin:

EL PROCESO DE DOCUMENTACIN Tenemos diferentes tipos de documentacin: DEL SISTEMA: o Interna (programas). o Externa (p.e., DFD, Diagramas E-R, Diagramas de Clases) DEL USUARIO: o Hipertextos / tutoriales. o Ayuda en lnea. o Manuales de usuario. DE MERCADEO. EL PROCESO DE ADIESTRAMIENTO Hay que considerar a quin se va a adiestrar: o Usuarios directos del sistema. o Usuarios indirectos del sistema.

 Cada tipo de usuario tiene diferentes expectativas y habilidades. Normalmente, los trabajadores que ejercen el rol de instructor, son: o Vendedores. o Analistas que conocen el (los) sistema(s). o Instructores externos. o Instructores internos.

EL PROCESO DE SOPORTE Un Centro de Soporte a Usuarios (conocido tambin como Centro de Informacin), es un grupo de personas que estn en la capacidad de responder preguntas y asistir a los usuarios, dentro de una organizacin, en un amplio rango de necesidades en computacin. En un Centro de Informacin, se ejecutan las siguientes tareas: o Instalacin de nuevos HW y SW. o Asistencia de consultas de los usuarios sobre 4GL.

o Extraccin de datos de grandes repositorios para PC. o Asignacin de cuentas. o Se responden preguntas bsicas. o Se dan demostraciones de HW y SW. o Se trabaja con los usuarios para proponer cambios en los sistemas.