1

CICLO DE VIDA DE DESARROLLO DE SISTEMA (CVDS)

Asumir el reto de desarrollar e implantar un sistema de informacin es una tarea compleja que involucra muchas fases distintas, cada una de las cuales con frecuencia debe ser completada antes de que se pueda comenzar una tarea subsiguiente, as para crear sistemas de informacin exitosos fue desarrollado el ciclo de vida del desarrollo de sistemas (CVDS) que es el conjunto de fases o actividades que realizan los analistas, diseadores, programadores y usuarios finales para desarrollar e implantar un sistema de informacin. Se puede decir, que el CVDS es un proceso por el cual los analistas de sistemas, los ingenieros de software, los programadores y los usuarios finales, se relacionan y estudian la situacin actual con el objetivo de elaborar un sistema de informacin o alguna aplicacin informtica; en todo caso se trata de una herramienta de gestin de proyectos que planea, ejecuta y controla los proyectos de desarrollo de sistema. En trminos generales el grupo de analistas, diseadores y programadores enfrentan el escenario de resolver un problema para un grupo de usuarios finales, donde los miembros del departamento de sistemas lo denominan genricamente con el nombre Proyecto. Fase 1---- Investigacin Preliminar: comienza con la solicitud por parte de la gerencia, la administracin, un grupo de usuarios o los especialistas de sistemas en mejorar un proceso, aplicar una norma o aprovechar una oportunidad para mejorar la organizacin, sin importar cual sea el origen de la solicitud el proceso se inicia. Cuando se formula la solicitud comienza la primera fase del CVDS, la esta conformada por: a) Aclaracin de la solicitud b) Estudio de factibilidad c) Aprobacin de la solicitud. a) Aclaracin de la solicitud: Antes de considerar el desarrollo de un sistema es necesario precisar: qu desea o aspira el usuario?, pues muchas peticiones que provienen de obreros, supervisores, gerentes y administradores no estn formuladas de manera clara, pero representan la voz de la organizacin y sus problemas; por consiguiente, antes de considerar el desarrollo de cualquier proyecto de sistema es necesario que la solicitud se examine con detenimiento, para ir estableciendo los limites del mismo.

b) Estudio de factibilidad: El desarrollo de un sistema de Informacin suele ser caro, as antes de iniciar cualquier proyecto se debe hacer un estudio de viabilidad; que es una investigacin rpida de los planes, problemas, las oportunidades o las normas que desencadenan y permiten el desarrollo de este proyecto Whitten, Lonnie y Victor, (1996, 112). El Estudio de Factibilidad lo lleva a cabo un pequeo equipo de personas que pertenecen a la organizacin o asesores externos y que se vern afectados por el proyecto y que no debe durar ms de 8 das hbiles. En la investigacin preliminar se estudian los siguientes aspectos: b.1) Factibilidad Tcnica: Consiste en determinar si dentro o fuera de la organizacin existe la tecnologa y el recurso humano capacitado para poder desarrollar el proyecto.

b.2) Factibilidad Econmica. Consiste en determinar si los costos de desarrollo e implantacin del sistema se justifican en funcin de los beneficios que se obtienen; para esta fase por lo general se desarrollan tablas de costo x beneficio

b.3) Factibilidad operacional: Consiste en determinar si los usuarios potenciales estn en capacidad de usar apropiadamente el sistema, o cuanto tiempo se requerir para formar el personal en el uso apropiado del nuevo sistema de informacin.

b.4) Factibilidad de Calendario: Consiste en dar respuesta a la siguientes pregunta:Puede la solucin desarrollarse e implantarse en un plazo aceptable?, es decir, la construccin del sistema puede desarrollarse en un tiempo razonable para recuperar la inversin y satisfacer a los usuarios finales.

Al finalizar esta etapa el grupo de trabajo debe entregar un informe con todas las posibles alternativas de solucin acompaadas con su estudio de factibilidad y el plan de desarrollo correspondiente. c) Aprobacin de la solicitud Consiste en que la alta gerencia administrativa despus de escuchar el informe de factibilidad tome la decisin para continuar o no con el proyecto.
Aceptar la recomendacin Enmendar la recomendacin Devolver las recomendaciones Rechazar todos los proyectos

En resumen en esta primera etapa el analista se involucra en al identificacin de los problemas y las oportunidades que ofrece la empresa a nivel de desarrollo de sistemas de informacin. En muchas ocasiones la empresa ya tiene detectadas sus reas dbiles y se llama al analista ya con ciertos objetivos previstos. Esta etapa es crtica, ya que nadie desea perder el tiempo resolviendo el problema equivocado.

4 1. Determinacin de Requerimientos: Despus de realizar la investigacin preliminar, el analista tiene que plantear los requerimientos del usuario para el nuevo sistema; es decir, las necesidades y caractersticas que deber cubrir el nuevo sistema. Para identificar los requerimientos de informacin se utilizan varias tcnicas o herramientas como los son documentos, la entrevista, los cuestionarios, etctera. 2. Diseo del sistema: El Diseo de un sistema de informacin produce los detalles que establecen la forma en la que el sistema cumplir con los requerimientos de informacin. 3. Desarrollo de Software: Consiste en escribir los programas necesarios para el sistema. Los programadores son responsables de la documentacin de los programas, que tambin se realiza durante esta etapa, as como explicar el funcionamiento de los mismos y por qu ciertos procedimientos se codifican de determinada forma. La documentacin es importante ya que por medio de ella ser posible modificar o llevar a cabo el mantenimiento del programa.

4. Prueba del sistema: Cada uno de los programas desarrollados es probado de tal manera que funcione correctamente. Durante esta fase el sistema es empleado en forma experimental para asegurarse que el software no tiene fallas, se alimentan al sistema datos de entrada para su procesamiento y se examinan los resultados obtenidos. Es recomendable que las pruebas sean conducidas por personas ajenas a las que desarrollan el software, con esto se busca que las pruebas sean completas e imparciales y que el software sea confiable. 5. Implantacin y evaluacin: La implantacin es el proceso de verificar e instalar nuevo equipo, entrenar a los usuarios, instalar la aplicacin y construir todos los archivos de datos necesarios. Dependiendo del tamao de la organizacin y del riesgo asociado al uso del nuevo sistema se puede comenzar la operacin del sistema slo en un rea de la empresa. Es recomendable que trabajen paralelamente el anterior sistema y el nuevo para comparar los resultados obtenidos. La evaluacin del sistema se lleva a cabo para identificar sus puntos dbiles y fuertes. Aunque en algunas ocasiones este proceso de evaluacin no recibe la importancia que merece, si se realiza de forma adecuada proporciona mucha informacin que puede ayudar a mejorar la efectividad de los esfuerzos de desarrollo de aplicaciones subsecuentes.

5 1.- Principios generales del Ciclo de Vida de Desarrollo de Sistemas (CVDS) 1.1.- Implicar al usuario: Es importante estar claro que el sistema a ser desarrollado le pertenece al usuario del sistema, el analista es simplemente un experto en tecnologa de la informacin que viene a resolver uno o varios problemas puntuales de procesamiento de informacin; comprometer al usuario permite evitar errores en la construccin del sistema, adems que ayuda a vencer el miedo al cambio que toda persona tiene al momento que un nuevo sistema es instalado, y siempre se debe recordar ellos son los que pagan.

1.2.- Se deben Apoyar las actividades de la Organizacin: Toda organizacin debe tener una Visin y Misin especfica, las cuales son su constante motivacin; as la Administracin es encargada de definir las Polticas, Normas, Metas y Estrategias para cumplir con esos principios, de tal manera que cuando se desarrollan los sistemas de informacin ellos se deben desarrollar para servir de apoyo a la alta gerencia y a la toma de decisiones con lo cual se garantiza la productividad de la Organizacin.

1.3.- Aplicar un mtodo de resolucin de problemas: En el momento que el analista estudia la situacin actual se encuentra con: normas, reglamentos, oportunidades, amenazas, actividades, personas, documentos, es decir, el medio ambiente en general que rodea un sistema; para desarrollar una solucin de sistemas en forma eficiente se debe usar un mtodo, con el cual se busca evitar que se pierdan detalles en la construccin de un nuevo sistema; as El Ciclo de Vida de Desarrollo de Sistemas es ante todo un mtodo para resolver problemas, que le permite al analista estudiar en detalle la situacin actual y construir en detalle una solucin, el cual consta de las siguientes actividades: 1. Investigacin preliminar 2. Determinacin de los requerimientos del sistema 3. Diseo del sistema 4. Desarrollo de software 5. Prueba de los sistemas 6. Implantacin y evaluacin

En trminos generales dichas fases o actividades se pueden resumir en: 1. Anlisis 2. Diseo 3. Desarrollo de Software 4. Implantacin

Anlisis

Diseo

Desarrollo de Software

Implantacin

SISTEMA DE INFORMACN o PROBLEMA

1.4.- Justificar los sistemas como una inversin de capital: Los sistemas de informacin son ante todo una inversin de capital, pues los propietarios o la organizacin deben pagar: luz, agua, telfono, personal, discos, hojas, etc...para su realizacin; es por ello que todo analista de sistemas debe plantearse de ante un nuevo sistema: Primero, para cualquier problema es probable que existan varias soluciones, y segundo se debe evaluar la viabilidad de cada una de ellas. El analista debe tener presente esas premisas, pues, ninguna organizacin invierte para no recoger esa inversin a un corto o mediano plazo.

1.5.- Disear el sistema para el crecimiento: La vida til de un nuevo sistema debe ser visto como una solucin a largo plazo, por lo tanto debe ser diseado para que progresivamente el sistema se vaya adaptando a los cambios planteados por los usuarios a los datos, por ejemplo: ingresar nuevos productos, cambiar el iva, cambiar niveles de seguridad, entre otros; de tal manera que se evite la entropa del sistema.

2.- Anlisis: Es el estudio en detalle del sistema actual para conocer: Los procesos Las personas que los manejan Los controles Los documentos que se usan Los datos que usan La informacin que genera y su calidad Y de esta forma poder definir donde efectuar mejoras al sistema; para poder lograr este objetivo se deben cumplir las siguientes fases: 2.1. Investigacin Preliminar 2.2. Determinacin de requerimientos

8 2.1.- La Investigacin preliminar 2.2) Determinacin de los Requerimientos: La siguiente fase del anlisis consiste en conocer y estudiar en detalle la situacin actual, para llegar a una compresin ms profunda de los problemas, las normas, las oportunidades, las limitaciones, los procesos, los datos y todo el medio ambiente en general del sistema actual. Los objetivos fundamentales de esta fase son: Conocer los procesos bsicos de la situacin actual Obtener el diccionario de datos de la situacin actual Definir las fortalezas, oportunidades, amenazas y debilidades del sistema actual (ANLISIS DE LA SITUACIN ACTUAL) Determinar los Requerimientos ser incorporados en el sistema propuesto. Aprender cmo funciona el sistema actual se requiere de la participacin activa de los propietarios, los usuarios(Directos e Indirectos), pues incrementa su sentido de responsabilidad y propiedad del sistema de informacin a ser desarrollado. Para llegar a conocer el funcionamiento en detalle del sistema actual se usan por lo general los Diagramas de Flujo de Datos (D.F.D.), que son modelos que muestran el flujo de los datos desde que entran al sistema, son procesados, almacenados y finalmente se entrega informacin al usuario para la toma de decisiones; paralelamente se estructura el diccionario de datos de la situacin actual. Para realizar los D.F.Ds. el analista conversa con varias personas para reunir detalles relacionados con los procesos de la organizacin, sus opiniones sobre por qu ocurren las cosas, las soluciones que proponen y sus ideas para cambiar el proceso; es decir, el analista hace uso de una o ms de las siguientes tcnicas de investigacin de hechos: Elaboracin de Entrevistas Reunin y discusin en grupos Observacin Muestreo de archivos y formularios Encuestas y cuestionarios. Al concluir este fase el analista debe tener: 1. Los Requerimientos del Nuevo sistema, es decir, un listado de todas las caractersticas o Entradas/Salidas que deben ser incluidas en el nuevo sistema, entre las cuales se puede sealar: Como se capturan los datos Como se procesan los datos y que controles usan Cuales son los procesos Cual es el volumen y la frecuencia de los datos Cual es la frecuencia con la cual se genera un reporte Cuales son los niveles de acceso 2. El Diccionario de Datos del sistema Actual. 3. El Anlisis del Sistema Actual, es decir, un listado de las Fortalezas y Debilidades del Sistema actual a) Actividades de la Determinacin de Requerimientos: a.1) Usar la Experiencia: Todo analista puede tener cierto grado de experiencia o contacto un sistema similar al que se esta estudiando, y dicha referencia puede ser usada para: Establecer una mejor planificacin de proyectos

9 Anticipar problemas Prever un caracterstica del nuevo sistema Definir procesos, datos y controles mas rpido Optimizar el tiempo

a.2) Determinar el objetivo del sistema: Consiste en definir especficamente cual es el objetivo central del sistema a ser desarrollado, pues sin ello se puede llegar a divagar a tal punto que el proyecto inicial se pierde.

Sistema Actual

Objetivo(s) del Sistema Propuesto

a.3) Determinar los Requerimientos: Consiste en estudiar los hechos, los procesos, los datos, los depsitos y las personas del sistema actual, a travs de algn modelo que represente el sistema para definir cuales sern las caractersticas esenciales que deben ser incluidas en el nuevo sistema.

10

b) Los Requerimientos son: b.1) Bsicos: Son aquellas actividades o procesos indispensables que permiten cumplir con los objetivos del sistema.

Datos

Proc 1.

Proc 2.

Proc 3.

Informacin

As POR CADA PROCESO BSICO se debe determinar lo siguiente: Nombre del Proceso: Consiste en estudiar en detalle cada una de las actividades del proceso para especificar qu hace el proceso, cmo lo hace paso a paso y donde guarda los datos y/o la informacin; dicho Nombre debe ser un verbo en infinitivo claro, conciso y preciso, con el cual se identifica el proceso. Se recomienda hacer las siguientes preguntas: Cul es el nombre del proceso? Cules son los pasos o actividades del proceso? Dnde se realizan los pasos? Quines realizan .los pasos? Quines emplean la informacin resultante? Con cunta frecuencia se realizan?

Identificar que datos ingresan al proceso: Consiste en determinar que datos y/o informacin utiliza el proceso para llevar a cabo sus actividades. Determinar que Informacin es generada: Consiste en determinar que datos y/o Informacin da como resultado el proceso.

Datos

Proceso

Informacin

Frecuencia: Se debe determinar el nmero de veces que se presenta el proceso en el tiempo. Ejemplos: mensualmente, cada 15 das, cada tres meses, etc...

11

Volumen: Consiste en determinar qu cantidad de unidades son procesadas. Ejemplos: 15 solicitudes, 50 ventas, 70000 abonos, etc....

Identificar los Controles empleados: Consiste en identificar los puntos donde se establece un supervisin con los datos; en otras palabras, para establecer una comparacin con una norma preestablecida, por ejemplo: validar que no ingresen usuarios no autorizados, verificar que la cantidad vendida no supera la existen en el inventario, garantizar que un usuario con un nivel de acceso no pueda modificar los datos almacenados,..... Por lo general se plantean las siguientes preguntas: Existen estndares preestablecidos? Quin se encarga de supervisar? Cmo se detectan los errores? Cada cuanto se presentan los errores? Cmo se corrigen los errores? Qu datos se originan de fuentes externas y por qu? Cmo se presentan los errores? Con qu detalle se desea el informe de los errores? Cada cuanto y por qu se debe presentar un informe de errores?

12 b.2) De Decisin: A diferencia de las actividades de transaccin, las relacionadas con las decisiones no siguen ningn procedimiento especfico; es mas, las decisiones siempre se toman en base al resultado de los sistemas de transaccin, de all que entre mas seguros y confiables sean, la alta gerencia toma decisiones mas confiable y acertadas. Ejemplo: Cada vez que se debe iniciar un nuevo semestre se toman las estadsticas de los aprobados y reprobados por seccin y materia, para con este dato y la cantidad de alumnos por aula, el jefe de departamento decide crear las nuevas secciones. Al observar este ejemplo se puede notar que para la creacin de una nueva seccin, el jefe de departamento debe tener en sus manos buena cantidad de informacin para poder tomar la decisin mas acertada, es decir crear la seccin con X cantidad de alumnos.. Se recomienda plantearse las siguientes preguntas: Qu Informacin se usa para tomar decisiones? Cul es la fuente de la informacin? Qu sistema de transaccin produce la informacin que es usada en la toma de decisiones y por qu? Qu otros datos son necesarios y por qu? Quin toma las decisiones y por qu?

b.3) De Organizacin: En las Organizaciones cada departamento, seccin, rea depende uno de otro para brindar servicios o bienes a sus clientes, por consiguiente el trabajo de un departamento afecta al de los dems. El analista de sistemas debe determinar cules son los aspectos o elementos que produce el sistema actual y que afectan a otros departamentos, para de esta forma buscar la manera de mejorar los procesos en toda la organizacin.

Fase 1: Anlisis de Necesidades Durante el anlisis de necesidades, la primera fase CVDS, el equipo se enfoca en completar tres tareas: 1. Definir el problema y decidir se ha de proceder. 2. Analizar el sistema actual, a fondo, y desarrollar posibles soluciones al problema. 3. Seleccionar la mejor solucin y definir su funcionalidad. La fase 1 comienza cuando se identifica una necesidad para un sistema nuevo o modificado. Por ejemplo, los usuarios podran quejarse de que el sistema actual es difcil de usar. Los procedimientos simples requieren demasiados pasos, y el sistema se cae repetitivamente, con la consecuencia de una perdida de

13 informacin. Opcionalmente, un administrador se podra acercar de Informtica para pedir un reporte que actualmente no es producido por el sistema. Los analistas de sistemas comienzan entonces una investigacin preliminar, hablando con los usuarios y los administradores del departamento afectado. El primer reto es definir el problema con precisin. Con el problema exactamente definido, el departamento de Informtica puede decidir si va a tomar el proyecto(la decisin de ir o no ir. Cuando una decisin para proceder est tomada, los analistas de sistemas llevan acabo una investigacin concienzuda del sistema actual y sus limitaciones. Trabajan con la gente directamente involucrada con el problema para documentar cmo puede resolverse. El conocimiento reunido en relacin al sistema actual se documenta de varias maneras diferentes. Algunos analistas usan diagramas de flujo de datos, los cuales muestran flujo de informacin a travs del sistema(VER GRAFICO DE EJEMPLO). Podran usar algoritmos estructurados para describir alternativas y acciones del sistema actual. Otra opcin es presentar las acciones que se toman bajo diferentes condiciones en un rbol de decisin(VER EJEMPLO). La representacin grfica es ms fcil de comprender que un a lista. Con esta base, los analistas estn listos para considerar varias soluciones al problema. Podran llamar cientficos de computacin del departamento de Informtica para ayudarlos a identificar distintos enfoques. Cada uno es evaluado con base en las restricciones del proyecto, principalmente el presupuesto y el calendario. Si se debe proporcionar una solucin rpidamente, el equipo del departamento de Informtica podra considerar soluciones que fueran menos ideales, sin embargo, tiene la ventaja de un rpido cambio de posicin. Al finalizar la fase 1, equipo recomienda una solucin para ser adoptada. Los analistas usan la informacin que ya reunieron con los usuarios del sistema para determinar qu caractersticas debe haber en la solucin (Qu reportes deberan generarse, en qu forma sern emitidos y qu herramientas especiales se necesitan). Mediante la fase de anlisis de necesidades, permanecen enfocados en qu debera hacer el sistema, no cmo sern implementadas las caractersticas. Fase 2: Diseo del sistema Durante la segunda fase, Diseo del sistema, el equipo de proyecto encara el cmo de la solucin elegida. Por ejemplo, una aplicacin de la base de datos debera ser capaz de aceptar informacin de los usuarios y almacenarla. stas son funciones generales, pero Cmo las implementar el equipo? Por ejemplo, Cuntas pantallas de entrada son necesarias y cmo se vern? Qu tipo de opciones de men debe haber? Qu tipo de base de datos usar el sistema? Los analistas y programadores involucrados hasta este punto, usan con frecuencia una combinacin de diseo descendente y ascendente para responder esas preguntas. En el Diseo Descendente, el equipo comienza con el panorama general y se va al detalle. Se ocupan de las funciones principales que el sistema debe proporcionar y las dividen en actividades ms y ms pequeas. Cada una de estas actividades ser programada en la siguiente fase CVDS. En el Diseo Ascendente, el quipo comienza con los detalles ( Por ejemplo, los reportes que sern producidos por el sistema) y entonces se dirigen al panorama general (las funciones o procesos principales). Este enfoque es particularmente apropiado cuando los usuarios tiene requerimientos especficos para la salida por ejemplo, cheques para pago de nmina, los cuales deben contener ciertas piezas de informacin-. A travs de la fase 2, el administrador del equipo del proyecto revisa el progreso en el diseo de diferentes componentes del sistema. Al final de la fase se lleva a cabo una revisin ms amplia, involucrado

14 normalmente al departamento que ser afectado y a la administracin superior. Si el diseo pasa la inspeccin, el desarrollo comienza. En algunos casos la revisin pone de relieve problemas con la solucin general, y el equipo debe regresar a analizar o terminar el proyecto. Muchas herramientas estn disponibles para ayudar a los equipos a travs de los pasos del diseo de sistemas. La mayora de estas herramientas tambin pueden usarse durante de la fase de desarrollo, o, incluso, durante el anlisis. Por ejemplo, muchos equipos usan modelos de funcionamiento llamados Prototipos para explorar la vista y percepcin de las pantallas en relacin con los usuarios. Tambin usan aplicaciones de software especiales para crear esos prototipos rpidamente, as como para crear diagramas, escribir cdigo y administrar el esfuerzo de desarrollo. Estas aplicaciones entran en la categora de herramientas de ingeniera de software asistidas por computadora(CASE). En otras palabras, el software de cmputo est usndose para desarrollar otro software de cmputo ms confiable y rpidamente. Fase 3: Desarrollo del Software Durante la fase de Desarrollo, los programadores juegan el papel clave, al crear o personalizar el software para todas las varias partes del sistema. Normalmente, los programadores del equipo son asignados a componentes especficos del sistema general. Si un componente est crendose, los programadores escriben el cdigo necesario o usan herramientas CASE (Si es posible) para acelerar el proceso de desarrollo. Para los componentes comprados, los programadores deben personalizar el cdigo segn sea necesario para hacer que el componente encaje dentro del nuevo sistema. Hay dos rutas alternativas a travs de la fase 3:La ruta de la adquisicin o la ruta del desarrollo local. Tan temprano como la fase 1, anlisis de necesidades, el equipo del proyecto podra darse cuenta de que algunos o todos los componentes necesarios del sistema estn disponibles como hardware o software a nivel comercial, y deciden adquirirlos en vez de dedicarse a desarrollarlos. Adquirirlos componentes comerciales significa que el sistema puede construirse ms rpido y barato que si cada componente debe desarrollarse desde el principio. Otra ventaja de los componentes adquiridos es que ya se han puesto a prueba y se ha demostrado que son confiables, a pesar de que podran necesitar ser personalizados para encajar dentro del sistema general de informacin. En muchos casos, el equipo del proyecto de sistema compran (o adquieren) algunos componentes y construyen (o desarrollan) otros. Por lo tanto, siguen las rutas tanto de adquisicin como de desarrollo local a travs del CVDS al mismo tiempo. Los redactores tcnicos trabajan con los programadores para producir la documentacin tcnica para el sistema. La documentacin tcnica es sumamente distinta de la documentacin para el usuario, en ella se describe a los usuarios finales cmo usar el sistema; en cambio, la documentacin tcnica incluye informacin acerca de las caractersticas tcnicas del software y de la programacin, acerca del flujo de informacin y del procesamiento a travs del sistema, y acerca del diseo y disposicin del hardware necesario. Estos materiales proporcionan una vista general del sistema y, por lo tanto, sirven como una referencia para los miembros del equipo enfocados en los componentes individuales. Adems, la documentacin tcnica es vital para dar apoyo al personal y a los programadores a cargo del sistema durante la fase de mantenimiento. Otros redactores comienzan a trabajar con la documentacin para el usuario, y los arquitectos de asistencia al usuario comienzan a plantear la arquitectura del sistema de ayuda en lnea. Estos esfuerzos normalmente no son terminados hasta llegar a las primeras etapas de la fase de puesta en prctica. Poner a prueba es una parte integral de las fases 3 y 4 (Desarrollo y puesta en prctica). El enfoque tpico de poner a prueba es ir del componente individual hasta el sistema como un todo. El equipo de desarrollo del proyecto prueba cada componente por separado (prueba de unidades) y entonces se ponen a prueba los

15 componentes del sistema con cada uno de los otros (Prueba del sistema). Los errores se corrigen, se hacen, los cambios necesarios y las pruebas se llevan a cabo de nuevo. En seguida viene la prueba de la instalacin, esto es, cuando el sistema es instalado en un ambiente de prueba y probado con otras aplicaciones que use el negocio. Finalmente, se lleva a cabo una prueba de aceptacin, donde los usuarios finales prueban el sistema instalado para asegurarse de que encaja con sus criterios. Con frecuencia, los equipos de desarrollo del proyecto ponen a prueba sistemas o componentes de sistemas con transacciones reales algunas veces llamados informacin viva- . Esto ayuda a asegurase de que el sistema puede manejar el flujo de informacin esperado sobre una base diaria despus que le sistema se pone en lnea. Sin embargo, los programadores tambin debieran probar el sistema con datos invlidos o condiciones de excepcin. Por ejemplo, Qu pasa cuando un usuario teclea mal 1X33345 en vez de 1333345 dentro de un campo que solamente acepta informacin numrica? Este tipo de errores no debe existir en los datos que se usan normalmente para probar el sistema, pero probablemente ocurrir cuando el sistema sea usado por empleados reales. : Fase 4: Implementacin En la fase de Implementacin, el equipo de desarrollo del proyecto terminara comprando el hardware necesario para los usuarios del sistema e instala entonces el hardware y software en el ambiente del usuario. Despus, los usuarios comienzan a usar el sistema para realizar trabajo, no slo para proporcionar retroalimentacin en el desarrollo del sistema. El proceso de cambiar del antiguo sistema al nuevo se llama conversin. Los profesionales de los sistemas de informacin deben manejar cuidadosamente este proceso para evitar perder o corromper datos y frustrar a los usuarios que tratan de realizar su trabajo. La conversin puede ser: Conversin Directa: Todos los usuarios dejan de usar el sistema antiguo al mismo tiempo y despus comienzan a usar el nuevo. Esta opcin es rpida, pero puede ser destructiva. Adems, la presin sobre el personal de soporte puede resultar excesiva. Conversin en paralelo: Los usuarios continan usando el sistema antiguo mientras que una cantidad creciente de informacin es procesada mediante el nuevo sistema. Las salidas de los dos sistemas son comparadas, y si estn de acuerdo se hace el cambio. Esta opcin es til para ms pruebas reales del nuevo sistema, pero es muy desgastante porque ambos sistemas estn operando al mismo tiempo. Conversin en Fases: Los usuarios comienza a usar el nuevo sistema componente por componente. Esta opcin slo funciona para sistemas que pueden ser divididos en compartimientos o mdulos. Conversin piloto: El personal usa el nuevo sistema en un solo sitio piloto y luego la organizacin completa hace el cambio. A pesar que este nuevo enfoque podra llevar ms tiempo que los otros tres, da oportunidad al personal de soporte para probar concienzudamente la respuesta del usuario al sistema, y estarn mejor preparados cuando muchas personas hagan la conversin. Los capacitadotes y el personal de soporte tienen un papel significativo durante la conversin. Los cursos de capacitacin generalmente involucran conferencias del tipo de saln de clase, sesiones de manos a la obra con datos de muestra y capacitacin basada en computadoras, con la cual los usuarios pueden trabajar en su propio tiempo.

Fase 5: Mantenimiento

16 Despus que los sistemas de informacin son implementados, los profesionales del Departamento de Informtica proporcionan soporte durante la fase de mantenimiento. Monitorean varios ndices de la ejecucin del sistema, como el tiempo de respuesta, para asegurarse que el sistema se desempea segn se pretenda. Tambin responden a cambios en los requerimientos de los usuarios. Estos cambios ocurren por una variedad de razones. Conforme los usuarios trabajan con el sistema en una base diaria, podra reconocer situaciones donde un pequeo cambio en el sistema podra permitirles ser ms efectivos. O el administrador de un departamento usuario podra requerir cambios debido a nuevas disposiciones en el estado o en las regulaciones federales de la industria. Los errores en el sistema tambin se corrigen durante la fase 5. Con frecuencia los sistemas se instalan en un ambiente de usuario con errores de programacin o diseo ya conocidos. Normalmente estoe errores han sido identificados como no crticos, o no suficientemente importantes para retrasar la instalacin. Los programadores tiene listas de tales errores para corregirlos durante la fase de mantenimiento. En adicin, el uso diario del sistema podra resaltar errores ms serios para que los programadores los arreglen. Durante el lapso de vida restante del sistema se realizan regularmente cambios o actualizaciones. Sin embargo, en algn punto las reparaciones al sistema ya no cubren los requerimientos del usuario, los cuales podran haber cambiado radicalmente desde que el sistema fue instalado. Los profesionales del departamento de Informtica o los administradores de un departamento usuario comienzan a pedir una modificacin importante o un nuevo sistema. En ese momento, el CVDS ha regresado a su punto inicial y la fase de anlisis comienza de nuevo.

REFERENCIAS BIBLIOGRFICAS 1.- Anlisis y Diseo de Sistemas, Centro de Computacin Profesional de Mxico(CCPM), McGraw-Hill Interamericana, Editores S.A. de C.V., Agosto 2001, pginas 4-23. 2.- Introduccin a la Computacin, Peter Norton, McGraw-Hill Interamericana, Tercera Edicin,Marzo 2001, pginas 402-431.